Studies have found that for every second added to website loading time, 10% of users will be lost. In order to improve the page opening rate in seconds, people from all walks of life are constantly exploring optimization strategies. Optimization in the browser field alone can no longer meet the ultimate requirements. Everyone began to continue exploring in the direction of the server, and once let [server-side rendering] This ancient concept has become popular and is very popular.
Server side rendering is abbreviated as SSR, and the full name is Server Side Rendering. As the name suggests, the rendering work is performed on the server side. This method is not only beneficial to first-screen rendering and improves the first-screen response speed of SPA applications, but also facilitates search engine crawling and is beneficial to SEO optimization. However, by 2023, SSR is not as popular as expected.
Some commentators believe that most of the reasons for using SSR are to serve SEO, but now that search engines have kept up with the pace of development and have good support for SPA written in frameworks, SSR is not so necessary. Some people think that SSR is a false requirement. The business logic and controller are separated and loaded as quickly as possible.
However, some comments believe that there are still a large number of users who cannot achieve a good experience when accessing Web pages due to network environment or device conditions. If you want to improve the experience of these users, then SSR is an indispensable method. .
What is the real situation in this regard? In practical applications, what are the reasons that prevent SSR from becoming a mainstream development model for the Web? Is this approach obsolete in today's environment? What kind of business scenario is more suitable for SSR? In this regard, Open Source China invited two front-end tycoons to hear their opinions.
-
Liu Kui, nicknamed kuitos in the community. Front-end engineer of Alipay Experience Technology Department, author of the open source micro front-end solution qiankun, currently responsible for Web infrastructure R&D related work at Ant.
-
Liu Yong, nicknamed Tianzhu in the community, is the head of Node.js Infra of a large company and the core developer of EggJS / CNPM.
1. SSR is not a pseudo requirement
Q1: In your experience, what types of projects and scenarios are more commonly used for SSR ? Can you give some examples?
Liu Kui: Websites that are very sensitive to first-screen performance or have strong demands for SEO will use SSR more often, such as:
-
E-commerce platform: Faster first-screen rendering allows users to see product information faster and improves purchase conversion rate
-
Marketing activity page: Opening in seconds can effectively improve the business effect of marketing activities
-
Portal websites: Content-based websites usually have strong demands for SEO.
Q2: Based on your actual experience, what do you think are the advantages of SSR compared to CSR ( Client-side rendering ) mode?
Liu Kui: From my personal experience, the biggest advantage is the first-screen experience. Users can see valid page content during the HTML loading process in SSR mode. This is basically difficult to achieve with CSR.
Q3: Now that search engines already support rendering, do you think it is still necessary to use SSR for SEO reasons ?
Liu Kui: Due to well-known reasons, domestic search engines do not support SPA-type applications well. If you want your website to be better indexed by crawlers, you basically still need to use SSR (or a variant of SSR) solution. .
Q4: Some people think that SSR is a false requirement. To improve the first-screen rendering performance, the business logic of the back-end service should be separated from the controller. The controller is divided into a view controller and an interface controller, calling the same business logic. When the page is opened for the first time, the front-end JavaScript loads the data rendered by the page, and then requests the interface to obtain the data when the user interacts. This solution is much better than SSR which is anxious about performance. What do you think?
Liu Kui: The essence of this solution is still CSR, and it cannot solve the original problem of the CSR solution: that is, the user must wait until the JS download is completed -> initiate an interface request -> JS obtains the data and renders the page before they can see the valid content. In the more demanding network environment and user equipment conditions, this problem will become more obvious.
Liu Yong: Make technology selection based on the team's infrastructure maturity and business scenarios. There is no absolute advantage or disadvantage between these two solutions, nor are they absolutely separated. They can be combined into one solution through front-end engineering.
2. SSR, it’s a bit difficult to become famous.
Q5: Judging from the current situation, SSR has not become the mainstream development model of the Web. What do you think are the obstacles?
Liu Kui: I think there are mainly the following reasons:
-
Technical complexity: SSR needs to be rendered on the server side and integrated with the front-end framework, which requires more technical knowledge for developers.
-
Additional development and maintenance costs brought by SSR : Compared with CSR, the SSR solution requires the front-end to pay additional attention to server-related development and operation and maintenance, such as how to write higher-performance server-side rendering logic and how to deal with potential memory leaks. , variable pollution and other isolation issues, how to implement SSR disaster recovery (fallback to CSR when SSR fails), etc. These all require the team to invest additional resources and time.
-
Scenario matching: A large number of domestic services are distributed through carriers such as small programs and APPs, and there are relatively few pure Web technology stack products. This is very different from foreign scenarios.
Liu Yong: First of all, SSR requires server resource costs. In the context of cost reduction and efficiency improvement, it will need to be combined with some infrastructure such as Serverless or edge computing to find a balance point. At the same time, since it is a server, it has certain requirements for operation and maintenance capabilities, as well as certain requirements for the technical accumulation of the front-end team.
Secondly, if the encapsulation and maintenance of the framework are not done well, business students writing SSR can easily cause memory leaks, which is very common. Moreover, the current front-end framework has not been optimized for SSR scenarios. If the first screen display is fast, but then a very large Bundle file has to be downloaded, so the user interaction time is too slow, the gain outweighs the loss.
Finally, regarding the evolution path, for example, Ant has already perfected the upstream and downstream infrastructure of the offline package, and there are brother teams on the APP side and the network side working together to polish it. This model will have some flaws, such as business competition issues when there are too many offline packages. However, in terms of first-screen performance, SSR is not necessarily much better than it. At this time, there will be considerable resistance for them to switch to SSR.
Q6: Some comments believe that the development and maintenance costs of SSR are too high, and they have turned to CSR . Can CSR achieve the same effect as SSR? Is there any specific action plan?
Liu Yong: From the key point of first screen performance, if CSR does not make certain optimizations, at least three serial HTTP requests, the first screen time will definitely not be as good as SSR (the interoperation time is not necessarily).
However, there are many corresponding solutions, such as ServiceWorker, offline packages, etc.
Liu Kui: From the perspective of first screen rendering speed alone, if CSR wants to achieve similar effects to SSR, the following optimization solutions can be adopted:
-
Static resource optimization of the first screen page: through code cutting & lazy loading, etc., ensure that the JS/CSS required for the first screen is a minimized version, and directly into the HTML through inlining, etc., to reduce the network requests required for first screen rendering. ;
-
Caching and preloading : Use the client's caching and preloading mechanisms to improve the speed of secondary access;
-
Use a lighter framework: Choose a lighter front-end framework to reduce the JS size of the first screen and improve loading speed;
-
Optimize the response speed of key interfaces: Optimize the interface response speed of key content required for the first screen to ensure that the front end can render the page faster.
But if there are additional SEO demands, it may be difficult for pure CSR to achieve the same effect.
Q7: If the original application is directly switched to the SSR integrated application, how much will the cost be? What challenges will it pose to the development team?
Liu Kui: The costs and challenges are as follows:
-
Cost of application modification: Most applications cannot run directly in the server environment and basically require a certain degree of modification, such as eliminating the dependence on browser-specific APIs such as window and location in the first-screen rendering code, and building a JS running on the server, etc.
-
SSR function development and operation and maintenance challenges: Teams with rich front-end and server-side development experience are very rare in most companies. As mentioned earlier, SSR brings additional server-side development and operation and maintenance challenges. , this also needs to be considered by the front-end team.
3. Maybe, SSR + CSR will be the new direction in the future?
Q8: Some websites now use first-screen server-side rendering, that is, the page that the user first opens uses server-side rendering, which ensures the rendering speed, while other pages use client-side rendering , so that the front and back are completed. end separation. Do you think this would be a more perfect solution that combines the advantages of both?
Liu Kui: Yes, this is also the current best practice in the community, which can well retain the advantages of SSR and SPA applications.
Liu Yong: This has actually been practiced many years ago. For example, Yunlong's Scrat Pagelet at UC had a similar practice. Even at that time, subsequent pages were partially rendered through the server and the front-end pages were updated on demand.
This method has also been seen in some further practices in the industry: developers write logic naturally, without having to worry about separation or non-separation, and it is automatically split at the front-end engineering layer, SSG + SSR + CSR, Some that can be built statically are processed directly in the build phase, some that can be rendered on the server side, and the remaining non-required components are directly rendered on the front end. All of these can be done, provided the front-end engineering infrastructure is complete enough and the R&D model is converged enough.
As a final reminder, most of the SSR practices I know usually block a short-term CDN in front, and then use CSR to perform various modifications and subsequent business logic.
Q9: How do you see the future development of SSR ? Will it be phased out with hardware upgrades, or will it become more popular with technology updates?
Liu Yong: Optimization ideas will never go out of date. Maybe one day the SSR programming interface we are familiar with will change. For example, SSR used templates such as nunjucks and ejs, but now it uses react and vue. There will be new technologies emerging in the future, but it is likely to be a practice model of SSR.
Liu Kui: According to my experience, many times new technical solutions try to squeeze more hardware performance to obtain a better interactive experience. Therefore, there will be relatively "low-end" devices at any time. This should be It can’t be solved (laughs)
In my opinion, the main implementation cost of SSR is the R&D and operation and maintenance of the server. This is a huge burden for the front-end teams of most companies, and the low ROI makes it difficult to implement SSR. However, with the development of Serverless, many almost "zero operation and maintenance" Serverless solutions have emerged, which can greatly reduce the operation and maintenance costs of the front-end team. At the same time, judging from community trends, various front-end frameworks that have been popular in recent years are embracing Edge and SSR, such as Next.js, remix-run, Qwik, Astro, Fresh, etc. At the same time, libraries such as React have also introduced streaming SSR capabilities with better performance. Through the integration and iteration of these framework technologies, it can not only significantly reduce the research and development costs of front-end engineers developing SSR applications, but also further improve the performance effects of traditional SSR.
Judging from the current trends, I think SSR will become more and more popular as R&D and operation and maintenance costs decrease.
Q10: Based on your project experience, how would you evaluate the SSR model?
Liu Yong: Judging from the historical evolution of the front-end, it is SSR → CSR → SSR. At first glance, it seems that we are reversing history, but in fact it is not.
For example, at that time, the front-end HTML + CSS + JS were all-in-one single-file methods, because at that time the front-end did not have the ability to compile and could only be written together; with the evolution of front-end engineering, the development period was split into many File organization, automatic processing during construction has become mainstream; furthermore, single file methods such as Vue SFC have emerged. Is this going backwards? Actually not, but as the infrastructure improves, the user programming interface can be more intuitive, and things like performance and deployment can be left to the tools.
Therefore, I think the SSR mode has real scenarios, but at this stage, I think it still has many practical performance issues and engineering issues that need to be solved in order to be better implemented.
Liu Kui: Although CSR can also achieve a better first-screen experience, it is limited by the capabilities of the user's device and has an obvious performance ceiling. SSR can better leverage server-side capabilities such as edge computing (ESR) and streaming rendering to effectively raise the performance ceiling. In most cases, it will be an effective weapon for web applications to improve first-screen performance.
Of course, each project and team has different characteristics and goals, and various factors need to be considered comprehensively when choosing a development model.
What do you think of it? Did your project adopt SSR or CSR? Come and tell us your experience in the comment area~