Add support for critical CSS inlining with App Router #59989
Replies: 24 comments 93 replies
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Head tag of app router is not allowing to push inline CSS. So i have to put it on body tag |
Beta Was this translation helpful? Give feedback.
-
|
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,
|
Beta Was this translation helpful? Give feedback.
-
|
@rc-markzhou would you mind sharing your 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. |
Beta Was this translation helpful? Give feedback.
-
|
@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 |
Beta Was this translation helpful? Give feedback.
-
|
I have different classNames in tag style and in html after npm run start. How you avoid this problem? |
Beta Was this translation helpful? Give feedback.
-
Our results in the field were quite significant. Here are our field results using optimizeCss. |
Beta Was this translation helpful? Give feedback.
-
|
@leerob any update on this request? |
Beta Was this translation helpful? Give feedback.
-
|
I don't love the "not lots of upvotes" answer as it stops us from adopting appDir. |
Beta Was this translation helpful? Give feedback.
-
|
Critters is incompatible with streaming, so there is not a workaround currently. Upvotes aren't the only way, but they're helpful! |
Beta Was this translation helpful? Give feedback.
-
|
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"? |
Beta Was this translation helpful? Give feedback.
-
|
@leerob Can you please give us some workaround for criticalCss which will be helpful for most developers |
Beta Was this translation helpful? Give feedback.
-
|
Google penalizes SEO when there's a slow LCP which happens every time when the critical path css isn't server-side rendered. |
Beta Was this translation helpful? Give feedback.
-
|
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. 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()); |
Beta Was this translation helpful? Give feedback.
-
|
I think so too, but, as you can see, they are empty( |
Beta Was this translation helpful? Give feedback.
-
|
I'll let you know as soon as I implement next-intl, but if it's working |
Beta Was this translation helpful? Give feedback.
-
|
I have implemented this |
Beta Was this translation helpful? Give feedback.
-
|
As far as stragies go-- these were the default settings with the original "optimizeCss" flag... |
Beta Was this translation helpful? Give feedback.
-
|
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 . |
Beta Was this translation helpful? Give feedback.
-
|
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! |
Beta Was this translation helpful? Give feedback.
-
|
This is very important to get it working with the App Router! |
Beta Was this translation helpful? Give feedback.
-
|
I am also waiting for further updates. How many upvotes are critical for critical css🤌🏻?@leerob @mlstubblefield |
Beta Was this translation helpful? Give feedback.
-
|
Are you working with static pages? Have you tried my script up here? |
Beta Was this translation helpful? Give feedback.
-
|
I did try that approach, but any sort of dynamic routing does fall down @markoleavy. |
Beta Was this translation helpful? Give feedback.
-
|
This should apply to every static page for dynamic routes as well: import Critters from 'critters';
import fs from 'fs';
import path from 'path';
const critters = new Critters({
path: '.next/static/css',
publicPath: '/_next/static/css/',
inlineFonts: true,
preloadFonts: false,
preload: 'media',
});
function fromDir(startPath: string, filter: string) {
if (!fs.existsSync(startPath)) {
console.log('No .next folder found. Aborting.');
} else {
const files = fs.readdirSync(startPath);
Promise.all(
files.map(async file => {
const filename = path.join(startPath, file);
const stat = fs.lstatSync(filename);
if (stat?.isDirectory()) {
fromDir(filename, filter); //recurse
} else if (filename.endsWith(filter)) {
const inlined = await critters.process(
fs.readFileSync(filename, 'utf8')
);
fs.writeFileSync(filename, inlined);
}
})
);
}
}
const promise = new Promise(() => fromDir('.next/server/app', '.html'));
promise.then(() => console.log('Postbuild done')); |
Beta Was this translation helpful? Give feedback.
-
|
It's so frustrating, guys. At this point im pretty much regret all this time spent. could live with "not ideal" ssr stuff in page router 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 |
Beta Was this translation helpful? Give feedback.
-
|
I feel your pain. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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: 
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
You can use Tailwind CLI to generate css file sot my script will work for inlining Tailwind as well. In general, I don't recommend inlining Tailwind CSS files though. If you do that you cannot cache CSS files between requests and you end up sending all the utility classes used in the app on every page request. |
Beta Was this translation helpful? Give feedback.
-
@javascripter this doesn't usually apply as most navigation in a nextjs site is a "soft navigation" and will not reload an inlined element in the header if done correctly. Vercel just needs to inject the inline CSS in the , NOT include CSS in the page partial resources for hydration or soft navigation and then everyone's page load performance will increase. The only trade-off here is if you had a lot of localized CSS styles (many 10's of KB) that made the initial payload so much larger that its better to code split styles for various pages - but for almost all normal sites you are better off with a slightly larger number of initial bytes in a single request than splitting those bytes over multiple sequential render blocking requests. IMHO, the whole of idea of "streaming" responses in nextjs is missing the mark for any static website such as a marketing website and is really focused on "apps" where there are a lot of different components and views with lazy loaded app data, etc. Vercel wants to replace CRA with a better thing and in doing so is leaving behind all the people who just wanted to build normal websites with React. |
Beta Was this translation helpful? Give feedback.
-
|
vercel-labs/next-partial-prerendering@b06d388 |
Beta Was this translation helpful? Give feedback.
-
|
@zipme That works as well, but what we will recommend (I still need to write this up as a follow-up below) does not use |
Beta Was this translation helpful? Give feedback.
-
|
How do we keep only necessary styles from both tailwind and custom classnames (i.e. defined via tailwind.config)? |
Beta Was this translation helpful? Give feedback.
-
|
Hi everyone, Just want to give an update that our team has recently discussed critters/this discussion further! As mentioned above, this is unfortunately currently not compatible with App Router because of streaming. We're currently investigating how this would compare with Partial Prerendering (PPR) via a method like link-header prefetching, which could be an alternative way of achieving the same performance benefits as critters. We will report back on this thread with new updates! |
Beta Was this translation helpful? Give feedback.
-
|
@markoleavy no we had those loading as well. |
Beta Was this translation helpful? Give feedback.
-
|
Loading both style tag and the css with high priority is certainly not the best option.
<script>
self.__next_f.push([1,"5:I[4687,[],""]nc:I[74242,[],""]nd:[]n0:[[
["$","link","0",
{
"rel":"stylesheet",
"href":"/_next/static/css/f1821db79a35143b.css",
"precedence":"next",
"crossOrigin":"$undefined"}]],
["$","$L5",null,{
"buildId":"4",
// etc..
<script/>
A possibility - rough and risky - could be editing the static html inside the postbuild script with a tool like cheerio and remove the link rel part from the RSC payload from the static html. @samcx do you think it might be a viable workaround? |
Beta Was this translation helpful? Give feedback.
-
Injecting the critical styles to head tag solved my problem <style
id="global-style"
dangerouslySetInnerHTML={{
__html: fs.readFileSync(path.join(process.cwd(), 'path', 'global.css'),'utf8')
}}
/> |
Beta Was this translation helpful? Give feedback.
-
|
@ke1vin4real and how did you removed the css blocking request? |
Beta Was this translation helpful? Give feedback.
-
Agreed- while it's easy to inject the styles, we still need to eliminate the blocking requests. |
Beta Was this translation helpful? Give feedback.
-
Method for SSG static pages onlyI've worked a few hours on my previous script and I got it working. No css is loaded on first-page landing (when the html file is effectively used), so no blocking request (actually no css request at all) nor additional css kbs. In my case I had no significant improvement on performance tests, so I haven't fully tested it, as I'm probably not gonna use it in production. Anyway I got a perfect layout on all the pages I tested, within a quite complex tailwind based app. Hope it might be helpful for someone! Implementation
"postbuild": "tsx src/postbuild.ts",
/* eslint-disable no-useless-escape */
import { load } from 'cheerio';
import Critters from 'critters';
import fs from 'fs';
import path from 'path';
const critters = new Critters({
path: '.next/static/css',
publicPath: '/_next/static/css/',
inlineFonts: true,
preloadFonts: false,
preload: 'body',
logLevel: 'error',
});
function fromDir(startPath: string, filter: string) {
if (!fs.existsSync(startPath)) {
console.log('No .next folder found. Aborting.');
} else {
const files = fs.readdirSync(startPath);
// iterates over files and folders
Promise.all(
files.map(async file => {
const filename = path.join(startPath, file);
const stat = fs.lstatSync(filename);
// recursion in case stat is directory
if (stat?.isDirectory()) {
fromDir(filename, filter);
// checks if the file is an html
} else if (filename.endsWith(filter)) {
// inlines css and moves <link rel=stylesheet>s to body
const inlined = await critters.process(
fs.readFileSync(filename, 'utf8')
);
//writes critters' changes
fs.writeFileSync(filename, inlined);
//loads page on cheerio (html editor)
const page = load(fs.readFileSync(filename, 'utf8'));
page('script')?.each((i, elem) => {
const text = page(elem).text();
// If a <script> tag (RSC payload) contains a css import, removes it
if (text?.match(/\[[^\]^\[]+_next\/static\/css\/.*?\.css.*?\]/)) {
const newText = text.replaceAll(
/\[[^\]^\[]+_next\/static\/css\/.*?\.css.*?\]/g,
'[]'
);
page(elem).text(newText);
}
});
//removes <link rel=stylesheet>s to avoid css loading.
// Remove this part in case you might need non-blocking css load
page('[rel="stylesheet"]')?.each((i, elem) => {
page(elem).remove();
});
// writes cheerio's changes
fs.writeFileSync(filename, page.html());
}
})
);
}
}
const promise = new Promise(() => fromDir('.next/server/app', '.html'));
promise.then(() => console.log('Postbuild done'));
|
Beta Was this translation helpful? Give feedback.
-
|
I tried your script, but it did not seem to work correctly for me - it DID add the css into a style tag in the head of the SSG pages, but for some reason Critters just omitted some styles and selectors even though they were present in the markup and this would cause the pages to be loaded semi-broken. I've been trying for weeks to increase our page speed score, removing libraries and shaving KBs from the bundle little by little, to absolutely no avail. I was able to make the first load JS 113kB and did all of the image optimizations possible and I still get a measly 45 score on mobile. The fact that I cannot use critical CSS inlining and webworkers for offloading the main thread of all the third-party scripts the marketing dept wants to load is really frustrating as I though the App router already had everything I would need to make a fast static website. Sorry for the rant... |
Beta Was this translation helpful? Give feedback.
-
|
Hi @Danogot516, I'm sorry to hear it didn't work for you. I would be interesting to investigate why critters did fail to load part of the css, and see if there are possibile workarounds. |
Beta Was this translation helpful? Give feedback.
-
|
@markoleavy I did not test the speed. Dev tools lighthouse always seems to show drastically better results (~30 points) when compared to the pagespeed insights. I am not sure how to debug critters in this case, what I noticed is that I did not see any of the console logs in your scripts when running the build and postbuild scripts. I did git the css inlined, but for some reason critters just omitted parts of the styles - I would have two css rules |
Beta Was this translation helpful? Give feedback.
-
|
@samcx Do we have any ETA on this? This issue is having a lot of impact on our LCP and impacting our SEO performance. |
Beta Was this translation helpful? Give feedback.
-
|
@samcx I was hoping the vercel team would add it in the v15, but I don't see it in the changelogs :( |
Beta Was this translation helpful? Give feedback.
-
|
Terribly disappointed. Not a fan of React, even less of a fan of React-based server frameworks, only confirms negative perceptions about this part of frontend-land. It's an important feature for a server framework - please add support! |
Beta Was this translation helpful? Give feedback.
-
|
@gujral1997 v15 has necessarily landed yet—it's still a release candidate. It's going to land with React v19 when that's released on latest.
There is work being done for this (although not directly mentioned in the PR) → #67715. We will continue to share any important updates as they come! |
Beta Was this translation helpful? Give feedback.
-
@samcx thanks for the explanations and all the work so far, I am very much looking forward to using this. Personally I think its silly, especially when using Tailwind, but metrics are metrics, and we are frequently asked to fix this issue for our clients, so it is a major help knowing that the Next team is aware and has a plan. Should we expect a v14 release of this? It is not possible to move to v15 or canary with production projects, and this issue is quite time sensitive due to decreasing lighthouse scores that heavily affect SEO. I wish v15 was closer, but as things stand it is on rc~120++ and without a clear end date in sight (at least for those of us looking from the outside). The SEO stakeholders keep asking me to solve this, and I keep having no answer for them, so it'd be super useful for me to know if we will be waiting for v15 or should expect this in v14 in the next few weeks. :) |
Beta Was this translation helpful? Give feedback.
-
|
@markomitranic Unfortunately, there will not be a v14 release for Link Headers (I misspoke earlier, my apologies). A few months ago I spoke how better performance (comparable to critically inlining CSS) could be achieved via PPR → Link Headers. What I didn't mention clearly is that this is only achievable by PPR because we can quickly send a static shell, which then makes it feasible to send Link Headers with that static shell. You can also use PPR with v14 canary (I believe this requires React 19), which at that point, it's just better to be on v15 canary. In the meantime, you will have to resort to other options such as → #59989 (reply in thread). I also see that in our example, we applied a similar option (for Tailwind) → https://github.com/vercel-labs/next-partial-prerendering/pull/22/files#diff-eca96d2c09f31517696a26e1d0be4070e1fbab02831481bed006e275741d030b. The next v15 release is coming very soon! There is a draft PR if you look around (don't want to spoil it yet!). There is another un-related CSS conversation that is happening that can be beneficial for FCP performance. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the answer @samcx :) it encouraged me to talk to the stakeholders about going ahead with the v15 release instead of spending more time on this. As you said - nobody is shipping bugs villingly, and we seem to be so close to a golden RC, that the danger seems unimportant. And ultimately, what is the worst that could happen... At least for my App, I'd just go back to the latest v14 and that'd be it. |
Beta Was this translation helpful? Give feedback.
-
@samcx it's a real shame you all decided to ignore the industry standards and collective experience that made inlining critical CSS important due to "your opinion". There are technical/measurable reasons for inlining critical CSS which link headers do not address. It sounds like Vercel again forgot a huge portion of the internet - namely people building static sites with static export from NextJS. You won't be able to set HTTP headers on a static export site. Also for anyone building a SPA with NextJS inlining CSS will improve almost all metrics not only FCP. Also this header solution assumes you are on a new and fast device with a fast connection. Preload hints may reduce FCP (did Vercel test prior to deciding on this solution?) on a browser that supports HTTP/3 (QUIC) but not on a user agent served with HTTP/2 or HTTP/1.1 and even if the user agent is able to multiplex resource downloads its still not guaranteed to arrive earlier than the DOM content and not guaranteed to be parsed prior to parsing the DOM. Therefor it may often still be categorized as a render blocking request delaying FCP for many real users in the wild. Reading this thread it sounds like it will fail to meet the requirements for >50% of users - though it "might" reduce FCP for "some users". It really feels like Vercel looked for an easy way out instead of addressing the core performance regression in NextJS architecture. Sorry for the negative note - but you have a pretty active issue here with many community stakeholders sharing their needs - and it feels like the point was missed. I myself am using NextJS static export. |
Beta Was this translation helpful? Give feedback.
-
|
@benstechlab Thank you for the feedback! Those are definitely good points for supporting critically inlining CSS.
Not trying to ignore industry standards. This discussion is still open (and not the only discussion we're looking at for this topic) and we are still looking into this. There is currently a hacky method of implementing this right now → https://github.com/vercel-labs/next-partial-prerendering/pull/22/files#diff-8e01a6008a75f53a3c17280ea9cc6528a66a089726b406445648aa9ee3b6a0d9. As mentioned before, the initial reason for not supporting Critters (recently deprecated for Beasties!) was because we were utilizing streaming. I mentioned it as "elegant" because of how React determines what gets added to the Link Headers → . |
Beta Was this translation helpful? Give feedback.
-
|
Was this fixed in NextJs version 15? |
Beta Was this translation helpful? Give feedback.
-
|
No |
Beta Was this translation helpful? Give feedback.
-
|
Sad... I was waiting for the new version, thinking there would be a fix for this issue. |
Beta Was this translation helpful? Give feedback.
-
|
What is the alternative for Next.js these days? Remix? Astro? |
Beta Was this translation helpful? Give feedback.
-
|
Why does Lighthouse report that I only have this problem in the mobile version? |
Beta Was this translation helpful? Give feedback.
-
|
Post-build script I use whenever I need to inline CSS: import * as fs from 'fs'
import * as path from 'path'
import * as cheerio from 'cheerio'
const html_dir = path.join(process.cwd(), 'out')
// Function to read and process each HTML file
const process_files = (dir: string): void => {
// Function to process a single HTML file
const process_file = (file_path: string): void => {
const html_content = fs.readFileSync(file_path, 'utf8')
const $ = cheerio.load(html_content)
$('link[rel="stylesheet"]').each((_, element) => {
const href = $(element).attr('href')
if (href) {
const css_file_path = path.join(html_dir, href)
const css_content = fs.readFileSync(css_file_path, 'utf8')
$(element).replaceWith(`<style>${css_content}</style>`)
}
})
fs.writeFileSync(file_path, $.html(), 'utf8')
}
fs.readdirSync(dir).forEach((file) => {
const file_path = path.join(dir, file)
const stat = fs.statSync(file_path)
if (stat.isDirectory()) {
process_files(file_path) // Recurse into subdirectories
} else if (path.extname(file) == '.html') {
process_file(file_path) // Process HTML file
}
})
}
process_files(html_dir) |
Beta Was this translation helpful? Give feedback.
-
|
This is very similar to the one I posted above, but the css file will be loaded anyway (I guess without blocking request) when next opts in. Did you consider adding this part? // If a <script> tag (in RSC payload) contains a css import, removes it
if (text?.match(/\[[^\]^\[]+_next\/static\/css\/.*?\.css.*?\]/)) {
const newText = text.replaceAll(\[[^\]^\[]+_next\/static\/css\/.*?\.css.*?\]/g,'[]');
page(elem).text(newText);
} |
Beta Was this translation helpful? Give feedback.
-
|
@Danogot516 using cheerio instead of critters for inlining could solve your missing rules bug. |
Beta Was this translation helpful? Give feedback.
-
|
@markoleavy A hydrated app should request what it needs normally, as our inlining does not inline the whole CSS but just splits on a per-route basis. |
Beta Was this translation helpful? Give feedback.
-
|
You could include the process in the forEach iteration, and replace the regex with a matcher with the css file name. |
Beta Was this translation helpful? Give feedback.
-
|
Wild. I was wondering why our app core web vitals got so much worse after app router. Seems like hacky solution mentioned before is the answer for now. |
Beta Was this translation helpful? Give feedback.
-
|
Deleted all .module.css files and slapped the css code into a <style> tag in root layout . So dumb man. |
Beta Was this translation helpful? Give feedback.
-
|
Thank for all for your patience here. We're working on an experimental flag to enable CSS inlining, for both webpack/turbopack. You can follow along on the PR: #72195 |
Beta Was this translation helpful? Give feedback.
-
|
Is there an estimated date for when this feature will go live? |
Beta Was this translation helpful? Give feedback.
-
|
It's not available on the latest version of Next.js behind an experimental flag. |
Beta Was this translation helpful? Give feedback.
-
|
@leerob thanks for the quick Response. I am using latest version of next which is 15.1.0 but in the documentation its still showing behind experimental |
Beta Was this translation helpful? Give feedback.
-
|
Correct, it is still experimental. |
Beta Was this translation helpful? Give feedback.
-
|
We have a multi tenant product and none of the solutions worked. In addition to that the preload link header still isn't good enough. I tried to solve critical CSS inlining for Next.js app router and got it working (sort of) with a post-build script for non-static pages. Here's how:
const CriticalCss = () => {
const isServerInserted = useRef(false); // prevent double insertion
useServerInsertedHTML(() => {
if (!isServerInserted.current) {
isServerInserted.current = true;
return (
<style
dangerouslySetInnerHTML={{ __html: '{CRITICAL_CSS}' }}
/>
);
}
return null;
});
return null;
};
{process.env.NODE_ENV === 'production' && <CriticalCss />}
import fs from 'node:fs/promises';
import path from 'node:path';
const APP_PLATFORM = process.env.APP_PLATFORM;
const distFolder = `dist/${APP_PLATFORM}`;
const manifestPath = path.join(process.cwd(), `${distFolder}/app-build-manifest.json`);
async function replacePlaceholderInFile(
filePath: string,
criticalCss: string
): Promise<boolean> {
try {
const content = await fs.readFile(filePath, 'utf-8');
if (content.includes('{CRITICAL_CSS}')) {
console.log(`Found placeholder in: ${filePath}`);
const newContent = content.replace('{CRITICAL_CSS}', criticalCss);
await fs.writeFile(filePath, newContent);
return true;
}
return false;
} catch (error) {
console.error(`Error processing file ${filePath}:`, error);
return false;
}
}
async function removeCssLinkFromFile(
filePath: string,
paths: string[]
): Promise<boolean> {
try {
const content = await fs.readFile(filePath, 'utf-8');
let newContent = content;
// Simply remove the exact string from all file types
for (const cssPath of paths) {
newContent = newContent.replaceAll(cssPath, '');
}
const modified = newContent !== content;
if (modified) {
await fs.writeFile(filePath, newContent);
console.log(`Modified: ${filePath}`);
}
return modified;
} catch (error) {
console.error(`Error processing file ${filePath}:`, error);
return false;
}
}
async function traverseDirectory(
dir: string,
callback: (filePath: string) => Promise<boolean>
): Promise<number> {
const entries = await fs.readdir(dir, { withFileTypes: true });
let replacements = 0;
for (const entry of entries) {
const fullPath = path.join(dir, entry.name);
if (entry.isDirectory()) {
replacements += await traverseDirectory(fullPath, callback);
continue;
}
if (entry.isFile() && !entry.name.endsWith('.map')) {
// Skip source map files and check others
const replaced = await callback(fullPath);
if (replaced) replacements++;
}
}
return replacements;
}
async function main() {
/**
* Reads the app build manifest to find the css files
*/
const manifestFile = await fs.readFile(manifestPath, 'utf-8');
const manifest = JSON.parse(manifestFile) as {
pages: Record<string, string[]>;
};
/**
* Gets all css files that are set on the /layout
*/
const layout = manifest.pages['/layout'];
const criticalFiles = layout.filter((file) => file.endsWith('.css'));
const criticalCssContents = await Promise.all(
criticalFiles.map((filePath) => {
return fs.readFile(`${distFolder}/${filePath}`, 'utf-8');
})
);
/**
* Join the contents to replace the component content
*/
const criticalCss = criticalCssContents
.join('')
.replace(/`/g, '\\`')
.replace(/\$/g, '\\$')
.replace(/\\/g, '\\\\')
.replace(/'/g, "\\'")
.replace(/"/g, '\\"')
.replace(/\n/g, '\\n')
.replace(/\r/g, '\\r');
/**
* Replace the placeholder on all files
*/
const placeholderReplacements = await traverseDirectory(
distFolder,
async (filePath) => {
return await replacePlaceholderInFile(filePath, criticalCss);
}
);
console.log(`✅ Replaced {CRITICAL_CSS} in ${placeholderReplacements} files`);
/**
* Prevent including the css as link
*/
const removedLinksFrom = await traverseDirectory(distFolder, async (filePath) => {
return await removeCssLinkFromFile(filePath, criticalFiles);
});
console.log(`✅ Removed ${removedLinksFrom} links from ${criticalFiles}`);
}
main().catch(console.error);
Important: it's under development and I haven't tested everything to see if it blows up. This script inlines all .css files found on @leerob is there any way to tell next to put this higher in the head? precedence or data-precedence had no effect. |
Beta Was this translation helpful? Give feedback.
and others
-
To Reproduce
const nextConfig = { experimental:{ optimizeCss: true } }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
Beta Was this translation helpful? Give feedback.
All reactions