Configuring KeyCDN CDN: where a site loses speed and what breaks
While a site is opened from an office next to the server, slow site loading isn't visible: the page is assembled in fractions of a second.
For an audience in another region or country, the request travels a long route through dozens of intermediate nodes, and each link adds delay — page response time grows several times over.
Images, fonts, styles, and scripts "get heavy" first: they weigh more than markup, and they are served from the same server.
The second bottleneck in content delivery is spikes. A newsletter publication or social media post triggers a wave of requests, and the server simultaneously assembles pages and serves static content.
The channel and number of worker processes hit a ceiling, some requests time out, and part of the audience sees a white screen instead of the catalog.
At the same time, the static content itself is the same for everyone — there's no need to compute it on the server for each visitor.
The third reason is repeat requests. If caching headers and TTL are not set, files are transferred again on every visit; if file names are not versioned, the cache either doesn't update or is reset entirely.
Add uncompressed delivery and no edge layer — and most traffic goes through the application server, even though it shouldn't.
As a result, for some visitors the site is blazing fast, for others it lags, and it's the same build.
We break down how this is solved: how the delivery network is structured, what exactly to cache, how to serve static content past the application server, and how to tie this to releasing new versions.
What content delivery provides: latency, failures, and load
Faster page loading
The main weight of a page is static content and media: images, fonts, scripts, video. When they are served by the network node closest to the visitor KeyCDN, rather than your server, the browser receives a response without waiting for a full round trip to origin.
Time to first render is reduced much more noticeably than by any backend optimization, because the very cause of delay is eliminated — distance.
A separate effect comes from a well-designed caching policy: versioned files are marked with a long lifetime, and invalidation happens by tag rather than by resetting the entire cache. Releasing an update doesn't force visitors to re-download the entire asset set.
Reduced server load
On a typical site, 70–90% of requests are repeat delivery of the same files. If they are covered by cache on nodes, only dynamic content, APIs, and authorized scenarios reach the application.
Server load drops proportionally to the share of static content, and freed-up resources go to what actually requires computation.
Practical consequence: the same server handles a multiple of the traffic without vertical scaling — it's cheaper than adding capacity for a peak that happens a few times a month.
Fault tolerance during spikes
A spike from an ad campaign, newsletter, or media publication used to mean a queue of requests and timeout failures.
With distributed delivery, traffic spreads across nodes, and a slow or unavailable origin serves a previously cached response — the class of failures "site is down under load" simply goes away.
Behavior during a failure is configured separately: while the server recovers, visitors continue to receive static content and media. For the user, service recovery time is measured not by server startup time, but by cache lifetime.
Content delivery options: CDN, directly from the server, hybrid
Choosing a mode means choosing where the cache sits and what passes through it. When an intermediary accepts all traffic, it terminates secure connections, serves static content from edge nodes, and keeps copies of HTML, while the origin receives only cache misses.
Modes should be compared by three parameters: what falls under caching, how quickly a stale object is replaced, and what happens to personalized requests.
In KeyCDN, this is defined by rules based on paths, extensions, and request headers, with tag-based purge — the accuracy of the key determines whether a user gets acceleration or someone else's session.
| Option | When it fits | Limitations |
|---|---|---|
| Full proxying through an intermediary | Public content without authorization: catalogs, landing pages, media | Strict caching rules are required based on headers and authorization indicators; an error in the key serves someone else's session |
| Static-only caching | Stores, personal accounts, services with login | The origin handles dynamic content; peak load falls entirely on it |
| Direct serving from the server | Internal systems, traffic in one region, debugging | Speed depends on distance to the server; no protection from spikes |
| Hybrid delivery scheme | Different geographies, peaks, sensitivity to data freshness | Separate rules, revalidation, tag-based purge — configuration is more complex |
A hybrid scheme usually provides lower latency for static content and predictable freshness for dynamic content, but it requires discipline: rules are described explicitly and stored with the code. Then changing the mode is an edit to configuration, not a frontend rewrite.
Implementation stages: from request audit to handover to support
Implementing a CDN is not just switching a domain, but a sequence of work where each next action relies on data from the previous one.
The order is the same for a static site and for serving dynamic content via KeyCDN: first traffic data, then placement design, then configuration and verification. Below is how it looks in our practice.
-
Web traffic audit. We capture request logs for working days and weekends, group requests by resource type: share of static content, delivery volume, client geography, response codes. The output is two lists: paths that are cached and paths that must go directly to the origin.
-
Cache scheme design. We define rules by paths and extensions, time to live for each resource class, and the cache key taking into account relevant request parameters. Versioned file names and URLs with a user identifier are handled by different rules.
-
Zone and origin setup. We create a zone, specify the origin address, headers for passing the original client address, and restrict the origin with an address list or token — so that bypassing the CDN does not leave the server open.
-
Cache purge in the publishing pipeline. After a new version is released, only the affected file sets are automatically purged by tags, not the entire cache: deployment does not evict from cache what has not changed.
-
Verification on live traffic. We compare delivery directly and through the CDN, look at cache hit ratio and response codes, then migrate the domain to the CDN in increments rather than with a single switch. A sufficient hit ratio is the criterion for readiness for full load.
-
Handover to maintenance. We provide the flow diagram, rule table, rollback procedure, responsibility matrix, and monitoring regulations. Support engineers know which metrics to watch and what to do when the hit ratio drops.
List of deliverables: configurations, diagrams, regulations
The handover package is assembled so that a month later the client's team can change cache behavior, connect domains, and roll back a disputed release without us.
What is handed over is not a set of screenshots, but a working description of the setup and access to the KeyCDN panel and repository.
- Zone configuration files and caching rules in the repository: origin sources, domain binding, retention periods by content type, cache and bypass headers for dynamic paths.
- Route map and request flow diagram: where distribution between origins is enabled, where spike protection kicks in, and which nodes serve static content.
- Cache invalidation regulations: when a targeted purge by URL is sufficient, when a group purge by tags is needed, and when a full purge is required and why it is an emergency — the hit ratio drops and all traffic goes to the origin.
- Rollback instructions: switching delivery directly to the origin, removing the disputed rule, restoring the previous configuration revision — with an estimate of time for each operation.
- Maintenance regulations: who is on duty, which events they respond to, and which cache hit ratio, response time, and error count values are considered a reason to intervene.
- Infrastructure documentation: stand diagram, procedure for connecting a new domain and subdomain, requirements for certificates and their renewal deadlines.
- Handover procedure: roles and access, walkthrough of the build and deployment pipeline, acceptance on live traffic, and the window during which we remain available after launch.
The result is an autonomous setup: changes are made by editing configuration and deploying, not by exchanging messages with a contractor.
Case study: reducing response time and downtime on a real project
The project is an online store with a large catalog: product images, static content, and some catalog pages were served directly from the origin server.
On normal days this held up, but on promotion days median response time grew, and during planned service updates the site became unavailable for several minutes — exactly when traffic is at its peak.
The analysis showed two causes: the origin server spent resources serving immutable files and had no layer to keep content closer to the visitor.
We moved static content and media to KeyCDN and configured caching rules by content type: long lifetime for versioned files, short for HTML pages, with tag-based purge on publication.
Deployment was rebuilt so that only changed paths are purged on release, while the rest remains in cache.
| Metric | Before | After |
|---|---|---|
| Median response time | 1.3 s | 0.4 s |
| Cache hit ratio | 0% | 92–95% |
| Share of requests to the origin server | 100% | 8–12% |
| Unavailability on a peak day | 4–6 min | 0 |
The origin server stopped being a bottleneck: during peak periods it serves only dynamic content and order processing, while content is delivered from the nodes of the delivery network closest to the visitor.
The share of requests to the origin server dropped by almost an order of magnitude, so peak load on it no longer depends on the volume of traffic for images and static content.
Updates are rolled out without a downtime window — the cache version switches with one action, and rollback to the previous build takes seconds.
How does visitor-side cache differ from service-side cache?
Cache operates on two levels, and confusing them is the source of most freshness problems. The first is the visitor's browser cache: a copy of the file resides on a specific device, and we cannot see who is using it.
The second is the edge cache on the delivery service side: one copy is served to thousands of visitors from the nearest point without reaching the origin server.
Browser cache saves the most expensive load — a repeat one during page navigation. It cannot be controlled directly: after the response is served, the decision is made by the device based on cache control headers.
Therefore, a file is updated not "on top", but by changing the URL — the build adds a content fingerprint to the name, and the new version becomes a different resource for the browser.
Edge cache solves a different task: it removes peak load from the origin server and reduces response time for remote visitors.
Here we control cache lifetime — we define rules by file types in KeyCDN, and tie purge to the release event: after publication, the new version is served immediately, without waiting for the lifetime to expire.
Content freshness is a trade-off configured separately by resource class. Static content with a fingerprint in the name can be given a long lifetime, while pages and data can be given a short one, with revalidation against the server.
The levels do not replace each other: aggressive browser cache speeds up repeat visits but does not protect against a peak on the origin server, while configuring the edge without versioning URLs will leave some visitors on the old copy.
Technical concerns: invalidation, privacy, rollbacks
Serving static content from the node closest to the user is not difficult. Difficulties begin where you need to purge a stale object, avoid serving someone else's personal account from a shared cache, and preserve a clear path back. Below are answers to questions engineers ask before starting.
How is the cache purged after a release?
We build purging on two levels: targeted invalidation by tags for objects updated with each release, and full purge for everything else.
Static content — images, fonts, styles — lives with a long lifetime, while markup and data have a short one, so after publication the user receives the new version, not a mix of old and new.
What about private data and personal pages?
Caching of private pages is explicitly disabled: the cart, personal account, and everything served after authorization bypass the shared cache.
Protection of private data relies on a rule prohibiting storage of session-bound responses — this is described in the configuration, rather than left to the implementer's discretion.
Is there a rollback plan to the previous scheme?
The rollback plan is prepared before launch: traffic returns to the origin server by switching a record in the KeyCDN panel, and previous settings are stored in the repository alongside the current ones.
Rollback takes minutes and does not turn into an investigation of what changed and when — the configuration version is always at hand.
Let's discuss the task: we'll review the setup and come back with an estimate
Estimating the scope of website acceleration work only makes sense with real inputs.
Therefore, before calculating, we review how content is currently delivered, where traffic comes from, and which node is slowing down delivery — the server, the network, or the lack of edge caching.
Below is what to send so that the call immediately becomes a substantive conversation rather than requirements gathering.
- Domain, DNS scheme, and how static content is currently served: directly from the server, through a reverse proxy, or already through a delivery network.
- List of content types — images, scripts, styles, fonts, media — and which of these are generated dynamically.
- Current measurements: server response time, cache hit ratio, visitor geography, and their distribution by region.
- Build and deployment scheme: where the repository lives, how a release reaches production, and whether there are automated checks before publication.
- Constraints: data storage requirements, access to the registrar, delivery panel, and hosting provider, and windows when configuration can be changed.
- Who on your side approves DNS changes and certificate issuance.
On the call, we'll review which nodes provide the main gain, how object lifetime and cache invalidation on release are configured, and how to integrate delivery into automated deployment.
You'll receive an infrastructure work plan as a document: stages, scope of changes, activation procedure, rollback points, and acceptance criteria at each step. Describe the task — we'll come back with an estimate and a plan.