Skip to content

[🐞] Qwik is slow when used first time #6879

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ziimakc opened this issue Sep 12, 2024 · 7 comments
Closed

[🐞] Qwik is slow when used first time #6879

ziimakc opened this issue Sep 12, 2024 · 7 comments
Labels
STATUS-1: needs triage New issue which needs to be triaged TYPE: bug Something isn't working

Comments

@ziimakc
Copy link

ziimakc commented Sep 12, 2024

Which component is affected?

Qwik Runtime

Describe the bug

When you visit qwik website first time every action (button click, menu open) has a delay from 0.1-1 sec. Which makes qwik a slow website from user perspective.

Reproduction

https://qwikui.com/docs/styled/introduction/

Steps to reproduce

Open qwik-ui website anc click around on menu or any component, you will feel a delay. This will work only if you not visited it previously. You can try phone or tablet.

System Info

-

Additional Information

No response

@ziimakc ziimakc added STATUS-1: needs triage New issue which needs to be triaged TYPE: bug Something isn't working labels Sep 12, 2024
@wanjohiryan
Copy link

"Feels" qwik to me ;)

Can you share what device or devices you are using? iOS, PC, Tablet, Android... ?

Have you checked your network? That might be the issue 😅

@ziimakc
Copy link
Author

ziimakc commented Sep 26, 2024

@wanjohiryan it's android tablet, phone, windows linux pc. I have no problem with internet, it's super fast. Problem is that qwik doesn't prefetch components until you interact with them and for big components like menu it does like ~20 requests which of course will be visible slow and if you have a slow internet - it more noticeable. In my opinion it's a major flaw in qwik architecture.

What options do we have to solve this?

  • Prefetch component on hover
  • Give user ability to define if component should be prefetched (on page load, when it's in view and so on)
  • Bundle components data together so that one click on menu button will not trigger 20+ requests to load every single part of it like function separately.

@jacsamg
Copy link

jacsamg commented Oct 22, 2024

I tried it and it was VERY slow on my Android via Chrome. On my Windows PC via Chrome it was fast.

@iamarcel
Copy link

iamarcel commented Dec 2, 2024

Having the same issues.

The Qwik site itself is a good example: usually the first thing I want to do is search the docs, but after clicking Search there are 2-3 seconds where nothing happens at all. (This is on a fresh load only, after a Cmd+Shift+R refresh it's 300ms to download those JS files.)

Our app users have the same issues and it's frustrating for them.

When I'm looking at the network requests on an example in our app, it looks like all the q-data.json for the <Link>ed pages are being fetched, but not all the modules, resulting in a waterfall on the first click. In this case I looked at it's fetching 80 JS files.

(Admittedly, my ~200ms server latency isn't helping, but still. SSR page loads feel instant.)

Did I set up something wrong? Can I signal to the prefetcher that it can basically keep prefetching anything it notices?

Would it make sense for the optimizer to bundle some of these tiny modules? That would probably be a decent trade-off with the potential extra code being downloaded.

I added Insights but it looks like that's being refactored and the site is down, I'm assuming that's being reworked for Qwik 2.0.

For now, I've added a qsymbol event listener that pops up a little loading spinner in the corner for half a second, hopefully that helps users a bit 😊 (Ideally buttons would get disabled during symbol load of their onClick$ / navigation handling, but I don't know if I can do that.)

Loving the framework overall! Would be amazing if there was a great solution to this.

@iamarcel
Copy link

iamarcel commented Dec 2, 2024

I dug around a little.

On the docs side, it looks like the prefetching is disabled (which actually is the case by default on all apps, if I'm reading the code correctly):

// Core Web Vitals experiment until November 8: Do not remove! Reach out to @maiieul first if you believe you have a good reason to change this.
qwikPrefetchServiceWorker: {
include: false,
},

Sooo @maiieul how's the experiment been going?

Adding this to my root.tsx seems to help a lot! Though I don't know what I'm doing and I have no idea if this is okay, or interfering with the "normal" service worker or something.

        {!isDev && <PrefetchServiceWorker />}
        {!isDev && <PrefetchGraph />}

By the way, that qwikPrefetchServiceWorker render setting—does it do anything? I'm just rummaging through the code here on GitHub but couldn't find any place where it's used.

Even without the option, my app was emitting a qwikPrefetchSW array in the HTML.

I any case, if it's true that the prefetching (which IMO is a key element of making Qwik apps nicely responsive) is disabled by default, we should document that.

@maiieul
Copy link
Contributor

maiieul commented Mar 16, 2025

Hello there, sorry for the radio silence. We first thought there was no issue at all because of a bug in chrome https://issues.chromium.org/issues/392424832, where network throttling doesn't throttle at all when opening the chrome dev-tools with the throttling already turned on. As you can imagine, this didn't help in reproducing the issue on our side 😅 . To see the problem, I had to "go to website on incognito navigation", "open dev-tools", "turn on throttling", which is not intuitive because chrome remembers the previously set throttling, even on incognito navigation... I must say that a little screen recording would have helped a lot, and also that https://qwikui.com/docs/styled/introduction/ is not a valid minimal repro — not only qwik-ui has a lot of code, but also the problem could have been on the qwik-ui side and have nothing to do with qwik itself. Also we were side-tracked by another minor issue with service-workers on low-end devices.

So we didn't notice what was happening for those reasons. The issue here was that the qwik-city service-worker (ServiceWorkerRegister) wasn't prefetching a lot of chunks since 1.5.7. This indeed means waterfall delays on interaction, which are noticeable even on a good network, and can easily take a few seconds on bad network conditions.

Good news is we fixed this qwik-city service-worker issue in #7286. So I'm closing this issue for now. Please re-open another one if you encounter any similar issue in the future. I now know the system quite a bit more and can have a look at it.

This is also a bit related to #4149. And I have a fix for it in #7417.

I'm hopeful we can make a 1.12.2 patch release some time next week. This should solve all under-prefetching issues using the qwik-city service worker (ServiceWorkerRegister). If you want to try it out now you can install the pkg.pr.new npm i https://pkg.pr.new/@builder.io/qwik@7417 and npm i https://pkg.pr.new/@builder.io/qwik-city@7417.

@maiieul maiieul closed this as completed Mar 16, 2025
@iamarcel
Copy link

Amazing @maiieul! Thank you for all the efforts 🥇

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
STATUS-1: needs triage New issue which needs to be triaged TYPE: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants