Vous apporter une compréhension approfondie des modes de rendu courants tels que CSR, SSR, SSG, etc.

avant-propos

Des travaux récents impliquent CSR, SSR, SSG, et cet article vise à résumer et généraliser ces modes de rendu.

SPA, MPA, SSRet CSRCes mots peuvent apparaître fréquemment dans votre vie professionnelle, et il existe de nombreux articles connexes sur Internet. Si vous vous sentez vague ou complètement ignorant sur ces concepts, j'espère que cet article vous aidera à comprendre ces modes de rendu.

ZPS et AMP

AMP

MPA ( multiple page application) est appelé une application multi-pages , qui fait référence à une application avec plusieurs pages. D'un point de vue technique, vous pouvez le comprendre à peu près.

  • Le premier écran est rapide : chaque page est indépendante les unes des autres, et plusieurs pages html doivent être maintenues séparément, et chaque requête renvoie directement du html.
  • Le changement de page est lent : saut de document basé sur un navigateur natif ( navigating across documents). Par conséquent, chaque mise à jour de page est un rechargement de page, ce qui entraînera une énorme consommation de performances de redémarrage.
  • Convivial pour le référencement : au début de la page, il a tout le contenu de la page au lieu de "sans état", afin d'obtenir un meilleur effet d'indexation.

image.png

SPA

SPA ( single page application) est appelé Application à page unique . Utilisez js pour percevoir le changement d'url, effacer dynamiquement le contenu de la page en cours, puis monter le contenu de la page suivante sur la page en cours. A ce moment, le routage n'est pas fait par le backend, mais par le frontend, qui affiche dynamiquement les composants requis.

  • Vitesse de changement de page rapide : les sauts de routage sont basés sur des implémentations spécifiques (telles que vue-router, react-router et autres routages frontaux), plutôt que sur des sauts de documents de navigateur natifs, évitant ainsi le rechargement inutile de la page entière.
  • Séparation front-end et back-end : Basé sur le routage front-end, SPA est découplé du back-end applicatif, de sorte que le front-end ne dépend plus de la répartition du routage du back-end.
  • Le temps du premier écran est lent : en plus du HTML, le premier écran doit également demander et exécuter des fichiers js, et rendre le premier écran sur une page vide via js.
  • Le SEO n'est pas convivial : le contenu est généré par le rendu js, mais le moteur de recherche ne reconnaît pas cette partie du contenu, ce qui entraîne un mauvais effet SEO

image (1).png

RSE(Rendu côté client)

CSR (Client Rendering) est une méthode de rendu qui exécute JavaScript sur le navigateur pour générer le DOM et afficher le contenu. La RSE est plus proche du développement front-end moderne. Les vues et React que nous utilisons habituellement utilisent la RSE par défaut. Le processus général est le suivant :

  1. Le navigateur demande html et js au serveur frontal
  2. La page html est vide, le chargement initial n'affiche aucun contenu et le contenu est rendu en exécutant js
  3. Interagir via l'API exposée par le backend

Pour une application CSR typique, le navigateur ne reçoit qu'une page HTML utilisée comme conteneur d'application, il est donc également appelé une application monopage, de sorte que les caractéristiques de CSR sont similaires à celles du SPA mentionné précédemment.

image (2).png

SSR (rendu côté serveur)

concept

Au début, les développeurs aimaient créer des applications à l'aide de JSP ou d'autres moteurs de rendu de modèles, une approche connue sous le nom de SSR (Server Side Rendering). Contrairement au rendu côté client, les sorties SSR ont rendu du HTML complet, et l'ensemble du processus de rendu a lieu côté serveur.

Une fois que l'utilisateur a lancé une demande, le processus SSR est à peu près le suivant :

  1. Le service backend interroge le contenu requis par l'utilisateur via la couche de données
  2. Gérer la logique métier
  3. Coudre des pages à l'aide de modèles
  4. Renvoie la chaîne HTML rendue au client
  5. Rendu frontal et chargement de scripts JS pour compléter le reste de l'interaction

image (3).png

早期的 SSR 在内容更新/跳转,都需要再次请求服务器,重新加载一次页面。但在 React, Vue 等框架的加持下,我们语境中的 SSR 一般指的是首屏服务端渲染同构渲染(Isomorphic render,即新开页面访问 SSR 应用时,首屏会返回完整的 html,浏览器通过注水hydrate)成为 React 或 Vue 应用,后续用户进行跳转等操作时不会再向服务端请求 html,而是以类似单页应用的方式进行。

ssr1 (1).png

同构直出

上文中,我们提到了hydrate这个词,正是通过该操作使静态 html 页面转换成一个 Vue 或 React 应用,这依赖于 React 和 Vue 提供的「同构直出」功能。

在服务端渲染中,有两种页面渲染的方式:

  • 后端服务器获取数据并组装 HTML 返回给浏览器解析渲染页面
  • 浏览器在交互过程中,请求新的数据并动态更新渲染页面

这两种渲染方式的不同点在于运行环境的不同。同一份代码可以在客户端和服务器端运行,两个环境的渲染结果应该保持一致。因此,我们需要实现客户端和服务器端的路由、页面模板和数据共享。

image (4).png

我们通过webpack将打包出两份代码,一份在服务端运行。

Construction du rendu côté serveur de Vue (1).png

整体流程

以 Nuxt 为例,整体的渲染流程如下所示:

RSS (1).png

两个重要的概念

脱水(dehydrate)

