revisit modulepreload options?

[benmccann]

Describe the problem

safari and firefox have support now. do we need the other options still? safari and firefox are rolling out support and being adopted quickly

some of the other options result in double requests. see https://github.com/svelte-society/summit-website/pull/3

Describe the proposed solution

discuss with team

Alternatives considered

No response

Importance

nice to have

Additional Information

No response

[benmccann]

https://www.stetic.com/market-share/browser/ says most people are currently on Safari 17 using data from December

caniuse is using statcounter data from November. statcounter is currently down, so I can't see if their December data is different from their November data. https://www.w3counter.com/globalstats.php is also from November and still has Safari 16 in the lead

https://timotijhof.net/posts/2023/browser-adoption/ suggests that users migrate to new major versions of Firefox and Safari quite quickly, so I don't know that we need to worry about older versions much

[dummdidumm]

I don't think we should outright remove the option just yet, maybe in SvelteKit 3 or 4. What do you mean by changing the default? The default is modulepreload already, which AFAIK is the best option.

[benmccann]

Statcounter is back up. 2/3 of Safari users are already on Safari 17 in December according to it, which is a huge jump from the Nov data on caniuse.

The preload-mjs option results in double requests in Chrome, which we should mention in the docs at the very least. I don't know if that's changed behavior from when we introduced that option or not, but the docs make it sound like the best option and I don't think it is.

If we keep the option, which would would be better than the default and how long would that remain true? I'm not sure it has much benefit and is worth the complexity

[Rich-Harris]

The preload-mjs option results in double requests in Chrome

I can't reproduce this?

[benmccann]

I can't reproduce this?

Sorry, I had it wrong. It was Firefox

[Rich-Harris]

In that case I think it makes sense to keep the options for now — they still have value (at least in theory; not sure how many people are using them in the wild) and they really don't add much complexity. I suspect Safari 17 adoption will be high enough by the time we ship SvelteKit 3.0 to remove them then