What Is a CDN? How It Speeds Up Websites

A CDN stores selected website files near visitors, so browsers do not need to fetch every image, stylesheet, or script from your origin server. That shortens network trips and can reduce origin load, but it will not fix slow database queries or a cache rule that exposes private content.

What Is a CDN and How Does It Handle Requests?

I usually notice the value of a CDN when I test the same website from İzmir and Frankfurt. The application has not changed, but the distance has. A CDN, or Content Delivery Network, keeps selected content on edge servers in different locations so visitors can fetch it from a nearby point of presence instead of travelling to your origin for every request.

A CDN can store JavaScript, CSS, images, fonts, and sometimes HTML responses according to rules you define. If the requested object is already at the edge, the CDN returns it directly. If it is not there, the CDN fetches it from the origin, sends the response to the visitor, and may store a copy for later requests.

Your VPS does not disappear in this arrangement. It usually remains the origin server where the application, database, and changing content run. The CDN is the distribution layer closer to the visitor.

Start with static content and controlled caching – do not cache personalized responses such as sessions, shopping carts, or administration pages by default.

How Does a CDN Speed Up a Website?

A CDN does not make a website faster through one magic switch. Network distance, TLS connection setup, repeated downloads, and the amount of work left for the origin all affect the result.

Distance matters, but cache status matters too

A visitor may be in İzmir while the origin server is in Frankfurt. After DNS resolution, traffic goes to an edge location selected by the provider. If the response is already cached there, the visitor does not need another trip to Frankfurt for every image or stylesheet. Large files make this difference easier to see.

TTFB, or time to first byte, does not measure only PHP or database speed. It can include the network path, TLS negotiation, edge processing, and cache status. With a cache hit, the request never reaches the origin application, so the variable application time is removed. With a cache miss, the CDN still has to contact the origin.

I once looked at a good page-speed score and assumed the CDN was doing its job. A header check told a less flattering story: the asset was still missing at the edge and every test was reaching the origin. Since then, I check cache headers beside origin request counts.

It prevents repeated downloads

A browser cache and a CDN cache are not the same thing. The browser stores a file on one user’s device; the CDN stores content at an edge location for many visitors. The max-age, s-maxage, and no-store directives in the HTTP Cache-Control header affect how these layers behave. RFC 9111 describes the current core rules for HTTP caching.

For a versioned CSS file, you might use Cache-Control: public, max-age=31536000, immutable. The value 31536000 represents 365 days. When the file changes, publish a new name such as app.2026-09.css instead of reusing the same URL.

Choose TTLs by content type – use long lifetimes for versioned static files and shorter lifetimes for HTML that changes frequently.

CDN, Origin, and Browser Cache: What Is the Difference?

The origin is the authoritative application server. User accounts, carts, orders, and administration actions are normally generated there. The CDN is a distribution and traffic-absorption layer.

Caching every response blindly is dangerous. One bad rule can expose one user’s HTML response to another user, and that is a much worse problem than a slow page.

A common security model is to allow HTTP and HTTPS traffic to the origin only from the CDN provider’s current IP ranges. Keep that list updated automatically or at regular intervals. A static list left untouched for years can block new edge locations without making the cause obvious.

When Nginx runs on the origin, proxy headers, the real client IP, and the HTTPS state need separate attention. The basic virtual-host steps in How to Install and Configure Nginx on Ubuntu are useful when you are setting up a reverse proxy for the first time.

My rule – treat the origin as the authoritative application server, restrict public web access to the CDN ranges, and verify forwarded headers before going live.

Which Content Should a CDN Cache?

I start with content that is public, changes infrequently, and has a versioned URL. These resources are usually safe CDN candidates:

• CSS and JavaScript files
• JPEG, PNG, WebP, AVIF, and SVG images
• Web fonts
• Video segments and downloadable static files
• Versioned API responses with no private data

HTML needs more care. A public blog post that looks identical to every visitor may be cached, but a response containing a username, cart, currency, or session state should usually use private or no-store.

Cookies matter too. Some CDN rules exclude responses carrying a Cookie header from caching by default. Other configurations consider only selected cookies. Unnecessary query parameters in the cache key also reduce the hit rate. If parameters such as ?utm_source= can be normalized safely, you avoid creating many cached copies of the same content.

Check the origin headers first

Before placing a production site behind a CDN, inspect the origin response:

curl -I https://www.example.com/assets/app.2026-09.css

Look at Cache-Control, ETag, Last-Modified, and, when present, CDN headers such as Age or X-Cache. Providers use different names, so compare the headers with the cache status in the provider dashboard instead of trusting one header.

To check a second request without downloading the response body, run:

curl -sS -D - -o /dev/null https://www.example.com/assets/app.2026-09.css

-D - prints response headers, while -o /dev/null discards the body. That second request may still be a miss if you reached another edge location or the provider uses a short TTL. The result depends on the provider’s policy.

Verify, do not guess – use response headers and provider logs to confirm cache hits instead of treating a page-speed score as proof.

How Do You Configure DNS and HTTPS for a CDN?

CDN setup usually begins by pointing DNS records for your domain toward the provider’s network. A common model uses a CNAME for www.example.com; the root domain uses the ALIAS, ANAME, or apex-routing method supported by that provider. A DNS CNAME connects one hostname to another hostname. It does not directly provide an IP address.

Record the existing DNS entries before making changes. MX records affect email delivery, TXT records are used for verification and SPF, and CAA records control certificate-authority authorization. Removing mail records while moving only the website is an unpleasantly common migration mistake.

