Cumulative Layout Shift Debugger

Free, no signup. Each check loads the page in a real Chromium on mobile and desktop, under throttled CPU and network. Reports stay available for 14 days and open for anyone holding the link, under the terms.

European by default. Measurement server in Finland, reports stored in an EU database. How the data is handled.

About the Cumulative Layout Shift Debugger

The Cumulative Layout Shift Debugger visualizes the layout shifts of a webpage during load, on mobile and on desktop, so the elements moving around become easy to spot and fix.

Every test loads the page in a real Chromium browser and reads the Layout Instability API, the same source Chrome uses for the Core Web Vitals score. The recording marks each shifted region with a square, and the report lists the HTML elements behind every shift, ranked by how much each one added to the score.

Mobile emulates a Moto G Power at 412x823 with a 6x CPU slowdown on a Slow 3G connection, the device Lighthouse uses for its own mobile runs. Desktop runs at 1920x1080 with a 2x CPU slowdown on a 5 Mbps connection. Both settings surface the shifts visitors hit on slower hardware and slower networks. Report links stay live for 14 days and open for anyone holding the link.

Next to the lab result, the report shows Chrome UX Report field data for the tested URL and for the whole origin, so a controlled measurement sits beside what Chrome users experienced over the past 28 days.

How to fix the Cumulative Layout Shift score?

Cumulative Layout Shift measures visual stability. Chrome sums the scores of every unexpected layout move outside a 500ms window after user input, weighing both the share of the viewport affected and the distance the elements travel. The common causes and their fixes:

• Images without dimensions. Set width and height on every image and use srcset for responsive sources, so the browser reserves the right box before the file arrives.
• Ads, embeds and iframes without reserved space. Reserve the slot in CSS at the size the object renders at, keep the space reserved when an ad goes unfilled, and place non-sticky ads below the fold.
• Content injected after load. Add new elements below the existing content, or in direct response to an interaction, instead of pushing rendered content down.
• Web fonts swapping late. Preload the font files and set font-display, and match the fallback metrics to the web font so the swap moves nothing.
• DOM updates waiting on the network. Answer an interaction within 500ms and animate with CSS transform instead of properties forcing layout and paint.
• Containers hidden right after first paint. Print styles, cookie interstitials and grid containers visible for the first frames belong in the critical CSS with their dimensions reserved.

Known Issues

• Pages needing more than 30 seconds to respond and render end the test as a failure. A second run after the site settles usually finishes.
• Bot protection at the server or the CDN blocks some tests. Every request carries a unique X-Request-Id starting with webvitals.cls. and a Referer starting with https://webvitals.dev/, and site owners allowlisting both let the tests through.
• A capture occasionally goes wrong and reports a score of zero. Running the test again returns the real score.
• Pages restored from the back/forward cache start again at zero, because Chrome counts the restore as a separate visit.
• The Layout Instability API skips shifts inside iframes, so the score covers the parent document. Testing the iframe URL on its own shows the shifts inside.
• Heavy movement, vertical movement above all, makes single elements hard to isolate. Fixing the largest shifts first clears the picture for the smaller ones.
• Full-page cookie walls, language or geo redirects and self-signed certificates stop Chromium from rendering the real page, and the result then describes the interstitial instead of the site.
• Single Page Applications report metrics per navigation, so a full page reload gives the meaningful measurement.
• Slower connections and slower devices score higher, because more asynchronous resources arrive after first paint and move the layout again.
• Mobile scores run higher than desktop on the same page: a smaller viewport turns the same movement into a larger share of the screen.
• The debugger measures the initial page load, so shifts triggered later by scrolling or by interaction stay outside the score.

Frequently Asked Questions

How does the experimental cookie interstitial feature work?

Clicking a cookie banner away moves the Cumulative Layout Shift score in both directions, so running the test with the click and without the click gives the fuller picture.

Fill in the URL, then add the text of the element to click, often "Accept", "Accept all", "Verstanden" (German) or "OK". Selecting the element type helps the match land. Currently button, div, span and a are supported.

A few tips:

• The text match is case-sensitive, so "Accept" and "accept" find different elements.
• Where clicking the backdrop dismisses the notice, a div with a few sequential words from the banner text usually works.
• The match is partial, and the combination needs to be unique on the page. When the closest element appears in several places, one level up narrows the result.
• Other interstitials close the same way. Newsletter popups often go away with "X" or "Close" as the text and the matching element type.

How to test Cumulative Layout Shift from different countries?

Tests run through proxies in other countries, so the measurement sees the site the way a visitor there does. Pick a country under "Test from" and start the check.

How long does a report take?

A full report takes several minutes:

• The debugger follows redirects and tests the final destination on both an emulated mobile device and a desktop.
• A score of zero triggers extra attempts before the report closes.
• Heavy DOM changes after load, deferred JavaScript above all, stretch a single test to two minutes.
• The Chrome UX Report gets queried for the URL and for the origin.
• Rendering the animation takes up to 30 seconds per device, depending on the number of shifts.

Why does the CLS Debugger not load a URL?

Several things block a test:

• Firewalls blocking the tool's data center IP addresses, published at filibot.com.
• Pages needing more than 30 seconds to render.
• A domain name failing to resolve, or the wrong scheme (http against https).
• An invalid or self-signed SSL certificate.
• A page flagged as phishing or malware.
• Geographic or language restrictions on the page.

Identifying the CLS Debugger requests

The CLS Debugger fetches webpages from data centers in normal browser sessions. The requests come from a published set of IP addresses, listed at filibot.com and available as ips.json for firewall allowlists. Every request carries a Referer of https://webvitals.dev/ and an X-Request-ID starting with webvitals.cls.

The debugger shares those IP addresses with filibot and approaches a website as a visitor rather than as a bot, so robots.txt stays out of the picture. Blocking the IP addresses at firewall level keeps the debugger out.

More Core Web Vitals tools

Other free tools