SSR 概述
服务器端渲染全称是:Server Side Render,在服务器端渲染页面,并将渲染好HTML返回给浏览器呈现。
SSR应用的页面是在服务端渲染的,用户每请求一个SSR页面都会先在服务端进行渲染,然后将渲染好的页面,返回给浏览器呈现。
构建SSR应用常见的库和框架有:Vue Nuxt, React Next.js等,SSR应用也称同构应用。
Nuxt:
优缺点
■SSR的优点
- 更快的首屏渲染速度
√浏览器显示静态页面的内容要比JavaScript动态生成的内容快得多。
√当用户访问首页时可立即返回静态页面内容,而不需要等待浏览器先加载完整个应用程序。 - 更好的SEO
√爬虫是最擅长爬取静态的HTML页面,服务器端直接返回一个静态的HTML给浏览器。
√这样有利于爬虫快速抓取网页内容,并编入索引,有利于SEO。 - SSR应用程序在Hydration之后依然可以保留Web应用程序的交互性。比如:前端路由、响应式数据、虚拟DOM等。
■SSR的缺点
- SSR通常需要对服务器进行更多API调用,以及在服务器端渲染需要消耗更多的服务器资源,成本高。
- 增加了一定的开发成本,用户需要关心哪些代码是运行在服务器端,哪些代码是运行在浏览器端。
- SSR配置站点的缓存通常会比SPA站点要复杂一点。
跨请求状态污染
- 在SPA中,整个生命周期中只有一个App对象实例或一个Router对象实例或一个Store对象实例都是可以的,因为每个用户在使用浏览器访问SPA应用时,应用模块都会重新初始化,这也是一种单例模式。
- 然而,在SSR环境下,App应用模块通常只在服务器启动时初始化一次。同一个应用模块会在多个服务器请求之间被复用,而我们的单例状态对象也一样,也会在多个请求之间被复用,比如:
- 当某个用户对共享的单例状态进行修改,那么这个状态可能会意外地泄露给另一个在请求的用户。
- 我们把这种情况称为:跨请求状态污染。
- 为了避免这种跨请求状态污染,SSR的解决方案是:
- 可以在每个请求中为整个应用创建一个全新的实例,包括后面的router和全局store等实例:
- 所以我们在创建App或路由或Stor对象时都是使用一个函数来创建,保证每个请求都会创建一个全新的实例。
- 这样的缺点就是需要消耗更多的服务器资源