Please enable JavaScript.
Coggle requires JavaScript to display documents.
前端渲染 - Coggle Diagram
前端渲染
渲染模式
CSR（Client-side rendering）
主要缺陷在于随着应用程序的更新迭代，客户端所要执行 JS 代码量越来越多，前置的第三方类库/框架、polyfill 等都会在一定程度上拖慢首屏性能，在（中低端）移动设备上尤为明显
Code splitting、lazy-load等优化措施能够缓解一部分
指用 JS 直接在浏览器里渲染页面，包括数据请求、视图模板、路由在内的所有逻辑都在客户端处理
SSR（Server-Side Rendering）
以服务端渲染为主（JSP、PHP），在服务端生成完整的 HTML 页面
省去了客户端二次请求数据的网络开销，以及渲染视图模板的性能负担
在服务器上生成页面同样需要时间，会导致页面内容响应时间（TTFB, Time to First Byte）变慢
一种办法是可以通过流式 SSR、组件级缓存、模板化、HTML 缓存等技术来进一步优化
一种办法是继续在渲染模式上探索，采用静态渲染（Static Rendering）
因为页面逻辑（包括即时数据请求）和模板渲染工作都放在服务端完成，减少了客户端的 JS 代码量，流式文档解析（streaming document parsing）等浏览器优化机制也能发挥其作用，在低端设备和弱网情况下表现更好
Static Rendering
将生成 HTML 页面的工作放到编译时，而不必在请求带来时动态完成
为每个 URL 预先单独生成 HTML 文件，并进一步借助CDN加速访问
关键问题在于“静态”
需要为每个 URL 单独生成一份 HTML 文件：对于无法预知所有可能的 URL，或者存在大量不同页面的网站，静态渲染就不那么容易，甚至根本不可行
只适用于偏静态内容：对于动态的、个性化的内容作用不大
预渲染（Prerendering）
预渲染必须经客户端渲染才真正可交互
静态渲染得到的页面已经是可交互的，无需在客户端额外执行大量 JS 代码
Rehydration
将 CSR 与 SSR 结合
服务端渲染出基本内容后，在客户端进行二次渲染（Rehydration）
这种模式下，FP（First Paint）虽然有所提升，但 TTI（Time To Interactive）可能会变慢
在客户端二次渲染完成之前，页面无法响应用户输入（被 JS 代码执行阻塞了）
可能的优化方向是增量渲染（例如React Fiber），以及渐进式渲染/部分渲染
Trisomorphic Rendering
SSR + CSR + ServiceWorker rendering
首先通过流式 SSR 渲染初始页面，接着由 Service Worker 根据路由规则，借助 SSR 渲染出目标 HTML 页面
主要优势在于能够跨三方共享模板渲染和路由控制逻辑
性能指标
FCP（First Contentful Paint）：用户所请求的内容在屏幕上可见的时间点
TTI（Time To Interactive）：页面可交互的时间点
