Skip to content
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.

Sign up for GitHub

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

Jump to bottom

docs(FAQ): - lazy-loading on user interaction & speculative module fetching #5488

Merged
merged 1 commit into from
Nov 27, 2023
Merged

docs(FAQ): - lazy-loading on user interaction & speculative module fetching #5488

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 10 additions & 7 deletions packages/docs/src/routes/docs/(qwik)/faq/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,7 @@ contributors:
- wtlin1228
- ilteoood
- PatrickJS
- maiieul
---

# FAQ
Expand All @@ -38,7 +39,7 @@ Yes, and I am very funny too! [follow me](https://twitter.com/QwikDev)

## Why is it called Qwik?

Originally it was called _qoot_, but we thought it would be too hard to search for. One friend of ours, [@patrickjs\_\_](https://twitter.com/PatrickJS__), came up with Qwik and after an internal poll at [builder.io](https://www.builder.io/), we changed it!
Originally it was called _qoot_, but we thought it would be too hard to search for. One community member, [@PatrickJS\_\_](https://twitter.com/PatrickJS__), came up with ~~Qwik~~ and after an internal poll at [builder.io](https://www.builder.io/), we changed it!

## How is Qwik different from other frameworks?

Expand Down Expand Up @@ -110,23 +111,25 @@ export const App_component_p_onClick_01pEgC10cpw = () => console.log('hello');

> Note: The `$` is not related to `jQuery`, Svelte or any other framework.

## Does Qwik download JS when the user interacts?
## Isn't requesting JS on user interaction slow?

Nope. In production, Qwik uses a lot of information generated during SSR (Server-Side Rendering) to start [pre-populating the cache](../../(qwikcity)/advanced/speculative-module-fetching/index.mdx) with only the bits of interactivity available on the current page as soon as possible. This way, when the user clicks or interacts, the JS is already in the cache.
Only if you _download_ it on user interaction. Instead, Qwik _prefetches_ the current page's JS modules in a background thread trough the [service workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers) and _retrieves_ those modules from the browser's [Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache) when the user interacts with the application.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trough -> through


## If Qwik still requests the JS, then what's the difference?
This strategy is called [Speculative Module Fetching](../../(qwikcity)/advanced/speculative-module-fetching/index.mdx), and it is enabled by Resumability. Hydration frameworks must eagerly download and execute the code on page load to retrieve the event handlers, and therefore can't take advantage of speculative module fetching.

Pre-populating the cache is not the same as parsing and executing JS, and Qwik does not execute JS until the user interacts.
## How does Qwik know what to prefetch, and in which order?

In addition, [Speculative Module Fetching](../../(qwikcity)/advanced/speculative-module-fetching/index.mdx) enables Qwik to prioritize the important parts of interactivity before the less important parts.
In production, Qwik uses a lot of information generated during SSR (Server-Side Rendering) to start pre-populating the cache as soon as possible, with only the bits of interactivity available on the current page. This way, when the user clicks or interacts, the JS is already in the cache.

In addition, [Qwik insights](../../labs/insights/index.mdx) can be use to prioritize the important parts of interactivity before the less important parts.

For example, the "*Buy Now*" button is more important than the "*Add to Cart*" button, so Qwik will prefetch the "*Buy Now*" button first, and then the "*Add to Cart*" button.

Qwik does not need to prefetch everything to start running, while other frameworks do need to download the whole critical path before they can start running because of [hydration](https://www.builder.io/blog/hydration-is-pure-overhead).

## Are Qwik apps slow on slow networks?

Not at all! Thanks to [Speculative Module Fetching](../../(qwikcity)/advanced/speculative-module-fetching/index.mdx) Qwik apps are not more affected by slow networks than other frameworks. In fact, because of the fine-grained bundling and resumability, Qwik apps can become interactive with much less JS, effectively making them faster on slow networks.
Quite the opposite. In fact, thanks to Qwik's ability to [reduce network watefalls](../../(qwikcity)/advanced/speculative-module-fetching/index.mdx#reducing-network-waterfalls), it is likely that the requested modules have already been downloaded and stored in the browsers's Cache at the time of interaction. And Even if they haven't yet been cached, Qwik can [avoid duplicating the requests](../../(qwikcity)/advanced/speculative-module-fetching/index.mdx#avoiding-duplicate-requests) and can instead keep fetching the modules that are being requested to execute them as fast as possible. As a result, Qwik apps get to be responsive much faster, especially on slow networks.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

watefalls -> waterfalls

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@intellix could you make a quick PR fixing these (and anything else you find)?


## Does Qwik generate too many small files?

Expand Down
10 changes: 3 additions & 7 deletions .../docs/src/routes/docs/(qwikcity)/advanced/speculative-module-fetching/index.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,18 +51,16 @@ By pre-populating the cache from within a service worker (which is a worker), we

Qwik itself should be configured to use the [prefetchEvent](../../../(qwik)/advanced/prefetching/index.mdx#prefetching-implementation) implementation (which is also Qwik's default). When Qwik emits the event, the service worker registration actively forwards the event data to the installed and active service worker.

The service worker (which runs in a background thread) then fetches the modules and adds them to the browser's cache. “The main thread only needs to emit data about the required bundles, while the service worker’s sole focus is to cache those bundles. To achieve this, the service worker pre-populates the browser’s [Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache).
The service worker (which runs in a background thread) then fetches the modules and adds them to the browser’s [Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache). The main thread only needs to emit data about the required bundles, while the service worker’s sole focus is to cache those bundles.

1. If the browser already has it cached? Great, do nothing!
2. If the browser hasn't already cached this bundle, then let's kick off the fetch request.

Read more about [Caching Request and Response Pairs](#caching-request-and-response-pairs).

Additionally, the service worker ensures that multiple requests for the same bundle do not happen at the same time. More about this in the [Parallelizing Network Requests](#parallelizing-network-requests) documentation.
> The service worker ensures that multiple requests for the same bundle [do not happen at the same time](#avoiding-duplicate-requests).

## Caching Request and Response Pairs

In many traditional frameworks, the preferred strategy is to use `<link>` with a `rel` attribute of `prefetch`, `preload` or `modulepreload`. However, there are [enough known issues](../../../(qwik)/advanced/prefetching/index.mdx#link-rel) that Qwik has preferred to not make `link` the default prefetching strategy (though it still can be [configured](../../../(qwik)/advanced/prefetching/index.mdx)).
In many traditional frameworks, the preferred strategy is to use the html `<link>` tag with a `rel` attribute set to `prefetch`, `preload` or `modulepreload`. However, there are [enough known issues](../../../(qwik)/advanced/prefetching/index.mdx#link-rel) that Qwik has preferred to not make `link` the default prefetching strategy (though it still can be [configured](../../../(qwik)/advanced/prefetching/index.mdx)).

Instead, Qwik prefers to use a newer approach that takes full advantage of the browser's [Cache API](https://developer.mozilla.org/en-US/docs/Web/API/Cache), which is also better supported compared to [modulepreload](../../../(qwik)/advanced/prefetching/index.mdx#link-rel).

Expand All @@ -86,8 +84,6 @@ What's important here is that Qwik itself has no knowledge of a prefetching or c

This is where the power of the service worker and Cache API comes in! Qwik first pre-populates the cache for modules the user may soon request within another thread. And better yet, if it's already cached, then there's no need for the browser to do anything.

Other benefits include [Parallelizing Network Requests](#parallelizing-network-requests).

## Parallelizing Network Requests

In the [Caching Request and Response Pairs](#cache-api) docs we explained the powerful combination of the [Cache](https://developer.mozilla.org/en-US/docs/Web/API/Cache) and [Service Worker](https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker) APIs. However, we can take it even one step further by ensuring duplicate requests are not created for the same bundle, and we can prevent network waterfalls, all from within the background thread.
Expand Down