Menu Search
Jump to the content X X

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book now →

Getting Ready For HTTP/2: A Guide For Web Designers And Developers

The Hypertext Transfer Protocol (HTTP) is the protocol that governs the connection between your server and the browsers of your website’s visitors. For the first time since 1999, we have a new version of this protocol, and it promises far faster websites for everyone.

In this article, we’ll look at the basics of HTTP/2 as they apply to web designers and developers. I’ll explain some of the key features of the new protocol, look at browser and server compatibility, and detail the things you might need to think about as we see more adoption of HTTP/2. By reading this article, you will get an overview of what to consider changing in your workflow in the short and long term. I’ll also include plenty of resources if you want to dig further into the issues raised. My aim is to give you enough of the background to be able to make good decisions as you plan your move to HTTP/2.

A Brief History Of HTTP Link

HTTP is an old protocol, initially defined in 19911, with the last major revision — HTTP/1.12 — published in 1999. Websites in 1999 were very different to the websites we develop today. In http2 explained273, Daniel Sternberg notes that the amount of data now required to load the home page of an average website is 1.9 MB, with over 100 individual resources required to display a page — a “resource” being anything from an image or a font to a JavaScript or CSS file.

HTTP/1.1 does not perform well when retrieving the large number of resources required to display a modern website. As we’ll see later in this article, many of the performance best practices we know as web developers come from our coping with the limitations of HTTP/1.1.

SPDY Link

In 2009, two engineers at Google posted about a research project they had been working on named SPDY4. This project addressed some of the issues in HTTP/1.1. SPDY set out to:

  • allow concurrent requests across a single TCP connection, known as multiplexing;
  • allow browsers to prioritize assets so that resources vital to the display of a page could be sent by the server first;
  • compress and reduce HTTP headers;
  • implement server push, whereby a server can push vital resources to the browser before being asked for them.

In addition, SPDY requires an encrypted (HTTPS) connection between the browser and server.

SPDY doesn’t replace HTTP; rather, it’s a tunnel for the protocol and modifies the way existing HTTP requests and responses are sent. It requires support from both the server and the browser connecting to that server. With support available in NGINX and packages available from Google to enable support in Apache, there was a reasonable amount of adoption of SPDY. Browser support is pretty good, too, with modern versions of all major browsers5 supporting it.

SPDY browser support information on Can I Use6
SPDY browser support information on Can I Use. (View large version7)

HTTP/2 Link

We’ve seen SPDY enjoy some success, gaining adoption with both servers and browsers. However, you might also have spotted that, despite Internet Explorer 11 being supported, Microsoft’s Edge browser has dropped it. What’s happening here?

Support for SPDY has been dropped in Edge due to Microsoft implementing support for HTTP/2, the latest version of the HTTP protocol. While other current browsers still maintain support for SPDY, Chrome will remove support in 2016, and other browsers will likely follow. At the time of writing, Edge, Firefox, Chrome and Opera support both SPDY and HTTP/2. Safari, including on iOS, will join that group later this year with the launch of Safari 9.

SPDY browser support information on Can I Use8
SPDY browser support information on Can I Use. (View large version9)

HTTP/2 builds on the success of SPDY, which was used as a starting point for the new protocol. As such, the majority of SPDY’s objectives are met in HTTP/210. The requirement for an HTTPS connection has been dropped11. That said, all of the browser vendors have decided to only implement HTTP/2 for TLS (https) connections. So while you could potentially use HTTP/2 with clear text in server to server communications, our use case of serving HTTP/2 to browsers means that you need to have your site running on https before you can even think of moving to HTTP/2.

The HTTP/2 specification was finalized in February 2015; a year on, browser support in modern browsers is excellent. As with SPDY, HTTP/2 requires support both on the browser and server level, and there are already many web server implementations. You can keep track of these on the HTTP/2 wiki12. W3Techs also has a post from July 2015 detailing adoption rates13. Adoption of this protocol is happening rapidly, considering how relatively new it is.

Will We Have To Change Our Websites? Link

HTTP/2 is backwards-compatible with HTTP/1.1, so it would be possible to ignore it completely and everything will continue to work as before. The protocol change is completely transparent to users. Many readers of this article will have been using a protocol other than HTTP/1.1 for years. If you have a Gmail account and use Chrome to access it you will have been using SPDY and then HTTP/2 without knowing anything about it.

