study/ZiuChen.github.io
1
0
Fork 0
mirror of https://github.com/ZiuChen/ZiuChen.github.io.git synced 2025-08-17 23:19:55 +08:00
Code Issues Packages Projects Releases Wiki Activity
ZiuChen.github.io/docs/note/SSR.md
ZiuChen 6f5d00693e docs: note update
2023-02-15 00:39:34 +08:00

8.6 KiB
Raw Blame History

服务端渲染(SSR)

  • 邂逅SPA和SSR
  • Node服务搭建
  • Vue3 + SSR搭建
  • SSR + Hydration 水合
  • Vue SSR + Router
  • Vue SSR + Pinia

邂逅SPA和SSR

我们使用Vue开发的网页一般都是单页面应用程序（SPA Single Page Application）

  • SPA应用是在客户端呈现的，我们称这个渲染过程为CSR（Client Side Rendering）
  • 常见的B端Web应用开发模式，渲染工作在客户端进行，服务器压力较轻，服务器直接返回未经加工的.html文件
  • 所需要的资源（HTML CSS JS等），在一次请求中就加载完成，首屏时间更长，需要额外的首屏优化

与之相对的，就是服务端渲染（SSR Server Side Rendering）

  • SSR并不是什么新鲜的概念，早期的JSP或PHP就已经体现了服务端渲染的原理
  • 但是传统开发模式，代码耦合度较高，不容易维护

于是，同构SSR应运而生，我们称之为BFF（Backend for Frontend 服务于前端的后端）

  • 前后端一体化，一套Vue / React代码在服务器上运行一遍，在到达浏览器又运行一遍。
  • 前后端都参与到渲染中，并且首次渲染出的HTML相同

浏览器请求.html文件 => 服务端运行Vue / React代码并生成.html => 发送.html文件给浏览器 => 浏览器显示网页内容

=> 浏览器加载JS文件 => 绑定DOM事件 客户端渲染接管界面 => 再次跳转路由就是客户端渲染 无需请求后台

SPA的优点与缺点

  • SPA的优点
    • 只需要加载一次 更好的用户体验
      • 只有一个.html文件，页面切换不需要重新加载，所以比传统Web应用程序更快
    • 轻松构建功能丰富的Web应用程序
  • SPA的缺点
    • SPA应用默认只返回一个空HTML文件，不利于SEO
    • 首屏加载资源过大，影响首屏渲染速度
    • 不利于复杂项目构建

SEO优化

  • 语义性HTML标记
    • 标题用 h1，一个页面只应当由一个 h1 标签，副标题用 h2 - h6
    • 不要过度使用 h 标签，多次使用不会增加SEO
    • 段落用 p 标签 列表用 ul 标签，且 li 只放在 ul 中
  • 每个页面都需要包含标题+内部链接
    • 每个页面对应的title，同一个网站所有页面都有内链可以指向首页
  • 保证链接可供抓取
    • <a href="https://www.example.com" />
    • <a href="/relative/path/file" />
  • meta标签优化：设置description和keywords等
  • 文本标记和img
    • 比如<b>和<strong>加粗文本的标签，爬虫会关注到该内容
    • img标签添加alt属性，图片加载失败时供爬虫读取alt内容
  • robots.txt 文件，规定爬虫可以访问网址上的哪些页面
  • sitemap.xml 站点地图，在站点地图列出所有网页，确保爬虫不会漏掉某些网页

服务端渲染 SSR

服务端渲染 SSR （Server Side Rendering）

  • 页面是在服务端渲染的，用户每请求一个SSR页面，都会先在服务端渲染
  • 服务端渲染完成后，返回给浏览器呈现，浏览器发现JS脚本，解析脚本，向服务器发起请求，之后网页就可以交互了
    • app = createSSRApp(App) renderToString(app) => App String Html
    • client_bundle.js 客户端通过脚本激活应用程序 让应用程序可以进行交互，这个过程叫水合（ Hydration）
  • Vue Nuxt / React Next.js，SSR应用也称为同构应用（server_bundle.js & client_bundle.js）

SSR的优点

  • 更快的首屏渲染速度
    • 浏览器显示静态页面的内容要比JavaScript动态生成的内容快得多
    • 用户访问首页时立刻返回静态页面内容，而不需要等待浏览器先加载完整个SPA应用的JS代码
  • 更好的SEO
    • 爬虫擅长爬取HTML页面，服务端直接返回一个静态的HTML给浏览器
    • 有利于爬虫快速爬取网页内容，并编入索引，有利于SEO
  • SSR 应用程序在 Hydration 之后仍然可以保留Web应用程序的可交互性
    • 如：前端路由、响应式数据、虚拟DOM等

