The content was server-rendered. A 480KB script held it hostage.

The content was server-rendered. A 480KB script held it hostage.

A news startup did everything right on paper: SSR, real HTML in the first response, content visible immediately. Yet mobile rankings lagged and Core Web Vitals stayed red. Interaction-to-Next-Paint was 480ms; LCP, 3.8s.

The symptom confused them — if it's server-rendered, why is it slow? The HTML was there at 200ms.

Turns out a single render-blocking script in the , synchronous, 480KB, that the browser had to download and execute before painting anything. The server-rendered HTML existed but couldn't paint until that blocking script cleared. SSR got the content into the document; the script kept it off the screen. Googlebot's rendering reflected the same delay, and field LCP punished it.

We deferred the bundle, inlined critical CSS, and split the script so only 60KB was needed for first paint. The server HTML now painted at 1.1s.

LCP dropped from 3.8s to 1.2s. INP to 90ms. 'Good' Core Web Vitals URLs went from 8% to 94% in a month. Mobile organic +52% over the quarter.

Server-rendering content means nothing if a blocking script won't let the browser draw it.