You open a product page on your phone, reach for a button and watch it move as something else loads. Or you start reading a service description and a late banner pushes it down the screen. The website may be quick to appear, yet awkward to use.
Start by finding what changes the page layout. Compressing every image or installing another speed plugin will not necessarily stop the movement. A useful repair keeps the customer’s next action in a predictable place while the surrounding content loads.
For a UK business, the priority is the affected journey: choosing a product, requesting a quote or completing a booking. Diagnose that journey before commissioning a wider redesign.
What causes a website to jump on mobile?
The browser initially draws the page, then has to make room for something whose size or position changes. Common suspects include product photographs, embedded content, promotional banners and changing fonts.
Cumulative Layout Shift, or CLS, measures unexpected visual movement. The score reflects the largest burst of layout shifts during a page visit, rather than simply adding up every movement indefinitely. Google’s good threshold is 0.1 or less at the 75th percentile, assessed separately for mobile and desktop.
That is a diagnostic measure, not a stopwatch. A page can load quickly and still have poor visual stability. Equally, a button that stays in place but responds late needs a different investigation.
Some movement is expected. Opening a menu deliberately changes the page. Shifts within 500 milliseconds of qualifying input, such as a tap, can be excluded from CLS; scrolling does not receive the same exclusion. A delayed update after a tap can still count. Check the actual experience as well as the number.
Record the customer journey that goes wrong
Give your developer one repeatable example before changing settings. Choose an affected product, service or booking page and capture a short screen recording from arrival through to the jump.
Record these details alongside it:
- The exact page URL and the button, image or section that moves.
- The phone, browser and approximate screen size.
- Whether you arrived directly, followed an advert or clicked through from another page.
- Whether this was a first visit, a returning visit or a signed-in session.
- Whether the jump happened before scrolling, further down the page or after an action.
- The cookie choice and whether external content had been allowed to load.
Then try the same route on another phone. Include a narrower screen and a slower connection where practical. Do not stop at opening the homepage on an office computer.
For a retailer, test a product with several photographs and one with a different image shape. For a service business, include the page containing the quote form or booking widget. This helps establish whether the problem belongs to one piece of content or a shared template.
Why a good PageSpeed test can miss the jump
A standard Lighthouse page-load test captures a controlled loading sequence. It does not reproduce every customer’s later scrolling, personalised content or delayed interaction. Google’s explanation of lab and field data differences shows why real visitors can experience layout shifts that a loading test misses.
Use the test to investigate, but keep the recording of the customer’s route. A green result from a fresh page load does not resolve a complaint about movement halfway down a product page.
Also check the scope of any real-user figure. Is it for that page, a group of pages or the whole website? Avoid treating a broader result as proof that one particular button has been repaired.
Find the cause in a browser recording
Your developer can record the affected route in Chrome DevTools’ Performance panel. The current Performance reference describes the Layout shifts track: purple diamonds mark individual shifts, and selecting a shift or cluster reveals timings, affected elements and possible causes.
The important distinction is between what moved and what made it move. Google’s layout-shift debugging guide explains that a reported element may only be the victim. A quote button can move because a photograph above it suddenly gains height.
Ask for a clear diagnosis: which component changed, when it changed and why the page had not reserved the right space. A report saying only that the button shifted is incomplete.
For example, if a review widget expands above the enquiry form, investigate the widget’s container and loading behaviour. Adding arbitrary spacing around the form may hide the symptom on one phone while leaving it elsewhere.
Fix the component that changes the layout
Reserve the correct space for images and video
Images need a predictable shape before their files arrive. Google’s CLS optimisation guidance recommends image width and height attributes, or appropriately reserved space using an aspect ratio. Responsive sizing can still let the image fit the screen.
Check product galleries, project photographs and video containers at mobile widths. The reserved shape must match what eventually appears. A desktop landscape placeholder is a poor fit if the mobile version becomes a tall portrait.
Ask your developer to fix the shared component where appropriate. Manually patching one product leaves the next upload exposed to the same problem.
Make room for banners and external widgets
The same guidance recommends reserving space for late-loading content such as embeds. A map, review block or booking tool should not unexpectedly displace content someone is already using.
Test the component before loading, after loading and when it fails to load. If it appears only after a cookie choice, include both the placeholder and the permitted-content state in the test.
There is a design choice here: how much space should the page reserve, and what should occupy it while the content is unavailable? Agree that behaviour deliberately. An enormous empty block can make the page awkward too.
Check whether a font swap changes the text
If headings change shape and nearby content moves, investigate font loading. A fallback font may occupy different space from the final web font. Chrome’s guidance on matching font fallbacks describes techniques for reducing that mismatch.
Ask the developer to check the actual heading, navigation and button text at narrow widths. The acceptance test is readable, stable text with the intended design. Simply delaying all text until a font arrives is not a useful business outcome.
Check which CLS figure your report uses
There is a current reporting distinction for sites that update page content and the URL with JavaScript instead of loading a new document. Google’s CrUX metrics documentation lists experimental Core Web Vitals variants covering these soft navigations, introduced in October 2026.
Google’s explanation of the experimental measurements says the stable scores remain unchanged while the new versions are evaluated alongside them. If your developer uses these figures, label the metric clearly and compare like with like. A measurement change alone does not demonstrate that customers have stopped seeing a jump.
Prove the repair across the whole journey
Repeat the original recording after the change, using the same page and conditions. Keep the before-and-after evidence. Then test other pages using the repaired component.
A practical acceptance check should confirm that:
- The original unwanted movement no longer occurs on the affected phones.
- Product images, banners and widgets load into the intended space.
- Cookie choices, signed-in states and returning visits still work.
- Menus, product options and form messages remain usable.
- The customer can complete the enquiry, booking or order.
Keep this proportionate. Fixing an image container should not require redesigning every page. But check enough examples to avoid accepting a repair that works only for one photograph or screen width.
Longer-term reporting takes time. Google’s Search Console Core Web Vitals report groups similar URLs and reports group CLS using the previous 28 days of real-user data. Some pages lack enough data to appear. Check the CLS issue itself, because the group’s overall status can also reflect another metric.
Use repeatable browser evidence for the immediate repair, then review the real-user trend as new visits enter the reporting window. Neither an unchanged report on launch day nor an absent report proves the fix has failed.
Does a jumping page need a redesign?
Start with the smallest repair supported by the evidence. A gallery missing dimensions or a poorly sized embed may need a focused component change. Repeated problems across navigation, typography and page templates may justify broader work.
Google says Core Web Vitals contribute to its ranking systems, but good scores do not guarantee top rankings. The immediate reason to fix layout shifts is to give customers a stable route through your website.
Our web design approach focuses on usable customer journeys. If content moves while people try to enquire or buy, talk to BuzzBoost with the affected URL and a short recording. We can help establish whether a focused repair or wider template work is the sensible next step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
