Add support for critical CSS inlining with App Router

[mlstubblefield]

To Reproduce

1. Create a new next.js repository on vercel
2. Update next config
   const nextConfig = { experimental:{ optimizeCss: true } }
3. Add critters package - npm install critters
4. Host the page on vercel
5. Run the homepage of the app through webpage test https://www.webpagetest.org/result/231027_BiDcZF_FDJ/1/details/#waterfall_view_step1

Critical CSS is blocking :( and not optimized!

Current vs. Expected behavior

Before the appDir, critical css was inlined and FCP would be really really fast.
Now, you can see that FCP is behind the blocking CSS!

Just look at this waterfall https://www.webpagetest.org/result/231027_BiDcZF_FDJ/1/details/#waterfall_view_step1

[thaophamvan]

There is no way to inline critical CSS on App router. I can't find any solution to do it now. I don't know why Nextjs not support for App router

@mlstubblefield do you have any solution to solve it now?

[mlstubblefield]

Yea, it's a bummer- we saw huuuge improvements in our FCP when we first added critters, so I'm sad to see it no longer function.

[nilskaspersson-imtf]

Same. To be frank, I'm quite confused why the web dev community seemingly has abandoned efforts to inline the critical path. It is such a massive performance improvement.

[leerob]

Critters does not support streaming. This experimental flag works in the Pages Router (no streaming) but does not work with the App Router (has streaming). I've updated this issue to be a feature request and converted it to a discussion.

[thaophamvan]

Head tag of app router is not allowing to push inline CSS. So i have to put it on body tag

[rc-markzhou]

I am also looking into a way where I can put all css styles into a style tag which gets injected to head rather than requesting from external css files to improve the LCP etc.

What I have tried so far,

1. Use Cloudflare worker script to parse the HTML and find the external CSS request, make a fetch call for the external CSS file and replace the link tag with a style tag which holds the CSS content. It works, but obviously there is a mismatch with SSR and CSR output. However, I didn't notice any impact from end user perspective.
2. Config the webpack to use style-loader with insert: 'head' option. However, it doesn't work for SSR.

[fluidprompter-ben]

@rc-markzhou would you mind sharing your style-loader webpack config? I'm curious to try it with static site generation with NextJs app router.

FYI, considering your 1st option mentioned cloudflare, I export static nextjs site and host on cloudflare pages and use pages functions (essentially workers) to supplement my static site with server side code and do not use NextJS for middleware/redirects/etc. I found this is almost 200% faster than SSR with next-on-pages (though maybe next-on-pages edge runtime isn't as fast as vercel, I don't know). I currently average FCP/LCP around 650ms (desktop highspeed connection warm edge cache) with 100-200ms of that being CSS blocking loading.

[rc-markzhou]

@fluidprompter-ben Basically, this solution doesn't even generate the style tag on server side render. On client side, we gonna experience a Flash Of Unstyled Content(FOUC).

next.config.js

webpack: (config, options) => {
  if (!options.isServer && !options.dev) {
    config.module.rules.push(
      {
          test: /\.(sa|sc|c)ss$/,
          use: [
            {
              loader: 'style-loader',
              options: {
                insert: 'head',
                injectType: 'singletonStyleTag',
              },
            },
            {
              loader: 'css-loader',
            },
            'postcss-loader',
            'sass-loader',
          ],
        },
      )
    }

    return config
}

[Mifaresss]

I have different classNames in tag style and in html after npm run start. How you avoid this problem?

[mlstubblefield]

I would be very interested to hear performance comparisons from folks who were using optimizeCss in the Pages Router, versus streaming with the App Router, both in lab data and field data results.

Our results in the field were quite significant. Here are our field results using optimizeCss.

Something like 700-800ms improved FCP for mobile p90.
#29925 (comment)

[thaophamvan]

@leerob any update on this request?

[mlstubblefield]

I don't love the "not lots of upvotes" answer as it stops us from adopting appDir.
That being said, is there any direction that you could provide on how I could roll my own appDir + critters plugin?

[leerob]

Critters is incompatible with streaming, so there is not a workaround currently. Upvotes aren't the only way, but they're helpful!

[mlstubblefield]

Let's say critters was compatible, where would I/how would I plug it in? Would the StyledComponents implementation be similar in terms of how it "should work"?

[kgvivekwork]

@leerob Can you please give us some workaround for criticalCss which will be helpful for most developers

[tropikoder]

Google penalizes SEO when there's a slow LCP which happens every time when the critical path css isn't server-side rendered.

[markoleavy]

I'm testing a postbuild script to get inlined critical css with critters on html files for SSG pages, for the moment just in preview branches and on the homepage only.
I don't get any errors on the browser console, but lab performance didn't change significantly. Probably because of the large amount of inlined css, or some critter setting I'm not getting right. In particular I'm wondering which "preload" strategy would be better for next. I've tried default, swap, body and false, didn't notice any difference in test results.
I'm using version 13.4.12 with tailwind and next/fonts.
Here's the script:

import Critters from "critters";
import fs from "fs";

const critters = new Critters({
  path: ".next/static/css",
  publicPath: "/_next/static/css/",
  inlineFonts: true,
  preloadFonts: false, // next is already preloading them
});
async function editHome() {
  const inlined = await critters.process(
    fs.readFileSync(".next/server/app/index.html", "utf8")
  );
  fs.writeFileSync(".next/server/app/index.html", inlined);
}

new Promise(() => editHome());

[Mifaresss]

I think so too, but, as you can see, they are empty(

[markoleavy]

I'll let you know as soon as I implement next-intl, but if it's working
properly (and considering next app is full of unstable features and
unexpected behaviours, I'm afraid it's not) the html file must be
somewhere, otherwise it can't be served.

[vasujhawar]

I have implemented this
https://locize.com/blog/next-app-dir-i18n/
I got the html files generated after build, I will let you know if this script works or not.

[mlstubblefield]

As far as stragies go-- these were the default settings with the original "optimizeCss" flag...

next.js/packages/next/src/server/post-process.ts

Line 237 in 2f7721a

const Critters = require('critters')

{
ssrMode: true,
reduceInlineStyles: false,
path: renderOpts.distDir,
publicPath: `${renderOpts.assetPrefix}/_next/`,
preload: 'media',
fonts: false,
}

[mlstubblefield]

I tried to get this to work on pages w/ dynamic routes and had issues. In a lot of ways I'm having the same problem as @vasujhawar .

[calliope-codes]

tldr: Under Chrome "Slow 3G" conditions, it appears that inlining critical css makes the difference between good and mediocre/poor Core Web Vitals outcomes using the app router.

I have performed some lab benchmarks with a small GKE-deployed NextJS 14.1.0 ssr application with some suspended async operations (waterfall screenshot below). The waterfall suggests that inlining critical CSS would have a substantial positive performance impact on FCP in high-latency and/or low-bandwidth situations.

Below is a screenshot of the waterfall for the site, with disabled cache and Chrome "Slow 3G" (2 seconds request latency, 400 kbps down). Because Chrome adds two seconds of latency to each request, the fully-loaded HTML document is available two seconds before the critical (external) CSS finishes loading.

(In low-bandwith conditions, even with fetch priority set properly, the external CSS is competing with the loading Javascript, making it load even more slowly. If the CSS were inlined, the high latency and low bandwidth means the inline CSS/html has several seconds at 400 kbps down where it is the only resource being fetched, so high latency might actually help FCP in low-bandwidth situations!)

From a "qualitative" perspective, the slow FCP in this situation makes a lot of the (really cool) NextJS preloading UI optimizations less impressive, because the suspended SSR (especially with non-dynamic routes) finishes long before critical CSS is even ready! Without inlining critical CSS under these network conditions, preloading only looks good if the browser has a warm cache.

With my use case, I expect greater-than-normal visits under bad network conditions and no browser cache. The most important site content is text, and I want to display that immediately. (NextJS caching is a fantastic tool for this!) Aside from the inline CSS issue, the NextJS app router is performing beautifully. (In fact, CWV for mobile/desktop are generally well above 90%.) However, I feel bad that in spite of the technical backflips I'm doing, anyone inlining their critical CSS is going to massively outperform my app on FCP in bad network conditions.

I am also particularly sensitive to performance under bad conditions because I am hoping to use benchmarks as marketing materials (both personally as a developer and for the product), and it's tough to give a talk on web performance when your critical CSS is not inline. In some ways, I feel like the sword character from Indiana Jones, doing weeks of next-gen optimizations and being taken out by style={{backgroundColor: 'black'}}.

If I am misreading or misinterpreting that waterfall screenshot, please let me know. As always, thank you maintainers!

[welschmoor]

This is very important to get it working with the App Router!

[vasujhawar]

I am also waiting for further updates. How many upvotes are critical for critical css🤌🏻?@leerob @mlstubblefield

[markoleavy]

Are you working with static pages? Have you tried my script up here?
I'd be curious to understand why is not working as expected in my project.
Of course should work just for static pages and for FCP and LCP on site landing only.

[mlstubblefield]

I did try that approach, but any sort of dynamic routing does fall down @markoleavy.

[kenaku]

It's so frustrating, guys.
Spent like a month converting our middle size app to "app router" with all the bells and whistles, optimised what i could, fully adopted new patterns, dealt with dozens of issues with hydration errors and router quirks, integrated pretty awkward parallel routes and intercepted routes api's...
Only to land with like 10 seconds of a white screen on slow 3g.
Page router with css optimisation was 2 times faster to FCP and better LCP scores.

At this point im pretty much regret all this time spent. could live with "not ideal" ssr stuff in page router
Why even advertise this architectural changes as a path forward, if it's basically a downgrade on major metrics?

Sorry for the rant, but it was really painful and hard to pull off and now i guess i will have to revert refactoring because of this css stuff

[mlstubblefield]

I feel your pain.

[behitesh]

Hi. Is there an update about adding support for Critical CSS?

I Spent more than a week migrating my app to app-roter only to realize this feature was missing. It was a lapse on my part not to notice this before migration 😞

Considering how significant this can be for the page-load experience boost, I can't help but wait to have the support added to take my effort and app to production

If anyone is already working on this please do mention it here... I'd be happy to help in any way possible.

[markoleavy]

My implementation of Critters with post-build works on static htmls, but for some reason it doesn't improve performance on my project, and it does not work if you use page revalidation or ISR. Just static builds.
Could be a good starting point though.

[oliviertassinari]

Similar result from https://danielnagy.me/posts/Post_tsr8q6sx37pl. Inlining critical CSS matters on mobile according to this benchmark:

https://youtu.be/1gZmkpsVGkk?si=q8pNnWqkJLYzqjlt

Sebastian made a similar point:

reactwg/react-18#108

[lainosantos]

HI. Since there are problems dealing with critical css with dynamic routes, why aren't you just providing a possibility to use a global css embedded in the head? Many projects only use a global css with tailwind and this solution already solves many performance problems and user experience. This is frustrating, an entire application being limited to already known performance problems.