A lot of developers (including me, a few years back) think that if an API responds fast, the UI should also feel fast.
But the real bottleneck often lies in what happens after the data arrives — when the browser starts to render it.
And here comes reflow, repaint and composite:
𝐋𝐚𝐲𝐨𝐮𝐭 (𝐑𝐞𝐟𝐥𝐨𝐰): The browser figures out where every element should sit and how big it should be.
Even something as small as changing font size or toggling a hidden div can trigger this.
𝐏𝐚𝐢𝐧𝐭 (𝐑𝐞𝐩𝐚𝐢𝐧𝐭): Once layout is done, it starts coloring things — text, borders, shadows, etc.
𝐂𝐨𝐦𝐩𝐨𝐬𝐢𝐭𝐞: Finally, it combines all the painted layers into a frame you actually see.
Now here’s where things go wrong 👇
When JavaScript keeps changing styles or reading layout properties in between DOM updates, the browser is forced to redo this work again and again — what we call 𝐥𝐚𝐲𝐨𝐮𝐭 𝐭𝐡𝐫𝐚𝐬𝐡𝐢𝐧𝐠.
That’s when your app feels sluggish, even though everything “looks fine” in the code.
A few practical things that actually help:
- Avoid triggering layout reads right after DOM writes.
Use transform and opacity for animations (don’t move elements using top or left).
- Debounce heavy scroll or resize handlers.
- And if you can — batch your DOM changes instead of doing them one by one.
It’s not about “micro-optimizing” — it’s about understanding how browsers think. Once you get that, performance tuning becomes way more predictable.
#FrontendPerformance #BrowserRendering #WebPerformance #FrontendEngineering #ReactJS #TypeScript #WebDevTips
Thanks for sharing