Flip the flag before you hand-build critical CSS
A client marketing site sat at 80 on mobile Lighthouse and would not move. We had done the honest work already: shrank a 270 KB favicon to 2.6 KB, preloaded a responsive hero image, demoted a decorative watermark's fetch priority, lazy-loaded the animation library. Still 80.
The LCP breakdown told the real story. Element render delay: 1,082 ms. The hero image was arriving fast and then sitting there, fully downloaded, waiting to paint. The blocker was a 64 KB external Tailwind stylesheet.
Read the LCP breakdown before doing anything
When element render delay dwarfs resource load duration, the download is not your problem. Something is blocking paint, and on a Tailwind site that something is almost always the generated stylesheet.
Here is the part that surprised us. Next.js 16 does critical CSS extraction by default, but it only inlines component-level style blocks. On our site that meant about 8 KB of decorative SVG animation CSS got inlined, and zero Tailwind utilities. Every above-the-fold class waited on the external sheet.
The 3-line fix
In next.config.ts:
experimental: { inlineCss: true }
At build time this replaces the generated stylesheet link with an inline style block in the HTML. No render-blocking request, no source changes.
The numbers on our site: element render delay went 1,082 ms to 46 ms. Mobile Lighthouse went 80 to 99, desktop 99 to 100. LCP dropped from 5.4 s to 2.0 s.
The alternative was extracting critical CSS from Tailwind output by hand. An hour or two up front, then maintenance debt every time the hero changes. That is digging the trench by hand while the trencher idles ten feet away.
To verify it after deploy, curl the live HTML. You want zero rel="stylesheet" links and inline style tags roughly the size of the old bundle. Production builds only; next dev will not show it.
When to skip it
The flag is global, not per page. And the styles get duplicated between the inline tags and the streaming payload: our HTML went from 117 KB to 315 KB uncompressed, though gzip recovered most of that on the wire.
Skip it when your visitors are mostly returning (they lose the cross-page CSS cache), when your bundle runs past roughly 100 KB, when a multi-page app would re-send the same CSS on every navigation, or when your server response time is already the bottleneck. The documented sweet spot is exactly what we had: atomic CSS, a marketing site, first-time mobile visitors.
The date on this advice
This is Next.js 16, written in August 2026, and the flag says experimental right on the label. Experimental flags get renamed, promoted, or dropped between major versions. If you are reading this on Next 17 or later, read the release notes before you copy the config line.
The principle underneath will outlive the flag: when mobile LCP is stuck, find out whether paint is blocked before you optimize downloads, and reach for the framework's own switch before you build the machinery by hand. We got 19 Lighthouse points for 3 lines of config. Try the flag first. Worst case, you flip it back.