For the most part, your CDN is responsible for the performance of your content delivery. The CDN controls its network, load balancers, caching servers and all else involved in delivering your content from the edge to your users.
So what can you do to contribute to excellent content delivery performance?
Read our 10 tips to optimize CDN performance.
1. Use high performance DNS
Imagine you're using
static.example.org on the CDN and
origin.example.org as your origin.
If the authoritative DNS for
example.org suffers from low availability and high latency, this surely has a bad impact on CDN performance.
Don't use the DNS service of your hosting provider just because it is included in the deal. It's easy and cheap to use high performance, global anycast DNS from providers like AWS, NS1, Cloudflare, Google or Azure.
Also, make sure to use high TTLs (Time-To-Live) on your DNS records, so resolvers can cache the records for a long time.
2. Move your origin close to your CDN
If most of your users are in Asia, do not place your origin in a far-away location like Amsterdam or New York but in ... Asia.
Keeping the latency low between CDN and origin is an effective way to optimize CDN performance for cache miss responses.
If you can't host your origin close to the CDN, consider using an Origin shield. Origin shield is extra caching layer between the CDN edge servers and your origin. The shield helps offload your origin and speed up cache miss responses. Read our CDN Guide: Origin shield to learn more and find out which CDNs offer origin shielding.
3. Have IPv6 connectivity
Facebook has done a lot of research into the impact of IPv6 on performance and concluded the effects are positive:
We've observed that accessing Facebook can be 10-15 percent faster over IPv6.
Can your CDN connect to your origin over IPv6? If yes, consider moving your origin to an IPv6-enabled hosting environment.
AWS S3 supports IPv6. Unfortunately, Google Compute Engine currently does not support IPv6.
4. Tune your initcwnd
The initial congestion window parameter (initcwnd) on your origin server likely has a value of 10. This means the server sends out 10 packets in the first round trip over a fresh connection.
A value of 10 is not bad, but a higher initcwnd likely has a significant positive effect on TCP performance, resulting in faster content transfer between origin and CDN.
Some CDNs have a initcwnd of 10, other CDNs have a (much) higher value. Read more: Initcwnd settings of major CDN providers.
Use our Initcwnd Checker tool to check your current initcwnd.
Important: do not 'simply' increase the initcwnd on your server(s) and assume that will work out well. It may not. A good starting point is the blog article Tuning initcwnd for optimum performance.
5. Keep connections alive forever
When the CDN needs to pull content from your origin, a TCP connection must exist between the two servers. Ideally, that connection is already there and can be reused, saving roundtrips and precious milliseconds to establish a fresh connection.
The CDN or the origin may terminate the connection. You have no control over how long the CDN keeps a connection alive, but you do control the keep-alive behavior on your origin.
Don't close the connection on the origin side, ever.
Worried about the many CDN servers establishing TCP connections with your origin and the origin not being able to handle that? Set up an Origin shield.
6. Reduce TLS connection time
Do you have a secure HTTPS origin? If yes, there are several optimizations you can do to improve CDN performance. To name a few: TLS False Start, TLS session resumption and TLS record size optimization.
Before getting to work with these TLS optimizations, ask your CDN if anything is needed from their side to make these optimizations have effect.Futher reading:
7. Minimize byte size
Reducing the byte size or 'weight' of your content is very effective in speeding up content delivery performance. The less bytes over the wire, the faster your content arrives at your users.
There are many ways you can minimize byte size to enhance CDN performance Compression is the most effective and often easiest to implement. Read our CDN Guide: Compression to learn more about Gzip, Brotli and which content types should be served compressed. The Google Developers site has a good in-depth article about Text compression with GZIP.
8. Be a Cache-Control master
How can you make the CDN cache your objects for as long as you want and maximize the cache hit ratio?
Out of the box, most or all CDNs will follow the caching instructions your origin server sends by way of the
It's a very effective tool to improve CDN performance.
Cache-Control: max-age=86400 tells the CDN and browsers the object may be cached for 86400 seconds.
Cache-Control: max-age=3600, s-maxage=86400 informs the CDN it may cache the object for 24 hours and browsers should cache the object no longer than 1 hour. Note: not all CDNs support
s-maxage by default.
Cache-Control: max-age=86400, stale-while-revalidate=300 instructs the CDN and browsers to cache the object for 24 hours and, at the end of those 24 hours, the CDN may serve the stale response for up to 300 seconds while new content is being fetched from origin.
- HTTP Caching | Web | Google Developers
- The essential guide to CDN: CDN Caching (Incapsula)
- CDN Guide: Serve stale
9. Enable conditional requests
When a CDN receives a request for a stale object (in cache, but expired), the CDN must first contact the origin before sending a response to the user.
If the cached object has a
ETag header, the CDN can make the request to origin conditional by adding
If-None-Match headers. The origin can decide to respond with a lightweight
304 Not Modified response (headers only) or send a heavy
200 OK response (headers and body).
304 Not Modified response is better for performance than the
200 OK response because the size of the response is much smaller and so less roundtrips are needed between CDN and origin.
Configure your origin server to always send a
ETag header, as this greatly helps improve cache miss performance.
10. Be careful with the Vary header
Your origin should not serve objects to the CDN with a header like
Vary: Cookie or
Vary: User-Agent, Cookie. These Vary headers have a big negative effect on cache hit ratio and CDN performance.
Is your origin sending these Vary headers for no purpose? Remove them!Important:
- Don't ever use
Vary: *. An object with that header will never be stored in a CDN cache
- Always send the
Vary: Accept-Encodingheader with (Gzip) compressed content
Further reading: Best Practices for Using the Vary Header