However, many of the things you think of as being best practices can be detrimental to performance under HTTP/2. Over time, as more servers update to use HTTP/2 and more people have browsers that support HTTP/2, your website, at one time well optimized according to best practices, will start to seem slower than websites optimized for the new protocol.

What Do We Need To Change To Embrace HTTP/2? Link

In the rest of this article, we’ll look at some of the common best practices that will become anti-patterns as HTTP/2 is adopted. As we’ve seen, the transition will be a slow one for many websites. To move to HTTP/2, your server software will need to be updated to support the protocol — which may be easy or almost impossible depending on how you are being hosted.

Before making changes to your website specifically for HTTP/2, you’ll also need to consider whether your visitors tend to have browsers that support it. Owners of websites that attract a lot of people using very up-to-date browsers will be able to make that switch sooner than owners whose logs show a majority of users on older browsers. To reflect this, I’ll also give you some suggestions on how to work in this transition time.

Make the Move to TLS Link

For a lot of websites the hardest thing about moving to HTTP/2 may not be HTTP/2 at all, but instead the requirement to run the site over a secure connection. If you are developing a new site or updating an old one your first move should be to make sure that you launch on or move to https as soon as possible. This is important not just for HTTP/2, Google uses secure connections as a ranking signal14, and browsers are starting to flag non-https websites as ‘not secure’. In the future you will find that some powerful HTML5 features, such as geolocation, are unavilable without a secure connection15.

If you have a site that is currently http only then my suggestion would be to prioritize a move to https first and then decide on your HTTP/2 strategy.

Turning Multiple Image Files Into Sprites Link

In HTTP 1.1, retrieving one large image is much more efficient for the browser than making a lot of requests for small ones. This is because multiple requests queue up behind each other. To work around this, we have been advised to turn our little icons into a sprite file16.

The resulting sprite is returned with one HTTP request, preventing the problem of multiple requests being queued. However, even if the visitor is on a page that shows only one of those icons, they will still have to download a much larger file than they need to in order to see that one image.

With the multiplexing ability of HTTP/2, this queuing of resources is no longer an issue. Serving the small images individually will be better in many cases; you will only need to serve what is required for the page that the visitor is on. Creating a sprite will still be warranted in some cases; HTTP requests are only one aspect of performance. Combining some images together in a sprite might achieve better compression and, thus, a smaller download size overall, especially if all of those images are used on the page being loaded. However, it will no longer be the case that a sprite is always the best choice.

Inlining Images Using Data URIs Link

Another workaround for the problem of multiple HTTP requests in HTTP/1.1 is to inline images in CSS using data URIs17. Embedding images in this way will make a style sheet much larger. If you have combined this with another optimization technique for concatenating assets, then a visitor will likely download all of this code even if they never visit the pages where the images are being used.

With HTTP requests being very cheap in HTTP/2, this “best practice” will hinder rather than help performance.

Concatenating CSS And JavaScript Link

As the final step in our build process, many of us will concatenate all of the small CSS and JavaScript files used on our website. We often want to keep these separated while developing to make it easier to manage these resources — but we know that delivering one file to the browser is more efficient for performance than delivering five. Once again, we are trying to limit HTTP requests.

If you are doing this, then a visitor who lands on your home page might download all of the CSS and JavaScript required for your website, even if they never use most of it. As a developer, you can get around this problem by carefully selecting and including specific files for each area of the website in your build process, but that can be quite a lot of work.

An additional issue with concatenation is that everything will need to be purged from the cache at once. You can’t give some files that never change a long expiry date while giving often changing parts of the code base a shorter date. It all has to be expired if even one line of CSS, used on a single page, is changed.

I imagine you see where this is going! HTTP requests are cheap in the world of HTTP/2. Organizing your assets during development according to the pages on which they will be used will be far better. You can then serve up only the code that the visitor needs. Downloading a lot of tiny style sheets won’t matter. You could also organize based on how frequently things change; assets with longevity could then be cared for longer.

Splitting Resources Between Hosts: Sharding Link

With HTTP/1.1, you are restricted to the number of open connections. If loading a large number of resources is unavoidable, one method to get around this restriction is to retrieve them from multiple domains. This is known as domain sharding18. This can achieve better loading times, yet can cause problems itself19, not to mention the development overhead of preparing this for your website.

HTTP/2 removes this need for domain sharding because you can request as many resources as you need. In fact, this technique will likely hurt performance because it creates additional TCP connections and hinders HTTP/2 from prioritizing resources.

How To Prepare For HTTP/2 Now Link

