Why the second visit can be faster
Explore how controlled reuse changes a web request, from cached naming information to a response stored near the reader.
Ask for a familiar resource
You return to a page or request an image you have seen before. The browser may already hold information from an earlier visit. This does not guarantee a faster load: the resource may have changed, its reuse rules may prevent caching, or the device may need to do substantial processing again.
Previously stored information can change the work required.
Reuse can avoid repeating an eligible operation.
Read the complete journey
- 1
Ask for a familiar resource
You return to a page or request an image you have seen before. The browser may already hold information from an earlier visit. This does not guarantee a faster load: the resource may have changed, its reuse rules may prevent caching, or the device may need to do substantial processing again.
Notice: Previously stored information can change the work required.
Explore The browser
Why: Reuse can avoid repeating an eligible operation. - 2
Reuse a valid naming answer
A resolver can reuse DNS records while their caching rules permit it, avoiding some repeated lookups. This is a cache of naming data, not a saved copy of the website. A valid DNS answer can shorten one dependency without changing the work needed to fetch and render the page itself.
Notice: A cached DNS record supplies naming information only.
Explore DNS & domain names
Why: A reused lookup can shorten discovery without retrieving the page. - 3
Check whether a stored response is reusable
For an HTTP response, the cache checks the relevant request and response metadata and freshness rules. If a usable fresh response is available locally, a download may be avoided. Some cases instead require validation with a server, which can save the body transfer while still involving a network exchange. Eligibility matters.
Notice: Freshness and validation rules determine response reuse.
Explore Caches & content delivery
Why: The cache must distinguish a suitable copy from merely stored data. - 4
Reach a closer serving location if needed
When the browser must fetch a resource, a distributed service may direct it to a nearby or otherwise suitable serving point. The selected point need not be the geographically closest one. Provider policies, routing, load, and availability influence selection, so the diagram makes no promise about a particular distance or speed.
Notice: A selected serving point can differ from the origin.
Explore Network interconnection
Why: Distributed delivery can reduce some travel and origin work. - 5
Go to the origin when the copy is insufficient
If the serving cache lacks a suitable response, it may retrieve one from the origin or another upstream service. The origin may generate fresh content. The response’s caching instructions then affect future reuse. Different resources on the same page can have different rules and take different paths. Different resources can have different reuse rules.
Notice: A miss or unsuitable response requires upstream work.
Explore Web servers & HTTP
Why: The origin remains necessary when a reusable copy cannot answer. - 6
Render the result again
The browser still needs to assemble the resources into a usable page. Reusing data can reduce network work without eliminating layout, painting, or script execution. The visible benefit depends on which part of the experience was slow. Caching is a targeted optimisation, not a universal cure for delay. Rendering remains real work.
Notice: The browser still assembles the visible result.
Explore The browser
Why: Network reuse does not eliminate local document processing.
Can a cached DNS answer replace an HTTP download?
Reveal the explanation
No. It reuses naming information. Avoiding an HTTP body download requires an eligible response cache or another application mechanism, with its own reuse rules.
Sources & further reading
Original explanations informed by these sources. Diagrams are conceptual; local systems differ.
- RFC 1034: Domain names — concepts and facilities IETF / RFC Editor; P. Mockapetris · 1987-11 · Source & rights record
- RFC 9111: HTTP Caching IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
- RFC 9110: HTTP Semantics IETF / RFC Editor; R. Fielding, M. Nottingham, and J. Reschke (editors) · 2022-06 · Source & rights record
- Populating the page: how browsers work MDN Web Docs / Mozilla contributors · Not stated · Source & rights record
- The Internet Way of Networking: Defining the critical properties of the Internet Internet Society · 2020-09-09 · Source & rights record
Another way through the system.
Load a page on your phone
A request across a network of networks.
When a network path breaks
Redundancy helps only when it is usable.
Send a photo while moving
Radio is the first part of a much longer trip.
Why a fast link can feel slow
Separate capacity from the waiting between actions.