【Nuxt】服务端渲染 SSR

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对象时都是使用一个函数来创建，保证每个请求都会创建一个全新的实例。
    
  • 这样的缺点就是必要斲丧更多的服务器资源
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。