HTTP/2 is already around since 2015. Heck, HTTP/3 even got standardized as of June 6th 2022. So why even bother talking about HTTP/1?
Well, I'm still seeing technical debt from HTTP/1. So let's dive in the anti-patterns I'm seeing when I'm doing pagespeed audits.
HTTP/1 history
HTTP/1 is around for a very long time. Even before I started with programming back in 2001. And although both HTTP/1 and HTTP/2 is around, HTTP/1 is still used by 40% of pages analyzed by HTTP Archive.
HTTP itself was unchanged for nearly two decades after HTTP/1.1 was introduced in 1997
The Web Almanac by HTTP Archive
Along the way, websites and webshops started to grow and started shipping more resources and libraries. As a result, the limitations of HTTP/1 became evident.
HTTP/1 limitation: amount of simultaneous downloads
With HTTP/1, a browser would only download 6 to 8 files at the same time, per domain. And when looking at public data, it's easy to see that webpages started to use more resources, hence running into the HTTP/1 limitation.
- On June 2011, the median amount of shipped requests on mobile devices was 28;
- On May 2015, just after HTTP/2 got introduced, this number grew to 55;
- Last month, June 2022, the median was 70.
Data and screenshot is coming from HTTP Archive reports.
Do note that the impact on user experience depends on how those resources are used, instead of how many is being used. But with the HTTP/1 limitations, there risk of impacting UX was quite high when not being familiar with how browsers work and how your work as a developer (or platform) could impact the user experience.
HTTP/2 fixing limitations
Addressing this download limitation was one of the goals of HTTP/2. But we had to wait until the end of 2015 for browsers to also adopt the new standard. So, other measures were needed to work around the limitations of HTTP/1.
HTTP/1 performance workarounds
With the HTTP/1 limitations in mind, it won't be difficult to think of workarounds: just use less resources or start using multiple domains. Or both.
Bundling JavaScript and CSS
Bundling your resources, such as JavaScript or CSS files, is one of the workarounds. But what if:
- your platform is responsible for creating a lot of individual files;
- or you're suffering from technical debt already before getting familiar with performance?
If you didn't want to sacrifice layout nor functionality or want to optimize the quick and dirty way, then there's only one solution: bundle all your resources.
But there's a big catch: the bigger a file becomes, the longer it could take to download. And when such resource is render blocking, it's actively hurting perceived loading experience and as a result user engagement.
Bundling is an anti-pattern in HTTP/2
In HTTP/2, this behaviour will end up impacting the download-time of other resources as well, because of the way HTTP/2 works. So, if your site isn't running on HTTP/2 anymore, you should be stepping away from obsessively bundling your resources.
Even better, try to keep framework, library and add-on resources codesplitted. Such as your framework file, and add-ons such as Bootstrap, Fancybox and FontAwesome. You could even codesplit CSS and JS per page template type. This would even prevent browsers from having to re-download all framework and library code during successive or repeated visits, even if you only made a change in your custom JavaScript.
Additionally, try to prevent the non-important resources from being render blocking, actually both in the case HTTP/1 as well as HTTP/2.
Domain sharding
The limitations of HTTP/1 also led to domain sharding: loading resources from multiple domains. And that makes sense: if the limitation is per domain, why not using multiple domains to load your resources?
As a matter of fact, one of the bigger Dutch webshops is still doing this today: bol.com. Bol.com is using the following subdomains for their own resources:
- www.bol.com
HTML pages such as contents of home, listing and product pages are served from their main domain. Favicon and other (touch) icons are also served from this domain, but browsers will download them in a later stage.
This domain is using the HTTP/1 protocol. - assets.s-bol.com
JavaScript, web font files and CSS is served by this subdomain. This domain actually is using the HTTP/2 protocol. - s.s-bol.com
This domain is used to load images that isn't related to product. So, in other words, images that were manually uploaded as part of content, such as banners or inline images.
This domain is using the HTTP/1 protocol. - media.s-bol.com
This domain will also serve images, but then images that goes with their products.
This domain actually is using the HTTP/2 protocol.
Bol.com is around for a very long time. They won a "best Dutch e-commerce" award back in 2002. HTTP/2 wasn't around yet. In other words: domain sharding was their best and future proof bet. Especially when now knowing that it would be around for at least another 13 years.
In their case, they would prevent an image download from being delayed when a browser was still stuck on style and script resources. So, while the browser was still downloading JS, CSS and font-files, the browser would simultaneously start to also download listing and product images.
Domain sharding drawbacks
Using multiple domains also means that the browsers needs to do multiple domain name lookups and TCP handshakes. But nowadays pagespeed challenges isn't only about the internet speed or amount of kilobytes that are being downloaded. Latency matters too.
Moreover and unlike HTTP/2, HTTP/1 won't use a connection that was already opened for a specific domain name. So when still using multiple domains to load resources while already running on HTTP/2, this now became a performance bottleneck.
This applies to your own created domain names, like bol.com deliberately did. But the drawback also applies to (public) CDN solutions to serve (public) libraries and frameworks. For example libraries like:
- jQuery, Angular, React or Vue libraries;
- Bootstrap JS + CSS;
- And addon's, such as Fancybox;
- Or icons and fonts, like Fontawesome.
You should've been self-hosting them already, which also applies to (Google) web fonts by the way. And once again: this especially is important when resources are in the head section of your HTML code. Or in other and more general terms: prevent serving resources from different domains when they are render blocking.
"But it's closer to my visitors"
It could be true that a CDN brings contents such as images closer to your visitor. But it will also involve an additionaly DNS lookup while an HTTP/2 connection to your domain is already open as well. You will have the potential to get more out of that connection, then setting up a new one.
In general, my advice is to only use yet another CDN or subdomain when it enables you and your shop to resize and compress images on the fly, for example.
HTTP/1 conclusion
HTTP/1 served us well up to 2015, and counting in case of the 40% remaining HTTP/1 users, maybe your site or webshop included. However, the best practices from the HTTP/1 era is more likely to come with anti-patterns and performance drawbacks in an HTTP/2 era.
So, whenever upgrading from HTTP/1 to HTTP/2 or maybe even HTTP/2, give your codebase and especially the way how resources are loaded, an extra thought as well.
Need help doing this, or still running on HTTP/1 and need a fresh pair of eyes? Do get in touch using my contact form.