一文带你搞懂 SSR

更新日期: 2022-06-10阅读: 1.1k标签: SSR

什么是 SSR

Server-side rendering (SSR)是应用程序通过在服务器上显示网页而不是在浏览器中渲染的能力。服务器端向客户端发送一个完全渲染的页面(准确来说是仅仅是 html 页面)。同时,结合客户端的 JavaScript bundle 使得页面可以运行起来。与 SSR 相对的,还有一种 Client-side rendering(CSR)。CSR 和 SSR 的最大区别只是提供 rendering 的是客户端还是服务端,其本质还有一种东西。故以下如果没有着重提出 CSR 和 SSR 不一样的地方,则默认是一致的。


为什么要 SSR

得益于 react 等前端框架的发展,前后端分离,webpack 等编译工具的流行,以及 ajax 实现页面的局部刷新,使得我们现在的应用程序不再像曾经的应用程序一般需要从服务端获取页面,可以动态的修改局部的页面数据,避免页面频繁跳转影响用户体验等问题。也就是 SPA 越来越成为主流应用程序模型。
但是 SPA 的使用,除了以上提到的优势以外,必然会带来劣势。譬如:

  1. 由于需要在页面加载之前就加载所有页面需要的 JavaScript 库,这使得首次打开页面所需要的时间比较久;
  2. 需要研发专门针对于 SPA 的 Web 框架(各种具备 SSR 能力的框架,包括 Next.js 等)
  3. 搜索引擎爬虫
  4. 浏览器历史记录的问题(基于 pushState 的各种 router)

为了解决上述提到的 1. 和 3. 的问题,SSR 开始登上历史的舞台。


SSR 怎么做


基于上述的理论,我们可以设计一个具有 SSR 功能的 React 框架。

首先,我们通过 create-react-app 命令初始化一个 React 项目,可以把初始化完成后的项目理解为具有最简单功能的项目。我们将基于该项目去实现一个 SSR 的功能。

# Yarn
$ yarn create react-app ssr-demo
同学们实践的时候需要注意,当前版本的 cra 命令新建项目的时候,启动会报类似于 Mini.... is not a function的问题。这是因为 mini-css-extract-plugin该插件版本更新导致的,只需要在 package.json里面通过 resolutions 限制mini-css-extract-plugin的版本为 2.4.5 即可

生成项目的目录如下:

./
├── README.md
├── build
├── node_modules
├── package.json
├── public
├── src
└── yarn.lock

已经自动安装完依赖,启动项目我们可以在「本地环境」看到一个最简单的页面。

接下来,我们去实现一个 SSR 功能。首先,我们需要安装 express(如果是 CSR 的话就不需要这一步)

yarn add express

安装完成后,我们需要在 server/index.js文件中编写如下代码

import express from "express";
import serverRenderer from "./serverRenderer.js";

const PORT = 3000;
const path = require("path");

const app = express();
const router = express.Router();

// 当爬虫的请求进来的时候,把所有请求导向 serverRenderer 路由
router.use("*", serverRenderer);

app.use(router);
app.listen(PORT, () => console.log(`listening on: ${PORT}`));

其中serverRenderer该文件内容如下:

import React from "react";
import ReactdomServer from "react-dom/server";

import App from "../src/App";

const path = require("path");
const fs = require("fs");

export default (req, res, next) => {
  // 获取当前项目的 HTML 模板文件路径
  const filePath = path.resolve(__dirname, "..", "build", "index.html");

  // 读取该文件
  fs.readFile(filePath, "utf8", (err, htmlData) => {
    if (err) {
      console.error("err", err);
      return res.status(404).end();
    }

    // 借助 react-dom 依赖下的方法将 JSX 渲染成 HTML string
    const html = ReactDOMServer.renderToString(<App />);

    // 将 HTML string 替换到 root 中
    return res.send(
      htmlData.replace('<div id="root"></div>', `<div id="root">${html}</div>`)
    );
  });
};

如上,我们完成了一个非常简单的具有 SSR 功能的服务端。
但是仅仅如此是不够的,我们还需要在根目录下,新建parser.js将ESM 转成 CommonJS 运行起来,代码如下:

require("ignore-styles");
require("@babel/register")({
  ignore: [/(node_modules)/],
  presets: ["@babel/preset-env", "@babel/preset-react"],
});

require("./server");

解释一下上面引入的包的作用:

  • @babel/register:该依赖会将 node 后续运行时所需要 require 进来的扩展名为 .es6、.es、.jsx、 .mjs 和 .js 的文件将由 Babel 自动转换。
  • ignore-styles:该依赖也是一个 Babel 的钩子,主要用于在 Babel 编译的过程中忽略样式文件的导入。

在经过上述的操作之后,我们先 yarn build出我们的产物,然后通过node parser.js来启动 SSR 服务。


经过上述的操作之后,我们设计出了一个非常简单的但合理的 SSR 服务端。作为对比,我们在这里简单的和 Next.js 做对比。

在 Next.js 项目的根目录中的 package.json 中,我们可以看到同样选择了 express 作为服务器.

