编程道路中遇到的不懂术语-SSR

SSR

1. 什么是SSR
2. SSR, SSG 与 CSR的区别，以及优缺点
3. 个人思考

1. 什么是SSR

SSR全称：Server Side Render
顾名思义，就是利用服务端性能从JSX渲染出html和js的技术。

以下是用户体验的一些指标

1. FP（First Paint）：浏览器页面第一次绘制像素所花的时间。

2. FCP （First Contentful Paint） 浏览器页面首次绘制文榜，图片，非空白Canvas 或 SVG的时间。

   补充： FP 指的是绘制像素，比如说页面的背景色是灰色的，那么在显示灰色背景时就记录下了 FP 指标。但是此时 DOM 内容还没开始绘制，可能需要文件下载、解析等过程，只有当 DOM 内容发生变化才会触发，比如说渲染出了一段文字，此时就会记录下 FCP 指标。因此说我们可以把这两个指标认为是和白屏时间相关的指标，所以肯定是最快越好。

   以下是官方推荐的时间区间，总之FP和FCP在2s内就是一个比较好的体验了。

   

3. LCP （Largest Contentful Paint），

• 用于记录视窗内最大的元素绘制时间，
• 该时间会随着页面渲染而变化。因为页面中的最大元素在渲染中会改变
• 用户第一次交互后停止记录该指标

补充： LCP 其实能比前两个指标更能体现一个页面的性能好坏程度，因为这个指标会持续更新。举个例子：当页面出现骨架屏或者 Loading 动画时 FCP 其实已经被记录下来了，但是此时用户希望看到的内容其实并未呈现，我们更想知道的是页面主要的内容是何时呈现出来的。

4. TTI （Time to Intertactive） 首次可交互时间

• 从FCP后开始计算
• 持续5s内无长任务（执行时间超过50ms），且无两个以上正在进行中的GET请求
• 满足记录条件时，往前回溯至5s，并从最后一个长任务结束时开始记录

疑问：为什么是长任务后50ms？

解答：
Google提出了一个RAIL模型， 如下

对于用户交互（比如点击事件），推荐的响应时间是 100ms 以内。那么为了达成这个目标，推荐在空闲时间里执行任务不超过 50ms（W3C 也有这样的标准规定），这样能在用户无感知的情况下响应用户的交互，否则就会造成延迟感。

为啥会要这个标准？

因此这是一个很重要的用户体验指标，代表着页面何时真正进入可用的状态。毕竟光内容渲染的快也不够，还要能迅速响应用户的交互。想必大家应该体验过某些网站，虽然内容渲染出来了，但是响应交互很卡顿，只能过一会才能流畅交互的情况。

5. FID （First Input Delay),记录在FCPTTI之间用户首次与页面交互时响应的时间延迟。（100ms内为优）

就是看用户交互事件触发到页面响应中间耗时多少，如果其中有长任务发生的话那么势必会造成响应时间变长。

6. TBT （Total Blocking Time） 记录在FCP到TTI之间所有长任务的阻塞时间总和

   假如说在 FCP 到 TTI 之间页面总共执行了以下长任务（执行时间大于 50ms）及短任务（执行时间低于
   50ms）

那么每个长任务的阻塞时间就等于它所执行的总时间减去 50ms

7. CLS （Cumulative Layout Shift） 记录了页面上”非预期“的位移波动

大家想必遇到过这类情况：页面渲染过程中突然插入一张巨大的图片或者说点击了某个按钮突然动态插入了一块内容等等相当影响用户体验的网站。这个指标就是为这种情况而生的，计算方式为：位移影响的面积 * 位移距离。

以上图为例，文本移动了 25% 的屏幕高度距离（位移距离），位移前后影响了 75% 的屏幕高度面积（位移影响的面积），那么 CLS 为 0.25 * 0.75 = 0.1875。

CLS 推荐值为低于 0.1，越低说明页面跳来跳去的情况就越少，用户体验越好。毕竟很少有人喜欢阅读或者交互过程中网页突然动态插入 DOM 的情况，比如说插入广告~

8. 如何优化

