Make Uxify one of your go-to sources on Google
Add Uxify on Google
What is Layout Thrashing?
Layout thrashing is what happens when JavaScript makes the browser recalculate the layout of a page over and over inside a single task. Layout is the step where the browser works out the size and position of every element on screen. It’s expensive, so normally the browser saves it up and does it once, right before it draws the next frame.
The trouble starts when a script flips between changing the page and measuring it. It sets a width or adds a class, then asks how tall some element is. The browser can’t hand back stale numbers, so it drops everything and runs layout on the spot. Developers call this a forced reflow. Once is harmless. Put it in a loop over 40 product cards, though, and the browser redoes the layout 40 times when one pass would have covered it.
Usual suspects on a store: sliders sizing their slides, scripts that force product tiles to equal heights, sticky headers checking scroll position, and review or chat widgets resizing themselves after they load.
What this means for revenue
Shoppers never see layout thrashing. They feel it. The filter drawer opens a beat late, the gallery stutters on swipe, and the size picker hesitates before “M” lights up.
Every forced reflow gets added to whatever task is running, so a quick click handler turns into a long task and drags out Interaction to Next Paint (INP), the Core Web Vitals metric for responsiveness. Google counts INP as good at 200 milliseconds or less. It also gets worse as pages get heavier, because each layout pass has more elements to work through, so a category page with 60 products and a handful of Shopify apps injecting markup will suffer far more than a lean landing page, especially on a mid-range Android phone.
And once someone tracks down the offending script, the fix is usually small.
How Uxify helps
Reality measures INP from real visitors in every session, so you can see which pages and interactions are slow, and on which devices. Ask Uxi can dig into the INP breakdown and suggest where to look first. INProve frees up the main thread right before an interaction and reschedules heavy scripts, so other work isn’t piling on while the browser is busy measuring. And Vita flags Core Web Vitals regressions, which is handy when a theme update or new app quietly starts thrashing.
Layout Thrashing FAQs
Is layout thrashing the same as layout shift?
No. A layout shift is content visibly jumping around, and it’s measured by CLS. Thrashing happens out of sight: the page might not move an inch while the browser grinds through the same math repeatedly. Shifts hurt CLS, and thrashing mostly hurts INP and smooth scrolling.
How do I spot layout thrashing?
Record an interaction in the Performance panel of Chrome DevTools. Lots of purple Layout blocks stacked inside one task, often with a forced reflow warning, point straight at the guilty line of JavaScript. Then check INP for those pages in Reality, since a developer’s fast machine often hides the problem.
How do you fix layout thrashing?
Read first, write after. Gather all the measurements a script needs in one go, then make all the changes together, so the browser only has to recalculate once. Animating with CSS transforms instead of width, height or top helps too, because transforms skip layout entirely. Our INP optimization guide covers more of the developer side, and for third-party widgets you can’t edit, the vendor usually has to make the change.