when ssr is true, img elements that throw 404 halt javascript from kicking in.

[HighFunctioningSociopathSH]

Describe the bug

If you have img elements with wrong src attributes that result in a 404, you can notice that javascript doesn't kick in unless all the img elements are done throwing 404 and since browser request take time, this means your code can take a few seconds to run.

Reproduction

+page.svelte

<script lang="ts">
  console.log("hello");
</script>

<img src="some" />
<img src="arbitrary" />
<img src="src" />
<img src="values" />
<img src="that" />
<img src="result" />
<img src="in" />
<img src="404" />

The above code results in the following logs

GET http://localhost:5174/some 404 (Not Found) localhost/:335
GET http://localhost:5174/arbitrary 404 (Not Found) localhost/:335
GET http://localhost:5174/src 404 (Not Found) localhost/:335
GET http://localhost:5174/that 404 (Not Found) localhost/:335
GET http://localhost:5174/values 404 (Not Found) localhost/:335
GET http://localhost:5174/result 404 (Not Found) localhost/:335
GET http://localhost:5174/404 404 (Not Found) localhost/:335
GET http://localhost:5174/in 404 (Not Found) localhost/:335
[vite] connecting... client:495 
[vite] connected. client:614
hello +page.svelte:2 

But If you turn ssr off then the logs would be like

[vite] connecting... client:495 
[vite] connected. client:614
hello +page.svelte:2 
GET http://localhost:5174/some 404 (Not Found) localhost/:335
GET http://localhost:5174/arbitrary 404 (Not Found) localhost/:335
GET http://localhost:5174/src 404 (Not Found) localhost/:335
GET http://localhost:5174/that 404 (Not Found) localhost/:335
GET http://localhost:5174/values 404 (Not Found) localhost/:335
GET http://localhost:5174/result 404 (Not Found) localhost/:335
GET http://localhost:5174/404 404 (Not Found) localhost/:335
GET http://localhost:5174/in 404 (Not Found) localhost/:335

Logs

System Info

System:
    OS: Windows 11 10.0.22631
    CPU: (16) x64 12th Gen Intel(R) Core(TM) i7-12650H
    Memory: 6.92 GB / 15.63 GB
  Binaries:
    Node: 23.7.0 - C:\Program Files\nodejs\node.EXE
    npm: 11.1.0 - C:\Program Files\nodejs\npm.CMD
    bun: 1.1.3 - ~\.bun\bin\bun.EXE
  Browsers:
    Edge: Chromium (129.0.2792.52)
    Internet Explorer: 11.0.22621.3527

Severity

annoyance

[7nik]

It isn't so, and, in fact, the order can be kinda arbitrary due to data racing.

When SSR is on, the browser receives a compiled page and starts loading images, and hydration always starts after the main body is loaded and parsed (and JS is loaded). So, here, images start loading first. The built SK project has JS preload tags, which makes the order even more unpredictable.
When SSR is off, at first, the app initializes and only then the images are added to the DOM, that triggers loading them.

this means your code can take a few seconds to run.

Did you measure this?

[HighFunctioningSociopathSH]

The more images the more it takes. for me in dev 5 images take about 2 seconds.

[trueadm]

I'm not sure this is something that Svelte can solve? I can emulate the same thing without Svelte using just HTML and JS.

[HighFunctioningSociopathSH]

@trueadm I see. Then do you have any advice as to what can be done instead to avoid this?

[huntabyte]

You can do something like attempt to load the images on the client and display a fallback while loading/if they fail.

This is something we do with the Avatar component in Bits UI, with the option to forcefully set the loading state to "loaded" if it is a static asset/you're confident it will be loaded fast enough to not stall out the rest:

https://github.com/huntabyte/bits-ui/blob/fbd9c431cfa6279b6ba7cbeba011c0f5fffebb3f/packages/bits-ui/src/lib/bits/avatar/avatar.svelte.ts#L32-L53

Refreshing the page here: https://bits-ui.com/docs/components/avatar and looking at the example will show the behavior you'll get. We have an extended 200ms delay set in that demo to prevent it from flickering too quickly which looks worse than 200ms delay.