Render blocking styles with app route and tailwind

[MartinaMilisic]

Hi! Im running on next 14.0.4 with tailwindcss 3.3.3 and i get quite low scores (lower than expected) because of render blocking resources. My assumption was that next and tailwind together would configure and optimise css to only import what is used, but it seems like it's not really doing that?

I'm only importing global.css into my layout file, as provided in the documentation. Is there something I'm missing? Can I do something more to optimise and prevent my css from blocking?

Worth mentioning, I am importing an external style sheet from node modules, also according to the documentation.

Thank you for any thoughts!

[JohnGemstone]

Have you gathered any insights into this? Experiencing the same, cheers!

[timomedia]

Do you have any solution for this problem? I really can't find a solution to this

[MartinaMilisic]

@JohnGemstone @timomedia sorry, haven't had much time to dig deeper into this. No luck so far :/ Please let me know if you make any findings!

[PegeDev]

any update for this issues ?

[MartinaMilisic]

Unfortunately no.

[bel7aG]

I can confirm, having the same issue even after reducing tailwind to 5.7KB on vercel

[rassemdev]

having same issue, i am using tailwind and fontawesome.

[doomietrue]

Same here, one 12kb css file and it takes 1 second :(

[bel7aG]

@leerob any help here?

[leerob]

If you are using the standard Next.js + Tailwind setup, you are going to have great performance for loading style sheets. Tailwind will automatically remove unused styles, and loading (and caching) and single, immutable style sheet has great performance. This is much faster than alternatives. More on this here: https://leerob.io/blog/css

You mention you are also including an external style sheet from node_modules. This however, is different. This could potentially be a very large style sheet, and it's not being automatically optimized by Tailwind (PostCSS currently behind the scenes). That style sheet is likely not needed for the initial paint, so it can be removed and included at the component level with the UI that consumes it.

[cpotey]

@MartyMilisic I do similar in one of our codebases in a root-level catch-all route, as we don't know what to render until the CMS response is returned, and that tells us what page design to choose - but sadly it doesn't remove any unused CSS (or JS).

So I think you are misunderstood, and that CSS/JS/component will still get loaded.

For example in my root-level [...slug]/page.tsx

import { Article, Topic, Brochure, etc... } from 'across-the-app' // import all the various components

export default async function Page({
  params,
  searchParams,
}: {
  params: { slug: string[] };
  searchParams: { [key: string]: string | string[] | undefined };
}) {
  const data = await getPageOrPreview({ params.slug.join('/'), searchParams });

  return <PageTypeComponent data={data} />
}

/*
 * This renders the component from the page type response
 */
const PageTypeComponent = ({ data }: { data: Page }) => {
  switch (data.type) {
    case 'article':
      return <Article data={data as ArticlePage} />;
    case 'topic':
      return <Topic data={data as TopicPage} />;
    case 'brochure':
      return <Brochure data={data as BrochurePage} />;
    case 'interview-topic':
      return <Topic data={data as TopicPage} />;
    case 'resource-hub':
      return <ResourceHub data={data as ResourceHubPage} />;
    case 'news':
      return <News data={data as NewsPage} />;
    [...] // removed others for simplicity
    default:
      return <>Page: {data.title}</>;
  }
};

Any page using the catch-all route seems to load ALL of the CSS, and ALL of the JS for all the other components in any route that uses this catch-all.

So in my case you render the Article component, as that's mapped from the CMS response, but all the others are still there in the bundle. This is from my testing as least, as I could see all the CSS/JS in my built files when I look through them on production.

I think you can probably leverage parallel routes or something else to help split it out, but haven't had a chance to dig into it further myself yet - or know what the best solution is for this scenario.

Would be interested to hear an answer to your question, as it might help solve my issues (and JS bundling size!) too.

EDIT: There might be some fantastic 5 minute refactoring of my code and yours, that solves all of these issues in a catch-all route - but I haven't discovered it yet 😅

[MartyMilisic]

Exactly like that @cpotey ! Thank you :) Yeah, it's a pitty that all js/css is loaded, but somehow it does make sense :/ I didn't think about that until now, that this might be the problem. I'm thinking this is a pretty common use case though if you want the cms to determine the routing/hierarchy. So yes, I'm hoping for a clever answer on this too! My thought was to lazy load the components, but what I understand that isn't really applicable when using server components (? - at least is that what I understood when reading the next documentation).

[MartyMilisic]

@leerob any good tips on this? :)

[emfelipe]

I've tried parallel routes, but they don't seem to fix the problem; the behavior remains the same. I haven't used Tailwind yet, just plain css but the issue appears to be identical.

From what I understand, Webpack combines all possible scenarios (all conditions - all server component imports) into one large CSS chunk instead of splitting them into smaller parts. As a result, we get massive unused css that can include all scenarios, rather than just the one that meets the conditions.

[MartinaMilisic]

@leerob (sorry for nagging here :)) - but do you have any good thoughts on how to solve the issue with loading all the css and js when using a single root level catch-all route (as described above)? Thank you!

[SergioColladoV]

Hi! Some updates here? I have the same problem. My lighthouse in performance is 99% because of the import of tailwind in layout.js. You can replicate it If you create a new project with npx create-next-app with tailwind.

[MartinaMilisic]

I haven't been able to look further into this so I'm not aware of a solution yet :/