-
Notifications
You must be signed in to change notification settings - Fork 890
Description
Describe the issue
When Nuxt UI is paired with Tailwind CSS v4 (via @tailwindcss/vite
) the build emits a hashed file such as /_nuxt/ entry.11BHMGLZ.css
. That file contains every Tailwind utility that gets pulled in through the root stylesheet. Nuxt
injects a <link rel="stylesheet">
for it in the document <head>
, so the browser must download ~265 kB of CSS
before it can render. In Lighthouse and WebPageTest this request shows up as the dominant LCP blocker for us.
The only workarounds we have found are to inline the whole file (which bloats HTML responses and removes caching
benefits) or to accept that the request blocks first paint. Even enabling @nuxtjs/critters
still leaves the large
entry chunk untouched, so we do not get a working critical CSS setup out of the box.
Steps to reproduce
- Create a fresh Nuxt 4 project.
- Install Nuxt UI and Tailwind 4 (
@tailwindcss/vite
). Leave the defaultapp/assets/css/main.css
with@import "tailwindcss";
. - Run
pnpm build
. - Inspect
.output/public/_nuxt/entry.*.css
(ours is 265 kB). Run Lighthouse against the built site and note the
render‑blocking warning.
Expected behaviour
Ideally, Nuxt UI would either:
- only emit the subset of Tailwind actually used, or
- split utilities into non‑blocking bundles / inline per‑route critical CSS automatically so the entry chunk isn’t a
monolithic render blocker.
Additional context
Environment: Nuxt 4.1.2, Nuxt UI 4.0.0, Tailwind 4.1.13, @tailwindcss/vite
. Even with @nuxtjs/critters
enabled the
entry stylesheet remains large and render blocking.
Thanks for taking a look—happy to provide any extra traces or builds if helpful.