Speed up homepage load

[PeterJCLaw]

At the moment the homepage takes around 17-20s (DOMConetentLoaded in 2-3s) to fully load over a simulated (using Chrome's dev tools) "Good 3G" connection (without caching). This compares fairly badly to the previous site's 2-3s (DOMConetentLoaded in < 1s).

I think there are a number of causes to this, though a fuller investigation is warranted:

• We don't compress the served content (we used to support at least gzip)
• We don't signal to the browser to Keep-Alive the HTTP connection, which we used to (I'm not sure how this relates to HTTP/2, which we should also look at using)
• There's are a lot more content (both number of items and overall size) on the homepage now: 14 requests, 251KB vs 24 requests and 1.6MB.

TODO:

• GZIP SVG files as well Compress more things #65
• Remove redundant JS loading (i.e: replace our JS with CSS) Copy navigation toggle from docs #128 (thanks @as2247!)
• Avoid forcing extra SSL negotiations by using consistent domains Optimise user tracking JS #66
• Also shrink the blue logo Remove redundant image #67
• Ensure suitable cache headers are sent (my browsers do see some cache headers, but webpagetest claims we're doing it wrong)
• Either enable HTTP/2 or document why we can't

[jimmythompson]

Do you know how much of this is because the latest news post is a competition summary?

[rgilton]

Hey,

A better thing to consider is what speed is actually required!

Rather than just state "this is too slow", how about defining what is an acceptable load time (e.g. Which features of the site must be functional by a specific time), then implementing a test setup to ensure that this is actually met. This would be a far more productive activity.

On 11 September 2016 21:11:53 BST, PeterJCLaw [email protected] wrote:

At the moment the homepage takes around 17-20s (DOMConetentLoaded in
2-3s) to fully load over a simulated (using Chrome's dev tools) "Good
3G" connection (without caching). This compares fairly badly to the
previous site's 2-3s (DOMConetentLoaded in < 1s).

I think there are a number of causes to this, though a fuller
investigation is warranted:

• We don't compress the served content (we used to support at least
  gzip)
• We don't signal to the browser to Keep-Alive the HTTP connection,
  which we used to (I'm not sure how this relates to HTTP/2, which we
  should also look at using)
• There's are a lot more content (both number of items and overall
  size) on the homepage now: 14 requests, 251KB vs 24 requests and 1.6MB.

[PeterJCLaw]

Some of this is certainly due to the currently news story being the competition summary, though that is something which is going to be the case for ~4 months of the year, and those are the months of the year where new people are most able to actually join SR, so it's a fair comparison to be made.

I suspect that while we'll have more traffic during the other portions of the year, that traffic will be from people who already have an interest in us anyway.

From memory, the single biggest portion of the homepage is the top banner image, though the new fonts which are loaded aren't small either.

In terms of what "fast enough" means, I'm not sure. This is definitely something which falls into the "a fuller investigation is warranted" that I mentioned originally. It's worth noting however that while I've used a mobile connection to benchmark against, I started looking at this because of a combination of:

• noticing that we weren't GZIPing or Keep-Aliveing any more, and
• feeling that the page was taking longer to load

We should also compare the number of visitors we get on mobiles vs desktop before a decision is made about what "fast enough" means.

[PeterJCLaw]

Ok, so we're now several months later. I feel that sufficient time has now passed over which we should have the data on the number of users on the site. I've not looked at that myself, but it should be available in piwik.

For a starting point comparison I've run webpagetest against the old and new homepages using the default settings. The results are both remarkable and exactly what my gut reported in the first place:

• https://www.webpagetest.org/result/170208_VY_RM8A/ (old; loads in ~2s)
• https://www.webpagetest.org/result/170208_2P_RM8C/ (new; loads in ~5s)

It should not take 5s for a website's home page to load! 2s is hardly anything to be proud of either, but was a world better.

Here's a list of relatively quick wins:

• Ditch js/main.js and the jQuery it loads.
  This removes two JS files, one of which is huge, for an effect which can (essentially) be replicated in CSS. Frankly we don't even need the effect to be as fancy as it is and the page-load improvements will be worth it. Local testing suggests this removes ~0.3s off the localhost page-load time, so I expect it will be much better for people on actual mobile devices (which have both slower CPUs and network connections)
• Collapse all our CSS into a single file.
  Yes not all of it is actually ours, but at the moment we're forcing everyone to undergo 12 round-trips to a variety of hosts. At the very least we should only have one (not three) requests to Google's fonts api (Combine font css #61 combines the font CSS requests).
• Shrink our images.
  • The hero image is just under 5000px wide. In my opinion this is several times as big as it needs to be. The typical argument in favour of large images is for high-DPI screens, but this image is behind a blue overlay and a title, so that argument doesn't really hold. Shrink the homepage hero image for faster page loads #62 shrinks the hero image.
  • Running our larger images through tinypng offers some substantial reductions in size, see Run images through tinypng #64.
• Reduce the number of images.
  There are currently 7 images on the homepage, one of which is always redundant. We currently load two copies of the logo but only ever show one of them. Use styling to achieve a smaller image on mobile #63 uses styling to achieve the same effect.

In the longer term we really should be serving using HTTP/2 rather than HTTP/1.1. This is entirely doable now that we're serving plain files through nginx. Obviously the main advantage of HTTP/2 is really the server-push it enables and further work is needed to get to that, but even without that there should be some improvements just from using the more condensed protocol.
Nginx has supported HTTP/2 since 1.9.5 and we seem (inspected from the headers returned) to be using 1.11.9, so there really isn't much reason not to enable it. The only reason I can think of is that we need to support clients which don't support HTTP/2 and it's not possible to run with both protocols enabled at the same time. I've not checked either of those however.

[PeterJCLaw]

I've just done some very crude testing of the quick wins I created PRs for. Together they improve the (local) first-load time from ~1.30s to ~0.96s; with a hot cache it goes from ~0.95s to ~0.55s. If we see even remotely proportionally similar gains on the live site, this is already looking like a significant improvement.

[jimmythompson]

Cheers for doing all this Peter, I merged your stuff and deployed it, the results are here:

https://www.webpagetest.org/result/170209_ZD_129Z/

[PeterJCLaw]

Just spotted that we use a different image on the other pages (i.e: not the homepage), so we should apply the same trick CSS logo shrinking trick there.

It also occurred to me that we could use <link rel="preload" ...> to pre-fetch images (etc.) common to secondary pages for visitors of the homepage.

[PeterJCLaw]

Interesting, the speedups seem to be roughly in line with what my local benchmarks suggested (by proportion), though they aren't all coming in ways I'd expected them to.

[PeterJCLaw]

I've updated the description to include a TODO list. I suggest we work through that list and then close this ticket; further issues can be raised separately.

[PeterJCLaw]

Latest report: https://www.webpagetest.org/result/170209_GE_1VB9/ Interestingly it seems that the load times fluctuate more by report run than they do as a result of our changes.

[PeterJCLaw]

New report: https://www.webpagetest.org/result/181215_FM_13JZ/

[PeterJCLaw]

Report on 3G based in London: https://www.webpagetest.org/result/181215_57_812c687ef1dcbae60291f02b2827a0e3/

[PeterJCLaw]

Update: since the move to Mythic Beasts we are indeed now serving with HTTP/2

[PeterJCLaw]

Some new runs:

• https://www.webpagetest.org/result/220305_AiDcX3_8WS/
• https://www.webpagetest.org/result/220305_AiDc2E_8WX/
• https://www.webpagetest.org/result/220305_AiDcDG_8X7/