If you are starting a project that you expect to have some longevity but cannot launch of HTTP/2 perhaps due to server support, it would be worth considering how you can prepare for HTTP/2. You could add a few things to your build process now that will make the switch easier later on.

Create Individual Assets in Addition to Sprites and Data URIs Link

If you are creating sprites, add to your process the creation and optimization of those individual assets as well, or smaller page-specific sprites if you feel performance would be best enhanced by these. This will make it easier for you to switch from big sprites to small (or no) sprites when the tipping point for your website is reached.

The same is true for data URIs. If you are currently using these in your CSS, have the images ready for when you switch away from this technique.

Organize Your Assets By Website Section Link

With CSS and JavaScript concatenation, there is a temptation to optimize for ease of development because the files will all get squashed together anyway. When you switch over to HTTP/2, you will get the best performance by carefully managing resources so that only the things needed by a certain page are delivered to that page. Therefore, starting to organize your development in this way now will pay off. For now, you may well still concatenate, and when the tipping point is reached, you can stop that part of your build process and serve the resources individually.

Manage Domain Sharding Link

The current best practice for HTTP/1.1 is to limit sharding to two host names. There is a way to get HTTP/2 to coalesce the connections, if the TLS certificate is valid for both hosts and the hosts resolve to the same IP. Since browser implementors require HTTP/2 to be running over HTTPS, it’s necessary to get the TLS certificate to run over HTTP/2. See more on slide 2620 of Ilya Grigorik’s slidedeck from the Velocity Conference.

Slide from Ilya Grigorik's presentation21
Slide from Ilya Grigorik’s presentation. (View large version22)

More To Come Link

Ultimately, we’ll get a whole slew of best practices for HTTP/2. For best performance, this protocol will hand a lot of control back to you, which means you will need to make decisions for each project. I haven’t covered in this article how to take advantage of new features of HTTP/2 such as server push. This technology allows you to decide which resources are a priority and instructs the server to hand those out before less important things.

When To Switch? Link

For designers and developers who do not have full control over the servers they deploy to, the decision may have to wait until the servers they use are updated. There are hosting companies ofering HTTP/2 already – even for shared hosting – so deploying to a supporting server is something you could recommend to a client if you know they would benefit.

Once your website is hosted on a server that supports HTTP/2, the decision of whether to continue optimizing for HTTP/1.1 or to optimize for HTTP/2 will come down to the protocol supported by the majority of your users. Remember that HTTP/2 is backwards-compatible — you don’t need to do anything specific. The decision you need to make is when to optimize for it.

You’ll need to decide according to your analytics data. If more visitors are using HTTP/2-supporting browsers than not, then I’d suggest that’s a reasonable tipping point for optimizing for those users. Many of us will already have reached that point23. You should use data from sites such as Can I Use along with data gathered from your own analytics and knowledge of your likely audience. For example, many of the benefits of HTTP/2 will be felt most keenly by users of HTTP/2 supporting mobile devices. If you have a high percentage of mobile traffic that might be an indication to move to HTTP/2 sooner. However, if you have a high percentage of mobile traffic from users who browse using Opera Mini then that would be a reason to hold off on the move to HTTP/2 as it currently does not have support while having a high number of users in some parts of the world.

If you are building a brand new website today, I’d suggest keeping HTTP/2 optimization in mind throughout your build. If at launch, you feel that you need to make concessions for HTTP/1.1 due to browser or server support, a lot of that can be done in the build process, allowing you to switch to the HTTP/2 version as soon as you feel the time is right.

Your HTTP/2 Action Plan Link

  1. Launch with a secure connection or make the move to TLS now
    This should be your priority.
  2. Prepare for HTTP/2 in your build process.
    Any website you build now would likely benefit from being optimized for HTTP/2 over its lifetime. Use the tips above to create a build process that can be optimized for both protocols.
  3. Check your statistics.
    By comparing browser usage on your website with the support table on Can I Use24, you can see what percentage of visitors would benefit from HTTP/2 optimization.
  4. Check your hosting.
    When you reach the point when you would benefit from switching, you will need to ensure that your server supports HTTP/2. Speak to your hosting provider or server administrator to find out their migration plan.
  5. Roll out HTTP/2 optimization.
    Once your server supports HTTP/2, the rest is up to you. Stop using the old best practices and switch to the new. This will mean that users with browsers that do not support HTTP/2 will get a slower experience, which is why the driver behind your change should be the tipping point when the majority would benefit.

