Search Console flags layout shift on your pages, or a customer mentions the page jumped just as they went to tap something, and Lighthouse gives the same page a clean zero. Both can be true at once. A default Lighthouse run loads the page once at full speed, estimates the slow-connection timing afterwards, and stops when the load does, so it never sees a shift that needs a slow first visit, a click, or a scroll.
We found two of those on our own site in September. All 42 pages at the time scored 0.000 for layout shift on a normal load in our audit, and Lighthouse’s default run agreed on the post we checked. Behind that number, the report from our free checker was pushing the page out of place on every staged check, and our brand font was rewrapping headings on slow first visits. Here is what each one looked like, why the default run missed both, and four checks aimed at finding them on your own pages.
What counts as a layout shift
A layout shift is content moving after it has already been drawn: a paragraph sliding down because an image above it finished loading, or a button jumping as a banner appears. Chrome groups shifts that happen close together into bursts, and Cumulative Layout Shift (CLS) is the score of the worst burst. Google counts 0.1 or lower as good, measured so that three in four page loads have to meet it.
One rule matters for everything below. A shift within half a second of pressing a button or a key does not count, because the visitor caused it and expects the page to change. The clock starts at the press, so anything that lands more than half a second later counts in full, and scrolling is not that kind of input, so a shift a scroll sets off is scored too. Why lab tools and real visitors disagree more generally is covered in the post on INP.
A layout shift after a click: our checker’s report
Our free AI citeability checker takes a web address and returns a report once our server has fetched the page as several AI crawlers would. That takes seconds, far past the half-second allowance, and when the report arrived it pushed the section below it out of view. In our staged test, with the answer held to four seconds and the form at three scroll positions on a phone and a desktop, it scored 0.90 to 1.0 every time, nine to ten times Google’s line.
A Lighthouse run never saw it, because a standard run loads the page and stops without clicking anything.
The fix came in two parts, and we measured each on its own before shipping either, which turned out to matter, because each one alone still failed somewhere in the staged test.
- Reserve the space at the press. The report’s space is set aside at the moment of the press, while the press still counts as the cause, so the sections below move inside the grace period rather than four seconds later. On its own, this still scored 1.0 on a phone with the page not yet scrolled.
- Scroll after the paint. Testing turned up a second cause: the page jumped down to the new report in the same instant the report appeared, and in our test Chrome scored the section below as having leapt into view. Waiting until the report has painted before scrolling to it fixed that, but on its own this still reached 0.62 with the page scrolled so the form sat at the top of the screen.
With both in place the report scored 0.000 in every staged run, and when we reran the same test against the live site in late September, every run still read 0.000, including the ones where the check returns an error instead of a report.
If your site has a quote calculator, a search box, filters, a “load more” button, or a form that shows a confirmation from the server, it has the same shape. The content arrives after the grace period has run out, and whatever sits below it moves.
A late font on a slow first visit
Rajdhani is the only typeface on our site. It swaps in when it arrives, and on a fast connection it arrives before the page first paints, so nothing moves. On a slow first visit it can lose that race. We ran Lighthouse from the command line at desktop size with its phone throttling forced on, a slow 4G connection and a processor slowed four times, which the DevTools panel’s Desktop setting will not do (step 1 below). The font landed 20 to 50 milliseconds after the first paint and the page drew itself in Arial first. We measured Rajdhani at 8 to 15% narrower than Arial, so when it swapped in, the headings rewrapped and the article under them jumped. That scored 0.389 on one blog post on desktop.
Lighthouse’s default run gave the same post 0.000. The default loads the page at full speed and then estimates how long a slower connection would have taken, and its layout-shift score comes from that fast load, where our font arrived before the first paint. When we held the font back on purpose across the whole site, 8 of 84 runs (42 pages at two screen sizes) went over 0.1, the worst at 0.383 on that same post.
The fix was to make the stand-in font take up the same room. We resized two stand-ins to Rajdhani’s width and line height, Arial for desktops and Roboto for Android, since most Android phones have no Arial and use Roboto as their default font, with the scale measured over the text of every page on the site rather than a sample line. The swap now moves almost nothing, though the Android half was checked in a simulation rather than on a phone. The staged worst case went from 0.383 to 0.055, and the same throttled Lighthouse command that read 0.389 now reads 0.001 on the live post. A few long titles still wrap onto a different number of lines, which no single scale factor can prevent, and Safari ignores the line-height half of the match.
There was a cheaper fix, and we turned it down. Setting the font to font-display: optional gives it no more than about a tenth of a second, and if it misses, that page stays in the stand-in font. It scored zero everywhere. It would also have shown a slow first visitor the whole page in the stand-in font, and for a brand built on one typeface that was the wrong trade to make for a score.
Before and after
Lab measurements from our own site, September 2026. The staged tests hold back the font or the server’s answer on purpose, and none of these numbers comes from real visitors yet.
| What we tested | Normal load or Lighthouse default | Staged or throttled, before the fix | After the fix |
|---|---|---|---|
| Checker report, after a click | 0.000 on a normal load, which never clicks | 0.90 to 1.0 in every staged check | 0.000 |
| Brand font arriving late, 42 pages | 0.000 on every page | 0.383 at worst in our audit with the font held back, 8 of 84 runs over 0.1 | 0.055 at worst, none over 0.1 |
| One blog post, Lighthouse with throttling applied | 0.000 in the default run | 0.389 in Lighthouse (the post behind the 0.383 above) | 0.001 |
How to make a hidden layout shift show itself
You do not need a custom audit to find out whether a page has either problem. These four checks cover both, and the first three run in Chrome’s own developer tools, so the list can go straight to whoever builds your site.
- Run Lighthouse with the slowdown applied, on Mobile. In Chrome DevTools, open the Lighthouse panel, set Device to Mobile, and switch the throttling from estimated to applied. Today that is the gear icon, then Throttling method, then DevTools throttling (advanced). On Mobile the page now actually loads over slow 4G with a phone-speed processor, so a late font gets its chance to move things, while on Desktop the same setting adds no slowdown at all and can hand you the same zero. Compare its layout-shift number with the default run’s.
- Scroll the page, then use everything that waits on a server. Open the Performance panel, whose Live metrics screen scores your own visit as you use the page and lists each layout shift with the element that moved. Scroll from top to bottom once the page has loaded, since anything that loads as the reader scrolls can shift what is below it, then submit the forms, run the search, apply the filters, and watch which ones add to the score.
- Reload slowly at your normal window size, and read the number. Back on the Live metrics screen, slow the processor four times, put the network on slow 4G, and turn the cache off. Today those sit in its Environment settings box as CPU 4× slowdown, Network Slow 4G, and Disable network cache. Those settings apply at whatever size your window is, so a rewrap at desktop width, like our 0.389, should show up here even though step 1’s phone-sized run can miss it. Reload, read the layout-shift score, and open the Layout shifts tab to see each element that moved. If the headings are among them, the stand-in font needs resizing.
- Read what real visitors recorded. Search Console’s Core Web Vitals report shows a page once enough Chrome visitors have loaded it, and Cloudflare Web Analytics has a Debug View that names the five elements doing the most damage.
If step two moves the score, reserve room for whatever arrives before it arrives: at the moment of the press for anything a click brings in, and in the page’s layout from the start for anything that loads as the reader scrolls down, since a scroll gets no grace period. If the page also jumps to the new content, waiting until it has painted before scrolling to it is what closed the gap in our case. If step three does, have the stand-in font resized to the brand font’s width and line height, or accept font-display: optional and a plainer first visit.
Read the real-visitor numbers from step 4 with two limits in mind. Search Console grades groups of similar pages on the last 28 days of visits, so a page you have fixed stays flagged for weeks, and once you mark an issue fixed (the Start Tracking button, today) it watches for another 28 days before it calls the issue fixed. And layout shift can only be measured in Chrome and browsers built on it, while Google’s phone numbers come only from Android, so an iPhone visitor’s jump reaches neither report.
A zero describes one load
None of this makes the default run useless. It is quick and repeatable, and a shift that happens on every ordinary load will show up in it. Its zero describes one load, at full speed, with nobody touching the page, and the shifts people actually complain about tend to live outside those conditions.
Finding ours took a test that makes the font lose its race and uses the forms with the answer held back, and it reruns across every page whenever we ask it to. What it has not told us is how many real visitors felt either shift before the fixes, because every number above comes from the lab. Finding the shift a score missed, fixing the cause, and checking on a schedule that it stays fixed, as part of ongoing maintenance, is the performance side of our Monitor work.