WordPress and HTTP/2 — What Developers Need to Know?

Front-End Development Pain Points#

If you read my previous post about Advanced Gulp Workflow for WordPress, chances are you already know a lot about the pain points of front-end development. So, instead of explaining what they are, let’s shift our focus towards HTTP/2 in this post.

If you’re still reading this post, it means you have an above average interest in how the internet works, while you’re at it take a look at super cute web comics about How DNS Works by good folks at @DNSimple.

So, let’s begin with the front-end development pain points, shall we.

• Minification: Removing all unnecessary characters from source code without changing its functionality.
• Spriting: Taking multiple images and combining them into one, and using CSS to show only a part of the final sprite image
• Concatenation: Creating one large CSS or JS file by combining multiple small CSS/JS files
• Sharding: Hosting assets (E.g. Images, JS, CSS, etc.) on a different domain or on a sub-domain

So, what’s the deal?

HTTP 1.1 was standardized in 1997. While it did a good job, it is no more efficient and to top it off, it was designed 16 years ago. Just like the desktop you had in 1997, this protocol was not designed to deal with today’s internet. It was designed before we even knew what the world wide web would become. So, to get it working in this age, we had to improvise hacks that could help make our websites fast and more optimized.

Why We Needed These Hacks?#

Let’s review why we needed these performance techniques in the first place.

• Spriting & Concatenating: To avoid multiple HTTP requests. You should know that an HTTP v1.1 request is very costly, it is not compressed, loaded down with cookies it is faster to fetch single large files instead of requesting multiple smaller ones
• Sharding: Well, cookies if set, they are always sent with an HTTP request in HTTP v1.1. While assets like images don’t need ’em, it adds up to a lot of wasted space. So, it only made sense to serve assets from a different domain or a cookie-less sub-domain
• Two Simultaneous HTTP Requests: In HTTP v1.1 browsers allow(ed) only two simultaneous HTTP requests which, of course, doubles if we serve assets from another domain, hence increasing the page speed.

Why HTTP/2#

HTTP/2 is efficient and fast. HTTP/2 is almost here. The fun fact is that your browser most probably is already using HTTP/2.

I ain’t no expert on this topic, which is why I won’t go into details, though, as James Spader would say in Boston Legal —”I know enough to be dangerous”.

If, like me, you develop WordPress themes, then here is what you really need to know. Hacks and performance fixes which we had for HTTP 1.1 will actually slow down your theme’s page loading speed in HTTP/2.

How?

Why?

What?

Well, let’s see what makes HTTP/2 so much better when compared with the 16 years older version.

Advantages of HTTP/2#

• HTTP/2 requests are significantly smaller in size because it uses compression and thus makes them faster and less costly
• HTTP/2 uses multiplexers; which allow it to send and receive multiple files at the same time
• HTTP/2 allows the server to “push” content, that is, to respond with data for more queries than the client requested. This allows the server to supply data it knows a web browser will need to render a web page, without waiting for the browser to examine the first response, and without the overhead of an additional request cycle
• HTTP/2 can leave the connection open for reuse — no more time wasted for handshakes
• HTTP/2 leaves most of HTTP 1.1’s high-level syntaxes, such as methods, status codes, header fields, and URIs, the same. The element that is modified is how the data is framed and transported between the client and the server

What Can YOU Be Doing Wrong?#

In context of HTTP/2 being rapidly accepted by browsers here’s what you could be doing wrong in an ideal world with browsers, hosts and CDNs serving sites over  HTTP/2

• Loading one large CSS/JS file will be less efficient than loading smaller files separately
• You should loading CSS/JS files only when needed since loading assets which are not required for current page will only slow down the page speed (Concatenation and spriting are likely to do this)
• Sharding leads to more DNS lookups which are already a bad practice, but with HTTP/2 I’d strongly advise against it

If you are developing a site which you know is going to be served over HTTP/2 then don’t use any of these legacy performance hacks.

I Want a Demo?#

Here’s the mini-cherry on top of the regular cherry on top of the sundae of awesomeness i.e. HTTP/2 — A few demos and implementations of HTTP/2

• Demo at Akamai
• CDN77 Demonstration of HTTP/2
• Implementations at Github for HTTP/2

Which Browser Support HTTP/2

• Chrome supports HTTP/2 by default (verified as of version 41 using Akamai’s HTTP/2 browser support detector)
• Firefox supports HTTP/2 which has been enabled by default since version 36
• Internet Explorer supports HTTP/2 in version 11, but only for Windows 10, and is enabled by default
• Opera supports HTTP/2 by default (verified as of version 28 using Akamai’s HTTP/2 browser support detector)
• Safari 9 supports HTTP/2 (OS X and iOS)

HTTP/2 Support for HTTP/HTTPS Servers

• IIS supports HTTP/2 in Windows 10
• OpenLiteSpeed 1.3.11 and 1.4.8 support HTTP/2
• LiteSpeed Web Server 5.0 support HTTP/2
• CDN77 – Content Delivery Network support HTTP/2
• Apache 2.4.12 supports HTTP/2 via the module mod_h2
• Nginx provides experimental support for HTTP/2

There’s an excellent write-up by Daniel Stenberg going into much more detail available as a PDF.

What Is Your Take on This?#