When you do move to HTTP/2, it would be interesting to benchmark the speed increases and to see which techniques have made the biggest differences on your websites. I’m looking forward to seeing information from real-world cases as people migrate websites. That information will help us develop a whole new generation of best practices.

Find Out More Link

An increasing amount of information about HTTP/2 is available online. I’ve listed some resources here for your reference, many of which I referred to while writing this article.

(rb, jb, al, ml)

Footnotes Link

  1. 1 http://www.w3.org/Protocols/HTTP/AsImplemented.html
  2. 2 http://www.ietf.org/rfc/rfc2616.txt
  3. 3 http://daniel.haxx.se/http2/
  4. 4 http://googleresearch.blogspot.co.uk/2009/11/2x-faster-web.html
  5. 5 http://caniuse.com/#feat=spdy
  6. 6 https://www.smashingmagazine.com/wp-content/uploads/2016/01/01-caniuse-spdy-opt.png
  7. 7 https://www.smashingmagazine.com/wp-content/uploads/2016/01/01-caniuse-spdy-opt.png
  8. 8 https://www.smashingmagazine.com/wp-content/uploads/2016/01/02-caniuse-http2-opt.png
  9. 9 https://www.smashingmagazine.com/wp-content/uploads/2016/01/02-caniuse-http2-opt.png
  10. 10 https://http2.github.io/faq/#what-are-the-key-differences-to-http1x
  11. 11 https://http2.github.io/faq/#does-http2-require-encryption
  12. 12 https://github.com/http2/http2-spec/wiki/Implementations
  13. 13 http://w3techs.com/blog/entry/http2_adoption_is_still_low_at_0_4_but_growing_fast_thanks_to_litespeed
  14. 14 https://googlewebmastercentral.blogspot.co.uk/2014/08/https-as-ranking-signal.html
  15. 15 https://code.google.com/p/chromium/issues/detail?id=464874
  16. 16 https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/CSS_Image_Sprites
  17. 17 https://css-tricks.com/data-uris/
  18. 18 http://www.stevesouders.com/blog/2009/05/12/sharding-dominant-domains/
  19. 19 http://calendar.perfplanet.com/2013/reducing-domain-sharding/
  20. 20 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present#slide=id.g40fbe7d8c_076
  21. 21 https://www.smashingmagazine.com/wp-content/uploads/2016/01/03-domain-sharding-opt.png
  22. 22 https://www.smashingmagazine.com/wp-content/uploads/2016/01/03-domain-sharding-opt.png
  23. 23 http://caniuse.com/#feat=http2
  24. 24 http://caniuse.com/#feat=http2
  25. 25 https://httpwg.github.io/specs/rfc7540.html
  26. 26 https://http2.github.io/faq/
  27. 27 http://daniel.haxx.se/http2/
  28. 28 http://chimera.labs.oreilly.com/books/1230000000545
  29. 29 https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present#slide=id.p19
  30. 30 https://addons.mozilla.org/en-us/firefox/addon/spdy-indicator/
  31. 31 https://chrome.google.com/webstore/detail/http2-and-spdy-indicator/mpbpobfflnpcgagjijhmgnchggcjblin?hl=en
  32. 32 https://pinboard.in/u:rmurphey/t:http2/

↑ Back to top Tweet itShare on Facebook

Advertisement

