HTTP/2 was finalized by the IETF earlier this year. This update to the HTTP protocol is the first major update in 16 years, since HTTP/1.1 was adopted in 1999. HTTP/2 promises faster websites by reducing latency through various innovations. Additionally, all major browser vendors have announced intentions to support HTTP/2 over TLS/SSL only, meaning that HTTP/2 brings with it an era of HTTPS only websites. For a deeper dive into HTTP/2, highly recommend the chapter on HTTP/2 in High Performance Browser Networking.
For the WordPress 4.4 release cycle, Scott Taylor has asked Eric Andrew Lewis and I to investigate what, if anything, WordPress can do to make HTTP/2 integration seamless. We want to get this discussion started with some initial thoughts and an invitation to brainstorm in a dev chat next week.
HTTP/2 has been developed to just work with existing websites, suggesting that there is nothing in particular that we need to do to make WordPress compatible with HTTP/2; however, for all intents and purposes, HTTPS is required for HTTP/2 to work in browsers. One area of focus for making it easier to deploy WordPress with HTTP/2 is to focus on tickets related to TLS/SSL issues. John Blackbourn has graciously compiled a list of tickets that could use attention:
In addition to focusing on these tickets, Eric and I have started working on more documentation for setting up TLS/SSL for WordPress, which will naturally lend itself to guides on HTTP/2 deployments for WordPress.
As for HTTP/2 and WordPress, we fortunately do not need to anything to make it work and existing web apps are already compatible. If we chose to, we can try to optimize WordPress for HTTP/2. These optimizations could manifest as optional theme support for HTTP/2 (i.e., add_theme_support() value) or using a constant to unlock HTTP/2 optimizations. We could add support for critical rendering path CSS that would allow WordPress to use server push to quickly deliver the assets to the browser. Additionally, we could consider building default themes with non-concatenated JS files to optimize delivery for HTTP/2 (we’d still ship the concatenated version for HTTP/1.1 deployments). These are merely early thoughts on what we might be able to do and we are hoping to gather feedback and ideas here and during the dev chat.
For those interested, Eric and I set up a test bed for HTTP/2 and WordPress. We have two sites set up, one with HTTP/1.1 and one with HTTP/2. Currently, they are running the exact same code base (with Twenty Sixteen!) and only differ in the protocol that is used. We intend to experiment with ideas on this setup. The repo is on Github and we plan to make more setup information available soon.
To kick things off, we will have a meeting on September 10 at 20:00 UTC in the #core room on slack.