QwikDev
[🐞] Qwik is slow when used first time
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
"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 😅
@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.
I tried it and it was VERY slow on my Android via Chrome. On my Windows PC via Chrome it was fast.
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.
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):
https://github.com/QwikDev/qwik/blob/b183a8b30c96c19eabf7fd65ab1ba7f837f81410/packages/docs/src/entry.ssr.tsx#L24-L27
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.
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 https://github.com/QwikDev/qwik/pull/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 https://github.com/QwikDev/qwik/issues/4149. And I have a fix for it in https://github.com/QwikDev/qwik/pull/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.