• 资源优化：

  • 压缩文件、使用 Tree-shaking 删除无用代码
  • 服务端配置 Gzip 进一步再压缩文件体积
  • 资源按需加载
  • 通过 Chrome DevTools 分析首屏不需要使用的 CSS 文件，以此来精简 CSS
  • 内联关键的 CSS 代码
  • 使用 CDN 加载资源及 dns-prefetch 预解析 DNS 的 IP 地址
  • 对资源使用 preconnect，以便预先进行IP 解析、TCP 握手、TLS 握手
  • 缓存文件，对首屏数据做离线缓存
  • 图片优化，包括：用 CSS 代替蹄片、裁剪适配屏幕的图片大小、小图使用 base64 或者 PNG 格式、支持 WebP 就尽量使用 WebP、渐进式加载图片

• 网络优化：

  • 该项措施可以帮助我们优化 FP、FCP、LCP 指标。

  • 这块内容大多可以让后端或者运维帮你去配置，升级至最新的网络协议通常能让你网站加载的更快。

  • 比如说使用 HTTP2.0 协议、TLS 1.3 协议或者直接拥抱 QUIC协议~

• 优化耗时任务：

  • 该项措施可以优化TTI，FID，TBT指标
  • 使用webWorker将耗时任务发配到其他线程中，从而不影响主线程的流畅度
  • 调度任务+时间切片，React16中的Fiber技术，类似携程。简单来说就是给不同的任务分配优先级，然后将一段长任务切片，这样能尽量保证任务只在浏览器的空闲时间中执行而不卡顿主线程

• 不动态的插入内容：

  • 该项措施可以帮助我们优化 CLS 指标。
  • 使用骨架skeleton给用户一个预期内容框架，突兀的显示内容用户体验不好
  • 一定要设置图片的长宽，并使用站位图给用户一个图片位置的预期。
  • 不要在现有的内容中间插入内容，起码给出一个预留位置

2. SSR, SSG 与 CSR的区别

• SSR

  • 优点：
    • 服务端渲染则是在服务端完成页面的渲染，在服务端完成页面模板、数据填充、页面渲染，然后将完整的HTML内容返回给到浏览器。由于所有的渲染工作都在服务端完成，因此网站的首屏时间和TTI（页面可交互的时间）都会表现比较好。

    

    • 服务接口请求的内部调用，远远优于CSR的请求方式
  • 缺点：
    • 渲染需要在服务端完成，并不能很好进行前后端职责分离
    • 而且白屏时间也会比较长
    • 同时，对于服务端的负载要求也会比较高
    • 一些常用的浏览器的API可能无法正常使用，比如window、document和alert等，如果使用的话需要对运行的环境加以判断

• SSG （Static Site Generation）

  • 空间换时间的一种策略，Google的搜索前15w条，淘宝的店铺展示…

  • Amstack SSGJamstack

    • (JAM代表 Javascript,API和 Markup)是一种使用 Static Site Generators(SSG)技术、不依赖 Web Server的前端架构。

    • 如果我们基于SSR的性能痛点继续思考解决方案,摆在面前的路无非两种：

      1. 种办法是可以通过流式SSR、组件级缓存、模板化、HTML缓存等技术来进一步优化
      2. 另一种办法是继续在渲染模式上探索,采用静态渲染( Static Rendering）

    • 而静态渲染的页面显然是缓存的究极形态。我们将生成HTML页面的工作放到编译时,而不必在请求带来时动态完成。为每个URL预先单独生成HTML文件。这样用户每次请求就不需

• CSR/BSR （client/browser Side Rendering）

  • 优点：前后端分离，MVVM
  • 缺点： 前后分离带来了CSR,同时带来了各种问题
    1. SEO,CSR首次加载的HTML文档没有内容,而目前大多数搜索引擎主要识别的内容还是HTML,对 Javascript文件内容的识别都还比较弱。
    2. Js代码量&首屏性能,CSR初始化页面会出现白屏,因为CSR的加载一般需要3个HTP生命周期:
       • 加载HTML文档->
       • 加载]S文件->
       • AP请求数据->
       • 根据数据渲染页面-> end

• 三者对比

个人思考：

• 未来前端的发展方向：
  未来可能是三者并用，但是这回对开发人员要求更高，需要更多的技术栈。所以之后的融合三方面的开发框架是个趋势，如何规定好三者的搭配形成规范，并对配置自动化，在不影响开发体验的情况下就可以实现三者的融合与部署。例如利用好打包工具区分三者的标签，如何规范化CI/CD的过程，如何统一后端中前端服务的架构…
• 挑战：
  1. react/vue的配合和升级
  2. CI/CD 与git配置的自动化流程
  3. 前端如何在后端扮演一份角色，不破坏前后分离的架构同时更好的提供前端服务