I Crashed a Mobile Browser With One CSS Property. Here's What I Learned About Rendering.

A few months ago, I was debugging a checkout flow on mobile. Everything looked fine on desktop — smooth step transitions, nice fade-ins, snappy UI. Then QA pinged me: "the payment page freezes on iPhone SE for ~2 seconds when opening." I opened Web Inspector, navigated to the Layers panel, and my jaw dropped. What should have been 3–4 composite layers turned into 34 . Every pricing card, every badge, every animated element had been silently promoted to its own GPU layer. The page was eating over 200 MB of GPU memory just to show a pricing table. The fix? Moving one z-index and removing two will-change declarations. Three lines of CSS. But to understand why that worked, you need to understand how browsers actually render pages. And that's what this article is about. The rendering pipeline: from HTML to pixels Every time a browser displays a webpage, it follows a pipeline. Think of it like a factory assembly line — each stage builds on the previous one: HTML ──► DOM ──► Render Tree ──► L