Quickly get an understanding, know the general things.
If using Client-Side Rendering (CSR), the first screen will be slow, what should we do?
This will be separated later.
- SSR rendering can be used, first render the first screen, and then use JS for subsequent rendering
- However, the JS still needs to be downloaded and go through the hydration process, which means associating the HTML with the corresponding JS. Hydration does not mean re-rendering, it adds event listening logic to the HTML. Theoretically, FCP (First Contentful Paint) is very fast.
- During the hydration process, the JS will run twice, once on the server-side and once on the client-side. Theoretically, it increases the TTI (Time to Interactive).
- With SSR, it means having Node.js, which also means having requirements for security, stability, and high performance.
- Astro attempts partial hydration, also known as island
- Next.js/Nuxt.js both have the concept of server components
- But qwik is completely 0 JS, providing only HTML, so the performance is strong enough. Next, qwik will be introduced
- How to improve SSR performance
- For example, caching
stale-while-revalidate=<seconds>experimental indicates that the client is willing to accept stale responses while asynchronously checking for a new response in the background. The value in seconds indicates the length of time the client is willing to accept stale responses. --from MDN
- For example, island architecture
- Load and initialize based on events such as requestIdleCallback scheduling, viewport visibility, interaction possibility, and product value
- Different from the progressive hydration mentioned above, partial hydration of islands does not affect the performance of other units
- qwik proposes that "hydration is pure overhead", the hydration process is completely redundant, hydration is pure overhead
The most difficult part of hydration is finding events and connecting them. That is, where and what, what is the closure that closes
app_stateis the state understood by everyone
- The state of the associated mapping of the framework
- Hydration process: download component code - execute component code - restore state and locate association - add event handling to the DOM
Reference interpretation articles
- hydration is pure overhead All interpretation articles are derived from here
- There is an article on Zhihu SSR framework challenger in the new era: qwik
- The Challenge of Efficient Hydration dev.to
- Qwik-The Ultimate Solution for Frontend Performance?
The difference between SPA and island, island generates JS requests only when there is a click interaction
RSC can put the rendering of some components on the server, and the frontend only does pure display, and only the dependencies of RSC will not be packaged into the client. This way, if a component has a larger third-party dependency, the third-party dependency can be placed in RSC, and the component can be run on the server and the generated result can be transmitted to the browser for display.
For example, a chart, canvas, or markdown rendering is completed on the server. In this way, the client cannot access the rendering process.
How to achieve it?
Simply put, the HTML contains relevant information for executing JS, and additional JS will be parsed and triggered for download when necessary. This HTML containing additional information is called additional information serialization, such as events, states, etc.
- Record the events and states of the current component on HTML attributes, called serialization
- JS is also embedded to map and compare in order to achieve event recovery
This ability is called resum-ability.
For example, a counter tool, which displays a static page by default, and only downloads and executes JS when clicked. Before the user performs any operations, there is no JS download and execution at all, which is a complete lazy loading. During the build process, many chunks will be generated, each of which is small and has a small granularity.
Is this the silver bullet to solve all problems? Not necessarily, for example, lazy loading execution also involves an activation process. Use dynamic prefetch technology reasonably.
The build artifacts of lazy loading will not be very large. Will there be too many? Traditional build tools handle granularity segmentation.
No need to worry about performance leaks after execution.
component$ method, indicating the boundary of lazy loading
A single page will not satisfy the basic requirements, so there is the "Qwik City" suite, which supports routing, layout, loader, validation, middleware, caching, etc.
Supports SSR and SSG.
- Qwik focuses on components and state management
- Qwik City is a suite of functions.
It feels interesting, actually the transition from Vue/React is not that big.