Next.js 16.3.3's inlineCss flag fixed my performance score - here's what happened

I was building a website, and everything was fine. Then one day my performance score dropped from 100 to 70 and below. That matters more than it sounds: a performance score under 90 can hurt your traffic. Long loading times mean bad user experience. Bad user experience means fewer customers. Fewer customers is bad for you. I ran an audit on my own site with Scanora, the tool I'm building, and it flagged performance as the weakest area. My first instinct was to blame a <motion.div> - Framer Motion animations are an easy scapegoat. But digging deeper, the real numbers told a different story:

- TTFB: an excellent 19ms

- Total page weight: only 430KB

- No single large or slow resource

The actual gap was between server response and First Contentful Paint: 2.7 seconds for content to actually appear on screen. Fast server, slow paint - that's the signature of a render-blocking resource, not a slow backend.

The cause: my CSS was being loaded via a standard <link rel="stylesheet"> tag. That forces the browser to download HTML, parse it, discover the stylesheet link, then fetch it - before it can paint anything. One more network round-trip standing between a fast server and a visible page. It turns out Next.js shipped an experimental flag for exactly this in 16.3.3: inlineCss.

// next.config.js

const nextConfig = {

experimental: {

inlineCss: true,

},

}

With it enabled, Next.js swaps the <link> tag for an inline <style> tag — your CSS arrives with the HTML itself, in the first response, no extra request required.