Why Azure CDN does not speed up a site: breakdown of typical failures
Connecting Azure CDN by itself does not speed up a site.
If caching rules, certificates, and the purge procedure are not configured for the actual static asset structure, metrics do not change: response time remains the same, origin load does not decrease, and some visitors see broken pages. Content delivery is not a switch, but a set of interrelated configuration parameters.
The most common failure is the cache serving a stale version of static assets. The edge relies on cache headers from the origin: if they are missing or the time-to-live is set incorrectly, files either are not cached or remain in cache after a release.
After a new version is deployed, the browser receives an old script mixed with new styling — the interface falls apart, and the form does not submit.
The second failure is HTTPS breaking on the static subdomain. The certificate is issued for the main domain and does not cover the separate subdomain, or an incomplete certificate chain is served. The browser blocks such resources: the page opens but is left without images and styles.
The third failure is that the origin is not offloaded. If the edge does not serve static assets from cache, every request goes to the application server, and a traffic spike brings it down just as it would without content delivery.
A separate cause is manual cache purge after a release: it is performed not for all paths, and some users see a mix of versions for a long time. We will review how each of these failures is resolved.
What configured caching provides: measurable effects
The edge on Azure CDN changes the origin load profile: some requests simply do not reach it. Below are three effects that are visible in metrics after configuration, rather than in a report of work done.
Origin offload and peak load relief
Static assets — images, fonts, scripts, styles — are served by the point of presence closest to the user, not by the application server.
The origin retains requests to dynamic content and the API, so during a peak — campaign launch, catalog publication, mass employee login — it receives several times fewer concurrent connections.
Cache rules by extension and a separate short time-to-live for markup provide a predictable hit ratio instead of “cache everything.”
Stable page response time during traffic surges
When traffic grows severalfold, response depends on the availability of a ready copy and the distance to the serving edge, not on server capacity.
Static assets with a long time-to-live are served from cache without hitting the origin, so the response time graph remains flat instead of dropping at the peak.
A load test before and after configuration shows the difference in the distribution tails, not in the average — that is exactly where problems are visible.
Unified HTTPS and correct redirects on all domains
The certificate lives at the edge: renewal and key rotation do not depend on the web server configuration.
A redirect rule brings the main domain, aliases, and HTTP to a single canonical form while preserving the path and query parameters, so search engine bots are left with no duplicates.
Cache purge is triggered from CI/CD immediately after release — updated files are available without manual actions and without a window where some users see the old version.
Azure CDN profiles: comparison of delivery options
The delivery profile determines which caching rules are available: the standard set has general settings, while the advanced one has rules by paths, extensions, and request headers.
The choice should be finalized before switching the domain: some options are not interchangeable without changing the entry point.
| Option | When it fits | Limitations |
|---|---|---|
| Standard delivery profile | static assets, identical logic for all sections | general settings, no rules by path |
| Profile with advanced rules | API, static assets, and media have different time-to-live | rules need to be versioned and tested |
| Custom reverse proxy with cache | need control over cache key and invalidation | a separate node that must be operated |
| Cache at the origin | authorized responses, private data | the channel is not offloaded, gain only on repeats |
Caching rules by paths
A rule by path ties behavior to an address prefix: /api/ — no cache, /static/ — one hour, /media/ — one day. The first match usually stops evaluation, so exceptions are placed above general masks; otherwise, personalized responses will go into the shared cache.
Rules by file extensions
Rules by extension (.css, .js, fonts, images) are easier to read and cover the entire build.
The weak spot is addresses without an extension and version parameters in the query: they are described separately; otherwise, after a file update, the client will receive the previous copy.
In practice, an advanced profile on top of origin cache provides a predictable static asset time-to-live and purge via API from the build process — without waiting for expiration after deployment.
Implementation procedure: from content audit to handover
We configure caching in Azure CDN in iterations: first we establish what exactly is being served, then we describe the rules, and only after that do we enable main traffic.
The procedure excludes the case where the cache is already serving content but the rules for it have not yet been set.
- Inventory of domains and content types. We collect names and subdomains, label static assets, media, build files, and service responses. For each type, we note whether it is cached or bypasses the cache.
- Caching scheme. We set retention periods by file groups, rules for accounting for the query string, and update behavior: versioned files get a long time-to-live, entry points get a short one.
- Domain binding. We connect the point of presence, bind the domain, and verify that DNS records match and that serving order is correct.
- Certificate and HTTPS. We issue a certificate, enable forced HTTPS and redirects, and verify the chain on each subdomain.
- Cache purge in the pipeline. We embed a purge step after publication — the build itself invalidates what has changed, without manual actions by the on-call engineer.
- Verification and handover. We run the scenarios, record the result, and hand over access, the scheme, and the regulations.
Scenario verification
We build verification on real paths: updating an individual file, a full release rollback, certificate change, purge by mask. We consider a scenario passed only when the new version is visible at all points and the old one does not come back from intermediate caches.
First release and handover
We conduct the first release with a reduced traffic share: some requests go through the delivery network, some directly.
When the cache hit ratio and serving time match expectations, we switch the entire flow and close the stage with handover of access, the scheme, and the regulations.
Documentation, schemes, and regulations after implementation
After Azure CDN is launched, the customer's team has a set of documents according to which changes are made without us. This is also the entry point for a new engineer: it shows why a caching rule is set exactly this way and what will happen during a rollback.
Configuration and access rules
- Caching rules as a ready configuration: a file in the repository where retention periods are set by paths and extensions — static assets with a long time-to-live, HTML and API responses with a short one or full cache bypass.
- Point-of-presence map: which edge nodes serve the audience, where compression is enabled and where capabilities are limited, so that rules do not include things that will not work in some regions.
- HTTPS and redirect settings: certificate binding (managed or custom), forced redirect from HTTP, minimum TLS version, path rewrite rules.
- Access matrix: who changes rules, who only views metrics, who triggers cache purge.
Release procedure
- Built-in cache purge step: after deployment, the pipeline invokes purge by path mask and tags, waits for confirmation, and proceeds only on success — otherwise, the release stops.
- Version release order: build, deploy, purge, warm-up, verification — with a note on which steps are safe to repeat.
- Instructions for verification and metric collection: control requests to key paths, cache status in the response header, hit ratio and edge response time, with thresholds for rollback.
Case study: how the origin was offloaded and response stabilized
What it was like before configuration
A storefront with heavy static assets: catalog images, styles, scripts, fonts. The cache on Azure CDN used one short time-to-live for all file types and without binding to build versions — only a third of requests were served from cache, and the rest went to the origin.
During peak hours, response time grew along with traffic, and after a release, a separate class of failures surfaced: for several minutes, the markup referenced files that were not yet at the edge.
What was done
We separated caching rules by content type: versioned build files got a long time-to-live, HTML got a short one with mandatory revalidation, and API responses were excluded from cache.
We added a purge step to the pipeline — the cache is invalidated by masks after artifact publication and before traffic switching.
What metrics were obtained
The cache hit ratio grew from a third to a majority — about four fifths of requests. Requests to the origin decreased by approximately three times, and response time at peak stopped growing: it remains at the level of off-peak hours.
The “broken static assets after release” class is closed — the mismatch window between deployment and invalidation has been eliminated.
No rollbacks were required: previous artifacts live in cache until the end of their time-to-live, so returning to the previous version remains instantaneous.
How does cache purge differ from static asset versioning?
In Azure CDN, a forced purge removes an object from edge nodes without waiting for the cache time-to-live to expire.
The operation is asynchronous: a response comes immediately, but propagation across nodes takes minutes, so a window remains between deployment and guaranteed new content.
Purge is set by exact path or by mask — a mask is more convenient but affects everything matching the pattern.
Static asset versioning solves the same task differently: the build puts a hash in the file name, and the markup references the new address. The previous file remains available, the new one has not yet been seen on edge nodes — invalidation is not needed in principle.
A side effect is that old versions accumulate in storage, so they are cleaned up by a separate lifecycle rule.
The choice is dictated by whether the name can change. Scripts, styles, fonts, and images are versioned, and they are given a long time-to-live with an immutable flag — the browser stops revalidating.
Addresses with a fixed name — markup, manifest, configurations — are not versioned this way, and only purge remains for them.
In practice, these are two policies in one delivery setup. Markup is served with a short time-to-live and purged by mask from the build pipeline; assets are served with a long one and without purge at all.
Cache purge by a mask like a catalog with all assets is risky: mass invalidation drives traffic to the origin and easily hits a load peak.
The result: changing the name is the norm for built files, purge is for fixed addresses. Mixing both strategies in one rule is not advisable.
Common technical questions about cache and HTTPS
Edge cache does not cancel application logic: first the origin decides whether the response depends on the user, and only then does the response enter edge storage.
Therefore, almost all doubts during configuration handover concern where the boundary between static assets and a personalized response lies, and who controls it: an edge rule or origin headers.
Below are five questions that most often come up during acceptance and in the first weeks of operation.
Can dynamic pages with personalization be cached at all?
Yes, but selectively. Requests with authorization cookies and the authorization header bypass the cache; only anonymous GET requests are cached.
For personalized pages, the origin sends a no-store directive — then the edge does not hold the response even for a second, and data does not leak between users.
Why do some users see the old version of a page after a release?
Version mismatch occurs when markup and interface files have different time-to-live values. We serve markup with a short time-to-live, and files with a long one and a hash in the name, so that old and new sets do not mix on the same page.
Cache purge for changed paths is performed in the build pipeline before traffic switching: invalidation does not propagate across nodes instantly.
What happens to the site when the certificate is renewed?
A managed certificate is renewed automatically if the domain points to the edge via a CNAME record and is not proxied by a third-party service — domain ownership validation is performed via DNS.
With a custom certificate, the new one is uploaded in advance, and the previous one remains active until the overlap ends: connection interruption and browser warnings do not occur.
Changes at the origin do not appear — what should be checked first?
First, the origin's own headers: they take priority over edge rules. Then, whether the query string is part of the cache key: if it is not, addresses with different parameters return the same response.
And third, whether the cookie bypass rule is too broad, causing the cache not to be populated at all.
How can you make sure the cache is actually working?
We look at the hit indicator and response age in the headers, not just the load time in the browser. We check from several regions and for different file types, then codify the check in the pipeline: after cache purge, the response must update. This way, configuration regression is caught before user complaints.
Let's discuss the task: what to prepare before work starts
Estimating Azure CDN configuration is accelerated exactly as much as the input data is complete. When domains, content types, and the environment scheme are collected piecemeal, we spend time on clarifications instead of designing caching rules. Below is the minimum set with which we can immediately calculate the architecture.
- List of domains and subdomains — with a note on which serve static assets, which proxy the API and should not be cached at all. Separately — plans for new names and certificate binding order.
- Content types and static asset shares — which paths we cache for a long time, which we revalidate on every request, and where content changes frequently. This determines rules by extensions, paths, and response headers.
- Environment scheme — how many environments there are, how staging stands are separated from production, whether separate profiles are needed, and how traffic is distributed between origins.
- Current HTTPS state — where certificates are issued, whether custom ones exist, whether forced redirection and a minimum protocol version are required.
- Version release procedure — how builds are currently deployed, what triggers cache purge, and what should happen during a rollback to the previous version.
- Access rules and roles — who manages the profile, how permissions are granted and for which environments, and whether isolation between teams is needed.
- Origin constraints — private storage, load balancers, geographic restrictions, and requirements for request logs.
Describe the task within this scope — we will return with an estimate and a work plan, including the caching scheme, HTTPS connection procedure, and the cache purge step in the release pipeline.