What Is a CDN?
Author: Domeny.ForSale editorial team Published
In brief: A CDN is a network of servers that delivers website content to users from appropriately selected locations, rather than fetching everything from a single server. It can reduce loading times for images, scripts and other files, and ease the load on your hosting. However, it does not replace a well-performing server or website optimisation, and its effectiveness depends on the type of content and configuration.
How a CDN and caching work
CDN stands for Content Delivery Network. Its servers act as intermediaries between the visitor and the origin server — the place where the website runs or its original files are stored. Traffic is directed to an appropriate network node, not necessarily the closest geographically, but one also selected according to network conditions and availability.
The fundamental mechanism of a CDN is caching — storing temporary copies. A network server can keep a copy of an image, CSS stylesheet or JavaScript file and deliver it to subsequent visitors without fetching it from the hosting server again. If no copy exists yet or it has expired, the CDN usually fetches the content from the origin server, according to the configured rules.
Imagine a shop hosted on a server in Poland that also receives visitors from Canada. Without a CDN, their browsers fetch product images directly from Poland. With a CDN, they may receive cached copies from a node that is closer in network terms, reducing latency. However, the first request for a particular file may still require contact with the origin server.
What a CDN speeds up, and what it cannot fix
The simplest use of a CDN is to deliver static files — files that do not change for each visitor. These include images, fonts, stylesheets, scripts and downloadable files. A copy stored once can be used in responses to many people.
A CDN can also cache entire HTML pages if the service and application rules allow it. This requires greater care: a public guide can usually be cached differently from a shopping cart, customer dashboard or page showing personalised prices. Dynamic content generated for a specific request is not always suitable for a shared cache.
A CDN does not remove the underlying cause of a slow application. If a page waits several seconds for a database query, a request that needs to reach the server may still be slow. The network will not fix an excess of scripts running in the browser either. It can deliver a large image faster, but reducing that image’s size remains a separate task.
Some services also offer image optimisation, traffic filtering or protection against DDoS attacks — attempts to overload a service with massive numbers of requests. However, these features are not identical across all CDNs. Check their scope and limits in the documentation for the specific provider.
CDN, hosting and DNS serve different roles
Hosting provides the resources needed to store files and run an application. A CDN primarily acts as an intermediary in content delivery and reduces the load on the origin. In a typical setup, you still need hosting, even if visitors receive most images from the CDN cache.
DNS is the system that helps determine where to direct a connection for a given domain. Connecting a CDN often requires changes to DNS records or the domain’s name servers. This does not mean moving the application itself: what changes is the route requests take to reach the website.
A CDN can be enabled for the entire website or only for a separate subdomain containing files, such as static.example.com. In the first case, login handling and private content need particularly careful configuration. In both cases, you should ensure HTTPS — an encrypted connection — is used, including between the CDN and the origin server.
When implementing a CDN makes sense
A CDN is particularly useful when your audience lives in different regions, your website serves many files or it experiences sudden traffic spikes. Many users downloading the same materials can then use cached copies instead of placing a load on the hosting server with every request.
For a small local website whose audience is close to a good server, the improvement may be less noticeable. Before adding another service, check what is actually slowing the website down: the application’s response, image transfers or scripts running in the browser. Compare measurements from your audience’s locations, rather than only from your own computer.
When choosing a provider, check how data transfer and requests are billed, the network’s coverage, file limits and the ability to remove cached copies quickly. Confirm current prices, feature availability and data processing rules in the official pricing information, documentation and terms of service.
How to set up a CDN without content problems
The biggest configuration risk is storing a private response as a cached copy available to other people. Another common problem is displaying outdated files after the website has changed. A short deployment procedure helps:
- Define what can be cached. Start with public images, CSS and JavaScript. Exclude the shopping cart, customer account and responses containing user data from the shared cache.
- Set the expiry time for cached copies. TTL, or time to live for a cache entry, should match how often the content changes. Check how the CDN interprets cache-control headers, including
Cache-Control. - Plan updates. Use new names for modified files, such as
style.v2.css, or remove old copies using the cache-clearing function. - Test typical actions. Check logging in, forms, purchases and publishing changes. Compare how things work for logged-in and anonymous users.
Before changing DNS, save the existing configuration and prepare a way to roll back the deployment. Start with a limited range of files, measure the effect and only then expand the caching rules.
See also: What is an AI agent?
Read also