dig +short www.example.com CNAME
dig +short www.example.com A
dig +short example.com MX

The first command shows the CNAME target, the second shows the IPv4 response, and the third shows mail servers. DNS answers do not change everywhere at the same moment; TTLs, resolver caches, and the provider’s rollout time all matter. When troubleshooting DNS, I reach for dig +short before opening a control panel because it shows what resolvers are returning.

On the HTTPS side, certificates are served at the CDN edge. The connection between the CDN and origin should also use HTTPS where possible, with certificate verification enabled. A mode called Flexible by some providers can encrypt the visitor-to-CDN connection while leaving CDN-to-origin traffic as plain HTTP. That is unsuitable for session cookies and login credentials.

The CDN must send the correct Host header and SNI value to the origin. If the origin certificate covers only an internal hostname, verification fails. Test certificate renewal, redirects, and the HTTP-to-HTTPS policy before switching production traffic.

Before changing DNS – record every DNS entry, test the CDN-to-origin certificate path, and confirm the expected Host and SNI values.

Where Are the Security and Performance Limits?

A CDN does not remove every DDoS request. Provider capacity, protection layers, rate-limit rules, and the type of application attack all matter. Requests that bypass the cache with invalid parameters can still reach the origin.

If the origin IP has appeared in old DNS records, mail headers, a forgotten subdomain, or a server banner, an attacker may bypass the CDN. Restricting the origin firewall to the provider’s source networks reduces that risk. Changing SSH from port 22 is not security by itself; key-based authentication, firewall rules, and monitoring still matter.

Apply rate limits in observation mode first. A very low limit on a login endpoint can block legitimate users behind the same carrier-grade NAT. For APIs, limits based on identity, tokens, or user accounts may fit better than limits based only on IP address.

A CDN does not speed up database queries. If every cache miss still runs an expensive query, the origin remains slow. The EXPLAIN approach in What Is a Database Index? How Indexing Speeds Up Queries is a separate part of that investigation.

It also does not repair a 502 response from the origin. A broken connection between Nginx and PHP-FPM, an upstream, or the application remains broken; only some previously cached responses may continue to work. The upstream and log checks in How to Fix a 502 Bad Gateway Error still apply.

Keep looking underneath – protect the origin with firewall rules, inspect application logs, and monitor source-IP validation even after the CDN is active.

How Do You Purge a CDN Cache and Update Content?

Purging a cache deletes objects stored by the CDN so the next request fetches them again from the origin. Purging everything looks convenient, but on a busy site it can send many requests to the origin at once. That is the cache-stampede, or thundering-herd, problem.

Versioning files is usually safer. Publish style.2026-09-25.css instead of style.css, then update the HTML to reference the new name. For an urgent correction, purge only the affected URL. Short TTLs, stale-while-revalidate, or equivalent provider features can be used carefully for HTML and API responses.

After purging, I check three things:

1. Confirm that the new content exists in the origin response.
2. Check the cache status from a different edge location.
3. Make sure the browser is not still using the old file.

301 redirects can be cached as well. A wrong permanent redirect may remain in clients and CDN locations for a long time. If you are moving a domain or enabling HTTPS, the migration order described in What Is a 301 Redirect? An SEO Implementation Guide is safer than publishing permanent redirects without a rollback plan.

Prefer small changes – use versioned filenames, purge one URL for urgent fixes, and test the origin and multiple edge locations before calling an update complete.

Which CDN Metrics Should You Monitor?

“The CDN is active” is not enough information. I monitor cache-hit ratio, origin request count, origin response time, HTTP status codes, bandwidth, and latency by edge region.

A higher hit ratio can still come with a worse user experience; the CDN may simply be serving stale HTML quickly. Separate measurements by URL type. A high hit ratio is expected for static files, while a low or zero hit ratio can be normal for personalized endpoints.

Separate real-user measurements from synthetic tests. Lighthouse and similar tools may test from one location. Compare curl requests from different regions, RUM data, and application logs. Measure HTTP/2 and HTTP/3 support too; the basics are covered in What Is QUIC? A Guide to the Faster Internet Protocol.

My preferred rollout is incremental: record TTFB and origin CPU before the CDN, move only static files first, watch hit rates and error codes, and test HTML cache rules on a small group of URLs last. Every step needs a rollback path.

When a page does not get faster, the CDN may not be the problem. The HTML may be dynamic, images may be unnecessarily large, JavaScript may occupy the main thread for too long, or origin queries may be slow. A CDN reduces network transfer and repeated downloads; it does not fix browser rendering cost.

Measure both sides – keep origin metrics beside edge metrics so a fast cache hit does not hide a slow application.

Check These Before Enabling a CDN

• Record every current DNS record, including MX, TXT, and CAA entries.
• Move versioned static files first and leave personalized responses uncached.
• Inspect Cache-Control, ETag, and Last-Modified headers at the origin.
• Verify the CDN-to-origin certificate, Host header, and SNI value.
• Restrict direct HTTP and HTTPS access to the CDN provider's current IP ranges.
• Test cache hits from more than one location with curl and provider logs.
• Define a purge and rollback procedure before changing HTML or redirect rules.

When I point a domain to a CDN, I also account for DNS caches before judging whether the change worked. I explain the timing and the role of TTLs in [What Is DNS Propagation? How Long Does It Take?].

Frequently Asked Questions

Sources

• RFC 9111 – HTTP Caching — rfc-editor.org
• RFC 9114 – HTTP/3 — rfc-editor.org
• ICANN – Domain Name System — icann.org
• MDN – Cache-Control header — developer.mozilla.org