The State of Web Vitals

Scheduling API use

How the page schedules main-thread work: scheduler.yield / postTask vs setTimeout churn.

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

At a glance the headline numbers for Scheduling API use

How the page schedules main-thread work: scheduler.yield / postTask vs setTimeout churn.

6
Categories
In the distribution
47.6%
Fleet share
Top: raf
65.7%
Sites with any
Of raf

2.0% of scheduling calls use scheduler.yield. 46.2% chunk work with setTimeout.

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

The scheduling API use mix who uses what, and how stable each group is

Median CLS (sites using feature)
0
0.10
0.20
0.30
0.40
0.50
Raf0.0048% of sites
SetTimeout0.0046% of sites
RequestIdleCallback0.003% of sites
Scheduler yield0.002% of sites
SetInterval0.001% of sites
PostTask0.000% of sites
VariantShare of requestsMedian
Raf
48%
0.00
SetTimeout
46%
0.00
RequestIdleCallback
3%
0.00
Scheduler yield
2%
0.00
SetInterval
1%
0.00
PostTask
0%
0.00

Scheduling API use. On the fleet: 47.6% raf, 46.2% settimeout, 3.4% requestidlecallback. 65.7% of sites use at least one raf.

Lowest-share bucket: CLS 0.00. Highest-share bucket: CLS 0.00. r = +0.39.

By count raf leads (47.6%); by bytes it is scheduler yield (0.0%). computed

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

Passing CLS 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
Raf 47.6%
91
86
86
87
88
89
88
88
88
87
88
85
SetTimeout 46.2%
95
91
91
93
93
91
91
88
87
86
85
81
RequestIdleCallback 3.4%
90
82
88
90
88
88
84
80
88
90
86
86
Scheduler yield 2%
89
85
71
84
87
94
88
73
98
89
SetInterval 0.7%
93
91
90
88
88
87
86
83
80
78
77
70
PostTask 0%
89
88
89
← few of this category on the pagemany →
60%95%+ of sites passing CLS 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 CLS.

SetInterval swings the hardest: 93% of sites pass CLS with few, 70% 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 CLS? the pass rate with few vs many of each category

60%70%80%90%100% few → many
SetInterval 0.7% 93% → 70%
SetTimeout 46.2% 95% → 81%
Raf 47.6% 91% → 85%
RequestIdleCallback 3.4% 90% → 86%
Scheduler yield 2% 89% → 98%
% of sites passing CLS · 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 SetInterval costs the most: the CLS pass rate falls from 93% with few to 70% 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

Long tasks block every interaction that arrives while they run. The fix is yielding: split the work and give the browser a chance to handle input in between. How a site yields matters. scheduler.yield hands control back and resumes with priority. postTask schedules work with an explicit priority. A setTimeout chain yields too, but blindly: no priority, and every link in the chain adds delay.

Seeing the modern scheduler APIs on a site is a strong signal: someone engineered the INP instead of inheriting it.

How does this affect the Core Web Vitals?

Passing INP barely moves across the range: 96% at one end, 92% at the other. This signal does not separate passing sites from failing ones.

The split is bigger on LCP: 87% pass where Raf is rare, 79% where it is common.

Go fix it Yield to the main thread → The dataLayer INP yield pattern → JavaScript priority levels →
Related signals Interaction invoker types → CSS hints → Yielding strategy → INP phase breakdown → Chrome field data from 94,910 sites, representing millions of real page loads · How we measured