Cutting a page's layout shift from 0.57 to 0.031, and 1.5 MB of JavaScript with it

Our portfolio page felt fine on a fast laptop and felt broken on a phone. The numbers said the same thing, and they were worse than we expected.

What we measured

• **Cumulative Layout Shift: 0.57.** Anything above 0.1 is "poor". The page was moving under the reader's thumb.
• **JavaScript transferred: 1,716 KB.**

Cause one: everything was client-rendered

The page was wrapped in a dynamic import with `ssr: false`. Nothing existed in the initial HTML, so the browser had no idea how tall anything was until the JavaScript arrived — and then the whole page appeared at once, shifting everything below it. Removing that wrapper meant the markup shipped in the response and the browser reserved space correctly. CLS went from 0.57 to 0.031.

Cause two: an animation library that earned nothing

`gsap` was in the bundle for two effects that CSS could do. Removing it, and lazy-loading the gradient background behind a dynamic import, took JavaScript from 1,716 KB to 170 KB — a 90% cut, for no visual difference we could detect side by side.

What we would tell you

• **`ssr: false` is a layout-shift decision, not just a rendering one.** If the content matters for first paint, it should be in the HTML.

2. Measure CLS after the change, on a throttled phone profile. Desktop hides this class of bug almost completely.

3. Check what your animation library is actually doing. Ours was doing 4% of the work and carrying most of the weight.

4. A 90% bundle cut is possible more often than people expect — it usually means something was included by default that nobody chose.

We published the before and after because the interesting part is not the number. It is that we shipped a page we had not measured.