SSR的缺点

  • SSR 通过需要对服务器进行更多的API调用，在服务端渲染需要消耗更多的服务器资源，成本较高
  • 100个人访问这个网站，服务器就要为每个人渲染100次
  • 增加了一定的开发成本，开发者需要关心哪些代码是运行在服务端的，哪些则是运行在浏览器的
  • SSR配置站点的缓存通常会比SPA站点要更复杂

SSR 解决方案

  • 传统方案：PHP JSP ...
  • 从0开始，搭建SSR项目：Node+Webpack+Vue/React
  • 选用现成的框架
    • React Next.js
    • Vue3 + Nuxt3 || Vue2 + Nuxt.js

静态网站生成 SSG

静态网页生成 SSG（Static Site Generate）

  • SSG应用在构建阶段就确定了.html页面的内容
  • 用户访问网站，服务器直接返回.html文件给客户端，相当于一个静态资源
  • 优点
    • 直接返回静态的html文件，有利于SEO
    • 相比于SSR，不需要每次请求都由服务端处理，所以可以大幅减轻服务端压力，也可以将文件放到CDN上优化访问速度
    • 保留了SPA应用的特性，比如前端路由、响应式数据、虚拟DOM等
  • 缺点
    • 如果网站的内容需要更新，那么需要重新构建与部署
    • 只能生成偏静态的页面，不利于与用户的交互，所有用户获取到的页面都是相同的
  • 哪些应用场景：文档站、个人博客、新闻站点等

SSR与SSG的优势

  • 更短的首屏时间
    • 只需要请求一个HTML文件就能展示出页面
    • 虽然在服务端仍然需要调取相关接口，但是服务器-服务器之间的通信远比客户端快，有时甚至是同一台服务器的本地接口
    • 不再需要大量的js文件请求，这就使得SSR/SSG可以拥有更短的首屏时间

跨请求状态污染

  • 在SPA中，整个生命周期只有一个App对象实例/一个Router对象实例/一个Store对象实例

    • 因为每个用户使用SPA时，各自的渲染进程都是在自己的浏览器上独立进行的，这是一种单例模式

  • 然而在SSR的环境下，App模块通常只在

    服务器启动时

    初始化一次，同一个应用模块会在多个服务器请求之间被复用

    • 单例状态对象也会在多个请求之间被复用：
    • 某个用户对共享的单例状态进行修改，那么这个状态可能会意外地泄露给另一位正在请求的用户
    • 我们将这种情况称为：跨请求状态污染

  • 为了避免这种跨请求状态污染，SSR的解决方案是：

    • 在每个请求中，为整个应用创建一个全新的实例，包括后面的Router和Store等实例
    • 带来的缺点就是：需要消耗更多的服务器资源

Nuxt3 系统学习

  • 邂逅Nuxt3
  • Nuxt3 初体验
  • Nuxt3 全局配置
  • Nuxt3 内置组件
  • Nuxt3 样式和资源
  • Nuxt3 页面和导航
  • Nuxt3 动态路由

认识Nuxt3

  • 支持数据双向绑定和组件化：Vue.js
  • 处理客户端导航：Vue Router
  • 支持开发中热模块替换、生产环境代码打包：Webpack5 Vite
  • 兼容旧版浏览器，支持ES6+语法转译：ESBuild
  • 支持开发环境服务器，支持服务端渲染/API接口转发
  • 使用h3实现部署可移植性（h3是一个极小的高性能http框架）
    • 如：支持在Serverless、Worker、Node.js环境中运行

搭建Nuxt3环境

使用命令行工具 Nuxi 初始化Nuxt：

  • npx nuxi init project-name
  • pnpm dlx nuxi init project-name
  • npm install -g nuxi && nuxi init project-name

解读脚手架创建的初始化项目的package.json中的脚本：

{
  "private": true,
  "scripts": {
    "build": "nuxt build",
    "dev": "nuxt dev",
    "generate": "nuxt generate",
    "preview": "nuxt preview",
    "postinstall": "nuxt prepare"
  },
  "devDependencies": {
    "nuxt": "^3.2.0"
  }
}
  • build 构建正式版本，将被输出到.output文件夹
  • dev 开发环境
  • generate 打包正式版本项目，但是会预渲染每个路由（nuxt build --prerender）
  • preview 对打包项目启动本地预览服务器
  • postinstall 该脚本为NPM的生命周期函数，将在npm install后执行

针对postinstall中执行的nuxi prepare脚本，官方文档有如下解释：

The prepare command creates a .nuxt directory in your application and generates types. This can be useful in a CI environment or as a postinstall command in your package.json.

执行该脚本后，将在项目根目录创建.nuxt文件夹

  • 这个文件夹将作为默认构建输出的文件夹
  • 其中的文件都以.d.ts结尾，是Nuxt的TS类型声明