Tecof • September 15, 2026
What Is a CDN? How It Speeds Up Your Website
In Brief
A CDN (Content Delivery Network) copies your site's files onto servers spread across the world and serves every visitor from the nearest copy; even if your origin sits in Frankfurt, a visitor in Konya pulls the product photo from an edge node in Istanbul, so time to first byte drops and your origin no longer produces the same file thousands of times. A CDN does three jobs at once: it shortens distance, it takes load off the origin, and it filters incoming traffic to form a security layer. As of 2026 the question is no longer "should I use a CDN" but "which content do I cache, under which rule, and for how long".
Tuesday evening, 21.15. A home textiles store announced its new season collection through an Instagram account with 180,000 followers. Within ten minutes concurrent visitors went from 40 to 2,300. The server did not go down, but the category page went from 1.9 to 7.4 seconds, and the add-to-cart rate fell from 4.1 percent to 1.6 percent. The team said "the server isn't enough" and doubled the plan; the bill went from 1,400 TL to 3,200 TL and the page came down to 6.1 seconds. The next morning the network tab made it clear: the category page weighed 3.8 MB, and 3.3 MB of that was 42 product images, each pulled from the origin individually for every visitor.
The problem was not the server's power but the same file being sent 2,300 times from the same place. A product photo changes once a day, maybe never; yet the server reads and sends it again on every request. That is exactly what a CDN solves: produce unchanging content once and keep it close to the user. Upgrading hardware does not solve this, it only makes it expensive.
How a CDN Works: Origin, PoP and Cache
The basic terms
These are the terms that come up constantly in CDN conversations and are most often confused with one another:
- Origin server: Where your site actually lives — database, application code, source files. A CDN does not replace the origin; it sits in front of it.
- PoP (Point of Presence): A cluster of servers the provider places in a city — Istanbul, Frankfurt, Amsterdam, Sofia. Visitors land on the nearest PoP through DNS and anycast routing.
- Edge: The cache server inside the PoP, closest to the user. "Served from the edge" means the request never reached the origin.
- Cache hit: The requested file is already at the edge. The response comes back in milliseconds.
- Cache miss: The file is not at the edge, so the edge fetches it from the origin, hands it over and keeps a copy. The first visitor pays that cost; the ones after do not.
- TTL (Time To Live): How long a copy stays valid at the edge. When it expires, the edge asks the origin whether the file is still current.
- Purge: Manually invalidating a copy before its TTL runs out — used when a price changes or an image is replaced.
Why distance matters this much
Istanbul to Frankfurt is 1,900 km as the crow flies; the real fibre route is 1.5 to 2 times that. An HTTPS request needs several round trips — TCP handshake, TLS handshake and the request itself. In the range we see in the field, one-way latency from Turkey to Frankfurt sits at 35-50 ms and the round trip at 70-100 ms; multiply that by three or four and 250-350 ms is gone before the first byte arrives. On a request landing on an Istanbul PoP, the same round trip is 5-15 ms. The difference comes from distance itself, not server speed.
Measurements with and without a CDN
The table below summarises the ranges we typically see on a mid-sized e-commerce site whose origin is in Frankfurt. The figures are for a mobile 4G connection, an empty browser cache and the main category page.
| Scenario | TTFB (ms) | LCP (s) | Total page weight | Requests reaching origin |
|---|---|---|---|---|
| No CDN, Frankfurt origin | 310-420 | 4.2-5.6 | 3.8 MB | 100% |
| CDN on, static cache enabled | 90-140 | 2.6-3.4 | 3.8 MB | 12-18% |
| CDN + WebP conversion | 90-140 | 1.9-2.4 | 1.4 MB | 12-18% |
| CDN + WebP + responsive sizes | 85-130 | 1.4-1.9 | 0.8 MB | 10-15% |
| Bigger server plan only | 240-330 | 3.9-5.1 | 3.8 MB | 100% |
The last row matters: bigger hardware improves TTFB somewhat but does not rescue LCP, because the bottleneck is distance and bytes, not the processor.
Static and Dynamic Content: What You Cache, What You Never Cache
The logic of the split
The simple rule: if the same URL returns the same response to everyone, it can be cached; if it changes per person, it cannot. Product images, category banners, CSS, JavaScript and fonts are the same for everyone. Cart contents, the top bar that says "hello Ayşe", order tracking, checkout and the account panel are personal. There is a grey zone in between: product detail HTML looks the same to everyone, but stock and price can change — that is where short TTLs belong.
What a wrong rule actually costs
One client had cached every HTML response with a one-hour TTL "to make it faster". The result: the first user's cart was stored at the edge, and for 40 minutes everyone landing on the same PoP saw that cart; three people got as far as checkout with someone else's basket. That is not a speed problem, it is a data leak. The second common mistake is leaving the session cookie out of the cache key, so a logged-in user's personal information can be served to anonymous visitors. The third is the opposite: Cache-Control: no-store on every response, so the CDN holds nothing and you pay the bill without any gain.
Rules by content type
| Content type | Cache rule | Suggested TTL | Consequence of a wrong rule |
|---|---|---|---|
| Product images, banners | Edge + browser cache | 30-365 days | Needless origin traffic, slow LCP |
| CSS / JS (version-stamped) | Edge + browser, immutable | 365 days | Full re-download on every deploy |
| Fonts | Edge + browser | 365 days | Late text render, higher CLS |
| Category page HTML | Short edge cache, cookies excluded | 60-300 s | Stale stock and price |
| Product detail HTML | Short edge cache + purge | 60-120 s | Wrong price on display |
| Cart, checkout, account | No cache | 0 (no-store) | Mixed-up carts, data leak |
| Search results | No cache or very short | 0-30 s | Irrelevant or empty results |
| Order/shipping API responses | No cache | 0 | Stale tracking status, support load |
The safest way to write rules is "close everything first, then open one thing at a time"; the reverse leads straight to the cart story above. On the integration side, reviewing how APIs and e-commerce integrations are wired helps you work out which endpoints can never be cached.
Image Optimisation: The Biggest Win Is Here
Format: WebP and AVIF
If you keep a product photo as a 420 KB JPEG, the same image lands at 140-180 KB in WebP and 90-130 KB in AVIF with no perceptible quality difference. Modern CDNs do this conversion without touching the source file, by reading the browser's Accept header: AVIF to browsers that support it, WebP to those that do not, JPEG to old ones. You do not have to rework your image archive; the rule is written once.
Responsive sizes and lazy loading
The waste we see most often is a 2000-pixel-wide product photo squeezed into a 180-pixel box on a phone: the browser downloads the whole file, then shrinks it. A CDN's image resizing solves this with a URL parameter — 180, 360, 720 and 1440-pixel variants from the same source file, with srcset telling the browser which width to fetch. Add loading="lazy" to images below the fold, but never to the large image on the first screen, because that directly delays LCP.
The numbers on a real example
Back to the home textiles store. The category page's LCP element was a 1,240-pixel-wide, 680 KB duvet cover photo in the first row. Three steps changed it: the CDN went live and the image came from an Istanbul edge instead of Frankfurt, dropping download time from 1.9 seconds to 0.9; WebP conversion took the file from 680 KB to 210 KB and the time to 0.4 seconds; a 720-pixel mobile variant brought it to 74 KB. LCP went from 5.1 seconds to 1.8, and the add-to-cart rate during campaign week rose from 1.6 percent to 3.7 percent. We covered how gains like this turn into sales in our piece on improving conversion rate in e-commerce.
Core Web Vitals: What a CDN Fixes and What It Does Not
LCP: the biggest gain
LCP (Largest Contentful Paint) is how long the largest image or text block on screen takes to appear — in e-commerce, almost always a product image. A CDN touches it directly, by shortening TTFB and by shrinking the image. In the range we see in the field, a 40-60 percent LCP improvement from CDN plus image optimisation alone is ordinary. One caveat: if the LCP image is not preloaded and is only discovered behind the CSS, the browser finds it late no matter how fast the CDN is.
INP: the metric a CDN barely touches
INP (Interaction to Next Paint) measures how quickly the interface responds when a user taps, and it is determined by the weight of JavaScript running on the main thread. If you ship a 900 KB bundle, downloading it from the edge in 40 ms fixes nothing; the browser still has to parse and execute it. What fixes INP is code splitting, dropping unused libraries and cutting third-party tags. Being honest here: a CDN will not rescue INP.
CLS and server response time
CLS (Cumulative Layout Shift) is elements jumping around while the page loads. A CDN helps indirectly: when fonts and images arrive quickly, fewer elements settle late. But the real fix is explicit width and height on images, font loading managed with font-display: swap, and fixed heights reserved for ad and popup slots. Likewise, if the code generating your dynamic HTML spends 800 ms in the database, a CDN cannot hide it; on a cache miss those 800 ms show up in full. A CDN does not make slow code fast, it only moves a copy of fast code closer. Missing that distinction when choosing infrastructure is a common error; we looked at it from another angle in mistakes in choosing an e-commerce platform.
Security: The Side of CDNs People Discuss Less
DDoS protection
Because a CDN routes all traffic through its own network, it absorbs volumetric attacks before they reach the origin. Most attacks small and mid-sized stores in Turkey face are not sophisticated; the edge filters them with rate limiting and IP reputation lists. Hiding the origin's real IP is part of this too: if it leaks, an attacker bypasses the CDN entirely, which is why the origin firewall should allow only the CDN's IP ranges.
WAF and bot management
A WAF (Web Application Firewall) is a rule set that inspects incoming requests and blocks SQL injection, XSS and known exploit attempts. Bot management is a separate job: you want Googlebot in and a competitor's price-scraping bot out. The practical rule is to allow search engine bots, slow scrapers with session-based rate limits, and put tighter per-IP limits on login and checkout endpoints. An overly aggressive bot rule pushes legitimate users into a CAPTCHA wall and cuts conversion; run rules in "monitor" mode first and count the false positives.
SSL termination
A CDN completes the TLS handshake at the edge near the user, which alone saves 100-200 ms on mobile connections. Certificate management moves to the provider, and automatic renewal removes outages caused by expired certificates. The connection between edge and origin must be encrypted too; a setup that only encrypts the user side is half a solution. For certificate types and validation levels, see our piece on what an SSL certificate is.
Cost and Choosing a Plan
When the free tier is enough
Under roughly 50,000 monthly page views, with a simple catalogue and sales in one country, the free tier is usually enough: static cache, automatic SSL and basic DDoS protection are all there. Where it stops: image conversion is normally a paid feature, WAF rules are limited, detailed cache analytics are missing and support response time is not guaranteed. If you cannot afford to wait when a cache rule misbehaves on a campaign day, the entry-level plan pays for itself.
How bandwidth is billed
Providers use one of three models: unlimited bandwidth plus a per-request fee, a per-GB fee, or a flat monthly package. Traffic from Turkey falls under "Europe" pricing with some providers and a separate region with others; check the contract. A practical calculation: a store with 300,000 monthly page views serving 1.2 MB per page generates roughly 360 GB of traffic. If image optimisation brings that to 150 GB, the bill falls by the same proportion — optimisation is not only a speed item, it is a direct cost item.
Plan comparison
| Tier | Typical monthly cost | Included features | Suitable bandwidth | Who it fits |
|---|---|---|---|---|
| Free | 0 TL | Static cache, SSL, basic DDoS | Fair use | Blogs, corporate sites, new stores |
| Entry | 700-1,500 TL | Image conversion, WAF rules, purge API | 500 GB - 2 TB | 100-500k monthly views |
| Growth | 3,000-9,000 TL | Bot management, edge rules, analytics | 2-10 TB | Stores with campaign peaks |
| Enterprise | On quote | SLA, dedicated PoP, log export, support | Per contract | Multi-country, high revenue |
The campaign day scenario
11.11 and Black Friday are the two dates when traffic in Turkey runs 6 to 12 times a normal day, and in sales starting at 00.00 the first 20 minutes are the critical window. Without a CDN the origin queues requests, TTFB climbs to 2-3 seconds and a large share of users leave before the page opens. With a CDN, static files come from the edge and the origin only sees cart and checkout requests — usually 10-15 percent of the total. The same hardware can carry ten times the traffic that way. At Tecof, pre-campaign cache warming and purge operations can be automated within defined permission boundaries; on the e-commerce platform side these controls are managed from the panel.
Setup: DNS, Purge and a Checklist
Routing through DNS
Setup happens one of two ways. The first is delegating the domain's nameservers to the CDN provider; all DNS records move there and the proxy switch is turned on. The second is pointing only the www and root records to the CDN's target as a CNAME in your existing DNS. For stores whose domain sits with a local registrar, the second carries less risk, because MX records and email flow stay where they are. Lower the TTL to 300 seconds beforehand, and switch during working hours on a non-campaign day.
Purge discipline
Purging happens three ways: single URL, tag-based, and full cache. Clearing the whole cache is the easiest and most expensive option; the edge empties and for the next few minutes every request goes to the origin, creating exactly the load you were avoiding. The right approach is to tie product updates to tags: when a price changes, only that product's detail page, the related category pages and its images are invalidated. If price and stock updates come from an ERP such as Logo or Mikro, a purge trigger belongs on the integration side; otherwise a price changed in the panel stays stale on the site for 30 minutes.
Pre-campaign checklist
- Cache hit ratio: If it is below 90 percent on static files, the rule is wrong — go check it.
- Cart and checkout: Verify in two different browsers that these paths carry no cache headers.
- Image format: Confirm in the network tab that product images arrive as WebP or AVIF.
- LCP image: Make sure the large first-screen image has no lazy loading on it.
- Purge path: Measure how many seconds it takes for an ERP price update to reach the site.
- Origin firewall: Verify it is open only to the CDN's IP ranges.
- Error page: Test what the edge shows when the origin does not respond.
- Mobile testing: Run the tests on a real phone over 4G, not on a desktop. For the mobile picture as a whole, mobile app or mobile-friendly site is a good starting point.
Setting Up a CDN in 30 Days
Days 1-7: measure and document where you stand
Measure before you change anything. Pick the five pages with the most traffic; for each, record TTFB, LCP, page weight and request count separately on mobile 4G and desktop. List how many KB the images are and what format they are served in. Measure the origin's dynamic HTML generation time on its own — above 600 ms, there is work to do there before the CDN. By the end of the week you should have a one-page "before" table.
Days 8-14: set up the static cache
Open the CDN account, point DNS with a low TTL, and cache static files only: images, CSS, JS, fonts. Do not cache HTML yet. Explicitly exclude cart, checkout, account and API paths, and test that exclusion. Watch the cache hit ratio; if static files are not above 90 percent, something is wrong with version stamping or cookie settings. At the end of the week, measure the same five pages again and write the difference next to the "before" table.
Days 15-21: turn on image optimisation
Enable automatic WebP/AVIF conversion and bring responsive sizes into the listing and detail templates with srcset. Add lazy loading to images below the fold, remove it from the LCP image and preload that one instead. Keep quality in the 80-85 band; lower values cause visible degradation in categories like textiles and jewellery. By the end of the week a 50-70 percent drop in total page weight is a reasonable expectation.
Days 22-30: security, monitoring and a campaign rehearsal
Turn WAF rules on in monitor mode first, count false positives for a week, then switch to blocking. Configure bot management to allow search engines, close the origin firewall to everything but CDN IP ranges, and set alert thresholds for cache hit ratio, origin error rate and LCP. Finally, run a campaign rehearsal: warm the 200 most-visited URLs, push a price update, measure how many seconds the purge takes, and put the results beside the "before" table.
Here is the job for tomorrow morning: open your highest-traffic category page on your phone over 4G, open the network tab in developer tools, reload, and note two things — the total bytes downloaded and the names of the three largest files. Those three are almost certainly product images; write down their sizes and formats, then measure how many pixels wide the same image is actually displayed on the phone screen. That gap is the first and most honest estimate of what a CDN will give you.
Frequently Asked Questions
Does using a CDN hurt SEO?
Set up correctly it does the opposite: page speed and Core Web Vitals improve, which helps search visibility. Harm comes from bad setup — redirect chains, different content in different regions, or Googlebot blocked by bot rules. After the switch, watch Search Console's crawlability and page experience reports for two weeks.
Can I downsize my origin server?
Once static traffic moves to the edge, the origin's CPU and bandwidth usage falls significantly, but go through at least one campaign period before deciding. Dynamic requests (cart, checkout, search) never pass through the CDN and they are what create load at peak.
My cache hit ratio is stuck at 60 percent — why?
Three common causes: file names carry no version stamp, so the cache empties on every deploy; query parameters (utm and similar) sit in the cache key, so the same file is stored dozens of times; or the application sets a session cookie on every response, so the CDN treats the content as personalised. All three are configuration fixes.
Do I need a provider with a PoP in Turkey?
Not strictly, but it makes a difference. With a provider that has an Istanbul PoP, domestic latency sits at 5-15 ms; with one whose nearest node is Frankfurt or Sofia, it rises to 30-50 ms. If 90 percent of your traffic comes from Turkey, a local PoP pays measurable returns; if you sell mostly internationally, global coverage matters more.
Why can the cart page never be cached?
Because the same URL returns different data to every user. When the edge stores a response without a key distinguishing who made the request, that response goes to the next user — someone else's cart, and personal data shared without consent. The only correct setting for these paths is to disable cache entirely.
Will a CDN speed up my slow server code?
No. On a cache hit the user never reaches the origin and never sees the problem, but on every cache miss your code's real duration surfaces. If a database query takes 800 ms, those 800 ms are felt in full. A CDN hides slow code, it does not improve it; the query and template side is a separate job.
Does converting images to WebP reduce quality?
With the quality setting kept in the 80-85 band, typical product photos show no visible difference while file size drops 60-70 percent. In categories with fine texture — textiles, rugs, jewellery — it is a good habit to put a few sample images side by side in both formats and have the design team sign off.
How do I warm the cache on campaign day?
One or two hours before the campaign starts, call the 200-500 most-visited URLs in sequence with a script; each request places a copy at the edge. Include the size variants of product images too. This removes the cache miss wave of the first minutes and leaves the origin idle during the most critical 20.
When should I move from the free plan to a paid one?
When one of three signals appears: you need image conversion or resizing, you need to write WAF rules for your own requirements, or you want a guaranteed support response time on a campaign day. Above 100,000 monthly page views these thresholds usually arrive together.
Will setting up a CDN cause downtime?
Not when it is planned. Lower the DNS TTL to 300 seconds a day before, switch during working hours on a non-campaign day, and watch the error rate for the first hour. If something goes wrong, reverting DNS takes minutes. What is risky is leaving the TTL at 24 hours and switching at midnight.