Cache and CDN: Why Page Speed Is Not Just the Database

A slow page is a path problem before it is a database problem

A teammate opens a slow page and immediately says, “We need a database index.” That may eventually be true, but the conclusion is premature. The browser may be waiting on an image, a stylesheet, a shared cache, an origin response, application work, or data access. Some resources may never reach application or database code on a given request.

This lesson builds Delivery & Cache Path Record v1. The record follows a resource through the delivery path, marks what is observed versus hypothesized, distinguishes private and shared reuse, and states what evidence is still needed before changing a layer.

The practical goal is narrow: diagnose where latency could live without turning “cache,” “CDN,” “server,” or “database” into a universal answer.

Carry forward the request path and timing model

WEBF-001 is the hard prerequisite: preserve the browser–server request/response boundary and remember that a page can require multiple resources. WEBF-004 is the soft prerequisite: preserve when a responsibility can occur—before a request, during request handling, or later in the browser—without importing that entire lesson.

This page owns only cache and delivery-path reasoning inside the split WEB-000 mental model. It does not teach cache configuration, CDN vendor setup, database tuning, framework APIs, or end-to-end performance engineering. It also does not close the full WEB-000 canonical or the chapter exit.

Trace one resource at a time through candidate boundaries

Use a path model instead of a single bottleneck label:

Browser / private cache. A cache dedicated to one user can reuse stored HTTP responses when the applicable cache rules allow it. RFC 9111 distinguishes a private cache from a shared cache. [S-RFC9111]

Shared cache / delivery intermediary. A shared cache can reuse responses for more than one user subject to HTTP caching constraints. A CDN is a distributed delivery system; CDN nodes may hold copies of content and can reduce some delivery distance or origin load, but “CDN” is not identical to “HTTP cache” and is not a performance guarantee. [S-RFC9111] [S-MDN-CDN]

Origin / server application. If an intermediary does not satisfy the request, it can continue toward the origin. The origin may serve an already-produced resource or perform current request-time work. [S-MDN-WEB]

Data boundary. Application logic may query a database or another data source, but only if that request path actually reaches that responsibility. A database hypothesis must therefore be supported by path evidence, not by the symptom “page feels slow.”

The model is per resource. HTML, CSS, JavaScript, images, fonts, and later API requests can take different reuse and delivery paths within the same page experience.

Keep reuse, freshness, correctness, and latency separate

The Delivery & Cache Hypothesis Ledger is the row-level evidence table inside Delivery & Cache Path Record v1; it is not a second artifact. For each resource or request step, record:

• Observed fact: what you actually know from the scenario or evidence.
• Resource / path step: which response or boundary you are reasoning about.
• Cache role: PRIVATE_CACHE, SHARED_HTTP_CACHE, NO_CACHE_ROLE_OBSERVED, or UNKNOWN based only on cache evidence.
• Delivery boundary: BROWSER_OR_USER_AGENT, CDN_OR_EDGE, ORIGIN_SERVER, DATA_BOUNDARY, or UNKNOWN based only on path evidence. A CDN node may also act as a shared HTTP cache, but those are two facts to record, not synonyms.
• Latency hypothesis: what could be contributing delay; keep it a hypothesis until evidenced.
• Reuse evidence: whether a stored response actually satisfied or may satisfy the relevant request under the stated evidence.
• Freshness/validation evidence: separately record what is known about freshness or validation; reuse alone does not supply this evidence.
• Correctness note: whether the content is semantically correct for the user/request; do not infer this from cache reuse alone.
• Uncertainty / constraint: what is missing or conditional.
• Next evidence: what observation would confirm or reject the hypothesis.
• Bounded decision: what you can conclude now without pretending the whole path is proven.

RFC 9111 defines freshness in terms of when a stored response can be reused without validation. That cache meaning of “fresh” is not a proof that application content is semantically correct, authorized for the user, or the newest possible business value. [S-RFC9111]

Why the familiar shortcuts fail

A cache hit is evidence of reuse, not evidence of correctness

If a stored response is reused, you have learned something about the delivery path. You have not automatically proven that its application data is correct, that personalization rules were appropriate, or that invalidation matched a business requirement. Treat those as separate questions.

A CDN can help one part of a path and leave another part untouched

MDN describes a CDN as distributed servers that can deliver copies of data closer to users. The same MDN page also notes that CDN use can introduce dependencies and can sometimes reduce performance because extra connection work may be involved. The bounded conclusion is therefore “a CDN changes the delivery path,” not “a CDN always makes a site faster.” [S-MDN-CDN]

Fast HTML does not prove a fast page experience

A browser requests and assembles multiple resources. An HTML response can arrive quickly while a later large asset or another request dominates what the learner perceives. The HTML path and the asset path need separate ledger rows. [S-MDN-WEB]

A slow origin response still does not identify the database by itself

If evidence places delay after the request reaches the origin, the candidate set narrows—but application computation, upstream services, data access, serialization, and other responsibilities can still differ. This lesson does not teach those implementations; it teaches how not to skip the evidence boundary.

Worked contrast: diagnose the path, not the slogan

Example 1 — repeated public stylesheet

A public stylesheet has already been stored by a private browser cache and is reusable for the next equivalent request under the applicable cache rules. The useful observation is that the browser may satisfy that resource without contacting the origin for the full response. The bounded decision is not “the site is cached”; it is “this resource has a plausible private-cache reuse path.” [S-RFC9111]

Example 2 — realistic product case, answer deliberately withheld

The authoritative scenario is this: HTML is fast from a shared cache, but a large browser-fetched asset dominates the experience; no database change can explain the symptom. Do not copy a completed classification from this section. Enter the observed HTML fact and the separate asset fact into Delivery & Cache Path Record v1, then decide which boundaries still need evidence. This scenario is intentionally reserved for independent evidence work.

