Adding a CDN isn't "adding one more server" between you and the client, and it will still speed up uncached responses.
|
|
I think there's a performance myth out there that sites should not use a CDN (content delivery network) for their "main" application domain - that is, the domain that serves your HTML or JSON responses. This came up from a few people in response to my previous email about front-end optimizations everyone should be doing.
To recap, a content delivery network (or "edge network") is just a company that runs a few dozen datacenters in locations all around the world. You change the DNS entries for your domains to point to that company's datacenters, rather than your application. This means that clients connect not directly to your application, wherever it is in the world, but instead to the closest CDN point-of-presence (PoP).
For HTTP-cached responses, the benefit is obvious and extreme. For example, on www.speedshop.co, my CSS and other static assets are HTTP-cacheable with very long lifetimes. This means that the asset is always fresh when a client requests it from the CDN, so the point of presence can serve that asset immediately to the client rather than go all the way to my origin server.
For uncached responses, the argument goes a bit like this:
- To connect to my server, a client is directed through a series of 6 to 12 additional nodes/servers (what you see when you run traceroute).
- If I put my server behind a CDN, I am simply adding one more node to this list.
- Therefore, because a CDN has N+1 nodes between my server and my clients, it must be slower and increase time-to-first-byte.
This logic is wrong for a number of reasons, because its assumptions are wrong. Even if the response is uncached, a CDN can decrease TTFB because:
- SSL negotiation is faster. When using a CDN, the SSL connection is usually terminated at the CDN's PoP, not at your origin server. That can cut out hundreds of miliseconds of round-trip-time during that process if your client is far away from the origin.
- Once inside the CDN's PoP, CDNs seem to be a lot better at routing traffic onward to the origin than ISPs. I recently removed 300ms of TTFB from a client's app by moving their main domain onto a CDN, which we were able to prove by running Apache Bench on the new domain versus just directly connecting to their server. I just got a report from a reader yesterday with a similar reduction of TTFB by ~50%.
Fastly and Cloudflare generally seem to be the best CDNs out there right now. Both score very highly in terms of TLS performance, HTTP/2 features, and overall latency.
I truly believe the addition of a CDN will make any web application more performant on the whole for it's users. I don't think there are good reasons for not using one in 2020. All that said, there probably are exceptions for not using a CDN. I can't pretend to know everyone's use-cases, and only a Sith speaks in absolutes. If you can think of any, you can reply to this newsletter and let me know.
Until next week,
-Nate
|
|
|
|