perf(qwikloader): put qwikloader in a separate bundle

[wmertens]

We were embedding the qwikloader, which is faster for initial load, but recent experiments with modulepreload show that this isn't necessary.

By putting the qwikloader in its own bundle and using modulepreload + async module script:

• the bundle is discovered during the html download
• the bundle downloads together with the html
• the bundle can be served with brotli compression, which is more costly to do during SSR
• subsequent SSR requests never have to download the 1.5-2kb again
• multiple containers with the same qwik version can all embed the script import tag and it will only be loaded once

This doesn't seem to impact LCP at all.

In the pathological 3G simulation with the fixed 2s lag, the chunk is fetched first, while the html is still downloading, and finishes pretty soon after html finished downloading and while the other resources are also downloading, so the user doesn't really notice anything.

compared to before:

(the other two yellow preloads you see are the preloader bundle and the qwik core bundle)

PS it would be really cute to find a string to embed in the preloader that would make the current uD3ipkCl hash start with ql_. Anybody with a lot of compute time to burn? :)

[changeset-bot]

⚠️ No Changeset found

Latest commit: 4163cce

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@builder.io/qwik@7613

npm i https://pkg.pr.new/@builder.io/qwik-city@7613

npm i https://pkg.pr.new/eslint-plugin-qwik@7613

npm i https://pkg.pr.new/create-qwik@7613

commit: 4163cce

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
qwik-docs	✅ Ready (View Log)	Visit Preview	4163cce

[maiieul]

If I'm not mistaken the page can now be visible before the qwikloader is finished downloading, which means some user events might get lost between that time.

For example:

If a user clicks between ~3100ms and ~4400ms on slow 3G the user event won't be registered. It's a little annoying for demos.

On the other hand you could argue that slow 3G latency is unrealistic and that this change theoretically should improve performance for real users.

So I'm not sure what I prefer here ^^.

I'd like to test on my Xiaomi on real 2G before we merge this.

[wmertens]

would be interesting to see if 103 Early Hints would help, but Safari doesn't implement preload so that's a huge chunk of the mobile userbase for which it won't work.