In short
What’s checked
whether your page’s code forces the browser to recalculate layout outside the moment it would have done so on its own.
Cut-off
triggered when your website’s code adds up to 30 ms or more of forced recalculations, the threshold at which Chrome warns in the console. Code from other companies (cookie banners, analytics) doesn’t count.
Why it matters
the browser has 16.66 milliseconds per frame and, after its own work, leaves about 10 for your page’s.
Severity in Wakaris
Improvement. It’s the most frequent finding in the catalog: it appears on 98.4% of analyzed pages (internal Wakaris figure).
What this finding is and what it measures
Every time the browser paints the screen it goes through the same stages: it runs the code, works out which style rules apply, decides the geometry of each element (that stage is called layout), fills in the pixels and composites the layers. Normally it decides when to do each stage and groups them to avoid repeating work.
Forced reflow breaks that order. It happens when code changes a style and immediately asks for a measurement that depends on that style: an element’s width, its height, its position. The browser can’t answer with the old value, so it interrupts what it was doing, applies the pending changes and recalculates the layout right there. The web.dev documentation calls it forced synchronous layout, and it’s exactly the work the browser was trying to save.
This finding is triggered when Wakaris finds that pattern on your page.
How it’s detected
Wakaris loads your page and watches whether the pattern appears during that process: a style write followed by a geometry read that forces an immediate recalculation. It adds up the time of the recalculations caused by your own website’s code and triggers at 30 ms, the threshold at which Chrome itself warns in the console. Code from other companies, such as a cookie banner or analytics, doesn’t count: changing it isn’t in your hands. Nor does code the browser can’t attribute to any script, because it wouldn’t tell you what to change.
Two clarifications for reading it correctly. The first is that a single load is observed without interaction, so recalculation that appears when opening a menu or scrolling is left out of the check. The second is that the finding says the pattern exists, not how much it costs: it doesn’t distinguish between a single read, which is barely noticeable, and a loop that recalculates the layout fifty times in a row. To know which one you have, you need to look at the code.
Why it matters
The key is the budget. The web.dev documentation sets the target at 16.66 milliseconds per frame for smooth display, and warns that, after the browser’s own work, the page’s code has about 10 left. In the case that same page documents, a forced layout inside a loop took more than 28 milliseconds per frame: almost double the entire budget.
What you notice when that budget runs out isn’t a number, it’s a feeling. The page appears but doesn’t respond to the first click, scrolling stutters and animations jump. And the cost is paid on the visitor’s device, not your server: a mid-range phone takes much longer than the computer where the website was coded.
It’s classified as Improvement and not Critical, and for good reason: although it’s frequent, almost no page breaks because of it.
Common causes
The pattern is almost never written on purpose. It comes in three ways.
The first is a loop that alternates reading and writing. Going through a list of elements, reading the width of one and applying it to the next forces the browser to recalculate on every pass, because the styles have changed since the previous read.
The second is animations built with properties that affect geometry. Animating width, height or position forces the layout to be redone on every frame, while properties that only recomposite layers skip it entirely.
The third, and the most common on a website nobody wrote from scratch, is third-party code: a carousel, a height equalizer, a component that measures its container to position itself. Each one does its own read and write without knowing what the others do, and the effect adds up. That’s why the finding also appears on carefully built pages.
How to fix it
Start by narrowing down the ground: Wakaris confirms the pattern is on that page, and from there it’s code work.
The rule that solves most cases is batching. Do all the reads first and all the writes afterwards. Moving the measurement outside the loop and reusing it turns fifty recalculations into one, without changing anything you can see.
For animations, replace properties that move geometry with ones that only recomposite layers: moving and scaling with transforms, or changing opacity, skips the layout stage entirely.
And if an area of the page is independent from the rest, tell the browser. CSS containment lets you declare that a block’s internal layout doesn’t affect anything outside it, so a change inside doesn’t force the whole document to be reviewed. Its variant for off-screen content avoids rendering what isn’t visible yet, which speeds up the first load.
Comparison of a loop that alternates reading and writing versus the same loop with the read moved outside
Brief to generate the image
Editorial illustration for a Wakaris technical guide. Topic: Comparison of a loop that alternates reading and writing versus the same loop with the read moved outside. Style: white background with a soft lime→pale green wash (#F8F7D6 → #E2F2DC), green→lime gradient accent (#8ED390 → #DCD86F), near-black ink (#12150B), pill shapes and rounded corners, soft shadows, clean schematic look, no photography. Format: 16:9, 1440 pixels wide. No legible text: any label, code or figure is shown as gray placeholder bars. The caption carries the meaning, not the image. No real logos or third-party brands. No recognizable people. Tags: cost, rendering, comparison, loop, reads, writes, alternating, versus
Ask your AI
If you want to dig into your specific case, copy one of these two prompts and paste it into the AI you use. Pick the one that fits your situation.
I already have the finding measured with Wakaris and want to fix it
Act as a professional, careful web technical auditor. Your goal is to help me understand a specific finding about my website and decide what to do about it, without making anything up. Context: I got this finding with Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, experience, accessibility and legal) and explains each problem so that every role on a team can understand it. The finding is: Rendering cost. My page forces the browser to recalculate the layout of its elements at the wrong time, because the code changes a style and immediately asks for a measurement that depends on that style. Reference: it’s triggered when the website’s own code adds up to 30 ms or more of forced recalculations during load, the threshold at which Chrome itself warns; third-party code doesn’t count. Paste the Wakaris result here: on which page you got it and what else the report flags in the performance area. If you don’t have it, tell me and I’ll explain how to get it before we continue. Rules you must follow at all times: 1. Don’t assume anything about my website. Every piece of data you use must come from what I confirm or from what Wakaris has measured. If you don’t know it, ask me before stating it. 2. Before giving me conclusions, ALWAYS ask me these questions, together and in plain language, to find out whether this finding really affects me and where: a) What platform is your website on? (WordPress, Shopify, custom-built site, other) b) Does the page have a carousel, gallery, drop-down menus or blocks that are equalized in height? c) Are there custom animations, and do you know whether they change size and position or only fades and slides? d) How much third-party code does the page have: chats, maps, reviews, social widgets? e) Do you notice the page stuttering when you scroll or being slow to respond to the first click, or does it run smoothly? f) Do you have access to the source code and templates, or only to the admin panel? g) If code needs changing, would you do it yourself, an in-house technician or an agency? 3. Every statement or recommendation must be argued in relation to MY context, not in general. If you recommend something, explain why it applies to my case. 4. Always state your level of certainty. If something is a hypothesis because you can’t measure it, say so: you can’t see my website, you’re reasoning from what I tell you. 5. Keep in mind it doesn’t always hurt the same: help me estimate whether in my case it’s a detail or a real problem, instead of assuming it’s serious from the start. 6. Don’t propose irreversible or risky technical changes (changing templates or components in production, disabling plugins all at once) without first warning me about the risk and that a backup or a test environment is advisable. 7. If you need data that can only be obtained by measuring the website (confirming the finding, the specific page, or whether the fix worked), tell me and recommend that I run the page through Wakaris again: that gets measured, not guessed. 8. The final decision is mine, not yours. Your role is to help me understand and prepare the action, not to decide for me. 9. If the fix is beyond what I can do myself, or a team is going to carry it out, help me get the problem ready to hand over: what it is, where it is, why it matters and what needs to be done, in an actionable format for that person. Source for this finding: https://www.wakaris.com/en/guides/performance/rendering-cost To measure it or measure it again: https://www.wakaris.com/ Start by briefly introducing yourself in your role and asking me the first block of questions.
I haven’t measured it yet and want to check whether my website has this problem
Act as a professional, careful web technical auditor. I’m investigating whether my website has a specific problem and I want you to help me find out honestly, without taking it for granted. Context: I got here through Wakaris, a tool that analyzes a website across 9 areas (performance, SEO, security, social, market, AI, experience, accessibility and legal) and explains each problem so that every role on a team can understand it. The problem I want to investigate is: Rendering cost. It’s when a page’s code forces the browser to recalculate the layout of its elements at the wrong time, in the middle of its work, which eats up part of each frame’s budget. Reference: it’s triggered when the website’s own code adds up to 30 ms or more of forced recalculations; third-party code doesn’t count. I DON’T know yet whether my website has it: I want to find out. Rules you must follow at all times: 1. First and most important: this is detected by observing how the page behaves as it loads, and you can’t load my website from this conversation. Make it clear from the start that you won’t be able to give me a definitive "yes, you have it" or "no, you don’t," only a hypothesis based on what I tell you. 2. Don’t assume anything. Before giving me any assessment, ALWAYS ask me these questions, together and in plain language, to estimate whether I’m likely to have it: a) Does your website stutter when you scroll, or freeze for a moment right after it appears? b) Does it have a carousel, gallery, animated counters or blocks that are equalized in height? c) How many third-party components does it have: chats, maps, reviews, social widgets? d) Was it built with a purchased template, a visual builder, or custom-made? e) Do you notice the slowness more on mobile than on desktop? 3. With my answers, give me a clear estimate of whether it’s LIKELY or UNLIKELY that I have it and through which route, argued from what I’ve told you and explicitly marked as a hypothesis, not a diagnosis. 4. Be honest about frequency: this pattern is very common, so telling me it’s likely adds little. What’s useful is helping me estimate whether in my case it’s actually noticeable. 5. Tell me directly that the only way to really know is to check it, and that I can do it for free and without creating an account by running my website through Wakaris, which will tell me whether the pattern is on that page, and the status of the other areas too. 6. If I ask you how to check it by hand, don’t hide it from me, but remind me that Wakaris does it faster, on the real page, and with extra information I don’t get by hand. 7. If, once checked, it turns out I do have it, tell me the next step is to understand how it affects me and how to fix it in my specific case. 8. The conclusion and the decision are mine, not yours. You help me find my bearings. Source for this finding: https://www.wakaris.com/en/guides/performance/rendering-cost To measure it: https://www.wakaris.com/ Start by briefly introducing yourself in your role, making point 1 clear, and asking me the block of questions.
Frequently asked questions
What exactly is a forced reflow? +
It’s a layout recalculation the browser has to do ahead of time. It happens when code changes a style and then asks for a measurement that depends on it, such as width or position. The browser can’t return the old value, so it recalculates on the spot.
If it appears on 98.4% of pages, do I need to do anything? +
Not urgently. That’s why Wakaris classifies it as Improvement and not Critical. It’s worth looking at when the page is already tight on performance or when you notice stuttering while scrolling: that’s when the fix is usually cheap and noticeable. If the page runs smoothly, it can wait.
Can you see a forced reflow with the naked eye? +
Sometimes yes and sometimes no, and that’s the trap. Nobody notices a single read. A loop that recalculates dozens of times turns into jerky scrolling, jumpy animations and moments when the page doesn’t respond to the first click.
Is it the same as content that shifts while loading? +
No. That other finding measures elements moving around before your eyes, and you can see it. Rendering cost measures the browser’s internal work: the page can stay perfectly still while recalculating its geometry many times per second.
Sources cited
- web.devAvoid large, complex layouts and layout thrashing, web.dev: the definition of forced synchronous layout, the loop that causes it, the case of more than 28 milliseconds per frame, and the rule of batching reads and writes.
- web.devRendering performance, web.dev: the five stages of painting, the 16.66 milliseconds per frame with about 10 available for your own code, and which properties trigger layout versus those that only composite.
- developer.mozilla.orgReflow, MDN: reflow as the recalculation of position and geometry, followed by repaint.
- developer.mozilla.orgUsing CSS containment, MDN: containment limits recalculation to the declared subtree, and the variant for off-screen content avoids rendering it until it’s needed.
Updated: September 8, 2026.
This article is part of Wakaris, which analyzes your website across 9 areas and explains each finding so that every role on your team can understand it.