What is a CDN, and why does every conversation about website speed end up there sooner or later? It starts with a simple fact: your site sits on one server at one specific point on the map, but your visitors are scattered — some inside Iran, some on the far side of the country's international gateway — and there is no single point that is close to all of them. A content delivery network (CDN) is the engineering answer to that dead end: a copy of the site's content is kept on nodes close to the users, so every request is answered over the shortest possible path. In this guide we take the CDN mechanism apart without exaggeration — edge caching, HIT and MISS, origin protection, image optimization — and we are just as honest about what a CDN cannot do.
What is a CDN? A content delivery network in plain terms
A CDN — short for Content Delivery Network — is a set of servers deployed in different geographic locations, each of which is called an "edge node": edge because it sits at the edge of the network, close to the end user, rather than at the center next to your main server. Once your site's domain is put behind a CDN, each visitor's request first reaches the nearest edge node, not your main server — the server that CDN terminology calls the "origin".
An edge node does two jobs. It keeps the content it has already fetched from the origin in its own storage and serves that copy directly the next time it is asked; and for requests it has no answer to, it passes them to the origin on the user's behalf and returns the response. The practical result of this dual architecture is that images, stylesheets and fonts are served from a few dozen kilometers away from the user, and the origin server deals with a handful of edge nodes instead of thousands of users. That is why a CDN counts as a speed tool and a protective layer at the same time — two roles we look at separately below.
Let's clear up a common misconception right away: a CDN does not replace your hosting. The original copy of the site — code, database, files — always lives on the origin, and the edge nodes only hold temporary copies of its cacheable parts. Without an origin, a CDN has nothing to distribute.
What problem does a CDN solve? The physics of distance and TTFB
One number shows why distance matters: path latency, the time it takes a packet to travel from the browser to the server and back. Before it receives the first byte of any resource, the browser has to make that round trip several times, and the TTFB (time to first byte) metric records exactly that wait. The key point is that this cost is not paid once: a page with dozens of static files repeats the same base latency over and over, and the sum is the pause a user feels before the page appears.
For a visitor in Tehran, a server in Frankfurt is often more than 100 milliseconds "away"; the same visitor usually reaches a node inside the country in a few tens of milliseconds — and sometimes less. Multiply those two numbers across the thirty or forty static resources of a typical page — images, CSS, JavaScript, fonts — and the real weight of distance becomes clear: when all of these files come from a nearby edge node, a large part of the load time quietly disappears. That is exactly how a CDN speeds up a website: not by making anything "more powerful", but by shortening the distance most of the bytes have to travel.
We break down the causes of this latency and how to measure it in a separate guide to reducing ping; and if you are still deciding where your main server should live, our comparison of Iran and foreign hosting shows where the origin should be — a decision that a CDN makes less important but does not make go away.
How does CDN edge caching work? HIT, MISS and cache lifetime
The heart of every CDN is its edge cache, and its behavior can be described in two words. When a request reaches an edge node, the node first looks in its own storage: if it has a valid copy of that content, it serves it immediately — that response is a HIT, and your server never even hears about it. If it doesn't have one, or its copy has gone stale, it forwards the request to the origin, returns the response to the user and at the same time keeps a copy for next time — that is a MISS, and it pays the full path latency, but it turns the next request for the same content into a HIT.
How long each piece of content stays in the cache is not the CDN's decision alone; the origin server declares, through HTTP headers — specifically Cache-Control — how long each response counts as "fresh", and the edge node sticks to that. The full mechanics of these headers are explained in MDN's documentation on HTTP caching. You can check the cache status of a file yourself with a simple request:
curl -I https://example.com/assets/logo.png
HTTP/2 200
cache-control: public, max-age=86400
x-cache: HIT
age: 4210The x-cache header (or its equivalent on each network) tells you whether the response came from the cache or from the origin, and age tells you how many seconds this copy has been sitting on the edge. This is the measure of a healthy CDN deployment: the ratio of HITs to total requests. A ratio that stays low means the nodes keep running back to the origin, and you have effectively just added a middleman to the path.
What content does a CDN cache, and what does it not?
The short answer: anything that is the same for every user is a candidate for caching; anything that differs from user to user is not. The table below draws the line more precisely:
| Content type | Cache status | Notes |
|---|---|---|
| Images, CSS, JavaScript, fonts | Fully cached, for a long time | The same for everyone; this is where a CDN pays off most |
| Large downloads and video | Cached in chunks | Professional networks cache the file piece by piece, so seeking in a video does not pull the whole file again |
| HTML of public pages (articles, product pages) | Cached briefly | Cacheable, but with a short lifetime so updates show up quickly |
| Personalized HTML (shopping cart, dashboard, user account) | Not cached | Different for every user; built at the origin every time |
| POST requests and transactional APIs | Not cached | Their result is a change of state, not content; they only pass through the CDN |
| WebSocket and live connections | Passed through, no caching | The CDN acts as a gateway; caching plays no part |
This table carries a hidden message we will come back to: the larger the share of personalized content on your site — a shop whose users are always logged in, a user panel, a web-based tool — the smaller the share of your traffic that can be cached, and the more realistic your expectations of a CDN should be.
A CDN is not just about speed: origin protection
A content delivery network's second role gets less advertising but matters more on a bad day: the CDN stands between the internet and your server.
Absorbing malicious traffic before it reaches the origin
When the domain's public record points to the edge nodes, any flood of requests — real visitors or an attack — hits the edge first. An edge node can cap the request rate and the number of concurrent connections per IP, close slow and half-open connections, and keep the weight of an attack on itself; the capacity a distributed network has to absorb that load is not comparable to that of a single server. Throughout all of this, the origin only sees the nodes' filtered traffic.
Keeping the origin IP hidden
When the CDN is on, a DNS lookup of your domain returns the edge nodes' IP addresses, not the main server's. That means automated scans and direct attacks have no address to aim at. This concealment is not absolute, though: if the same IP has been published somewhere else — an old DNS record, the headers of emails the server sends, or a service that gives away its own address — it can be traced. Completing this shield is up to you: restrict direct access to the origin in your firewall so that only the edge nodes can talk to it.
Image optimization on the edge
Edge nodes are also a good place for repetitive processing work, and the most prominent example is image format conversion: a JPEG or PNG image is converted right there on the node into the modern WebP or AVIF formats and cached, and each browser gets the best format it has declared it understands. The savings are real — on the Mehran Host CDN, the site's own 158 KB PNG image came down to 31 KB as WebP and 16 KB as AVIF after conversion on the node — and because the result is cached, the cost of conversion is paid only once. Brotli compression for text, stylesheets and scripts belongs to the same family: an optimization that happens on the edge without any change on your server.
What a CDN can't do
The market is full of the idea that a CDN is a magic speed button. It isn't, and before you buy a CDN for your site it is better to know where its hands are tied:
- Dynamic HTML still comes from the origin. A page that is built separately for each user — shopping cart, search results, dashboard — cannot be cached. The speed of these pages depends on the resources and efficiency of your own server, and the CDN only tidies up its network path.
- It does not cure a slow backend. If your pages have a high TTFB because the database queries are heavy or there are too many plugins, the problem starts before anything reaches the network. For a WordPress site, we have laid out the full plan for that surgery in our guide to speeding up WordPress.
- It is not a replacement for a server. If the origin goes down, cached content usually keeps being served for a while, but new pages and every dynamic action stop working. A CDN increases resilience; it does not take the job of keeping the origin up off your shoulders.
- It does not rescue bad architecture. A site that generates dozens of uncacheable requests for every visit stays just as heavy behind any CDN; the cacheable share of the traffic is decided by the site's own design.
Choosing a CDN for a site whose visitors are in Iran
Everything so far has been general; but choosing between an Iranian and a foreign CDN involves a variable of its own: the unstable quality of the international gateway — the small number of state-operated links that carry all traffic between Iran and the rest of the internet.
An edge node inside Iran: insurance for days of disruption
Global CDN networks have no edge nodes inside Iran. That means that for a visitor inside the country, the "nearest node" is still on the far side of the international gateway, and during periods of disruption or restricted international bandwidth, the very static files that were supposed to arrive quickly from the edge arrive slowly and erratically — exactly when you need stability most. A CDN with a node inside the country reverses this scenario: an Iranian visitor's traffic to the cached content never leaves the country at all, and if the origin is also inside Iran, the MISS path stays domestic too.
The other side: don't forget visitors abroad
If part of your audience is outside the country, a node inside Iran is not enough on its own; their path to a domestic node crosses the international gateway just as much as an Iranian user's path to a European node does. A network that has nodes both inside Iran and in Europe, and sends each visitor to the node that suits them, covers both groups — the same architecture we recommended for sites with two audiences in our comparison of Iran and foreign hosting.
One provider or a mix of networks?
There is another way: combining two CDNs — say, a foreign network for global visitors and a domestic one for users in Iran — split at the DNS level. This architecture is feasible, but know its hidden cost: two settings panels, two places to purge the cache that have to be purged at the same time, two separate paths for SSL certificates, and debugging that always starts with the question "which network was the problem?" For most sites, a single provider that covers both sides with one panel and one cache is simpler and less error-prone; keep a multi-network setup for when scale or specific requirements genuinely call for it. If splitting at the DNS level is unclear to you, our guide to DNS records is a good place to start.
And before any decision, measure where you stand now: the Mehran Host website speed test is free, shows TTFB and the loading stages as a real visitor sees them, and detects whether your site is already behind a CDN.
Mehran Host's CDN with an Iran edge: set it up from the DNS panel in minutes
Our last word in this market is simple: turning on a CDN should not take more than a few minutes of your time, and it should not force you to move anything. On the Mehran Host content delivery network, all you need is for the domain's nameservers to point to Mehran Host; after that you will see a CDN switch next to each A record in the DNS panel — turn it on, and the origin IP is registered and hidden, the public record changes to the edge nodes, and the SSL certificate for that name is issued automatically within a minute or two. Your hosting or server doesn't need to be here either; the origin can stay anywhere in the world.
The edge nodes are located in Iran and Europe, and each visitor is directed to the node that suits them — so the two-sided architecture we recommended in the previous section comes without combining two networks. The cache has three selectable modes, and purging it for a single URL or the whole domain takes one click; image optimization to WebP and AVIF, Brotli compression and HTTP/3 are enabled on the nodes, and each site's statistics — request count, the share of responses served from cache, the traffic saved at the origin, broken down by node — are visible in the panel without storing visitors' IP addresses or browsers. The pricing is simple too: on any domain whose DNS is hosted with Mehran Host, the first 1 TB of CDN traffic per account is free, and after that each GB costs 1,000 Toman (1 Toman = 10 Iranian rials), deducted from your wallet based on usage. Full details, the list of nodes and their measured latencies are on the CDN page.
Frequently asked questions
What is a CDN, and how is it different from hosting?
Hosting is where the original copy of your site — code, database and files — runs; a CDN is a network of edge nodes that keeps copies of that site's static content close to users and answers requests over the shortest path. A CDN complements hosting rather than replacing it: without an origin server there is nothing to distribute, and dynamic content is always built at the origin.
Does a CDN really make a website faster?
For static content — images, stylesheets, scripts, fonts — yes, and the effect is larger for users who are farther from the origin, because it removes the path latency from dozens of requests. Personalized HTML and dynamic requests, however, still come from the main server, and their speed depends on that server's resources. The real improvement depends on how much of your site's traffic is cacheable, not on the provider's advertising.
Does a CDN help SEO?
Not directly: Google gives no ranking credit just for using a CDN, so its effect is indirect and comes through speed. User-experience metrics are collected from real visitors' browsers, and when static resources are served from a nearby node, load time and metrics such as LCP improve — and a faster page does better in search, especially on mobile. So a CDN is one lever for speed, and speed is one lever for SEO.
For an Iranian website, is a foreign CDN better, or a CDN with an edge node inside Iran?
If most of your visitors are inside Iran, an edge node inside the country is what makes the difference: the user's path to cached content stays domestic and remains stable during disruptions to international connectivity — exactly when foreign networks are at their slowest. If you also have visitors abroad, choose a network that has nodes both inside Iran and in Europe and sends each visitor to the node nearest to them.
How do I check whether my site is behind a CDN and its cache is working?
Check the response headers: send a curl -I request to the URL of a static file, and headers such as x-cache (or its equivalent) show whether the response came from the edge cache or from the origin, while Cache-Control gives the cache lifetime. If most responses for static files are MISS, your cache settings need a review. The free Mehran Host website speed test also detects CDN use and breaks down the loading stages.