prevent loading global style entry css file

[danielroe]

We now have styles inlined in the page (nuxt/framework#7160), and we've switched the global CSS file to a non-blocking prefetch. However, the vite preloader does still add these styles to the page, and we can probably avoid this (or have an option to avoid this).

Note: this may be unfeasible as entry.css may include more CSS than is inlined in the page, and be necessary for subsequent navigation. See #14943 for example.

[praveshishere]

It would be nice to have a configuration option to disable prefetching entry.css (or delaying) on our end (if that's possible).
styles on subsequent pages could be loaded on demand.

[jgupta]

In favour of lighthouse score, since we already have critical css inlined we should defer non-critical css.

[jgupta]

Chrome developer tool performance insights shows entry.css as render blocking. For testing, we removed entry.css file using build:manifest hook and it improved lighthouse score significantly.

  hooks: {
    "build:manifest": (manifest) => {
      Object.values(manifest).forEach((entry) => {
        if (entry.isEntry) {
          entry.css = [];
        }
      });
    },
  },

[danielroe]

@jgupta We should already do that:

https://github.com/nuxt/framework/blob/5855ba4684e36eb1e785f377d034277f008bc92a/packages/vite/src/server.ts#L132-L140

Would you provide a sandbox in which entry.css is render blocking?

[jgupta]

@danielroe below are two URLs.

Old URL (without our hook) and this new URL (with our hook). Both URLs have exact same code except the hook above.

The way entry.css is added is still a blocking request (at least in Chrome).
<link rel="prefetch stylesheet" href="/_nuxt/entry.c5c3adc4.css">

We may modify it as follows (source)
<link rel="stylesheet" href="/_nuxt/entry.c5c3adc4.css" media="print" onload="this.media='all'; this.onload=null;">

I can't find source but I have read somewhere that above might interfere with Content Security Policy (CSP). I am not sure about proper solution for this but if the css continues to be blocking, inline css is useless. Alternately, we might try adding css to early hints.

[danielroe]

You're right, it seems blocking, and it shouldn't be. I've raised nuxt-contrib/vue-bundle-renderer#39 to address that issue.

[Anoesj]

@danielroe below are two URLs.

Old URL (without our hook) and this new URL (with our hook). Both URLs have exact same code except the hook above.

The way entry.css is added is still a blocking request (at least in Chrome). <link rel="prefetch stylesheet" href="/_nuxt/entry.c5c3adc4.css">

We may modify it as follows (source) <link rel="stylesheet" href="/_nuxt/entry.c5c3adc4.css" media="print" onload="this.media='all'; this.onload=null;">

I can't find source but I have read somewhere that above might interfere with Content Security Policy (CSP). I am not sure about proper solution for this but if the css continues to be blocking, inline css is useless. Alternately, we might try adding css to early hints.

This change depends on JavaScript to load styles. Therefore, generated builds don't load this CSS file and styling breaks when JS is disabled. Can you take another look at another possible solution that doesn't require JavaScript to be enabled to make sites look like they should? 😄

Also, when JavaScript is enabled, there's a flash of unstyled elements with this solution. It doesn't look nor feel right!

[danielroe]

Agreed. I think it is best to completely remove support for inlining entry CSS for now. ~> nuxt/framework#8666

[Anoesj]

Thank you Daniel, that was fast! Will this be shipped with rc.13 or rc.14? Would be nice to include this in rc.13, since serving an unstyled website to users with JS disabled is a pretty big shortcoming 😬

[danielroe]

This will be in rc13.

[manniL]

Thank you Daniel, that was fast! Will this be shipped with rc.13 or rc.14? Would be nice to include this in rc.13, since serving an unstyled website to users with JS disabled is a pretty big shortcoming 😬

Feel free to try it out on the edge channel though 😋