FOUC when refreshing the page

[Matth10]

Hey!

I've been spiking on your awesome project to see if we can use it with one of our apps. However, when we do a full refresh of the page during development we have a FOUC.

We are using Stimulus / Tailwindcss (now windicss). I'm loading the main CSS by importing the stylesheets from the application.js directly. In terms of setup, we are pretty close to your example.

So according to the Vite doc, it supposes to load the CSS when the associated async chunk is loaded to avoid FOUC. https://vitejs.dev/guide/features.html#css-code-splitting

I'm wondering if you have any thoughts on this issue?

Vite config

import { defineConfig } from 'vite'
import RubyPlugin from 'vite-plugin-ruby'
import ViteLegacy from '@vitejs/plugin-legacy'
import FullReload from 'vite-plugin-full-reload'
import StimulusHMR from 'vite-plugin-stimulus-hmr'
import WindiCSS from 'vite-plugin-windicss'

export default defineConfig({
  plugins: [
    RubyPlugin(),
    FullReload(['config/routes.rb', 'app/views/**/*', 'app/components/**/*'], { delay: 200 }),
    StimulusHMR(),
    ViteLegacy({
      targets: ['defaults', 'not IE 11']
    }),
    WindiCSS({
      root: __dirname,
      scan: {
        fileExtensions: ['erb', 'rb', 'html', 'js'],
        dirs: ['app/views', 'app/javascript', 'app/components', 'app/helpers'],
        safelist: [/-span-/, /form-/, /grid-cols-/, /checked-sibling/]
      }
    })
  ]
})

[ElMassimo]

Hi Matthew!

the async chunk is guaranteed to only be evaluated after the CSS is loaded to avoid FOUC.

I believe the documentation is talking about the Build Optimizations in Vite.js. I don't think that paragraph applies in development.

Are your concerns related to the user experience once in production, or does it bother you in development?

I have definitely seen FOUC during development, although after the initial load, HMR takes care of things and it does not happen again. I have not seen FOUC in production though.

[Matth10]

Yes, right it was more for production.

So it's only happening on development when using the full reload plugin. We use view_component to build most of our UI so we don't have HMR for them. We only have HMR for the stimulus controllers which is not producing a FOUC.

It's not a user issue but nicer to have for the developer experience.

[ElMassimo]

I was able to find a relevant thread in Vite, reply by the creator himself: vitejs/vite#149 (comment)

Because Imports are async, the css is only inserted after they are fetched.

The only way around this would be pre-collecting all the CSS and insert them before any rendering happens - which requires a full bundling process (exactly what we are trying to avoid).

Seems like a reasonable price to pay given the performance boost.

[Matth10]

Yeah, it makes total sense when we use a javascript framework for the frontend but when it's just rails view and view_component it doesn't make a module for each component so we can't have HMR for them, which is not that good.

[ElMassimo]

Makes sense. Try the workaround I provided, if it works, it should be reasonable to make a PR to vite-plugin-windicss to support this.

[ElMassimo]

For the reason FOUC happens in development, read this thread.

I'm not sure it will be worth the hassle, but in the spirit of providing a solution:

Something that you could try in development is to render a separate vite_stylesheet_tag that adds any critical CSS before the async scripts are loaded.

Example:

<%= vite_stylesheet_tag 'critical' if Rails.env.development? %>

Let's say that your main JS entrypoint imports other stylesheets, such as theme.css, you would then import that in critical.css:

@import "~/styles/theme.css";

Have in mind that this is only suitable for styles that you are in full control of (not dynamically injected by Vite plugins).

[Matth10]

Ok I see. Not sure it will work in our case because we also use windicss to setup our base style. So this will be reloaded each time. Anyway, I'll see how I can improve that.

Thanks again!

[ElMassimo]

@Matth10 Kept thinking about it, and another way to tackle it is to ensure the CSS generated by Windi is loaded in a blocking fashion.

Try the following plugin:

let windiPlugin

export default defineConfig({
  plugins: [
    {
      configResolved (config) {
        windiPlugin = config.plugins.find(plugin => plugin.name === 'vite-plugin-windicss')
      },
      async load (id) {
        if (id === '/windi.css?direct')
          return await windiPlugin.api.generateCSS()
      },
    },

and add the following to your layout:

    <%= vite_stylesheet_tag 'windi.css' if Rails.env.development? %>

[Matth10]

That's a good idea however by doing that we are blocking the refresh to wait on the css to be generated which leads to a slow refresh. (3-4s)

[ElMassimo]

Gotcha, thanks for letting me know.

I guess FOUC during the initial load in development can be considered one of the limitations of not bundling.

[Matth10]

Yeah I think vite makes a lot of sense when we use a javascript framework so we can leverage the HMR. In our case, our javascript bundle is really small, with just a couple of stimulus controllers. So no HMR when developing views and components. However, using windicss would be a huge gain even for our stack. 👍