Details and metrics that highlight R4MP improvements.

[szczz]

The initial implementation of #42 is complete (#50), but I need metrics and details for each of the sections before I can complete the PR. I'm hoping that we can use this discussion to come up with the key points we want to highlight. We have 3 sections to fill out.

Enhanced Interface

Developer Friendly

Faster Than Ever

Here's a basic idea of what I was thinking but it shouldn't be limited to stock images. I'm also hoping for creative ideas on how we can demonstrate improved performance metrics.

[james-rae]

Performance may be a bit of a tricky/sore spot. The initial "Faster than Ever" claim on the o.g. marketing site was a bit of a hot take / fervent hope.

Some things have changed drastically between how Ramp2 and Ramp4 are built & bundled.

The RAMP2 built library is 3.5 MB, while RAMP4 is 10 MB 🍭 🤡 👍

• RAMP2 will download the ESRI libraries it needs dynamically at runtime, while RAMP4 bundles them.
• RAMP2 will also generally download jQuery on a separate script, RAMP4 does not have jQuery.

So while RAMP4 has less web requests (everything is downloaded in a single fetch), the RAMP2 chrome will appear and display the spinner while other stuff is downloading. The last time I timed it, RAMP2 was faster, or had the appearance of being faster, by around a second.

Prior to migrating to using Vite as the build tool, RAMP4 was a chunked build. See ramp4-pcar4/ramp4-pcar4#985. This was much faster in terms of perceived responsiveness (things would download as needed), but our "build" was a massive collection of webpack js files instead of one neat and tidy ramp.js.

There could be analysis done comparing all relative library sizes (e.g. vue 3 vs angular 1, esri 3 vs esri 4, npm package imports after tree shaking), but this will probably a true chore (something to add to the list of punishments, perhaps).

Runtime performance is typically a function of internet & server response times, but would be interested to see if there is any significant difference. I do know ESRI's v4 Feature Layer engine is supposed to be more intelligent in how it makes requests, but to be honest whenever I inspect it appears greedy if anything (heh more server hits === more esri licenses 🧠)

[szczz]

Sounds like we need to put our marketing caps on and spin this in our favour.

Perhaps instead of "Faster than ever" we have "New and improved" or something along those lines. In this section we can highlight the reduction in web requests, shift to a more modern web framework, and find a metric that suggests improved performance as we're less dependent on server response times?

[james-rae]

One reasonable test would be to make two identical sites and compare the total downlaod (easy enough to see in the network tab of the browser). I've looked for any existing samples but there is always some difference (RAMP2 prod sites usually have WET, RAMP4 analogs don't, or different layers being used).
Suggest a site with no layers, same basemap, same map size (meaning same number of tiles), no WET. Run in private browser to avoid cache gains. This should capture the full library weight.

🤔 if only there was a student who is currently making samples in both R2 and R4 at the moment 🤔

[szczz]

We're going to proceed with benchmarking RAMP 4 against RAMP 3 to get some data.

So far we've decided to do performance testing on Storylines with both R3 and R4. We'll also create sites with no layers, no WET, same basemap, and same map size for a fair comparison. Please suggest more ideas as they come.

Once we have these metrics we'll display them with Highcharts or other royalty-free images.

[james-rae]

Some artwork, gratis.