How HTTP/2 could work for SEOs
Have you heard the buzz around HTTP/2? It’s been coming out of the woodwork in the last few months and last week, UnGagged speaker Tom Anthony published a really useful overview of what HTTP/2 could mean for SEOs.
If you haven’t been keeping tabs, HTTP/2 started out life as a Google research project. The intention was to address the latency issues inherent in the way that browsers request website data from servers. Annoyingly, data can’t travel faster than the speed of light (bummer) and so the distance between the request and the server can cause delays for the user. HTTP/2 (which was known as SPDY while it was still a Google research project) addresses this issue.
How? Through multiplexing. With HTTP/2, multiple browser requests can share the same connection to the server. This prevents data requests from stacking up (the way they do with HTTP/1.1) which will in turn speed up your site load-times. Amazing!
That’s great, but how does HTTP/2 affect SEO?
It all comes down to site speed. We know that site speed is one of the many factors that Google considers when it calculates the rankings. So anything that helps improve your site speed could also have a positive impact on your SERPs.
As Tom mentioned in his blog post, using HTTP/2 demonstrates to Google that you’re trying to speed up the experience for users when they visit your site. Chrome supports HTTP/2, which means that usage data is already being factored into measuring site speed as a ranking factor. Shifting to HTTP/2 can shave up to 2.5 seconds off your load time and that’s something that Google definitely won’t ignore.
Google’s Gary Iylles and John Mueller have both said that Googlebot isn’t crawling HTTP/2 but that it doesn’t actually matter. In this instance, it’s not Googlebot we’re trying to impress. In Tom’s words: “Googlebot won’t benefit, but Google will notice.”
Ok, so what’s the catch with HTTP/2?
Well so far, there doesn’t seem to be one. I know that’s going to be tough for the SEO industry to accept, because we prove our salt by being critical and untrusting of everything. But it’s true. There’s no migration required for HTTP/2 because the server does all the work, responses are the same format, status codes are the same, and servers will default to HTTP/1.1 if necessary.
The only caveat is that you need to be careful if you’re going to be implementing server push. If it’s not done correctly, users will be given files their browser has already cached when they move from page to page within your site. It could slow down the user experience and undo any good that HTTP/2 could be doing.
So yes, HTTP/2 needs to be implemented properly, and requires collaboration with whoever looks after your servers. If you have a CDN, you’re in luck because they can do all the work for you, and as CDN’s already reduce some of the latency, HTTP/2 is going to double your results with very little effort. But even if you don’t have a CDN, there’s little to no dev work involved to get HTTP/2 up and running.
As long as your site has already been migrated to HTTPS, there is no reason to delay rolling out HTTP/2. If you’re still on HTTP, this is yet another reason why you should be getting your site moved over – HTTP/2 won’t function on non-secured sites, and you do not want to miss out on these site speed benefits.