阅读 207

前端项目服务端渲染(SSR)

这是我参与8月更文挑战的第11天,活动详情查看:8月更文挑战

名词解释

SSR

  • SSR:服务器端渲染-将客户端或通用应用程序渲染到服务器上的HTML。

CSR

  • CSR:客户端渲染-通常使用DOM在浏览器中渲染应用程序。

Rehydration

  • Rehydration: “启动”客户端上的JavaScript视图,以便它们重用服务器渲染的HTML的DOM树和数据。

Prerendering

  • Prerendering:在构建时运行客户端应用程序以将其初始状态捕获为静态HTML。

TTFB

  • TTFB: 到第一个字节的时间-视为单击链接到输入内容的第一位之间的时间。

FP

  • FP: First Paint-第一次获取任何像素对用户可见。

FCP

  • FCP: 第一个内容丰富的油漆-所请求的内容(文章主体等)可见的时间。

TTI

  • TTI: 互动时间-页面互动的时间(事件连线等)。

前端渲染介绍

CSR客户端渲染

今天介绍的是服务端渲染(Server-side Rendering),简称为SSR。 首先介绍一下常见的web渲染模式,第一个是目前前后端分离的主要开发模式,也是大多数前端同学的开发方式,就是客户端渲染(Client-side Rendering)。目前的三大框架Angular,React,Vue都是基于CSR开发的框架,我们在开发时只需要和后端同学,提前约定好接口,接着前端页面由我们前端同学开发构建,在需要页面刷新的地方,可以使用Ajax技术进行局部刷新。

CSR (Client-Side Rendering) – rendering an app in a browser, generally using the DOM.
复制代码

CSR渲染.png 上图是Google大会上贴出的介绍CSR的一张原理图,net代表网络请求,请求js文件“bundle.js”,此时是FCP时间点,

FCP:First Contentful Paint - the time when requested content (article body, etc) becomes visible.
复制代码

翻译过来就是:第一个内容丰富的渲染-所请求的内容(文章主体等)可见的时间。接下来由我们的js引擎以及浏览器渲染引擎渲染更多的页面内容。渲染完毕后又到了一个时间点:TTI。

TTI: Time To Interactive - the time at which a page becomes interactive (events wired up, etc)
复制代码

翻译过来就是:"互动时间-页面互动的时间(事件被整理等",也就是用户第一次可以与页面交互的时间点。而从FCP到TTI需要花费的时间则是由我们前端打包的js文件大小决定。这其中包含了我们的业务代码,同时又有第三方库的部分代码。对于性能较差的机器,也就花费时间更长。在google大会上提到的有利用HTTP/2 Server Push或者<link rel=preload>加载数据,可以提升性能,而在我们前端开发中还可以使用懒加载,webpacktreeshaking等等减少js文件大小来减少渲染时长。同时由于目前的前端框架大多开发的是单页面应用SPA(single page Application),如果js文件较大,则首屏加载会变慢,影响用户体验。让我换个思路,改变渲染模式,想想会有什么效果。

SSR服务端渲染

服务器呈现响应于导航生成服务器上页面的完整HTML。这样可以避免客户端进行数据获取和模板化的其他往返过程,因为它是在浏览器获得响应之前进行处理的。服务器渲染通常会产生快速的First Paint (FP)First Contentful Paint (FCP)。在服务器上运行页面逻辑和呈现可以避免向客户端发送大量JavaScript,这有助于实现快速的交互时间 (TTI)。这是有道理的,因为使用服务器渲染,您实际上只是将文本和链接发送到用户的浏览器。这种方法可以在很大范围的设备和网络条件下很好地工作,并且可以带来有趣的浏览器优化,例如流文档解析。SSR渲染过程大致如下图所示:

SSR渲染.png

通过服务器渲染,用户不太可能会等待CPU绑定的JavaScript处理才能使用您的网站。即使 无法避免使用第三方JS,使用服务器渲染来减少自己的第一方JS成本也可以为您提供更多的“预算”。但是,此方法有一个主要缺点:在服务器上生成页面会花费时间,这通常会导致首字节时间 (TTFB)变慢。

服务器渲染的动态特性可能会带来可观的计算开销。许多服务器渲染解决方案不会提早刷新,可能会延迟TTFB或将发送的数据加倍(例如,客户端JS使用的内联状态)。在React中,renderToString()可能很慢,因为它是同步的并且是单线程的。要使服务器呈现“正确”状态,可能涉及寻找或构建组件缓存解决方案,管理内存消耗,应用备忘录技术以及许多其他问题。通常,您要多次处理/重建同一应用程序-一次在客户端,一次在服务器。仅仅因为服务器渲染可以使某些事情更快地出现,并不意味着您要做的工作更少。

服务器渲染会为每个URL按需生成HTML,但比仅提供静态渲染内容要慢。如果您可以进行其他工作,则服务器渲染+ HTML缓存可以大大减少服务器渲染时间。服务器渲染的优势在于,与静态渲染相比,它能够提取更多的“实时”数据并响应更完整的请求集。需要个性化的页面是请求类型的一个具体示例,无法与静态渲染一起很好地工作。

参考链接

Google开发者大会对于前端渲染的介绍

文章分类
前端
文章标签