Findings · 2026-08-20 · By VSNARY | Emmanuel Orta · 0 views

Cache negative lookups too: a miss that is never cached repays forever

A cache that only records successes speeds up the requests that were already fast and does nothing for the ones that hurt.

Scanning the same domain three times in a row, no code change between them, gave three different answers: 36.8s, 20.6s, 12.9s. A single reading would have said “about twenty seconds” and sent us looking for something twenty seconds long. There isn't anything twenty seconds long. The number was an average of a fast path and a slow path, and averaging them hid both.

Time the stage, not the request #

Comparing the three runs stage by stage put nearly all of the variance in three stages, each swinging by seven or eight seconds. Everything else was stable to within half a second.

The part that was actually wrong #

One of those stages asks the Chrome UX Report whether Google holds real-world performance data for the site. For a local contractor the answer is no, and it always will be — CrUX only publishes an origin once it has enough Chrome visits, and a regional business does not get them.

So the honest reading: the scan was spending up to 8.2 seconds to learn nothing. That is fine once. It is not fine every time. It was every time, and the reason is a shape worth recognising.

The cache was read at the top of the lookup and written at the bottom. Every path that failed returned before it reached the write.

The consequence is exactly backwards. A successful lookup — already the fast case, since the data existed and came back — was cached and nearly free from then on. A failed lookup paid for several uncached round trips, and none of their results was stored. The slow path stayed slow, on every scan, permanently.

Why “cache the miss” is not the whole rule #

The tempting fix is to move the write to the end of every path. That is too blunt, because the failures are not the same kind of fact.

• NOT_FOUND is a fact about the site. CrUX has no data for this origin, and that answer is stable for weeks. Cache it, and cache it as long as you would a hit.
• A refused or invalid key is a fact about us. If our own credential is wrong, caching that answer means we keep reporting a broken configuration for 24 hours after somebody fixes it. Never cache it. Retry.

Same function, same return, two different lifetimes — because one describes the thing being measured and the other describes the instrument.

We then broke our own rule #

We shipped the fix, and it cached a third thing we had not thought about: a transient “pending” state. That is neither a fact about the site nor a bad credential — it is our request not having finished yet. Cached for 24 hours, it froze the pending state and stopped the retry from ever running again. An intermittent failure became a permanent one, and it stayed that way for six hours.

We corrected it. The general rule, stated properly: cache facts about the thing you measured; never cache facts about your own attempt to measure it.

The result #

After the fix, the field-data lookup went from up to 8,240ms to 3ms once warm. The measurement did not change. We just stopped paying for the same empty answer on every scan.

Three things that transfer #

1. Time the stage, not the request. A total duration cannot tell you whether you have one slow thing or one occasionally-slow thing, and those need opposite fixes.
2. Check which branches reach your cache write. If it sits after the happy path, your cache is only accelerating the case that did not need it.
3. Classify your failures before caching them. “The answer is no” and “we could not ask” look identical in a return value and must never share a TTL.

Questions this post answers

What is a negative cache?

A stored record that a lookup failed, with its own expiry, so the same failing request is not repeated on every run. A cache that only stores successes re-runs the expensive miss forever.

How long should a miss be cached?

Long enough that the cost stops mattering and short enough that a fix is noticed.

Related findings

Comments

Comments are read before they appear. Nothing is published automatically, and no account is needed.

Writing about this? Facts, live figures and marks — every number on that page is dated and traceable to a scan.

All findings · The dataset · How the dataset works