LAUNCH Pantheon Announces New Levels of Automation with Autopilot Get Access

Why HTTPS Deployments Need a CDN

There are many reasons to deploy HTTPS to a website: search engine ranking, avoiding browser warnings, and (of course) the security of your users. Yet, performance remains a priority for SEO and user engagement. Achieving both requires using a CDN; deploying HTTPS without a CDN is slow.


TLS (the foundation of HTTPS) has been fast for years. But, even with TLS 1.3 (or TLS 1.2 with false start), a new client needs at least two round trips to the point of TLS termination to start loading a page:


Even if we assume that the processing time on each side is zero (which is beyond optimistic), you can plug any site into a distributed ping tool and double the numbers to get a best-case scenario. The doubled ping time represents the minimum time to first byte (TTFB) with TLS based on that network path. Everything else (HTML, media assets, CSS, Javascript, etc.) waits on that. While TTFB isn’t everything, it’s still a tax on starting the real work of loading a page and appears to be Google’s PageRank signal for performance.

Deploying HTTPS with a CDN fixes this problem by reducing the distance and network hops between the client and the point of TLS termination. And, because web pages aren’t just HTML—they have loads of other assets too—and all elements on the page have to be HTTPS to avoid mixed content warnings, the round-trip time to the point of TLS termination stacks on top of the time to load the page.

So, let’s do the math. Let’s consider a site with TLS terminated only in Chicago. Let’s say someone is loading the site from San Francisco. Let’s also assume the page has 35 additional assets (CSS, JS, etc.) and the client runs six simultaneous connections (what Chrome uses for HTTP/1.1). If TLS negotiation is instantaneous at each end, bandwidth is infinite, and the server returns all content instantly then we still have nearly 400ms before the page will render. It will be much worse under realistic conditions.

Here’s how the calculation works in detail:

  1. Divide the number of requests (including the page itself) by the number of connections. In this case, we have 35 assets plus the HTML page divided by six connections. So, each connection handles six requests.

  2. Connections happen in parallel, so we can use the time for one connection as the total time.

  3. Each connection requires one round trip (RT) to negotiate TLS.

  4. Each connection requires one RT for each request.

So, we get 56ms/RT ✕ (1 TLS RT + 6 Request RTs) = 392ms. For Europe, we get about 700ms. For Australia, we get 1554ms, already well on the way to problems before accounting for any other overhead.

If we look at ping times around the world, the round trip times (RTT) often exceed 100ms and can reach half a second:

Los Angeles
New York


POPing the Question: How Much Can a CDN Help?

If we deploy HTTPS on top of a CDN, we can “beat the speed of light” compared to a typical deployment with speed-of-light connections between the client and server.  Obviously, we can’t actually exceed the speed of light. Instead, we use fewer trips and shorter distances:

  • Round trip times to the host fall to <20ms because the browser connects to a local POP instead of the origin.

  • The POP uses a combination of HTTP/2 and TLS 1.3 (or TLS 1.2 with false start, which delivers similar performance). This cuts out multiple round trips. Once QUIC is added in (in a future update to Global CDN), yet another round trip will go away.

  • HTTP/2 push can turn requests that would be round trips into one-way trips from the server to the client. And, by keeping the client’s connection filled, even that one-way latency drops off as an relevant delay.

  • HTTP/2 allows clients to negotiation HTTPS only once (with the POP) and use the connection for all resources in parallel.

  • The CDN POPs maintain persistent connections to the origin, allowing them to skip multiple round trips (over a long distance) that would otherwise need to occur. So, even cache misses are faster than before.

The result, with some careful front-end performance tuning, is sub-second page loads from almost everywhere on every continent (well, except Antarctica and behind the Great Firewall).

WP enterprise  

Developer’s Guide to Frontend Performance
Learn how to ace an online speed test with Pantheon’s Global CDN in our comprehensive guide.


Origin HTTPS + CDN for Assets Isn’t Enough

Some providers build half solutions: HTTPS to origin for the main HTML page and URLs that route to a CDN (with the CDN’s own certificate) for the embedded assets. This speeds up delivery versus no CDN at all, but it falls short for two reasons: performance and security.

The downside for performance is requiring a round-trip to the origin for the main HTML page, even for anonymous visitors on frequently-viewed, cacheable pages. At best, this requires deploying a reverse proxy (like Varnish) at the origin—after HTTPS termination—so the backend doesn’t get overwhelmed with dynamic traffic. At worst, the site pays an 800ms tax on load times by visitors who are distant from the origin. Even HTTP/2 with push can’t overcome the need to wait on negotiating HTTPS with the origin.

This sort of half solution is also vulnerable to DDoS attacks, which will concentrate their traffic on the origin—an origin without the distributed mitigation of a CDN. A CDN can filter out attacks before they concentrate and overwhelm the origin. Just having assets like images on a CDN isn’t enough.


Efficiently delivering security and performance requires a full-site, HTTPS-enabled CDN. While there are many products that you can add in front of other platforms (or hosting providers) to get these benefits, Pantheon is the only one that includes it with every plan. Other providers bundle HTTPS for pages and a CDN for assets, but partial measures yield partial benefits.

You may also like: 

Topics Security, Speed & Performance, Website Technology

Let’s get in touch