The future of WordPress performance: CDNs, HTTP/2, and more

Vasken Hauri on January 5, 2016 • 5 Comments

It’s an exciting time in the WordPress community, with the release of Calypso, a successful inaugural WordCamp US, and WordPress now powering 25% of all websites. Maturation of the WordPress REST API is enabling the decoupling of the content management layer from the display layer, which has the potential to further drive adoption; larger teams can write independent code that communicates via the API, reducing blockers and accelerating feature releases. At the same time, the entire Web is poised to undergo a metamorphosis, as HTTP/2 begins to fundamentally change how content is delivered.

While these developments offer tremendous potential for those of us who work with WordPress for a living, I think there are some important considerations to keep in mind as WordPress and the Web move into a new era of maturity and possibility.

Using a CDN with DDoS protection is increasingly important

We recently started testing a CDN service that offers DDoS protection and mitigation for this site. While we hardly consider ourselves a high-profile target, the number of attacks reported by service is astonishing (more than a dozen every day, sometimes double or triple that). The majority are attempts to exploit known vulnerabilities in WordPress plugins (or other common web applications), such as those listed in the WP Vulnerability Database. Exploit mitigation (or at least, notification) at the CDN layer provider is compelling.

In addition to protection from known vulnerabilities, CDNs are vital to accommodating significant burst traffic, and eliminate the effort involved in hosting sites in multiple datacenter across the world. Instead of scaling your servers to manage exponential traffic as a story goes viral or an online catalog gets slammed on Cyber Monday, the work is offloaded to the CDN and its network of edge servers.

Of course, a CDN might not speed up your site–in fact, it can do just the opposite if you start serving up your site over HTTP/2 and you’re using “best practices” for optimizing your site for HTTP1.1.

The way that WordPress sites commonly use CDNs will need to evolve

Source: http://webdesignledger.com

Many WordPress sites use a CDN or a cloud-based object storage system interchangeably. In this setup, the main domain of example.com is served from the origin servers, and traditionally “static” assets (JavaScript, CSS) are served via a CDN using a subdomain (or even multiple subdomains, like a.example.com, b.example.com, and so on, in a process known as domain sharding). This approach maximizes the number of concurrent connections that a client browser will use to download the site’s assets, resulting in a performance boost even if the CDN isn’t inherently “faster” than the web servers.

Sometimes an object storage service like Amazon S3 is used in lieu of a CDN, which lightens the load on the web servers, saves disk, and offers the same concurrent connection advantage as a CDN. This advantage becomes a disadvantage when we add HTTP/2 into the mix.

With HTTP/2, a single TCP connection supports full multiplexing, meaning multiple resources can be concurrently delivered to the browser without the need for multiple subdomains. In fact, having multiple subdomains suddenly becomes bad for performance, as each new subdomain requires a new TCP connection, instead of using the connection that’s already open for the main domain.

A site configured to use a CDN provider for DNS and DDoS protection. Source: http://globaldots.com

On top of this, all current browser implementations of HTTP/2 require SSL/TLS, meaning WordPress needs to be configured to run over HTTPS. The good news is that HTTP/2 multiplexing in combination with the de facto HTTPS requirement, works quite well with a CDN (assuming your CDN provider offers HTTP/2, of course). Here’s where the configuration changes significantly: instead of sending requests for a subdomain to the CDN while maintaining a DNS record for the main site pointing to your web servers (or load balancer), all DNS can simply be routed through the CDN.

There are a couple of benefits: first, you can take advantage of the CDN to shorten DNS lookup times for your visitors, and second, since you don’t need to filter URLs for your static assets in WordPress, it’s a lot easier to set up (often just a matter of repointing DNS and activating the site in the CDN provider’s dashboard). Of course, if the CDN’s DNS service fails, your site will appear to be down, so choose your CDN provider carefully.

The major downside is that you will need to maintain SSL on the CDN itself. Historically, this type of service has been relatively pricey, and CDNs aren’t exactly cheap to begin with. As HTTP/2 grows in popularity, however, more CDN providers are offering more cost-effective ways to handle SSL termination, and with increased usage and competition, the prices are likely to drop even further.

SSL will become the standard for WordPress sites

While SSL in the WordPress dashboard is relatively well-established as a basic security measure, most sites continue to use HTTP for public facing content. HTTP/2 will be a major force in driving the transition to an all-SSL WordPress experience as the norm. It’s great to see the discussion on the Make WordPress Core blog concerning concrete steps to prepare for a much higher rate of SSL adoption.

Putting it all together

While mass adoption of HTTP/2 and SSL for WordPress will take some time and work, you can start taking concrete steps to prepare sites for optimal perform in the future. In summary:

1. Use a CDN that offers security and DDoS protection. This help you detect and prevent common exploits made against WordPress plugins and themes, and offers a nice performance benefit, especially for visitors far away from your servers.
2. Configure your sites to use the CDN’s DNS servers. This will not only give your visitors faster lookup times, but it will enable you to reduce the total number of TCP connections necessary once your site is using HTTP/2. In the meantime, you can still use domain sharding to maintain optimal performance using HTTP1.1.
3. Make sure your CDN provider supports HTTP/2. Since HTTP/2 requires SSL, you’ll want to also confirm that your CDN supports SSL (costs and options here can vary, so do your research!). SSL certificates can now be obtained for free (https://letsencrypt.org/), but many CDNs offer a reduced rate for using a SAN certificate (which enables them to use a single certificate for multiple domains); compare the cost of the cert with ongoing hosting costs through the CDN.
4. Make your plugins and themes SSL-ready. Once you’ve determined that your site functions properly over SSL (expect to cleanup of some hardcoded “http://” URLs, for one), you can make the switch to serving your site over HTTP/2.
5. Turn off domain sharding for static assets. At this point, you’ll need to decide whether to remove the sharded domains and use your CDN with a single domain (offering the best experience for HTTP/2 enabled browsers) or continue to offer multiple subdomains to ensure that legacy browsers do not experience degraded performance.