preloaded with link preload was not used within a few seconds. Warning

[ghost]

Describe the bug

On a Site build via @sveltejs/adapter-static
Firefox puts strange warnings into the console.

The resource at URL preloaded with link preload was not used within a few seconds. Make sure all attributes of the preload tag are set correctly.

URL means usually something like: https://[DOMAIN]/_app/immutable/chunks/1-b645c4a1.js

At first glance, this only seems to relate to files in the "_app/immutable" folder

Browser:
Firefox: 106.0.5 (64-Bit)
OS: Linux Mint 21

The strange thing is, that Chrome does not do this.

this is my package.json.
package.json.txt

Reproduction

• create new project.
• install @sveltejs/adapter-static
• change adapter in svelte.config.js to '@sveltejs/adapter-static'
• build project
• move content of build directory to a static hoster.
• call page in firefox
• wait a few seconds.

Logs

No response

System Info

System:
    OS: Linux 5.15 Linux Mint 21 (Vanessa)
    CPU: (16) x64 AMD Ryzen 9 5900HS with Radeon Graphics
    Memory: 7.50 GB / 15.04 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 16.18.0 - /usr/local/bin/node
    npm: 8.19.2 - /usr/local/bin/npm
  Browsers:
    Chromium: 106.0.5249.119
    Firefox: 106.0.5

Severity

annoyance

Additional Information

No response

[dummdidumm]

I don't think we can do much here. All modules related to the page are preloaded for maximum speed, and if some of them are not used right away that's probably better than loading them only when they are needed. I feel like it's safe to ignore this warning.

[Rich-Harris]

I think this might actually be a problem — the files in question are getting loaded twice in Firefox. I believe it's something to do with Vite's module preloading, though I can't offer any specifics beyond that right now

[geoffrich]

If it's the "loaded twice in Firefox" problem, that should've been fixed in Vite 3.2: #1042 (comment)

[Rich-Harris]

I'm still seeing it on (for example) https://kit.svelte.dev, which is built with Vite 3.2. Something else must be afoot

[ghost]

Hey, thanks for the replys.

To give a bit of context:
I'd love to use pure Svelte to create multi-page projects (as in multiple *.html files) but that is not its intended use and I respect that. However, having 100+ MB development overhead for each page (mainly the repeated node_modules) is also not an option.

So I'm trying to teach myself SvelteKit by converting an existing Svelte based, single page PWA Project to it.
You can check out how it's going so far, if you like.
https://github.com/DoodlingTurtle/SvelteKitLearningProject

There are a few (yet) unused components in there. Could that have something to do with it?

The build is also forced to be hosted on an Apache2 + PHP + MySQL Server combo, so static is the only adapter I can use.

And just to finish it. Please allow me to geek out for a second.
👏🤩. I love Svelte so much 😍. Thank you, It has been a super fun experience so far.

[dummdidumm]

This definitely comes from Vite. The <link rel="preload" as="script" href=".."> tags are inserted through a preload script by Vite which is injected into the start-[hash].js chunk. It can be turned off by doing modulePreload: false in the Vite config. I think it sneaked in through this PR: #7491 . @benmccann do you know more about this? AFAIK you were involved a little when this feature was implemented on Vite's side. To me it looks like we should set modulePreload: false to get back the old behavior.
Edit: I don't think my previous conclusion is right. We always had these modulepreload links present. But it seems what changed between Vite 3.1 and 3.2 (which the linked PR updates to) is that now disabling the polyfill works better, which results in these <link rel="preload" as="script" href=".."> tags getting generated. Previously <link rel="modulepreload" as="script" href=".."> tags were created (notice the modulepreload instead of preload), and that so far only works in Chromium browsers. Now that the link tag is preload it also is used for Firefox, which is why this warning appears since a few days/weeks for people.
So I think we have two options:

1. We turn off the modulePreload feature completely. That will remove those warnings, and it will probably save some bandwith for people since it might load things that are not strictly needed on that page (on the SvelteKit homepage it preloads the error page which should happen through loading the manifest already, and for some reason it preloads the docs layout)
2. We leave everything as is. I see some files getting downloaded twice on Firefox as Rich mentioned but the second call is cached already. We investigate further why it's getting called twice (my guess is that both Vite and SvelteKit want to preload the fallback error page and root layout).

Further investigation has shown that Vite injects the preload helper somewhat like this:

// before preload injection
() => import("./chunks/0-93be292d.js"),
// after preload injection
() =>
	__vitePreload(
		() => import('./chunks/0-93be292d.js'),
		true
			? [
					'./chunks/0-93be292d.js',
					'./chunks/_layout-8d2a742b.js',
					'./components/pages/_layout.svelte-38c4a372.js',
					'./chunks/index-e0f6e208.js',
					'./chunks/stores-378bd268.js',
					'./chunks/singletons-58fc2341.js',
					'./chunks/navigation-420c33d4.js',
					'./assets/SkipLink-c09ec3da.css',
					'./chunks/SearchResults-463cedeb.js',
					'./assets/SearchResults-f83a597b.css',
					'./assets/_layout-abb1856d.css'
			  ]
			: void 0,
		import.meta.url
	);

where __vitePreload iterates over each item in the array and adds a link to it if not already present. Note that the first entry is the same as the one being imported, which according to the call stack is the reason why some resources are loaded twice. Fixing that would solve the double loading problem, but it wouldn't fix the unused files warning.

[benmccann]

I think we should turn off modulePreload completely. It looks to be preloading all routes for the application in both Chrome and Firefox. I think what it's doing is looking for all dynamic imports and preloading them and when it comes across the routes manifest it preloads the whole app. I believe SvelteKit's built-in behavior of doing it only for the current route is a better solution

[Rich-Harris]

I think we should turn off modulePreload completely. It looks to be preloading all routes for the application in both Chrome and Firefox.

That's not what I'm seeing. If we disable module preloading, we'll be left with waterfalls.

In Chrome, here's what the <head> of https://kit.svelte.dev looks like after hydration:

Here's Firefox:

Note that the block of <link> elements at the end is different — in Chrome we get modulepreload links, while in Firefox we get rel="preload" as="script", because Firefox doesn't support modulepreload. Vite chooses preload here.

I'm left wondering if Vite should just not bother injecting <link> elements if modulepreload isn't supported — as far as I can tell, preload links just don't work, and it's causing extra work for no benefit.

[benmccann]

You're right. I got confused by the change in the routing manifest.

It works for me if we turn back on the polyfill. Any idea why that's disabled and can we just re-enable it?

[Rich-Harris]

It adds bytes. Not a lot of bytes, but: https://guybedford.com/es-module-preloading-integrity#modulepreload-polyfill

We need to figure out which we value more: shipping fewer bytes in browsers that support modulepreload, or avoiding waterfalls in those that don't

[dummdidumm]

Vite claims to have a polyfill for this which would make it work for modulepreload. AFAICT Vite preloads everything a file would import, so I guess we don't actually save any bandwith by telling Vite to not add these links - as Rich says, we only make it a little worse by having a little waterfall.
Regarding the double load problem, https://vitejs.dev/config/build-options.html#build-modulepreload has a resolveDependencies option which we maybe could use to remove that from the array of preloads (because it's loaded through the await import('..') anyway).
Best would probably be to have an option in Vite that says "ok I'll add this helper function, but I'm not actually going to use it if modulepreload isn't supported".

[benmccann]

Vite claims to have a polyfill for this which would make it work for modulepreload.

Yes, but we've disabled it. I sent a PR to turn it back on: #7770

The impact of a waterfall is somewhat substantial while the impact of the extra bytes is pretty minimal and non-detectable