Why a website is slow for remote users: content delivery bottlenecks
A user from another region waits longer for a response not because the server is weak, but because every request physically travels a long route to the single point where the content resides.
Content delivery latency is made up of network "hops" between nodes and connection setup time — and for static content that doesn't change between requests, these costs are paid anew every time a page is opened.
The first byte arrives later, the browser starts parsing the markup later, and the entire rendering chain shifts to the right.
A network bottleneck manifests not only as absolute latency but also as its instability: the longer the route, the greater the packet loss and retransmissions.
Media and static files compound the picture — images, fonts, and scripts are fetched in parallel, and if each of them travels halfway around the world, the total load time grows nonlinearly.
Server response time may be normal: the handler itself responds quickly, but the user still sees a slow page.
A separate problem is peak loads. A single point of presence receives all the traffic, and when requests spike, the queue for serving static content begins to compete with dynamic requests.
As a result, "heavy" files crowd out fast responses, and degradation affects even those users who are geographically close to the server.
This is solved by offloading static content and media to a CDN with regional points of presence: files are cached on nodes near the user, and only unique requests reach the origin server.
We break down how to properly choose the geography of nodes, configure caching, and avoid breaking content updates.
What a delivery network with regional points of presence provides
Load time: the difference between "opened" and "already scrolling"
A user in a region remote from the origin fetches every resource anew — static assets travel across half the continent, and the page assembles noticeably slower than for an audience near the server.
A point of presence in the region serves content from the nearest node: load time drops by multiples, not by percentages, and this is directly visible in first-screen bounce rate.
For an online store or a service with an order form, every second of waiting means lost conversions, not an abstract metric.
Load on the origin: the server stops being a bottleneck
Static assets and media move to network nodes, and the origin handles only dynamic content and the API. The share of traffic reaching the server drops by multiples — meaning the same server can handle more users without a configuration upgrade.
We configure caching by content type: images and scripts live long, while short-lived data is refreshed predictably, with no risk of serving stale content.
Resilience to peaks: traffic is absorbed before it reaches the server
A sale, a media publication, a seasonal surge — this used to mean request queues and rising response times for everyone. Nodes take the surge on themselves and serve cached content, while the origin sees a steady flow instead of a sawtooth pattern.
We separately configure behavior when the origin is unavailable: some requests are served from cache, and the site stays alive while the server recovers.
User geography: one site — a consistent experience everywhere
If the audience is distributed across regions, the speed difference between the "home" region and a distant one disappears.
We look at the map of requests, select nodes based on actual geography rather than a generic list, and verify the result with measurements from those same regions.
Delivery organization methods: comparing the options
The choice of delivery scheme determines how long a user waits for the first byte and how the site behaves under peak load. Below are three approaches that are realistically chosen between at the start of a project or during a migration.
| Option | When it fits | Limitations |
|---|---|---|
| Own server | One region, predictable audience, sensitive data that cannot be handed off externally | No geographic redundancy: a user from another region travels the entire route. Peaks are handled only through excess hardware, and a site failure brings down the entire service |
| Classic delivery network | Audience is distributed, static assets and media make up the bulk of traffic | The cache lives at the edge, but request logic still goes to a single origin. Dynamic and personalized responses are not accelerated |
| Multi-tier scheme with regional points of presence | Audience in several countries, both static and dynamic content, resilience to site failure matters | Requires configuration of caching, invalidation, and routing rules. Without proper configuration, the gains are lost to cache misses |
The difference between the options shows up not in average response time, but in the tail of the distribution: with an own server, distant users consistently fall into the slow segment; with a classic delivery network, the tail shrinks for static assets; and a multi-tier scheme also improves dynamic requests through the proximity of the processing node.
A multi-tier scheme is not "a delivery network plus another network." It is a hierarchy: regional points of presence accept the request, serve the cache, and maintain a connection to the origin, while an intermediate tier smooths the load on it.
Caching rules are configured by content type, and invalidation is tied to the release, so an updated page appears for everyone at the same time, rather than "at some point."
Switching between schemes does not require rewriting the application: the delivery layer changes, while the logic remains at the origin. Below, we break down how this is handled in practice.
How we implement a delivery network: stages of work
We start with an audit: we take the current delivery map — which domains and subdomains are served, where static files are stored, how dynamic content is delivered, which caching headers are already set on the application and server side.
At this stage, bottlenecks become visible: usually it's a single delivery region, the lack of separation by content type, and a cache that either doesn't work or holds data longer than it should.
Next, we design the delivery scheme for real traffic, not for abstract load.
We look at user geography, the share of static and dynamic content, and data freshness requirements: where a long cache is appropriate, where an object needs a short lifespan, and where forced invalidation by event is needed.
- Infrastructure audit. We analyze the current content delivery, entry points, DNS, certificates, and the behavior of origins under peak load.
- Delivery scheme design. We determine which regional points of presence are needed, how they connect to the origin, and how traffic is distributed between them.
- Cache configuration. We define rules by content type: lifespans, cache keys, cache bypass for authorized requests and the cart, and event-based purging when content is updated.
- Route verification. We test delivery from different regions, check cache hits, response time, and correct delivery when an individual point is unavailable.
- Protection and fault tolerance. We configure request rate limiting, filtering of unwanted traffic, and behavior when the origin fails.
- Documentation handover. We provide the delivery scheme, content update regulations, and cache purge instructions — so the client's team can manage the network without us.
After launch, we compare actual metrics with the calculated ones: cache hit ratio, response time by region, and load distribution. If there's a discrepancy, we adjust the rules rather than leaving them as they are.
What the client receives after implementation
Implementation ends not with launching traffic through the network, but with handing over a package that your team can use to operate, extend, and roll back this network without us. Below is exactly what is captured in the documents and configurations.
- Network configuration as code. Files describing regional points of presence, domain and subdomain binding, and rules for switching between nodes. Everything lives in a repository, changes go through review rather than being edited by hand in a panel.
- Traffic routing scheme. A map: which region serves which requests, how load is distributed between points, and what happens when a node fails. The scheme shows where a user's request goes and where it responds.
- Caching policies by content type. For static assets, media, API, and dynamic pages — each has its own time-to-live and invalidation rules. It separately describes what is not cached and why, so that content updates appear immediately.
- Invalidation and warm-up rules. How stale content is purged after a release, how points are warmed up before peak load, and who runs this and with which command.
- Regulations for managing headers and protection. Network-level security settings, source restrictions, and handling of certificates and their renewal.
- Monitoring and alerts. A dashboard for point availability, cache hit ratio, and response time by region; the thresholds at which a notification is sent to the on-call engineer.
- Documentation and knowledge transfer. A guide to standard operations, incident postmortems, and a recording of a session with your team — so that operations do not depend on a single person.
The package remains yours: configurations, schemes, policies, and regulations can be handed over to another team or developed in-house. Describe your task — we will come back with an estimate and a plan for your environment.
Case study: accelerating load times for users from three regions
The project is a marketplace with an audience in three regions: Eastern Europe, the South Caucasus, and Southeast Asia. The origin was located in a single data center, serving static assets and media directly, without an intermediate caching layer.
Pre-work measurements: median full load time of the catalog page was 4.8 s for far users versus 1.6 s for near users, the timeout failure rate was 7.4%, peak load on the origin was 900 requests per second, of which about 80% were repeated requests for the same images and scripts.
Cloudflare was chosen not for the brand, but for the geography: points of presence were needed in each of the three regions, not just in Europe.
Caching was configured by extensions and paths, versioned assets were moved to a long retention period, while HTML was given a short one with mandatory revalidation. The cache key was tied to region and language so that users would not be served someone else's localization.
Dynamic API requests were routed past the cache, but through the nearest point of presence — this cut connection setup time in half.
Failures were addressed separately: retries were enabled at the perimeter level, along with origin health checks and automatic bypass of an unavailable node.
This eliminated the class of errors where a user saw a timeout due to a single failure on the route rather than actual overload.
| Metric | Before | After |
|---|---|---|
| Median load time, far regions | 4.8 s | 1.7 s |
| Timeout failure rate | 7.4% | 0.9% |
| Peak requests to origin | 900/s | 210/s |
| Cache hit rate | — | 86% |
Load on the origin dropped by more than fourfold — with the same traffic. Sale peaks, which previously required manual scaling, now pass without intervention.
How a delivery network with regional points differs from a classic one
A classic delivery network is built around a few large nodes spread across continents. A user request goes to the nearest such node, and from there it is routed along the backbone to the origin.
As long as the audience sits in one or two regions, the scheme works: the cache fills up, latency is predictable.
As soon as traffic spreads wider — across provinces, neighboring countries, remote branches — each new region gets the same backbone latency as before, and the difference between "near" and "far" is erased.
Regional points of presence change the topology itself. Caching nodes are placed not in three or four data centers, but in dozens of locations close to end users, and are connected to the origin via dedicated routes.
A request completes within the region: static content is served from the local cache, dynamic responses travel over an optimized channel rather than the public internet.
Architecturally, this is no longer "one big cache," but a distributed network with coordinated purge and uniform caching rules across all nodes.
The differences show up in three things. First — response time: a user in the region loses the "far" segment of the route, and the page starts responding noticeably faster.
Second — resilience: a failure of one node or backbone direction does not bring down the entire region, traffic flows over to neighboring points. Third — predictability under load: local nodes absorb peaks and serve cache without overloading the origin.
For a business, this means that audience growth in a new region does not require rebuilding the infrastructure — it is enough to expand the network's presence.
We design such an architecture for the geography of a specific project: we determine where users actually are, which nodes are needed, and how to configure caching and purge rules so that regional points of presence deliver results rather than create desynchronization of content versions.
Common technical concerns when implementing
For regional points of presence, the same questions tend to come up: will this break the current stack, where does the data go, and how do you survive the switchover without downtime. Below are short answers on compatibility, security, and migration.
Will the CDN be compatible with our current stack and load balancer?
Yes, if you set the behavior for dynamic content correctly. Static content and media are cached at the edge, while requests to the API and authorization go directly to the origin — we define routing by paths and headers.
The load balancer remains the entry point for dynamic traffic, and the CDN works in front of it only for cacheable responses. Separately, we configure forwarding of the client address and protocol so that logs and address-based restrictions don't lose their meaning.
How is security and origin protection handled?
We close the origin to direct requests: the edge communicates with it over a dedicated channel with authentication, not via an open address. Certificates are issued and renewed automatically at all points, so expiration stops being a surprise.
At the edge, we enable rate limiting and basic filtering of suspicious traffic — some attacks are stopped before they reach the application.
How does migration work, and can we roll back?
We switch over gradually: first one traffic segment, we watch cache hit metrics and the error rate, then we expand.
Caching and routing rules are stored in version-controlled configuration, so returning to the previous scheme is a configuration rollback, not manually rewriting settings.
The origin remains operational the entire time, so if metrics deviate, traffic returns to it without downtime.
What difficulties arise at the start?
The main one is incorrect caching rules: overly aggressive ones serve stale content, while overly lenient ones reduce the gain to zero. The second issue is cache invalidation on release: without a well-thought-out update strategy, users see a mix of the old and new versions.
Both tasks are handled during setup, before going live with production traffic, not after an incident.
Let's discuss your task and come back with an estimate and a plan
To propose something meaningful for regional points of presence, we need to understand your traffic picture: where users are coming from, which regions are critical in terms of latency, and where static and API delivery is currently falling short.
Describe the task — your current content delivery setup, audience geography, bottlenecks — and we will come back with an estimate and a work plan: where to place points of presence, how to configure caching and routing, and what will deliver the greatest impact on speed and stability.
On our side, we bring the following to the discussion:
- An analysis of the current delivery setup: where time is lost on the path to the user and which regions are served the worst.
- A placement map of regional points of presence for your audience — with reasoning for why these specific locations.
- A caching policy: what is cached at the edge, what is cached at the origin, and how invalidation rules are managed.
- A request routing scheme: how a user reaches the nearest point and how the system behaves when a node fails.
- An edge protection plan: limiting load on the origin, filtering out parasitic traffic, and controlling content integrity.
- A procedure for connection and migration without downtime: how we switch traffic and what we verify at each step.
- Before-and-after metrics: response time, cache hit ratio, availability by region — so the impact is measurable, not just words.
- A support policy: who responds to degradation and how, and how rules are updated as the audience grows.
Describe the task in whatever form is convenient — what the project is, what the geography is, what is concerning you right now. We will come back with an estimate, a work plan, and clear timelines, without generic talk.
