The State of Web Vitals

Cache strategy mix

The caching posture across responses: immutable, long TTL, short TTL, no-store.

Field data PhoneDesktopAll Scope All sites Q1 2026 edition · Phone field outcomes
Metric LCP INP CLS
1

At a glance the headline numbers for Cache strategy mix

The caching posture across responses: immutable, long TTL, short TTL, no-store.

7
Categories
In the distribution
35.1%
Fleet share
Top: unspecified
97.7%
Sites with any
Of unspecified

3.1% of responses forbid caching outright. 10.9% are immutable.

The State of Web Vitals · Q1 2026 · 94,910 sites · phone field datacorewebvitals.io/state-of-cwv
2

The cache strategy mix mix who uses what, and how fast each group loads

Median INP (sites using feature)
0
100ms
200ms
300ms
400ms
500ms
Unspecified99ms35% of sites
Long ttl100ms25% of sites
Medium ttl100ms17% of sites
Immutable110ms11% of sites
Short ttl103ms8% of sites
No store102ms3% of sites
No cache104ms2% of sites
VariantShare of sitesMedian
Unspecified
35%
99ms
Long ttl
25%
100ms
Medium ttl
17%
100ms
Immutable
11%
110ms
Short ttl
8%
103ms
No store
3%
102ms
No cache
2%
104ms

Cache strategy mix. On the fleet: 35.1% unspecified, 24.7% long ttl, 16.6% medium ttl. 97.7% of sites use at least one unspecified.

Lowest-share bucket: INP 91ms. Highest-share bucket: INP 99ms. r = +0.48.

The State of Web Vitals · Q1 2026 · 94,910 sites · phone field datacorewebvitals.io/state-of-cwv
3

Passing INP per bucket every category and count level at once - color is the pass rate

1
2
3
4
5
6
7
8
9
10
11
12
Unspecified 35.1%
93
92
93
94
93
91
91
92
92
92
93
89
Long ttl 24.7%
89
92
93
93
93
93
92
94
94
95
94
90
Medium ttl 16.6%
89
93
94
92
93
92
92
93
94
94
93
90
Immutable 10.9%
93
88
91
92
89
87
90
86
78
92
92
88
Short ttl 7.8%
92
94
94
93
92
91
89
87
87
89
83
No store 3.1%
91
94
94
94
93
92
89
87
83
82
78
No cache 1.8%
92
93
93
92
91
89
90
87
85
82
84
78
← few of this category on the pagemany →
60%95%+ of sites passing INP Faded cells: under 100 sites

Each row is a category, each column its own count bucket (few on the left, many on the right); the cell is the share of those sites passing INP.

No cache swings the hardest: 92% of sites pass INP with few, 78% with many. computed

The State of Web Vitals · Q1 2026 · 94,910 sites · phone field datacorewebvitals.io/state-of-cwv
4

Few vs many - does quantity cost INP? the pass rate with few vs many of each category

60%70%80%90%100% few → many
No cache 1.8% 92% → 78%
No store 3.1% 91% → 78%
Short ttl 7.8% 92% → 83%
Immutable 10.9% 93% → 88%
Unspecified 35.1% 93% → 89%
Medium ttl 16.6% 89% → 90%
Long ttl 24.7% 89% → 90%
% of sites passing INP · hollow ring = pages with few, solid dot = pages with many

Per category: the pass rate among pages with FEW of it (hollow ring) against pages with MANY (solid dot), worst trend first. Thin buckets are excluded from the endpoints.

More No cache costs the most: the INP pass rate falls from 92% with few to 78% with many. computed

The State of Web Vitals · Q1 2026 · 94,910 sites · phone field datacorewebvitals.io/state-of-cwv
5

Why this matters for the Core Web Vitals, and where to start fixing it

Field data includes repeat visitors, and caching decides how fast the page is the second time. A response marked immutable is served from disk without asking the server anything. A short TTL forces a revalidation request first. A no-store response is downloaded again in full on every visit.

The pattern to aim for is old and boring: hashed filenames with long, immutable TTLs for assets, and short caching only where content actually changes. Every revalidation you avoid is a round trip the LCP does not wait for.

How does this affect the Core Web Vitals?

Of the 7 categories, Unspecified separates passing sites from failing sites the most. Where Unspecified is rare: 90% pass the LCP. Where it is common: 82%.

Go fix it TTFB: cache duration → Configure Cloudflare for passing the Core Web Vitals →
Related signals Cacheable responses → HTTP protocol mix → HTML size (kB) → Last-Modified present → Chrome field data from 94,910 sites, representing millions of real page loads · How we measured