Find ways to improve performance of the frontend

[diox]

I did some measurements of the load time of the new frontend vs the legacy site. Since we have lost our access to speedcurve I used webpagetest.

I used "Dulles, VA - Firefox" in WebPageTest, with 3 runs (using median for results), first view only, cable connection, private. For the legacy site, I used their scripting capabilities to set the cookie, as setting through a custom header didn't seem to work. I think 3 runs is not enough to get a clear picture (need to eliminate outliers to get a more real median result) but it's a start.

Also, load time is not a great indicator, but it's something.

New Site (Taken on Jan 25, before the push):

• Homepage median load time: 5.2s
• Search results ("adblock") median load time: 4.8s
• Detail page (adblock-plus) median load time: 5s

Legacy Site:

• Homepage median load time: 3s
• Search results ("adblock") median load time: 2.5s
• Detail page (adblock-plus) median load time: 3.3s

Observations:

• New site is roughly 2 seconds slower.

• For the homepage, I used /, so we're losing a bit of time redirecting to /en-US/firefox/. But I think that's somewhat realistic, and happens both on the legacy and the new site.

• A lot of time is spent loading images, and on the homepage at least, we load better quality ones on the new site, causing us to load more data overall. We don't run developer uploaded images through lossless optimizers, and we probably should to help here.

• We also spend a lot of time loading fonts, but I'm not sure if there is something we can do here. It's hard to optimize fonts on a multilingual website where we don't fully control the text content.

• I haven't tested repeat views, so caching headers are not taken into consideration.

[diox]

Relevant issues that would help:

• Add Preconnect header for mozilla CDNs
• Run developer-uploaded images through pngcrush/optipng/jpegoptim

[muffinresearch]

@diox thanks for doing this it would appear that we may have gotten slower since launch. Would be interesting to see if we get any benefits from reducing the pre-compressed CSS size to approaching a quarter of what it was now that's shipped.

First load is a good metric to have and we should aim to get this down from where it is. However one positive side-effect of the that upfront load penalty is the faster subsequent navigation. Of course there is almost certainly some optimisations we can do here but we need to do them carefully.

We have an issues for investigating bundle splitting, but this is something that would be quite complex and we'd need to weigh up carefully - tackling the lower hanging fruit makes more sense first.

• Investigate JS bundle splitting https://github.com/mozilla/addons/issues/11076
• Investigate CSS bundle splitting https://github.com/mozilla/addons/issues/11077

That said if webpagetest scripting allowed it, it would also be interesting to track something that shows where we are at beyond the first load. So we can see the benefits of the client-side navigation with data requests.

What would be useful is to start graphing this in some way for -dev stage and prod and getting alerts on significant negative changes. Speedcurve did provide some features like that, I'm already expecting an update on where that's at and if we can get back on that it will likely provide the quickest way to get ongoing updates and historical data.

[diox]

Re-ran the tests on the new site today, so post-push. I increased the number of runs to 9 to get a more accurate median time (which I calculated myself, rounding the numbers - WPT seems to take the best run, not the median).

We can see improvements:

• Homepage median load time: 4.3s
• Search results ("adblock") median load time: 4.4s
• Detail page (adblock-plus) median load time: 5.1s

Some of the improvements is due to the smaller CSS (we only gain 30 KB because of gzip, but every bit counts, and I guess it also helps parsing), but also increasing the number of runs helped reduce variance between the runs, since there are some large differences between the runs: For the homepage for instance, some runs were below 3.6 seconds, some were above 5 seconds.

I've focused on initial load rather than using scripting to navigate because I was more interested in the low hanging fruits that don't carry any risk, but that's definitely an option.

[muffinresearch]

I've focused on initial load rather than using scripting to navigate because I was more interested in the low hanging fruits that don't carry any risk, but that's definitely an option.

Yep that's a fair point, the navigation one will definitely be something more of interest should we start looking into bundle splitting. Since doing that might optimise the initial load at the cost of slowing the subsequent navigations in some cases.

[kumar303]

Ugh. We should really start tracking performance regressions so we can get an idea of what changes are causing slowdowns.

[tofumatt]

I'm just adding to this that a new low-handing fruit is the code in mozilla/addons-server#4286. It makes our flow integration better at the expense of an easy-to-shave 16kB. Maybe even something in a build step could change things. Figured I'd just mention it here for now so it's on record 😄

Edit: As @kumar303 pointed out, if we implement mozilla/addons#2958 then it shouldn't be an issue.

[stephendonner]

@digitarald not sure if you've seen this yet

[kumar303]

It would be nice to automate this for regressions. I re-ran them today out of curiosity. It's quite a bit slower.

• Homepage median load time: 5.9s
• Search results ("adblock") median load time: 5.6s
• Detail page (adblock-plus) median load time: 6.4s

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. If you think this bug should stay open, please comment on the issue with further details. Thank you for your contributions.