In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-14 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >
Share
Shulou(Shulou.com)06/03 Report--
This article focuses on "how to achieve Next.js hybrid rendering", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to achieve Next.js hybrid rendering.
Write at the front
In React ecology, Next.js is probably the best supported by SSR, but SSR is not all of Next.js, but it is only one of the pre-rendering support it provides:
SSG (Static Site Generation/Static Generation): static generation, static HTML generated at compile time
SSR (Server-Side Rendering): server rendering, dynamic generation of HTML upon arrival of user request
In a variety of ways to pre-render the page content before the start of CSR, so as to speed up the performance of the first screen while meeting the needs of SEO, which is the core feature of Next.js
Not only that, Next.js also provides mixing support, which can combine different rendering modes and complement each other, such as:
ISR (Incremental Static Regeneration): incremental static regeneration, periodically regenerating static HTML at run time
SSG downgrade SSR: SSR immediately when you miss the pre-generated static HTML
SSR with static cache: after the SSR is completed, the result is cached and returned directly the next time the static cache is hit (equivalent to SSG)
SSG combined with CSR: generate static part (page bounding box) at compile time, and CSR fill dynamic part (page content)
SSR interacts with CSR:URL to directly access faster SSR,SPA jump around and experience better CSR
These delicate mixed rendering support not only gives full play to the advantages of various rendering modes, but also adds a lot of color to Next.js.
SSG + SSR
SSG is equivalent to moving the rendering process of SSR forward to compile time, thus optimizing this part of the time-consuming and achieving excellent page loading performance. But there is also an obvious drawback-it can only be used to render static content, making it difficult for an otherwise powerful solution to show its talents. So, is there any way to expand its application?
Yes. The key is how to understand "static". Static and dynamic actually describe the change frequency of content, which is almost (never) constant, or the change frequency is very low, which we call static content. Therefore, as long as we find a way to deal with content changes, it is possible to expand the applicable scenarios of SSG from static content to dynamic content.
In extreme cases, "infrequently changing" is equivalent to "not changing every time", that is, except for real-time / personalized content that changes dynamically all the time, other scenarios can use SSG, of course, as long as the content can be updated and effective as often as needed. Content update is actually re-SSG, so there is only one update opportunity.
Another less obvious limitation is the amount of static content, because rendering has to be completed at compile time, and if there are 1 million pieces of static data, it will be compiled to generate 1 million HTML, which can take several days at a time. The compilation cost (regardless of time / machine) increases with the amount of content, which is an inherent problem with the SSG rendering mode and seems unsolvable. Unless, full pages are not generated at compile time.
The SSR for user request can provide the right update time, and as the downstream of compilation, SSR has the opportunity to stop the fish that missed the net. As a result, SSG and SSR hit it off, SSG compiles only a small number of hot pages, and the rest is generated by SSR at run time. When the user request arrives, it is decided whether to regenerate the SSR or follow the product generated last time based on whether the content needs to be updated:
Instead, you may statically generate a small subset of pages and use fallback: true for the rest. When someone requests a page that's not generated yet, the user will see the page with a loading indicator. Shortly after, getStaticProps finishes and the page will be rendered with the requested data. From now on, everyone who requests the same page will get the statically pre-rendered page.
Inspired by stale-while-revalidate, background regeneration ensures traffic is served uninterruptedly, always from static storage, and the newly built page is pushed only after it's done generating.
In this way, SSG expands the applicable scenarios (high-frequency changing content, endless mass of content), and SSR gains performance advantages (static cache):
This ensures that users always have a fast experience while preserving fast builds and the benefits of Static Generation.
P.S. For more information about the combination of SSG and SSR, see When is fallback: true useful?, Incremental Static Regeneration
SSG + CSR
Compared with SSR, SSG costs less, compiles locally to generate static HTML, and hosts to a Web server or CDN to enjoy the load performance improvement brought by pre-rendering. There is no high machine cost of application servers, and there is no need to worry about the availability and operation and maintenance of SSR online services.
Expanding the application scenario of SSG with SSR has to consider the cost that comes with it, so is there a lower-cost way?
There are, too, but there must be some compromise in experience. Since SSG is good at rendering static content, you might as well separate the static content of the page and leave the static part of the page to be compiled and generated by SSG, while the rest of the dynamic part is still filled with CSR:
First, immediately show the page without data. Parts of the page can be pre-rendered using Static Generation. You can show loading states for missing data.
Then, fetch the data on the client side and display it when ready.
SSG combined with CSR not only shortens the white screen time of page loading, but also avoids the extra cost of SSR. However, the only drawback is that the loading experience is not as good as pure SSG. After all, dynamic content (what users may be more concerned about) needs to be rendered twice on the client side, unlike SSG, which can render complete content at once. Therefore, this approach brings more experience improvement, and users feel that the loading of the page is faster, which can be regarded as a progressive rendering mode.
P.S. For more information about the combination of SSG and CSR, see Fetching data on the client side
SSR + CSR
The most intriguing combination of SSG, SSR and CSR is probably the third-- SSR combined with CSR.
Hydrate doesn't count. Is there any connection between SSR and CSR?
Of course there is. SSR can effectively shorten the white screen time during page loading, and at the same time provide a pleasant experience of complete presentation of page content at one time. In comparison, CSR rendering performance depends on the client environment and data request lag becomes infinitely large, which obscures the highlight advantage of CSR:
No refresh loaded content
Can be preloaded according to user behavior
These advantages are really not reflected in the loading process of the first screen, so just look at the page loading performance, SSR is completely better than CSR, either of the two can be, there is no need to combine. However, if we raise the perspective to the whole process of user operation, we find that CSR and SSR can be perfectly integrated in a very harmonious way:
Load SSR on the home screen: regardless of whether users visit the home page or secondary or tertiary pages directly through URL, SSR can render the page as quickly as possible.
Intra-site jump CSR: after the page jump in the interactive operation, the new content is loaded seamlessly through CSR, and even the content of the target page can be loaded ahead of time to predict user behavior.
At this point, I believe you have a deeper understanding of "how to achieve Next.js hybrid rendering". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.