将组件树序列化成静态的 HTML 片段,能直接看到初始视图,不过已经无法与之交互了,但这种便携的形态尤其适合网络传输。这个脱去动态数据,成为风干标本一样的静态快照的过程被称为脱水(dehydrate)。

注水(hydrate)

与脱水相反,将这个 html 躯干复活为 Vue 应用的过程称为注水。客户端并不重新生成 HTML 组件,而是重用服务器发送给它的 HTML,并附加「数据」与「交互性」,构建成完整的 Vue 应用,这个过程被称为注水(hydrate)。

Hydration is a process where a frontend framework like React, VueJS re-uses the static HTML structure it receives from the server (that was created at server-side at build time), and instead of re-generating the HTML nodes on the browser, simply “breathes” event handlers and interactivity into it.

SSR 与 CSR 的对比

优点
  • SEO 友好:搜索引擎爬虫可以直接抓取到最终页面内容。而 CSR 直接返回的 html 为空壳,对一些不加载执行 js 的低级爬虫来说这个页面的内容就是空的。
  • 首屏时间更短:服务端渲染直接返回带有数据的 HTML 文本,浏览器只需解析 HTML 并构建 DOM 树,无需额外执行 JS 来渲染首屏元素。
缺点
  • 占用服务器资源:渲染工作从浏览器转移到服务器,新增了数据获取的 IO 和渲染 HTML 的 CPU 占用。
  • 代码复杂度增加:需要同时兼容客户端和服务器端,代码编写时需要考虑两端的执行环境,且某些依赖库只能在客户端运行,增加了编码的复杂性。

SSG(Static Site Generation)

概念

SSG(静态站点生成)与 SSR 的原理非常类似,但不同之处在于 HTML 文件是预先生成的,而不是在服务器实时生成。

工作流程

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

icône ssg (1).jpeg

特点

SSG 的优缺点都非常明显,通常适用于静态页面,例如文档、博客、帮助站点和电子商务产品。

优点
  • 性能高:相比 SSR 减轻了服务器压力,还可以将生成的静态资源放到 CDN 上,充分利用缓存。
  • SEO 友好:搜索引擎爬虫可以直接抓取到最终页面内容
  • 易于部署:生成的静态页面可以直接部署到任何支持静态文件的 Web 服务器上,无需依赖 Node 环境等。
  • 高度安全性:由于服务器不需要运行程序,因此服务器漏洞仅限于操作系统本身,维护也更加方便。
缺点
  • 静态:只适用于静态数据,对于经常改动的数据,需要每次重新生成页面。

ISR(Incremental Static Regeneration)

概念

ISR(增量式网站渲染)结合了 SSG 和 SSR 的优势。ISR 的核心思想是将部分静态页面在构建时生成,并在用户访问时进行增量更新。

在 ISR 中,静态页面的构建仍然是在构建时完成的,类似于 SSG。然而,与完全静态的 SSG 不同,ISR 允许某些页面在构建后仍保持动态,并在用户首次访问时进行渲染。一旦渲染完成,生成的静态页面被缓存,并在后续的请求中被直接提供,以提高性能和响应速度。

工作流程

  1. 构建阶段:在构建过程中,使用SSG(静态站点生成器)生成静态页面,并将这些页面上传到 CDN。
  2. 用户发起页面请求:
    • 请求静态页面: CDN 直接返回;
    • 请求 ISR 页面,且该页面未被 CDN 缓存:直接响应 fallback 页面,浏览器接收到该页面后以 CSR 的形式渲染出内容;同时 CDN 会将请求转发到服务端,触发服务端渲染,服务器动态地生成页面内容,并返回给 CDN 进行缓存
    • 请求 ISR 页面,该页面 CDN 已有缓存且未过期:直接返回缓存的 html 页面
    • 请求 ISR 页面,该页面 CDN 已有缓存但已经过期:直接返回这份过期的缓存给浏览器,此时用户看到的是缓存已经过期的页面;同时 CDN 会将请求转发到服务端,触发服务端渲染,服务器动态地生成页面内容,并返回给 CDN 将该页面的缓存更新

ISR (1).png

特点

优点

L'avantage de l'ISR est qu'il trouve un équilibre entre statique et dynamique. Pour le contenu qui change peu fréquemment, SSG peut être utilisé pour générer des pages complètement statiques afin d'obtenir un chargement rapide et une faible charge du serveur. Pour les parties qui peuvent avoir besoin d'être mises à jour fréquemment, telles que les zones de commentaires ou les données en temps réel, ISR peut utiliser SSR pour générer dynamiquement ces contenus et effectuer des mises à jour incrémentielles dans les demandes ultérieures, afin de maintenir les performances en temps réel de la page. .

défaut
  • L'accès au contenu secondaire qui n'a pas été pré-rendu déclenche un repli, nécessite une RSE et se charge lentement.
  • La visite d'une page qui a déjà été pré-affichée mais qui a expiré et n'a pas été mise à jour entraînera une réponse en cache expirée. Les utilisateurs doivent actualiser une fois pour voir de nouvelles données.

Scénario d'application

Essentiellement, l'ISR est toujours dans le champ d'application du SSG, et les scénarios complexes ne peuvent toujours pas être traités. Ses scénarios d'application typiques incluent les commentaires de blog, les dernières listes d'articles, etc. En combinant ce contenu dynamique avec des pages statiques, il est possible de fournir une expérience utilisateur plus riche et en temps réel tout en maintenant des performances et une sécurité élevées.

Je suppose que tu aimes

Origine juejin.im/post/7233699680490799162
conseillé
Classement