SSR 和 SSG

2023-07-04 17:46:18

面试后引发的思考

SSR

我们传统的前端渲染方式是 CSR（Client Side Render）客户端渲染，网页的渲染过程发生在客户端，即浏览器中，通过 js 来动态生成页面的内容。在 CSR 模式下，浏览器向服务器请求一个 HTML 文件和一个或多个 js 文件，然后 js 在浏览器中运行，通过 DOM 操作动态生成页面结构，最终呈现在用户面前。

而 SSR（Server Side Render）服务端渲染，则是将 Web 应用程序在服务器端进行渲染的技术。在 SSR 中，服务器将页面的 HTML、CSS 和 JS 等资源组装成一个完整的页面，并将页面发送给客户端进行展示，减少了客户端的渲染工作量，提高了 Web 应用程序的性能和用户体验。

当我们对开启 SSR 的页面请求时，响应的是一个 HTML 字符串，在客户端再将静态的 HTML “激活”(hydrate) 为能够交互的客户端应用。

SSR 的优点

• 更快的首屏加载，客户端不需要等待 JavaScript 加载和执行，从而提高页面的加载速度和用户体验。

• SEO 更加友好，搜索时可以更好地抓取服务器端渲染的内容，提高页面的排名。

• 更好的可访问性，在某些情况下，客户端无法访问某些资源，例如 JavaScript 文件，使用 SSR 可以确保这些资源被渲染到 HTML 中，从而提高 Web 应用程序的可访问性。

• 更好的安全性，客户端无法访问服务器端的数据，从而提高了应用程序的安全性。

思考

今天面试时被问到一个问题，为什么 SSR 的页面 SEO 会更友好，顿时一阵语塞，因为平时所记着的 SEO 更加友好只是作为一个优点，缺没有思考过为什么 SEO 会更加友好，然后就开始去搜索一番，在 Vue.js 官网 里看到了一段话。

::: tip 截至目前，Google 和 Bing 可以很好地对同步 JavaScript 应用进行索引。这里的“同步”是关键词。如果你的应用以一个 loading 动画开始，然后通过 Ajax 获取内容，爬虫并不会等到内容加载完成再抓取。也就是说，如果 SEO 对你的页面至关重要，而你的内容又是异步获取的，那么 SSR 可能是必需的。 :::

看完突然感觉好像明白了。

个人理解，当我们在搜索引擎中搜索时，会根据一些页面的关键字来进行爬取对应的内容，把匹配度更高的页面放在搜索结果靠前的位置，但是如果是 CSR 的渲染方式，有些内容需要等到页面渲染的时候再通过网络请求来获取，那么我们爬虫爬取的时候就爬不到对应的关键字，对应的页面的搜索结果就不会靠前。而 SSR 在服务端就进行了这一步，所以我们会说 SSR 的 SEO 会更加友好

SSG

SSG（Static Site Generation）为静态站点生成，在构建的时候直接把结果页面输出 html 到磁盘，每次访问直接把 html 返回给客户端，相当于一个静态资源，与 SSR 的原理非常类似，但不同之处在于 HTML 文件是预生成的，而不是在服务器实时生成。

工作流程

• 构建阶段：在构建过程中，SSG 将源文件和模板（如 HTML、CSS）结合，生成静态页面。这些页面通常由预定义的布局、组件和样式组成。
• 预渲染：SSG 在构建过程中会自动执行预渲染。这意味着 SSG 会根据预定义的路由和数据源，在构建时生成静态页面的多个实例。例如，对于一个博客，每篇文章都可以在构建过程中生成一个独立的静态页面。
• 静态输出：一旦构建完成，SSG 将生成的静态页面输出到目标文件夹中。这些页面包含所有必要的 HTML、CSS 和 JavaScript，以及任何相关的静态资源（如图像、视频等）。
• 部署：生成的静态页面可以直接部署到任何支持静态文件的 Web 服务器上。因为这些页面不需要动态生成，所以它们可以被高效地缓存和交付给访问者，提供更好的性能和可扩展性。
• 用户访问：首屏直接解析 html 生成 dom。接着和 SSR 一样通过 hydrate 将整个应用转变成为 React 或 Vue 应用，使用户在交互时与单页应用无异。