Combining files, image sprites and serving images from extra domains were workarounds for HTTP/1.1. Over HTTP/2, which browsers only use on HTTPS, several of them now slow pages down. Check your host runs it, then retest.

A checklist written for another protocol

Open a website speed checklist from a few years ago and the same advice keeps appearing: combine your files, merge small images into one, and serve images from extra domains.

Each of those was good advice for HTTP/1.1, the protocol that browsers and servers used to talk to each other for most of the web's history.

The protocol has changed underneath them. HTTP/2, standardised in 2015, is supported by current versions of every major browser and by most good hosts.

Some of the old tricks now make no difference. A few make pages slower. Plenty of sites still run them, because nobody went back to check.

Why the old tricks existed

Under HTTP/1.1, a connection carries one request at a time. The browser asks for a file, waits for it to arrive, and only then asks for the next one on that connection.

To speed things up, browsers open several connections to each domain, usually about six. A page needing sixty files still queues them, six at a time.

Run a page like that through a speed test and the waterfall chart, which shows each file as a bar, looks like a staircase: groups of files waiting their turn.

Every trick on the old checklist was a way of shortening that staircase.

The tricks themselves

The third is the one that now does the most harm, because it works directly against the way the new protocol saves time.

What HTTP/2 changed

HTTP/2 lets one connection carry many requests at once. The browser asks for everything the page needs, and the files come back interleaved over the same connection.

The result is that requests are now cheap. Sixty small files over one connection no longer wait in groups of six, so the staircase flattens on its own.

Advice that now works against you

Domain sharding is the clearest case. Every extra domain needs its own lookup, its own connection and, on HTTPS, its own secure handshake before a single image arrives.

Under HTTP/1.1 that cost bought extra lanes. Under HTTP/2 the main connection already has all the lanes it needs, so the extra domains add waiting and nothing else.

One giant combined file has a quieter cost. Change one line in one script and every returning visitor downloads the whole bundle again, because the copy their browser saved no longer matches.

Sprites and inlined images share the problem: a visitor downloads the whole sheet of icons to see one, and an image written into the page cannot be reused by the next.

Why it only happens over HTTPS

The protocol itself allows HTTP/2 without encryption. Every major browser decided against it: Chrome, Firefox, Safari and Edge only use HTTP/2 on HTTPS connections.

So a site still on plain HTTP is on the old protocol, whatever its server supports. It gets the queue without the security.

Google announced this month that Chrome will mark every plain HTTP page Not secure from July. A move to HTTPS this spring is the moment to make sure HTTP/2 comes with it.

One catch: on some older servers, HTTP/2 is switched on but never used, because the encryption software underneath is too old to agree on it with current browsers.

A worked example

A marine electronics dealer sells chartplotters, radios and fish finders online, with category pages showing forty or fifty product photographs each.

In 2013 its developer followed the checklist of the day. Product images came from two extra subdomains, the icons were one sprite, and a plugin combined every script into one large file.

When the dealer moved to HTTPS this winter, the host enabled HTTP/2, and the pages were no faster. The waterfall showed why: the main domain used one connection, while each image subdomain waited for its own handshake.

The images moved back to the main domain, and the combined script was split into the few files each page actually used. Retested, the product photographs arrived together over one connection instead of in staggered groups.

Advice that has not expired

HTTP/2 removes the queue. It does nothing about the size of what is in it.

A home page carrying several megabytes of photographs is slow on any protocol, and an image saved four thousand pixels wide for a space four hundred wide is still a common problem on small business sites.

Checking what your site uses

In Chrome, open the developer tools, choose the Network tab and reload the page. Right-click the column headings and turn on Protocol.

A file marked h2 came over HTTP/2. One marked http/1.1 did not, and a mix usually means some files still come from an old image domain or a service that does not support it.

If every line on an HTTPS site reads http/1.1, ask your host why.

What a host should be running

HTTPS on every page, with a certificate that renews itself. HTTP/2 switched on, with encryption software recent enough for browsers to use it.

A current version of PHP 7 for anything built on WordPress, compression for text files, and caching instructions that let returning visitors reuse what they already downloaded.

None of this is exotic. A host that cannot offer it in 2018 is telling you how old its servers are.

The counter-case

Not every site gains much from this.

A brochure site of eight pages and twenty files was never badly hurt by the old queue, and the difference HTTP/2 makes to it is small.

Visitors on older office machines may see no difference either. Internet Explorer 11 only speaks HTTP/2 on Windows 10, so a Windows 7 desktop quietly falls back to the old protocol, and the site still works.

And a combining setting that tests faster on your own site should stay. Test rather than assume, in either direction.

For most sites, though, the order holds: HTTPS, then HTTP/2, then remove the tricks that fight it.

The order to do it in

  1. Move to HTTPS if you have not.
  2. Ask your host whether HTTP/2 is enabled.
  3. Check the Protocol column in Chrome.
  4. Retire extra image domains and serve from one.
  5. Test file combining both on and off.
  6. Shrink the images regardless of protocol.
  7. Retest the same pages afterwards.

Step four removes an actual delay rather than a theoretical one, because every extra domain costs a handshake that HTTP/2 was built to avoid.

The other upgrade most hosts are offering this year is covered in the PHP 7 upgrade your host keeps offering.

Frequently asked questions

What is HTTP/2, in plain terms?

The newer version of the protocol browsers and servers use to exchange pages. One connection can carry many requests at once, instead of one at a time.

Does HTTP/2 need HTTPS?

In practice, yes. Every major browser only uses HTTP/2 over an encrypted connection, so a site on plain HTTP stays on the old protocol whatever its server supports.

Which speed tricks have stopped helping?

Serving images from extra domains, merging icons into one sprite, and combining every file into one bundle. They were workarounds for a connection queue that HTTP/2 removes.

Why do extra image domains slow pages?

Each one needs its own lookup, connection and secure handshake. Under HTTP/2 the main connection already carries everything at once, so the extra domains add waiting and nothing else.

How do I check my site uses HTTP/2?

In Chrome's developer tools, open the Network tab, reload, and turn on the Protocol column. Files marked h2 arrived over HTTP/2; http/1.1 means they did not.

Does HTTP/2 fix a heavy home page?

No. It removes the queue, not the weight. Oversized photographs and scripts loaded on every page are just as slow, so shrinking images matters as much as it ever did.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

Still following a 2013 speed checklist?

Send us your address. We will check the protocol, the extra domains and what is actually slowing the page.

Start a Conversation