...
"eslint-plugin-react-hooks": "4.2.0",
"execa": "2.0.3",
"express": "4.17.0",
"faker": "5.5.3",
...

我们可以在 ~/packages/next/server/next.ts文件夹中,发现 Next.js会通过 createServer方法,启动一个 NextServer 对象,该对象负责启动服务器以及渲染模板模板。
命令调用如下:


在 [Next.js](https://nextjs.org/docs/basic-features/pages#server-side-rendering)的官网中,我们可以看到其支持在页面通过 getServerSideProps函数,来实现动态获取接口数据。其实,在大多数支持 SSR 的框架库中,都有类似的设计。因为 SPA 的应用,难免需要通过服务端获取动态数据,并渲染页面,而实现渲染动态数据的 SSR 的设计思路都较为一致。即在该页面的组件同一文件中导出一固定方法,并且 return 某一固定格式。框架会将该数据用作初始数据对页面进行 SSR 渲染。


我们以Next.js为例,了解了 SSR 的大致设计思路,那么接下来我们了解一下 CSR 的大致思路.。

CSR 可以理解为阉割版的 SSR,只实现了 SSR 的预渲染功能。一般用于静态网站,不具备动态获取数据的功能。

CSR 的渲染思路同 SSR 一致,不同点在于 SSR 是需要安装 express而 CSR 不需要安装 express。这也就导致了 CSR 和 SSR 在部署流程上的不同。SSR 项目如 Next.js应用在执行完 build 命令后,可以通过 start 命令执行启动服务器,不再需要配合 nginx 的反向代理。而 CSR 项目如 Umi仍然需要 nginx 的代理。

CSR 最大的不同点在于编译后产物的不同。通常一个前端项目在编译后的产物包括一下:

  • bundle.js或者 chunk.js
  • index.html
  • index.css
  • public/*
  • 其他相关文件,如 rss.xml等

而具备 CSR 的项目通过编译后,会有更多的 HTML文件,这些文件的架构会按照路由生成。譬如:我们目前路由如下:

  • /a
  • /b

分别对应 ComponentA 和 ComponentB,那么在我们编译后产物中会生成a.html和b.html。在我们将产物部署到 nginx 服务上后,就可以实现预渲染功能。

要实现以上功能,最重要的步骤如下:

  • 获取到当前项目的路由
  • 获取到路由对应的组件,如果组件未编译过,需要编译
  • 借助 react-dom 的能力将 JSX 渲染成 HTML,并插入到模板 HTML 中
  • 在编译后产物中根据路由创建文件夹,并将结果 HTML 生成到对应路径中

到这里,我们了解了整个 SSR 的流程,相信大家对 SSR 都有了一定程度的了解。目前社区的绝大部分框架都不需要我们自行去做 SSR。我们了解渲染过程有助于我们在应对各种层出不穷的框架时,能够以不变应万变。

来源:https://www.cnblogs.com/dtux/archive/2022/06/08/16355744.html

链接: https://www.fly63.com/article/detial/11692

使用 PHP 来做 Vue.js 的 SSR 服务端渲染

一个单页应用(通常也叫做 SPA )是一个客户端渲染的 App 。这是一个仅在浏览器端运行的应用。如果你正在使用框架,比如 React, Vue.js 或者 AngularJS ,客户端将从头开始渲染你的 App 。

React 中同构(SSR)原理脉络梳理

随着越来越多新型前端框架的推出,SSR 这个概念在前端开发领域的流行度越来越高,也有越来越多的项目采用这种技术方案进行了实现。SSR 产生的背景是什么?适用的场景是什么?实现的原理又是什么?

vue-ssr之nuxt.js的插件使用

有时候,我们会有这样的需求,在项目的前端页面中需要使用一个swiper插件,来实现图片轮播,但是nuxt是在服务端进行编译的,那么问题来了,我们如何像在vue中那样使用第三方模块,封装轮播公用组件呢?答案是:使用nuxt到插件功能。

手把教你搭建SSR(vue/vue-cli + express)

最近简单的研究了一下SSR,对SSR已经有了一个简单的认知,主要应用于单页面应用,Nuxt是SSR很不错的框架。也有过调研,简单的用了一下,感觉还是很不错。但是还是想知道若不依赖于框架又应该如果处理SSR,研究一下做个笔记。

基于Vue-SSR优化方案归纳总结

Vue-SSR相信大家都不陌生,与传统 SPA 相比,服务器端渲染 (SSR) 能够具备更好的SEO,方便搜索引擎爬虫抓取工具可以直接查看完全渲染的页面,除此之外,SSR能够在更短的时间内渲染出页面内容,通过在服务端填充数据吐出到客户端的方式,让用户有更好的用户体验。

React SSR 之为什么要进行限流

当对 React 应用进行页面加载或 SEO 优化时,我们一般绕不开 React SSR。但 React SSR 毕竟涉及到了服务端,有很多服务端特有的问题需要考虑,而限流就是其中之一。

React SSR 之限流

当对 React 应用进行页面加载或 SEO 优化时,我们一般绕不开 React SSR。但 React SSR 毕竟涉及到了服务端,有很多服务端特有的问题需要考虑,而限流就是其中之一。

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!