SSR
服务端渲染Server Side Render
就是当进行请求时,页面上的内容是通过服务端渲染生成的,浏览器直接显示服务端返回的HTML
即可。
通常在构建一个普通的SPA
单页应用时,就是构建的客户端渲染的应用,CSR
客户端渲染Client Side Render
就是当进行请求时,页面上的内容是通过加载的Js
文件渲染出来的,Js
文件动态运行在浏览器上面,服务端只返回一个HTML
模板。
SEO
、搜索引擎爬虫无法完整解析用户页面。SSR
服务端渲染Server Side Render
就是当进行请求时,页面上的内容是通过服务端渲染生成的,浏览器直接显示服务端返回的HTML
即可。对于传统服务端渲染,也称为后端模板渲染,如jsp
或者php
等,这是最早时期的web
,是指客户端请求时,在服务器上使用模板引擎将模板与数据拼接成完整的HTML
,再发送给客户端,客户端接收后直接解析HTML
就可以在浏览器上展示出来,不需要额外的异步请求获取数据,如果要使web
有交互性,客户端需要再用Js
去操作DOM
或者渲染其他动态的部分。
SEO
,由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面,如果SEO
对站点至关重要,而页面又是异步获取内容,则可能需要服务器端渲染SSR
解决此问题。time-to-content
,特别是对于缓慢的网络情况或运行缓慢的设备,无需等待所有的JavaScript
都完成下载并执行,用户将会更快速地看到完整渲染的页面,通常可以产生更好的用户体验,并且对于那些内容到达时间time-to-content
与转化率直接相关的应用程序而言,服务器端渲染SSR
至关重要。lifecycle hook
中使用,一些外部扩展库external library
可能需要特殊处理,才能在服务器渲染应用程序中运行。SPA
不同,服务器渲染应用程序,通常需要处于Node.js server
运行环境。Node.js
中渲染完整的应用程序,显然会比仅仅提供静态文件的server
更加大量占用CPU
资源CPU-intensive
-CPU
密集型,因此如果预料在高流量环境high traffic
下使用,需要准备相应的服务器负载,并明智地采用缓存策略。如果使用服务器端渲染SSR
只是用来改善少数营销页面,例如/
、/about
、/contact
等的SEO
,那么你可能需要预渲染,无需使用web
服务器实时动态编译HTML
,而是使用预渲染方式,在构建时build time
简单地生成针对特定路由的静态HTML
文件。如果使用webpack
,则可以使用prerender-spa-plugin
轻松地添加预渲染。
本质上对于渲染都是一样的,都是进行的字符串拼接生成HTML
,两者的差别最终体现在时间消耗以及性能消耗上。客户端在不同网络环境下进行数据请求,客户端需要经历从Js
加载完成到数据请求再到页面渲染这个时间段,导致了大量时间的消耗以及浏览器性能的消耗。而服务端在内网请求,数据响应快,不需要等待Js
代码加载,可以先请求数据再渲染可视部分然后返回给客户端,客户端再做二次渲染,这样大部分消耗的是服务端的性能,客户端页面响应时间也更快。
SSR
服务端渲染主要解决的是首屏渲染和SEO
优化,是否需要SSR
服务端渲染主要取决于SEO
对于网站是否非常重要以及内容到达时间time-to-content
对应用程序的重要程度。例如,如果你正在构建一个内部仪表盘,初始加载时的额外几百毫秒并不重要,这种情况下去使用服务器端渲染SSR
将是一个小题大作之举。然而如果大量的访问流量来自于搜索引擎的抓取,那么服务端渲染SSR
将是势在必行的解决方案,或者内容到达时间time-to-content
要求是绝对关键的指标,在这种情况下服务器端渲染SSR
可以帮助你实现最佳的初始加载性能。总而言之,开发需要根据实际场景寻找解决方案。