CLS 0.001 on three live sites — how we measured it.
Layout shift is the page sliding out from under the reader. Google calls anything under 0.1 "good"; all three live sites we run measure 0.001. Not luck — reservation discipline.
Layout shift has three classic sources: an image with no declared size, a late web font, and content injected after the fact. All three have the same cure: reserve the space BEFORE the content arrives. width/height on images, preloading and a measured fallback for fonts, a fixed height for the band.
- fersantekstil.com → CLS 0.001 · LCP 0.59s
- karcem.com.tr → CLS 0.001 · LCP 0.55s
- mikroyazilimdestek → CLS 0.001 · LCP 0.46s
- # 2026-08-21 · cold load · 1440×900
Why "closest to" zero and not zero itself?
Chrome can count elements whose content reflows even when their box stays put. In this site’s hero, the dot inside the line drifts as the variable font’s width axis opens: same box, same size, same line count — and still it records 0.027. We measured it, itemised its sources and accepted it deliberately: a gesture is part of the design as long as it stays inside the budget.
Font swap: the sneakiest source
The "late web font" item on that list is worth showing exactly as it appeared here. Two routes were over budget on mobile, and the first diagnosis was wrong: the blame went to the signature effect. Measurement disproved it. The shift happened at 2071 ms; archivo-var.woff2 finished at 2046 ms and the browser’s loadingdone event fired at 2073 ms. That twenty-five-millisecond gap is no coincidence — the shift was the swap.
The cause had two layers. One: the headings use the variable font’s width axis, and the fallback font has no such axis — so the text sits narrow while the fallback renders. Two, and this was the real one: the rule set its weight through font-variation-settings while CSS font-weight stayed at 400. Because that axis overrides font-weight on a variable font, Archivo drew correctly and the fallback stayed regular. Narrow and thin at once; when the real font arrived the heading widened and gained a line.
- h1 with fallback → 149px
- h1 with Archivo → 186px
- difference → +37px = exactly one line
- # mobile 390 · 4G · 4x CPU throttle
The fix came in two parts. First, the same weight value was written as font-weight onto the sixty-six rules that carried one — inert for the variable font, bold for the fallback. Then a size-adjust fallback family was declared for each of the sixteen width/weight pairs the site actually uses; the ratios were not guessed but measured in the browser on the same string. Result: zero pixels of h1 movement, and the worst route’s CLS fell from 0.1288 to 0.0216. The signature effect was never touched.
The lesson here is methodological, not technical: the first suspect is the most visible one and is usually innocent. A diagnosis that never puts the timestamps side by side will not find the right fix either — had the chosen remedy been applied, it would not have solved the shift, only killed the effect on mobile.
The real trap is not at load
Scrolling does not count as "recent input"; every shift during a scroll is written in full to real user data. A pinned section returning to flow could produce 0.64 in a single frame — moving the pin onto the transform channel erased it from the metric entirely. Nothing carried by a transform is a layout shift.
There is a measurement trap too: a lab tool that opens the page and waits sees only the load moment. Real users scroll. So the tests here scroll the page programmatically from top to bottom and record each shift together with its source — which element moved how far, at which millisecond, in writing.
Space is reserved before the content arrives; the rest is bookkeeping.