Rachel Andrew is a web developer, writer and speaker and one of the people behind the content management system, Perch. She is the author of a number of books including The Profitable Side Project Handbook. She writes about business and technology on her own site at rachelandrew.co.uk.

  1. 1

    If you run a website on Amazon Web Services and use an Elastic Load Balancer (ELB) then unfortunately http/2 isn’t yet a option. I expect Amazon will release a upgrade soon but it’s worth mentioning the problem as it stands at the time this article was written.

    4
    • 2

      Daniel Friesen

      February 25, 2016 9:27 am

      True. At least if you want this to be easy or absolutely want to terminate your HTTPS at ELB.

      If you’re willing to do some extra configuration on the set of backends that ELB connects to; you can setup the HTTPS certificates on the backends, use TLS load balancing on ELB, and enable the ProxyProtocol option so the IP is preserved (at least a few of the HTTP/2 supporting servers, including nginx and h2o, support proxy protocol).

      0
  2. 3

    It’s a good moment to point out for those that don’t already know, that https://letsencrypt.org/ provides free, automated SSL certificates. That ticks the first step off the list.

    21
  3. 4

    Nice article Rachel,

    You can use HTTP/2 and HTTP 1.1 as a backup for older browsers, I’ve managed to use some of the old practices to work with the HTTP/2 like compressing CSS and JS files into one larger file each is better in many ways than using 5 or more static files inside and before . Also, minifing those files will decrease the compressed file size.

    0
  4. 5

    M.Nadeem Aslam

    February 16, 2016 6:41 pm

    This was a great article! I should keep this in mind now when working on a new project. Thank you for the information!

    2
  5. 6

    Great write-up, Rachel. The order of preparation, along with the checklist, was very helpful.

    I recently made the switch to TLS for my entire site, but like Tom, am also waiting for my server provider, WP Engine, to support HTTP/2.

    It’s good to know I’ve got a good base setup for when the time comes.

    2
    • 7

      Andrew Douglass

      February 17, 2016 7:30 pm

      WP Engine does support HTTP/2! Get on it. I just went through and did a bunch of the things here, and it made a significant difference.

      0
  6. 8

    Scott Richardson

    February 16, 2016 10:40 pm

    It took a while to find it in this article, but the crux of the story is you actually have to do ‘nothing’ to your websites to implement HTTP/2 – no added code/tags or changes to your markup, per se. Just stop making optimisation concessions based around the current limitations of HTTP/1, and update your web server to support HTTP/2 at the server-level. Thanks for the info!

    7
    • 9

      Brendan Parsons

      February 17, 2016 8:41 am

      I came to the same conclusion too, Scott. Throughout the read I was thinking, “Ok, I wonder what I have to do to switch over.” Except for SSL cert..nothing, except change optimisation techniques :) I enquired to my host about http/2 and it’s already supported, yes!

      1
  7. 10

    It’s worth pointing out more clearly that moving to HTTP/2 while continuing the present HTTP/1.1 optimisations will leave you no worse off than now (and in fact better).

    So you don’t need to wait to move to HTTP/2 – once your server and/or provider supports it of course. You just need to wait, to STOP optimising for HTTP/1.1 as its no longer necessary under HTTP/2 and has downsides.

    Also those same downsides have always been present in HTTP/1.1 too – it’s just they are outweighed by the upsides there, but no longer are in HTTP/2.

    One slight word of warning is that gzip compression works better with larger files so you do need to be somewhat realistic and don’t switch to hundred of thousands of resources just for the sake of it.

    And finally when you do switch off those HTTP/1.1 optimisations the website will still work for non-HTTP/2 browsers. Just will be slower, so again don’t be afraid to do this when the majority of your users can benefit (which is probably the case already to be honest).

    3
  8. 11

    It will be a lot more feasible when providers like Amazon AWS wake up and start supporting HTTP/2 on their load balancers. We can talk fancy features all day but until the load balaners speak it, it’ll be confined to the lab…

    0
    • 12

      This is one of the main reasons I moved my sites across to CloudFlare. They not only provide Flexible SSL (for free) but also use SPDY so that you can take advantage of all the http2 goodness right now.

      0
  9. 13

    Very well written article. Covered everything from A-Z about HTTP/2

    -5
  10. 14

    I was wondering about Google ranking Https higher then other sites that do not use this.
    My site uses it when you login or on shopping cart pages but not on the front page and others. I didn’t build it, so it is just made like that.
    Should it be changed so every page including the front page is Https?

    0
  11. 15

    A lot of people jump the gun on HTTP/2. As you mention in your article, there are steps you need to take to properly utilize it. And it’s strange that those who are utilizing/supporting it – Google, Facebook, etc. – still have “anti-patterns” implemented: https://medium.com/@jdorfman/are-we-ready-for-http-2-cc174f994827#.7zcje5o8h

    1
  12. 16

    A nifty online tool to check if a website is HTTP/2 ready:
    https://tools.keycdn.com/http2-test

    0
  13. 17

    Thanks Rachel. This helps. However I have some questions in my mind, if you can help me.

    1) If my application(web page at browser) and mobile app, are getting content from CDN, do I have to make any specific changes in the code?
    2) From browser/app to origin servers, do I need to make any specific changes in code or at products like Sitecore etc(configurations etc)?

    0
  14. 18

    Lisa Manell

    May 12, 2016 2:54 pm

    Thanks for a great article! I guess HTTP/2 will also revolutionize the server software side. Alternatives like Caddy, ShimmerCat, etc are already making stuff a lot easier for web developers

    1

↑ Back to top