Retry import / chunk / CSS loads for transient network errors

[edwh]

Two extremely common Sentry errors on my live Nuxt site are TypeError: Importing a module script failed and Unable to preload CSS. These are almost certainly caused by transient network errors on mobile devices.

(The fact that I get the Sentry reports at all shows there are a lot of transient errors. I also have sleep/retry function in my API-accessing code for this reason using fetch-retry and which I can tell succeeds after some retries. So transient network errors are a common thing.)

I'd like to be able to add retrying for loading JS and CSS too - because these are common errors for mobile users. Is this achievable in any way at present?

A couple of notes:

• I am aware of discussions about detecting chunk load errors in the case where a new version of the code has been deployed. This is not that case, though it is related.
• I'm also aware of the preload function. That reduces the chances of this happening, but a) doesn't cure it and b) costs more network data for mobile users and therefore may not be desirable.
• I'm interested in everything that gets loaded - whether it's an entry script, a chunk, a dynamic component, CSS, or anything else that I might not have thought of.

Raising here as requested by @danielroe.

[isjelly]

Wondering the same thing. Our app is designed for mobile users to be used in specific locations. If these locations happen to have bad internet connections, a retry feature would be helpful.

[nickdnk]

For what it's worth, you can entirely circumvent this issue by not splitting your code. You can disable chunks/code-splitting by setting this config in nuxt.config.ts:

vite: {
  build: {
    rollupOptions: {
      output: {
        inlineDynamicImports: true
      }
    }
  }
}

I get that splitting the files is "smart" and all that, and that you potentially achieve a faster initial page-load while not loading stuff you don't need in the current context, but it comes with a lot of (to me) very unnecessary hoops to jump through to handle these chunk load errors. Unless your application is huge, you'll very likely not have any problems with this approach. I also noticed that if I let nuxt/vite handle all the code-splitting itself, I'll end up with a structure that looks something like (after gzip/br):

10-20 files at 4-5kb
1 file at 200kb

vs. just inlining everything:
1 file at around 300kb

In my case at least, there is virtually no gain from splitting the code into so many small files, each of which can fail to load at any time.

And something worth noting, before you say "well to mobile users the page might be slow" - yes, correct, but I'd take a slightly slower loading page any day over a page that stops working in the middle of route navigation in a payment flow or something similar where friction/dropoff is a problem. If the page doesn't load, users know they should just do a hard refresh. We've all navigated to a webpage where the CSS doesn't load, and we just retry and move on.

Reference: https://rollupjs.org/configuration-options/#output-inlinedynamicimports - note the warning about immediate execution of dynamically imported modules. Your mileage may vary.

[edwh]

vite:preloadError may be relevant. But the examples of this that I've seen use the sledgehammer approach of reloading the whole app. Is it possible to use that event to do trying of the chunk load?

[vim-daniel]

tried to play with it but because the API is not part of the promise, any intervention is useless