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

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.

WP REST APIWhile 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



Many WordPress sites use a CDN or a cloud-based object storage system interchangeably. In this setup, the main domain of 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,, 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.

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

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 (, 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.
  1. KeyCDN offers free SSL support with LetsEncrypt built in. I actually switched from MaxCDN to KeyCDN and find their prices much more favorable with the same or better speed/performance gains, not to mention the free of charge SSL support with LetsEncrypt.

    Thanks, appreciate the article. Good read!

  2. Great to see more web performance based article! It is very true that HTTP/2 and HTTPs are the future. Secure web is happening and people need to jump on board.

    Also, you might not be aware but there are CDN providers that already have Let’s Encrypt integrations. See list here:

  3. This will be a big change from the content delivery networks.
    Right now I can think of only a handful that support HTTP/2 CloudFlair is obviously one of them. CasheFly SAAS is one and EdgeCast ADN are the only ones that come to mind Fastly will have it in 1-2 months. As will incapsula I know Sucuri’s CloudProxy & Armors WAF can run HTTP/2
    I would be interested in hearing the names of some others that combined DDOS protection with HTTP/2

    I have to say though if you want to be completely protected against DDOS Armor & Incapsula & CloudProxy are The most secure options.

    I think the addition of PHP 7 and technology like HHVM

    it’s my opinion we are in for a much faster Internet experience on WordPress.

    I think it is unfortunate that most high-end CDNs charge so much for he ability to run your own SSL certificate because you cannot use your own host name.

    A good example would be if you wanted to AWS. Cloud front with a EV cert. You are out of luck unless you want to spend $600 a month just for the honor of running the certificate. SAN or shared SSLs used by the content delivery networks will work if you don’t mind the hostname becoming part of your link structure

    The use of IPv6 is doing a lot too fix the IP problem on the reason for the high cost of dedicated SSL in CDNs

    it’s a shame that shared certificates will not work on content delivery network will not work with for EV certs e.g e-commerce .

  4. CloudFlare is the first CDN to be green all the way across the board on Ilya Grigorik’s “Is TLS Fast Yet?” board, with support for session identifiers, session tickets, OCSP stapling, dynamic record sizing, ALPN, forward secrecy, and HTTP/2.


  5. I totally agree, http/2 will drive the adoption of all SSL for WordPress sites. I think it’s already heading in that direction. We are starting to see web hosts like StackPress enabling http/2 and Let’s Encrypt for all their users.

Leave a Comment

Finely crafted websites & tools that make the web better.