Why a site may miss the cache on its first visit

A website can look ordinary and still seem to reload every image, script and page on a visitor’s first visit. Whether the visitor is in Sydney or Melbourne, the first load may take longer while a second visit feels instant. That pattern usually indicates a cold cache rather than a broken website, although redirects, cookies and routing can obscure the cause.

Cache can sit in several places. A browser keeps selected files, a content delivery network keeps copies near users, and an application server may keep prepared data in memory. A request can miss in one layer and hit in another. The first visit tells us little until we identify which layer answered, which URL was requested and whether reuse was permitted.

The sparse page associated with this behaviour gives one clue: its visible link points back to the same domain with a tracking-style query parameter. That does not reveal the site’s purpose or prove caching is disabled. It does create two URL forms, however, and cache systems may treat them differently.

A first request can be a cache miss

Nothing is cached until a response is received, stored and judged reusable. On a new browser profile, the HTML request must reach a server, which must return a cacheable response before reuse. A cold CDN location has the same issue. The first request is a cache miss by definition; what follows is the useful test.

A page can mix policies neatly. Its HTML may be short-lived because prices or news can change, while a fingerprinted script is kept for a year. Images may load only after the visitor scrolls. The first visit then starts several cache fills, making the page look uncached when it is really a sequence of first-time asset requests.

A repeat request can still require network communication. If an expired browser entry is validated with an ETag or Last-Modified date, the server may return 304 Not Modified without the full body. DevTools labels that differently from a disk-cache hit, so a small network request does not mean the resource was downloaded twice.

Redirects and tracking parameters can split reuse

Redirects add another layer. A 302 or 307 response normally sends the browser onward without permanent reuse, while a 301 or 308 can be cached under common conditions. Reuse also depends on the destination’s headers and browser history. A chain through a tagged URL may produce a fresh lookup at every hop.

The interest in minimal sites for campaigns shows why simple pages can remain technically busy. A test URL might carry a traffic source, visitor ID or timestamp. That assists attribution but can defeat a shared cache when the query forms the cache key. The visible design says little about the headers behind it.

The same-domain link may add its parameter after the click rather than on the initial address. The landing page can then be cached normally while the tagged destination begins with a miss and redirects again to a canonical address. A Network panel showing 200, 302 and 200 responses is more informative than the final screen.

Headers and variations shape reuse

Cache-Control is the main instruction. public, max-age=600 permits reuse for ten minutes, private restricts storage to one browser, and no-store asks caches not to keep the response. no-cache means a browser may store the file but must check with the server before reusing it. Shared proxies can receive a separate s-maxage value.

Vary decides which request fields distinguish copies. A response marked Vary: Accept-Encoding may be stored separately for compressed and uncompressed forms. Vary: Cookie can multiply variants when a visitor has a session. Pages may also negotiate language or device type, so each apparent page view can become its own first visit.

A busy page such as live sport headlines can justify different freshness rules for changing text and static branding files. Comparing response headers for the page and its assets reveals whether they share one policy. Age, ETag and Last-Modified show whether an edge copy is fresh or being revalidated.

Cookies can change what gets reused

Cookies can turn an anonymous request into a personalised one. On the first visit, the server may set a session cookie, remember consent choices or identify a returning subscriber later. Shared caches are cautious about responses carrying user data, and some are configured not to store them. Once the browser sends that cookie, the cache key may change or the response may be private.

Consent interfaces complicate the sequence. The first response may contain a generic page and banner, then a request records the choice and returns another version. If that response included Set-Cookie, a CDN might bypass it. Australian sites operating under the Australian Privacy Act 1988 and Australian Privacy Principles may need to prevent personal information being exposed through shared caching.

This is not merely a compliance checkbox. If a page alternates between cached and uncached versions, an Australian marketer may see unstable campaign counts or different content in different cities. A visitor in Brisbane could receive a personalised variant while someone in Adelaide receives a generic one because a nearby edge had stored it.

Australian routes and CDN edges matter

Geography affects cache hits as well as speed. A CDN may have a warm copy in Sydney but none at the edge serving Perth, so two Australians can receive different response headers. Each edge normally maintains its own cache. A popular object can warm quickly around Melbourne and Brisbane while a less common page stays cold until a request reaches the origin.

The route to the origin still matters on a miss. Australian traffic may cross several networks, and fixed-line NBN can have a different path from mobile data. Some NBN premises use fibre to the premises, while others rely on fixed wireless or a copper-to-node connection. A slow first response may therefore be distance or congestion rather than caching.

DNS resolution and the TLS handshake are often cold too, even when no content is downloaded. A browser can reuse a DNS result or TLS session, while a CDN keeps the object nearby. Network timings separate connection setup, server wait and content download. This matters when someone says the site was slow “this arvo” without revealing whether they used home broadband, the train or mobile data.

Browser storage and service workers

Browser storage has limits and rules of its own. Private windows, new profiles, low disk space and stored-site data can reduce reuse. Browsers may partition cached material by site or top-level destination, so a file downloaded after one redirect can be unavailable later. Third-party scripts and analytics also create traffic the page owner does not control.

Images deserve separate attention. A gallery such as the official Pokémon anniversary collection may use large photographs and delayed loading. The first visit can request a preview, then full-resolution files as the visitor moves through the set. A recurring spinner may mean an image is being fetched and painted, not that the browser ignored a usable cached copy.

Service workers can change what a later visit does. A worker may serve a cached application shell, update an old version in the background or choose network-first content. That can look inconsistent because the first and later visits follow different pathways. A worker cannot retrieve something it never stored, so the initial load determines what is available offline.

How to identify the first miss

Start with the Network panel and preserve the log across a reload. Record the document request, every redirect and each asset’s status. Look for a memory-cache hit, disk-cache hit, 304 response, CDN cache header or “from disk cache” label. Repeat the visit in a clean session. Different clean-session behaviour points toward browser state rather than the origin.

Request the original and tagged URLs separately, comparing Cache-Control, Vary, Set-Cookie, Location and Age. Test with and without campaign parameters, because a CDN may ignore some query strings while preserving others. Command-line header checks should include realistic compression and cookie headers. Blocking scripts one at a time can reveal a client-side preference that changes the request sequence.

The likeliest explanation is often mundane: the first visit populated the cache, and the next reused it. A cache-busting query, redirect, personalised response or cold CDN edge can make that happen on a URL different from the one people think they visited. When the first request reaches the origin and the second returns a local copy or a validation response, the site is showing normal cache warming rather than a failure.