Contrast — origin HTML plus CDN-hosted static asset

Suppose the HTML reaches the origin while a static asset is delivered from a CDN node. The two resources do not share one path simply because they belong to one page. Record them separately. A change that helps the static asset does not by itself prove anything about origin application or database time.

Two misconceptions that must block completion

Misconception 1: “If the page is slow, optimize the database.” The symptom does not identify the resource or boundary. Repair it by first naming the slow resource/request and asking whether that path even reached application/database code.

Misconception 2: “Cache hit means correct and current.” Reuse/freshness semantics answer a cache question. Application correctness and business recency require their own evidence. Repair the statement by separating reuse evidence, freshness/validation evidence, and semantic correctness evidence. [S-RFC9111]

A third overclaim is common: “Add a CDN and latency is solved.” MDN itself documents tradeoffs; the correct architectural move is to state which resource path changes and which path remains untouched. [S-MDN-CDN]

For architecture review, turn nouns into falsifiable hypotheses

An experienced review should be able to replace “cache issue” with a testable statement such as:

• “This HTML response may be reusable in a shared cache; verify the response’s cache semantics and whether the request is eligible for shared reuse.”
• “The dominant resource appears to be fetched by the browser after HTML delivery; verify that resource’s delivery path before changing origin data access.”
• “The request reaches the origin, but the current evidence does not isolate application computation from data access.”

The record should preserve UNKNOWN when evidence is missing. UNKNOWN is better than a confident layer assignment that the path does not support. Keep cache semantics and delivery location independent: “served by a CDN” does not by itself prove shared-cache reuse, and “shared-cache reuse” does not by itself identify a particular CDN.

Legitimate choices depend on content and evidence

A response may reasonably be kept private to one user, eligible for shared reuse, delivered through a CDN, served directly from an origin, or deliberately not reused. These are not maturity levels and they are not a universal optimization ladder.

A shared cache can reduce repeated origin work for eligible responses, but shared reuse can be wrong for content whose semantics require user-specific handling. A CDN can move delivery nearer to users or reduce origin request burden for some resources, while adding another dependency and connection path. Direct origin delivery may be the correct bounded choice for other resources. [S-RFC9111] [S-MDN-CDN]

The decision rule is: name the resource, preserve its correctness constraints, identify the candidate delivery path, then ask which evidence would change the decision.

Fade the scaffold in three passes

Pass 1 — guided. For a public image, a personalized HTML response, and an API response, create separate ledger rows. Record cache role and delivery boundary separately. For cache role use PRIVATE_CACHE, SHARED_HTTP_CACHE, NO_CACHE_ROLE_OBSERVED, or UNKNOWN; for delivery boundary use BROWSER_OR_USER_AGENT, CDN_OR_EDGE, ORIGIN_SERVER, DATA_BOUNDARY, or UNKNOWN. Do not collapse cache semantics and delivery location into one combined label.

Pass 2 — repair. A teammate proposes a database index before identifying the slow resource. Rewrite the proposal as a bounded hypothesis with one missing-evidence note and one explicit non-claim.

Pass 3 — independent. Use the realistic fast-HTML/slow-asset scenario. Remove the layer hints. Complete Delivery & Cache Path Record v1 with observed facts, candidate latency location, uncertainty, next evidence, and at least two non-claims. Do not use “CDN,” “cache,” or “database” as an answer unless the path evidence justifies the term.

What counts as inspectable evidence

A complete Delivery & Cache Path Record v1 must:

1. map at least the relevant browser/private-cache, shared-cache/CDN, origin/server, and data boundaries without pretending every request visits all of them;
2. separate observed facts from latency hypotheses and architecture decisions;
3. distinguish cache reuse evidence, freshness/validation evidence, and semantic correctness evidence from one another;
4. state uncertainty and the next evidence needed;
5. include at least two explicit non-claims;
6. keep current technical claims tied to the three declared sources;
7. avoid claiming completion of the whole WEB-000 canonical or C01 chapter exit.

No coding Lab is required because this lesson assesses bounded diagnosis and decision reasoning rather than implementation execution.

Assessment ladder

1. Retrieval: distinguish private/shared cache, CDN delivery, origin/server, and data boundaries without turning them into one path.
2. Application: map a new multi-resource page symptom into separate ledger rows and state what is observed versus hypothesized.
3. Diagnosis: repair a claim that equates cache reuse with correctness/currentness.
4. Decision: choose a bounded cache/delivery decision for a scenario and state evidence that could invalidate it.
5. Transfer: diagnose the authoritative case where HTML is fast from a shared cache but a large browser-fetched asset dominates the experience and a database change cannot explain that symptom.

Diagnosis, decision, and transfer are blocking. A product or vendor name is not evidence. The final response must preserve uncertainty and non-claims.

Declared sources and freshness boundary

This lesson uses exactly three sources frozen in the Bible:

• S-RFC9111 — RFC 9111, HTTP Caching: cache storage/reuse semantics, including private and shared caches.
• S-MDN-CDN — MDN CDN glossary: CDN delivery concept and explicit tradeoffs; not a guarantee that CDN use improves every site.
• S-MDN-WEB — MDN How the web works: high-level browser request, server response, resource delivery, and browser assembly context.

All three were rechecked on 2026-09-10 and remain compatible with the declared claim boundaries. The source set was not expanded. Review is due no later than 2026-12-31, or earlier if the reference material changes a claim used here.

Final non-claims: a CDN does not replace a database; a cache hit does not prove semantic correctness; adding a CDN does not always make a site faster; this lesson does not own the complete WEB-000 mental model.