原文链接：边缘渲染如何提升前端性能？前端渲染的发展在谈ESR（EdgeSideRendering，边缘渲染）如何加速渲染之前，我们需要先了解一下前端渲染的发展历史，以及前端性能指标的优化是如何放在agenda，然后我们再回头看看ESR的出现，会发现它也是水到渠成的事情。其实整个前端的渲染方式是随着前端技术的演进而不断创新的，大致可以分为以下几个过程。SSR（ServerSideRendering）时代最早的前端渲染（2005年Ajax推出之前）（JSP、PHP）是和后端混合的，比如JSP、PHP等，但是混合写法前后端方式不同导致开发效率低下。比如改了个样式，又要重新编译，页面就会写得很重。在CSR（ClientSideRendering）时代的Ajax技术之后，加上通过CDN对静态资源进行缓存，前端SPA+CSR渲染得到了突飞猛进的发展。这种模式前端处理所有的逻辑，内容填充和路由，数据加载部分通过Ajax从后端获取，所以解决了前后端分工开发的问题。具体的请求时间线可以看下图。但是由于请求是全异步的，一是不利于SEO，二是需要HTML+JS处理数据拼接才能在前端完成渲染，首屏白屏时间会比较长，尤其是在一些低端机型上。更让人担忧的是SSR时代（Node）。后来随着以Node为首的全栈技术的发展，前端又回到了原来的SSR之路，只不过这次的回归是螺旋上升的。首先是前后端都是JS语法，大部分代码是可复用的。其次，SEO场景很友好。服务端渲染后直接返回最终的HTML，减少了白屏的等待时间，减少了异步请求过多导致的。性能问题也可以在服务器端解决，可以有效避免多次数据获取和内容填充。浏览器只需要绑定相关的JS逻辑和事件即可。具体的请求时间线可以看下图。随着ESR（EdgeSideRendering）时代边缘计算的发展，由于CDN节点距离用户更近，网络延迟更短的优势，我们可以将页面拆分为静态页面和动态页面，将静态内容缓存在CDN中并返回它快速的给用户，然后在CDN节点发起对动态内容的请求，然后将动态内容和静态部分以流的形式进行拼接，从而进一步提升用户首屏的加载时间，尤其是在边缘地区或薄弱的网络环境。很好的用户体验，另外还能减轻原有SSR服务器的压力。原理和优势刚才提到，ESR利用边缘计算能力，将返回的内容拆分成静态和动态两部分，以流的形式返回。依靠CDN的缓存能力，先将静态部分返回给用户，然后在CDN节点上不断发起动态数据请求，在静态部分之后进行拼接，继续回流。因此，它的优势也很明显：TTFB（TimeToFirstByte）很短：因为静态内容缓存在CDN中，很快就会返回给用户。FP（FirstPaint）很短：因为静态内容返回后，HTML的解析和JS、CSS的下载和执行就已经可以开始了。FMP（FirstMeaningfulPaint）很短：因为动态内容的请求是在CDN发起的，相比客户端和服务端的直接连接，请求减少了TCP连接建立和网络传输的开销，并且因为动态部分以分块形式流式传输如果公式返回，FMP将非常短，例如搜索网站的第一个搜索结果将首先绘制。应用场景示例场景一：直接在边缘节点部署SSR服务，中心服务提供数据接口直接将SSR服务移到边缘部署。具体过程如下图所示。场景二：边缘服务读取HTML缓存的静态部分，中心服务提供动态HTML。中心部署SSR服务，边缘流返回HTML内容（使用HTTPTransfer-Encoding:chunked传输机制）。有必要将静态和动态部分分开。具体过程如下图所示。边缘服务：请求静态HTML并返回，同时请求中心SSR服务，获取动态内容并返回SSR服务：去除静态HTML，将动态部分返回给边缘服务例如，以一个演示网站为举个例子，顶部导航可以看作是静态部分的缓存在边缘CDN中，下面的卡片是动态部分回源从中心服务获取数据。通过demo对比，可以发现ESR相比SSR有明显的优势。它的静态topguide是先绘制出来的，后面的动态数据也比SSR更快的返回。另外，结合下面的埋点统计，进一步印证了ESR的优势。结论与展望技术实现：ESR适用于页面渲染性能高的场景。在SSR的基础上借助边缘计算，进一步优化首屏绘制时间，减少用户页面白屏等待时间。部署方式：目前的实现方式主要是借助边缘faas部署ESR服务，具有接入速度快、弹性伸缩、运维成本低等优点；后期提供ER（edgejsruntime）部署，用户无需关心边缘节点，只需要关注代码本身，修改代码上传发布即可。与节点服务相比，js运行时可以提供更高的运行效率。技术展望：ESR目前是在SSR的基础上，结合边缘计算提升性能。未来我们会在Jamstack中结合ER和CDN的能力进行更多方向的探索，感兴趣的同学敬请期待
