服务端渲染(SSR)和Nuxt.js

服务端渲染(SSR)

客户端渲染和传统服务端渲染的问题

• SPA应用有两个非常明显的问题：

  • 首屏渲染慢
  • 不利于 SEO

• 传统的服务端渲染又存在:

  • 应用的前后端部分完全耦合在一起，在前后端协同开发方面会有非常大的阻力；
  • 前端没有足够的发挥空间，无法充分利用现在前端生态下的一些更优秀的方案；
  • 由于内容都是在服务端动态生成的，所以服务端的压力较大；
  • 相比目前流行的 SPA 应用来说，用户体验一般；

现代化的服务端渲染(同构)

1. 客户端发起请求
2. 服务端渲染首屏内容 + 生成客户端 SPA 相关资源
3. 服务端将生成的首屏资源发送给客户端
4. 客户端直接展示服务端渲染好的首屏内容
5. 首屏中的 SPA 相关资源执行之后会激活客户端 Vue
6. 之后客户端所有的交互都由客户端 SPA 处理

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ipXMBwvW-1599615479735)(image/…/…/image/同构渲染.png)]

• 这种方式简而言之就是：

  • 通过服务端渲染首屏直出，解决首屏渲染慢以及不利于 SEO 问题
  • 通过客户端渲染接管页面内容交互得到更好的用户体验

• 但是凡事都不会事完美的,如果要使用服务端渲染,就一定会存在相对的问题

  • 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些
    外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。
  • 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序
    (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。
  • 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server
    更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic)
    下使用，请准备相应的服务器负载，并明智地采用缓存策略。

什么情况下使用SSR?

其实根据上面的介绍,我们可以总结出两点

1. 首屏渲染速度是否真的重要?
2. 是否真的需要SEO?

第二点也是最直接判断是否需要使用SSR的条件了,如果你的项目一定需要SEO,那么你也不用纠结,那一定是需要SSR的,反之你才可以酌情考虑

Nuxt.js的基础介绍及用法

什么是Nuxt.js

• 一个基于Vue.js生态的第三方开源服务端渲染应用框架
• 它可以帮我们轻松的使用Vue.js技术栈构建同构应用
• Nuxt.js

使用Nuxt.js的情况

• 初始项目
• 已有的Node.js服务端项目
  • 直接把Nuxt当作一个中间件集成到Node Web Server中
• 现有的Vue.js项目
  • 非常熟悉Nuxt.js
  • 至少百分之10的代码改动

初始化Nuxt.js应用的方式

1. 手动创建
2. 使用create-nuxt-app

下面介绍以下手动创建的方式

1. 省略创建文件夹初始化过程…
2. 新建 package.json 文件来设定如何运行 nuxt

{
   
  "name": "my-app",
  "scripts": {
   
    "dev": "nuxt"
  }
}

3. 安装nuxt

$ npm i nuxt -D

4. 创建pages目录
   • *Nuxt.js 会依据 pages 目录中的所有 .vue 文件生成应用的路由配置。

$ mkdir pages

5. 创建pages/index.vue页面

<template>
  <div>
      <h1>Hello Nuxt.js</h1>
  </div>
</template>

<script>
export default {
    name: 'HomePage'
}
</script>

<style>

</style>

6. 最后启动项目

$ npm run dev

• Nuxt.js 会监听 pages 目录中的文件更改，因此在添加新页面时无需重新启动应用程序。

Nuxt.js路由

• Nuxt.js依据pages目录解构自动生成vue-router模块的路由配置