CDN Coverage

A CDN keeps copies of your pages and assets on servers spread around the world and answers each visitor from the closest one. Pages load faster, the origin server handles a fraction of the traffic, and a sudden spike or a denial-of-service attack is absorbed at the edge. A page that is only partly on a CDN loses most of that benefit: the browser still waits for the slowest asset, and the origin is still exposed. This auditor checks the HTML document and every first-load asset it discovers.

​

How it works

1. Fetch — downloads the audited URL once as 37AuditsBot. A blocked request ends the audit with 590; an IOException or an HTTP status of 400 or higher ends it with 500.
2. Discover — parses the HTML and collects every first-load asset: link[rel=stylesheet], script[src], img[src], every candidate of img[srcset], font preloads (link[rel=preload][as=font] and link[type*=font]), video[src] and source[src]. URLs are normalized the way browsers accept them (spaces, | and non-ASCII characters are percent-encoded). Inlined data: URIs never leave the HTML, so they are listed but not judged.
3. Classify — a resource is on a CDN when, in this order, its hostname ends with a known CDN suffix (.cloudfront.net, .cloudflare.net, .fastly.net, .akamaihd.net, .azureedge.net, .b-cdn.net and others), its response carries a CDN fingerprint header (cf-cache-status, x-amz-cf-id, server: cloudflare, server: AkamaiGHost, via: … cloudfront, x-served-by: cache-… and others), or its CNAME chain ends on a known CDN hostname. The HTML is classified from the response already fetched; each asset on an unknown hostname is probed with a HEAD request (GET when HEAD is refused). An asset whose probe throws counts as on a CDN when its CNAME points to one, otherwise it is reported with 501 and left out of the decision.
4. Rules — when no resource at all is on a CDN, every backend resource fails (400). When at least one resource is on a CDN, every backend resource warns (300).
5. Aggregate — FAIL wins over WARNING; when every probed resource is on a CDN the audit is SUCCESS (200), with the counts, the detection method of each resource and the inlined data URIs in the check data. A page whose HTML is on a CDN and whose assets all failed to probe is SUCCESS with the 501 checks attached.

​

What it audits

Every row maps to one checkRule* method and one CheckCode, in the order the auditor runs them. CheckCode suffixes use status ranges: 200 success, 300–399 warning, 400–499 fail, 500–599 error. Every per-resource check carries resource, kind (html, stylesheet, script, image, font or media), cdnDetection (hostname, headers, cname or none) and httpStatus (null when the resource was not requested) in its data. The 200 check adds resourceCount, cdnCount, inlinedCount, inlinedResources and the per-resource list.

​

Output documentation

​

Risks and considerations

​

Why CDN coverage matters

• Visitors far from the origin server wait for every byte to cross the distance; a CDN edge answers from nearby and cuts load time, which drives conversions and search rankings.
• The origin only sees cache misses, so a traffic spike, a viral post or a volumetric attack is absorbed at the edge instead of taking the site down.
• One asset that bypasses the CDN is enough to keep the page waiting and the origin exposed, which is why the audit looks at every first-load asset and not only at the HTML.

​

How CDNs are recognised

• A known hostname suffix is trusted without a request, so assets on *.cloudfront.net, *.fastly.net or *.b-cdn.net are never fetched.
• Header fingerprints cover the major providers (Cloudflare, CloudFront, Akamai, Fastly, Imperva, Google). A CDN configured to strip its headers on a custom domain is only found through its CNAME chain.
• The CNAME chain is followed through DNS for up to ten hops. A CDN reached through an A record on the customer’s own domain (for example an anycast setup with no CNAME) is not recognised, and that resource is reported as served from the backend.

​

Behavior changes in this version

• A page that cannot be fetched (timeout, DNS, TLS, HTTP 400 or higher) is now ERROR with 500; it used to be reported as FAIL.
• Mixed coverage now emits one WARNING check with 300 per backend resource; the result stays WARNING as before.
• An asset whose probe fails is now a 501 ERROR check that is left out of the decision; it used to push the result to WARNING on its own.
• The page is fetched once and ensureNotBlocked runs before any asset is probed; the old auditor probed the page before the block check and then fetched it a second time.
• Assets on a CDN no longer get one SUCCESS check each; the 200 check lists them in its data instead.
• srcset candidates are now read the way the HTML Standard does (a URL runs to the first whitespace), so an inlined data: URI with commas stays whole instead of producing a bogus backend resource from its second half.

​

What this auditor does not check

• Only the first-load assets written in the HTML are discovered; resources requested by scripts, CSS url() references and lazy-loaded images are not followed.
• Whether the CDN actually caches the resource (hit ratio, Cache-Control) is left to the Cache auditor.
• Third-party assets (analytics, tag managers, embeds) are probed like any other asset; moving them is often not in the site owner’s hands.