Migrating large sites to HTTP/2
Like in many things in IT, a simple task like can become a rather large undertaking when working with complex systems that have been in production use for years. There are often plenty of pitfalls and upgrading to HTTP/2 is the same.
With HTTP/2 upgrades of complex setups likely more issues will be caused by HTTPS upgrade, rather than HTTP/2 itself. You'll need to create a comprehensive testing plan and reserve plenty of time to do the switch and be prepared for a rollback to HTTP/1.1 if your efforts fail.
Don't rush it, even if your personal blog took just 15 minutes to upgrade...
Upgrading to HTTP/2 transport
HTTP/2 is designed to be a drop-in replacement for the 1.1 version. There are a lot of underlying improvements in the protocol and these are masked from firewalls and other network appliances using secure HTTP transport. When upgrading to HTTP/2 you'll need to upgrade to SSL at the same time, as browser only support secure communications.
There are countless ways on how a large sites' infrastructure is built. If your site is already using HTTPS for communications then adoption of HTTP/2 is well on the way. Complex setups might be positioned behind an SSL offloader or load balancer that might be hard to update / replace with a HTTP/2 compatible one.
When planning migrating a complex site to HTTP/2 its sensible to start working your way from the outside in. If your site is already running on HTTPS, then track down what is doing the SSL encryption and if it can be replaced by a HTTP/2 compliant system.
A common setup in use is Varnish with Nginx for SSL offloading and it's an easy case to upgrade as duties of the two applications are clearly defined. Introducing SSL to a non-secure Varnish setup is straightforward, read more about upgrading a site behind Varnish to HTTP/2.
If your existing HTTPS infrastructure is hard to upgrade to HTTP/2 compatible versions and you've recently made large investments in it, it might be worth simply taking a timeout and postpone upgrading to HTTP/2. It's not a dealbreaker.
Pitfalls of upgrading to HTTPS
If your site is not yet running on HTTPS, then you'll need to set it up. At best this is easy if your application environment supports it by default; Internally writing absolute URLs as https:// when encrypted, and so on.
This leads problems that are caused by the web’s security model, which is rooted in the same origin policy:
Code fromhttps://mybank.comshould only have access tohttps://mybank.com’s data, andhttps://evil.example.comshould certainly never be allowed access.
A media portal that has 5+ years of development behind it is likely to have a number of different sections built with different technologies. They have not had the incentive to serve with HTTPS before the arrival on HTTP/2 and many of these different applications likely have not been tested with HTTPS.
Make sure to check that all the third party widgets, polls and other tools that you use on your site support HTTPS. Sometimes the scripts loaded through HTTPS will try to load more scripts from unsecure locations, triggering errors like:
secure.js:167 Mixed Content: The page at 'https://example.com/' was loaded over HTTPS, but requested an insecure script.
Ideally all links should default to the current protocol (e.g. //anothersite.com) in links and references, but in practise there are often resources loaded with http, making visitors' browsers to trigger a warning.
Spotting all of these errors is a hard task. It's only made harder if users can register and make references by themselves, by providing a profile image URL, for example. This is a common problem and there are a few things you can do via Content Security Policy (CSP):
- Set the Content Security Policy to collect reports of mixed content with Content-Security-Policy-Report-Only
- Set the Content Security Policy to upgrade HTTP requests to HTTPS automatically upon request with Upgrade-Insecure-Requests
HTTPS SEO and HTTP/2 Performance anti-patterns
When upgrading to HTTPS it is important to remember that http://example.com and https://example.com sites are considered separate. Remember to create redirects, just as with any site move. Read more about SEO when moving from HTTP to HTTPS.
Also ever have different content in https://example.com/page1 and http://example.com/page1. Google, for example, now prefers HTTPS versions of websites:
As a natural continuation of this, today we'd like to announce that we're adjusting our indexing system to look for more HTTPS pages. Specifically, we’ll start crawling HTTPS equivalents of HTTP pages, even when the former are not linked to from any page.
In addition to base SEO things, make note that some performance optimisations like domain sharding have now become a hinderance to performance, not an advantage:
This is because current techniques used to decrease the number of asset files (e.g. CSS sprites and CSS concatenation) becomes a drag in page rendering speed in HTTP/2. Such techniques were beneficial in HTTP/1 since the protocol had difficulty in utilizing all the available bandwidth.
Read more about HTTP/2 optimisation and other things:
- HTTP/2 is here, let’s optimize!
- Architecting Websites For The HTTP/2 Era
- Do You Still Need Optimization After Migrating to HTTP/2?
- Performance improvements with HTTP/2 push and server-driven prioritization