is it a good idea using modulepreload?

[lili21]

The browser compatibility of this feature is not very good

data from caniuse

it will effect the page performance

there are some issue report the effective.

• Opt-in / opt-out of module preloading vitejs/vite#5991 (comment)
• Option to disable modulepreload vitejs/vite#5120

Currently all the <link type="modulepreload" /> links are at the end of body, before the bootstrap inline script. However, If you are using react@canary, all the links will be moved to the head and before the stylesheet. which will effect the page performance. in my project, it increased about 1 second of FCP.

why using react@canary?

because of the hydration error issue. #5244

[xHomu]

Currently all the links are at the end of body, before the bootstrap inline script. However, If you are using react@canary, all the links will be moved to the head and before the stylesheet. which will effect the page performance. in my project, it increased about 1 second of FCP.

Ugh, Vercel needs to stop pushing breaking changes to React core to patch bugs for Nextjs.

[sergiodxa]

The browser compatibility of this feature is not very good

The feature is a a progressive enhancement, if the browser doesn't support modulepreload the app still works, it just takes longer because the browser couldn't preload all the JS files.

But if the browser supports it, then can preload all JS entry-point files which means once they're needed it will be read from cache instead of requested.

So even if the browser doesn't support it yet, it may in the future and it will automatically give end-users a better UX when loading an app.

[Xiphe]

according to https://developer.chrome.com/blog/modulepreload/#does-preloading-modules-help-performance

Preloading can help in maximizing bandwidth usage, by telling the browser about what it needs to fetch so that it's not stuck with nothing to do during those long roundtrips. If you're experimenting with modules and running into performance issues due to deep dependency trees, creating a flat list of preloads can definitely help!

From what I understand: using <script type="module" src="" /> will basically tell the browser "I need this file asap!" which might cause the browser to give this a higher priority then needed (thereby potentially de-prioritizing stuff that's actually important).

[sergiodxa]

what's the benefit to use modulepreload?
we can just use <script type="module" src="" /> without the drawbacks. Right?

If you add a <script> tag the browser will execute the code, so Remix renders this single <script type="module"> in the HTML (copied from remix.run website itself).

<script type="module" async="">
import "/build/manifest-93FD8568.js";
import * as route0 from "/build/root-VHJ7ENMD.js";
import * as route1 from "/build/routes/__marketing-DIYFCLNS.js";
import * as route2 from "/build/routes/__marketing/index-TH4DDPWW.js";
window.__remixRouteModules = {"root":route0,"routes/__marketing":route1,"routes/__marketing/index":route2};

import("/build/entry.client-YUGSKNAS.js");
</script>

As you can see, this one initialize the application and imports other files, the manifest, the routes and the entry.client which will render your app.

Your application may need more JS modules that will be imported once these initial files are imported, parsed and executed. This essentially creates a waterfall where the browser doesn't need all the JS your app needs until it runs the other parts of the JS.

Here's where modulepreload enters, it tells the browser to start preloading every JS module Remix knows it will need for the hydration, for remix.run website this is the list at this moment:

<link rel="modulepreload" href="/build/manifest-93FD8568.js"/>
<link rel="modulepreload" href="/build/entry.client-YUGSKNAS.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-4T7MF43V.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-TG3PHT2T.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-LMXH6R3J.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-Q3IECNXJ.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-RHIVOWTS.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-7K7DCIAQ.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-H4XDEQIU.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-6O6KSYWM.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-YXBAB2HG.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-7QLVLIBI.js"/>
<link rel="modulepreload" href="/build/root-VHJ7ENMD.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-YM45YA2H.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-UG4ITVAT.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-GAD3OXC3.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-7HBSRPKD.js"/>
<link rel="modulepreload" href="/build/routes/__marketing-DIYFCLNS.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-FFGUPDIH.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-YG56YJSZ.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-AI7PZG3M.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-KE7EG7PW.js"/>
<link rel="modulepreload" href="/build/_shared/chunk-5XLFFDES.js"/>
<link rel="modulepreload" href="/build/routes/__marketing/index-TH4DDPWW.js"/>

As you can see, the files imported by the inline scripts are there, but also many other chunks which correspond to other files (e.g. components, utility functions, etc.) that the app needs.

So without the modulepreload the JS will take longer to be downloaded, parsed and run, because the browser just doesn't know yet all the files it needs, but when modulepreload is supported it will be faster because by the moment it reach the inlined script it could have already started to download the JS files.

This is similar to what would happen if your had a CSS file that used @import inside, the browser needs to download the first CSS, parse it, find the @import, and then download that other CSS, but you could use a <link rel="preload"> tag to tell the browser to preload that second CSS.

---

From the issues you linked, I understood the problem comes when the modulepreload are placed before the CSS loads, and because the CSS blocks the render and the modulepreload seems to be blocking the CSS it cause a waterfall.

But Remix renders the modulepreload tags before the inline script at the end of the document (or where you render the <Scripts /> component actually, but it's usually left at the end), so it can't cause that issue.

Now it seems react@canary is, for some reason, moving them to the head, and placing them before the CSS, which cause the waterfall issue.

I think in this case, using modulepreload is the correct thing, and react@canary is the one doing something wrong by changing the order of the HTML the application is rendering, this is some unexpected breaking behavior that as you can see it cause bugs and should be fixed by React itself IMO.

[lili21]

But I can prevent waterfall issue without modulepreload.

<script type="module" src="/build/manifest-93FD8568.js" />
<script type="module">
xxxx
</script>

and no browser compatible issue. modulepreload can fix the waterfall issue, but not all user get the benefit. and we are talking about all 27% users.

[lili21]

maybe we need add a polyfill for it?

[lili21]

@Xiphe the modulepreload scripts is what we need for current page, so yes, I do need this file asap.

[jrestall]

@lili21 To fix react@canary (18.3) moving the modulepreload links above the stylesheet links in the head you can add a precedence: 'high' attribute on stylesheet links from the remix links function. I don't think this is documented but I learnt it from the React unit tests for this new React codename "Float" hoisting behaviour.

e.g.

  export const links: LinksFunction = () => [
    { rel: 'stylesheet', href: appStylesHref, precedence: 'high' },
  ];

Will result in the stylesheet link being placed at the top of the head element.

  <head>
      <meta charSet="utf-8"/>
      <meta name="viewport" content="width=device-width,initial-scale=1"/>
      <link rel="stylesheet" href="/build/_assets/app-B5PUCUEH.css" data-precedence="high"/>
      <title>New Remix App</title>
      <meta name="description" content="Welcome to Remix!"/>
      <link rel="modulepreload" href="/build/entry.client-4MXBZIKC.js"/>
      <link rel="modulepreload" href="/build/_shared/chunk-PNG5AS42.js"/>
      <link rel="modulepreload" href="/build/root-XKG6C447.js"/>
      <link rel="modulepreload" href="/build/routes/_index-T377ZUPD.js"/>
  </head>