At a glance the headline numbers for Last-Modified present
Whether responses carry Last-Modified validators.
91.1% of sites send Last-Modified headers.
Last-Modified present sites that have it vs sites that don't
91.1% of sites send Last-Modified headers (173,239 of 190,130). With send: LCP 1.6s, 81.5% pass. Without: LCP 1.4s, 84.2% pass. Correlates with +162ms LCP and −2.7 pp pass rate. computed
Why this matters for the Core Web Vitals, and where to start fixing it
Last-Modified is the older validator. The browser sends the timestamp back (If-Modified-Since) and the server answers 304 Not Modified when nothing changed, saving the re-download of an expired cache entry.
It is weaker than an ETag: one-second resolution, and deploys often touch timestamps without changing content, which breaks the match. But any validator beats none. A response with no validator and a short TTL is re-downloaded in full on every revisit.
How does this affect the Core Web Vitals?
Having it makes no measurable difference to the LCP: 82% pass with it, 84% without.
Chrome field data from 189,915 sites, representing millions of real page loads. How we measured.
Live queries (1) — admin only
SELECT m.headers.has_last_modified AS val, COUNT(*) AS n,
quantile_disc(crux."phone".lcp, 0.5) AS median,
COUNT(*) FILTER (WHERE crux."phone".lcp IS NOT NULL AND crux."phone".lcp <= 2500) * 1.0 / NULLIF(COUNT(*) FILTER (WHERE crux."phone".lcp IS NOT NULL), 0) AS good,
COUNT(*) FILTER (WHERE crux."phone".lcp IS NOT NULL AND crux."phone".lcp > 2500 AND crux."phone".lcp <= 4000) * 1.0 / NULLIF(COUNT(*) FILTER (WHERE crux."phone".lcp IS NOT NULL), 0) AS ni,
COUNT(*) FILTER (WHERE crux."phone".lcp IS NOT NULL AND crux."phone".lcp > 4000) * 1.0 / NULLIF(COUNT(*) FILTER (WHERE crux."phone".lcp IS NOT NULL), 0) AS poor
FROM sites WHERE 1=1 GROUP BY m.headers.has_last_modified;