當(dāng)前幾種常見的前端性能優(yōu)化方案仍然不可避免地會存在一些缺點(diǎn)。本文在 ESI （Edge Side Include） 的基礎(chǔ)上，提出了一種新的優(yōu)化思路：邊緣流式渲染方案（ESR），即借助 CDN 的邊緣計(jì)算能力，將靜態(tài)內(nèi)容與動態(tài)內(nèi)容以流式的方式，先后返回給用戶。

背景

對于 web 頁面來說，首跳場景（例如 SEO、付費(fèi)引流）的性能普遍比二跳場景下要差。原因有多種，主要是首跳用戶在連接復(fù)用，和本地資源緩存利用方面，有很大的劣勢。首跳場景下，很多在端上的優(yōu)化手段（預(yù)加載，預(yù)執(zhí)行，預(yù)渲染等）無法實(shí)施。

在客戶端緩存能力無法利用的情況下，利用 cdn 距離用戶近的特性，可以結(jié)合緩存做一些性能優(yōu)化。

思路

思路 1：SSR

為了性能優(yōu)化考慮，我們一般都會通過服務(wù)端渲染（SSR） ，將首屏動態(tài)內(nèi)容直接服務(wù)端輸出。

這種方式的優(yōu)點(diǎn)是一次 html 返回即可包含頁面主體內(nèi)容，不需要瀏覽器二次請求接口后再用 js 渲染。但這種方式的缺點(diǎn)也比較明顯，對于距離服務(wù)端遠(yuǎn)，或者服務(wù)端處理時(shí)間較長的場景，用戶會看到較長時(shí)間的白屏。而且即使 html 返回完成了，用戶并不會立即看到內(nèi)容，頁面還需要加載前置的 js，css 等資源后，才能看到內(nèi)容。

思路 2：CSR + CDN

為了減少白屏?xí)r間，考慮利用 CDN 的邊緣緩存能力，可以把頁面 html 直接緩存在 cdn 節(jié)點(diǎn)上。但對于大部分場景來說，頁面的主體內(nèi)容都是動態(tài)，或者個(gè)性化的，把全部 html 內(nèi)容緩存在 cdn 上對于業(yè)務(wù)影響較大，很有少場景能接受。那么換個(gè)思路，只把 html 靜態(tài)部分緩存在 cdn 上呢？其實(shí)這個(gè)思路也是一個(gè)很常見的操作，即把 html 的靜態(tài)框架部分緩存在 cdn 上，讓用戶能快速看到部分內(nèi)容，然后再在客戶端發(fā)起異步請求，獲取動態(tài)內(nèi)容并且渲染（CSR）。CSR + CDN 模式下的渲染時(shí)序圖如下：

這種方式的優(yōu)點(diǎn)是頁面靜態(tài)框架緩存在 cdn 上，用戶可以快速看到頁面框架內(nèi)容，減少白屏等待焦慮。缺點(diǎn)是完整的頁面內(nèi)容需要再執(zhí)行 js ，拉取異步接口回來后再進(jìn)行渲染。最終有意義的動態(tài)內(nèi)容展示出來的時(shí)間，比 SSR 更晚。

思路 3：ESI

CSR + CDN 的方式，很好地解決了白屏?xí)r間問題，但帶來了動態(tài)內(nèi)容展示的延時(shí)。之所以有這個(gè)問題，是因?yàn)槲覀儼秧撁娴膭討B(tài)內(nèi)容和靜態(tài)內(nèi)容分割到了兩個(gè)階段中，并且是串行的，而且串行過程中還穿插了 js 的下載和執(zhí)行。有什么辦法把動態(tài)內(nèi)容和靜態(tài)內(nèi)容在 CDN 上整合起來呢？

ESI （Edge Side Include） 給了我們一個(gè)很好的思路啟發(fā)，ESI 最初也是 CDN 服務(wù)商們提出的規(guī)范，可通過 html 標(biāo)簽里加特定的動態(tài)標(biāo)簽，可讓頁面的靜態(tài)內(nèi)容緩存在 cdn 上，動態(tài)內(nèi)容可以自由組裝。ESI 的渲染時(shí)序圖如下：

這個(gè)方案看起來很美好，可以把靜態(tài)的部分緩存在 CDN 上了，動態(tài)部分在用戶請求時(shí)會動態(tài)請求和拼接。但最關(guān)鍵的問題在于，ESI 模式下，最終返回給用戶的首字節(jié)，還是要等到所有動態(tài)內(nèi)容在 CDN 上都獲取和拼接完成。也就是并沒有減少白屏?xí)r間，只是減少了 CDN 和服務(wù)器之間內(nèi)容傳輸?shù)捏w積，帶來的性能優(yōu)化收益很小。最終效果上與 SSR 區(qū)別不大。

雖然 ESI 的效果不符合我們預(yù)期，但給了我們很好的思考方向。如果能把 ESI 改造成可先返回靜態(tài)內(nèi)容，動態(tài)內(nèi)容在 CDN 節(jié)點(diǎn)獲取到之后，再返回給頁面，就可以保證白屏?xí)r間短并且動態(tài)內(nèi)容返回不推遲。如果要實(shí)現(xiàn)類似于流式 ESI 的效果，要求在 CDN 上能對請求進(jìn)行細(xì)粒度的操作，以及流式的返回。CDN 節(jié)點(diǎn)上支持這么復(fù)雜的操作嗎？答案是肯定的：邊緣計(jì)算。我們可以在 CDN 上做類似于瀏覽器的 service worker 的操作，可對請求和響應(yīng)做靈活的編程。

基于邊緣計(jì)算的能力，我們有了一種新的選擇：邊緣流式渲染方案（ESR）。方案詳情如下。

渲染流程

方案的核心思想是，借助邊緣計(jì)算的能力，將靜態(tài)內(nèi)容與動態(tài)內(nèi)容以流式的方式，先后返回給用戶。cdn 節(jié)點(diǎn)相比于 server，距離用戶更近，有著更短的網(wǎng)絡(luò)延時(shí)。在 cdn 節(jié)點(diǎn)上，將可緩存的頁面靜態(tài)部分，先快速返回給用戶，同時(shí)在 cdn 節(jié)點(diǎn)上發(fā)起動態(tài)部分內(nèi)容請求，并將動態(tài)內(nèi)容在靜態(tài)部分的響應(yīng)流后，繼續(xù)返回給用戶。最終頁面渲染的時(shí)序圖如下：

從上圖可以看出，cdn 邊緣節(jié)點(diǎn)可以很快地返回首字節(jié)和頁面靜態(tài)部分內(nèi)容，然后動態(tài)內(nèi)容由 cdn 發(fā)起向 server 起并流式返回給用戶。方案有以下特點(diǎn)：

首屏 ttfb 會很短，靜態(tài)內(nèi)容（例如頁面 Header 、基本結(jié)構(gòu)、骨骼圖）可以很快看到。

動態(tài)內(nèi)容是由 cdn 發(fā)起，相比于傳統(tǒng)瀏覽器渲染，發(fā)起時(shí)間更早，且不依賴瀏覽器上下載和執(zhí)行 js。理論上，最終 reponse 完結(jié)時(shí)間，與直接訪問服務(wù)器獲取完整動態(tài)頁面時(shí)間一致。

在靜態(tài)內(nèi)容返回后，已經(jīng)可以開始部分 html 的解析，以及 js， css 的下載和執(zhí)行。把一些阻塞頁面的操作提前進(jìn)行，等完整動態(tài)內(nèi)容流式返回后，可以更快地展示動態(tài)內(nèi)容。

邊緣節(jié)點(diǎn)與服務(wù)端之間的網(wǎng)絡(luò)，相比于客戶端與服務(wù)端之間的網(wǎng)絡(luò)，更有優(yōu)化空間。例如通過動態(tài)加速，以及 edge 與 server 之間的連接復(fù)用，能為動態(tài)請求減少 tcp 建連和網(wǎng)絡(luò)傳輸開銷。以做到最終動態(tài)內(nèi)容的返回時(shí)間，比 client 直接訪問 server 更快。

demo 對比

目前在 alicdn 上對主搜頁面做了一個(gè) demo （https://edge-routine.m.alibaba.com/）， 下面是在不同網(wǎng)絡(luò)（通過 charles 的 network throttle 配置限速）情況下，與原始頁面的加載對比：

不限速（wifi）

限速 4G

限速 3g

從上面結(jié)果可以看出，在網(wǎng)速越慢的情況下，通過 cdn 流式渲染的最終主要元素出來的時(shí)間比原始 ssr 的方式出來得越早。這與實(shí)際推論也符合，因?yàn)榫W(wǎng)絡(luò)越慢，靜態(tài)資源加載時(shí)間越慢，對應(yīng)的瀏覽器提前加載靜態(tài)資源帶來的效果也越明顯。另外，不管在什么網(wǎng)絡(luò)情況下，cdn 流式渲染方式的白屏?xí)r間要短很多。

整體架構(gòu)

架構(gòu)圖

邊緣流式渲染

1 模板

模板就是一個(gè)類似于包含 ESI 區(qū)塊的語法，基于模板，會將需要動態(tài)請求的內(nèi)容提取出來，把可以靜態(tài)返回的內(nèi)容分離出來并緩存起來。所以模板本質(zhì)上定義了頁面動態(tài)內(nèi)容和靜態(tài)內(nèi)容。

在流式渲染過程中，會從上到下解析頁面模板，如果是靜態(tài)內(nèi)容，直接返回給用戶，如果遇到動態(tài)內(nèi)容，會執(zhí)行動態(tài)內(nèi)容的 fetch 邏輯。整個(gè)過程中可能有靜態(tài)和動態(tài)內(nèi)容交替出現(xiàn)。

設(shè)計(jì)有以下幾種類型的模板。

1）原始 HTML

這種模板對現(xiàn)有業(yè)務(wù)的侵入性最小，只需要在現(xiàn)有的 SSR 頁面內(nèi)容里加上一定的標(biāo)簽，即可把頁面中動態(tài)部分申明出來：

《html》 《head》 《linkrel=“stylesheet”type=“text/css”href=“index.css”》 《scriptsrc=“index.js”》《/script》《metaname=“esr-version”content=“0.0.1”/》 《/head》 《body》 《div》staic content.。..《/div》 《scripttype=“esr/snippet/start”esr-id=“111”content=“SLICE”》《/script》 《div》dynamic content1.。..《/div》 《scripttype=“esr/snippet/end”》《/script》 《div》staic content.。..《/div》 《scripttype=“esr/snippet/start”esr-id=“222”content=“https://test.alibaba.com/snippet/222”》《/script》 《divid=“222”》 dynamic content2.。.. 《/div》 《scripttype=“esr/snippet/end”》《/script》 《/body》《/html》

2）靜態(tài)模板（暫時(shí)沒有關(guān)聯(lián)的實(shí)際場景）

這種模板需要單獨(dú)把模板發(fā)到 cdn 上（未來如果渲染層接入了 FASS 網(wǎng)關(guān)和 SSR ，在這塊可以和他們共用模板內(nèi)容，并且在工作流中發(fā)布模板時(shí)自動同步到 cdn 上一份，同時(shí)清空 cdn 上緩存）。動態(tài)的內(nèi)容有兩種渲染方式。一種是利用后端 SSR 出來的動態(tài) html 片斷，另一種是后端提供動態(tài)數(shù)據(jù)，由邊緣節(jié)進(jìn)行動態(tài)html片斷渲染。

使用 SSR 動態(tài) html 片斷的好處是，不需要在邊緣上做 html 模板渲染，并且不需要開發(fā)者寫兩套模板邏輯。缺點(diǎn)是需要后端有 SSR 能力，并且動態(tài)內(nèi)容傳輸體積較大。

使用邊緣節(jié)點(diǎn)渲染動態(tài) html 內(nèi)容的好處是，后端只需要提供動態(tài)數(shù)據(jù)，不需要 SSR 能力（但前端要有 CSR 的能力做降級兜底），并且傳輸?shù)膭討B(tài)內(nèi)容體積小。切點(diǎn)是邊緣節(jié)點(diǎn)上無法流式透傳動態(tài)內(nèi)容，需要等完整下載到邊緣節(jié)點(diǎn)上，處理后再返回給用戶。

《html》 《head》 《linkrel=“stylesheet”type=“text/css”href=“index.css”》 《scriptsrc=“index.js”》《/script》 《/head》 《body》 《div》staic content.。..《/div》 《scripttype=“esr/block”esr-id=“111”content=“https://test.alibaba.com/snippet/111”》《/script》 《div》staic content.。..《/div》 《scripttype=“esr/template”esr-id=“222”content=“https://test.alibaba.com/api/data”》 《div》 {$data.name} 《/div》 《/script》 《/body》《/html》

2 靜態(tài)內(nèi)容展現(xiàn)

靜態(tài)內(nèi)容來自于模板。對于不同模板類型，獲取靜態(tài)內(nèi)容的方式不一樣。對于 “原始 HTML” 類型的模板，靜態(tài)內(nèi)容會從首次動態(tài)請求返回的完整 HTML 中，根據(jù) html 注釋標(biāo)記提取出來，并存儲到 edge 緩存上。對于 “靜態(tài)模板”，會通過拉取 CDN 的的模板文件 ，并存儲到 edge 緩存上。靜態(tài)內(nèi)容有緩存過期時(shí)間和版本號。

模板一開始的靜態(tài)內(nèi)容會在響應(yīng)時(shí)直接返回給用戶。后續(xù)的靜態(tài)內(nèi)容（例如 html 和 body 的閉合標(biāo)簽）有兩種方式：

一種是等待動態(tài)內(nèi)容返回后，再寫到響應(yīng)流中。這種方式對 SEO 比較友好，但缺點(diǎn)是動態(tài)內(nèi)容會阻塞住后續(xù)靜態(tài)內(nèi)容，并且如果有多個(gè)動態(tài)內(nèi)容區(qū)塊的話，無法實(shí)現(xiàn)先返回的動態(tài)模板先展示，只能依次展示。

另一種方式是先把靜態(tài)內(nèi)容完全返回，然后動態(tài)內(nèi)容以類 bigpipe 的方式，通過腳本把內(nèi)容插入到對應(yīng)的坑位。這種方式的優(yōu)點(diǎn)是靜態(tài)內(nèi)容可以一開始就完整展示，且多個(gè)動態(tài)內(nèi)容可以先到先展示。缺點(diǎn)是對 SEO 不友好（因?yàn)閯討B(tài)內(nèi)容是能進(jìn) js 插進(jìn)去的）。

3 動態(tài)內(nèi)容

動態(tài)內(nèi)容是在渲染過程中，解析到需要動態(tài)獲取的區(qū)域，會在 edge 上發(fā)起動態(tài)內(nèi)容請求。動態(tài)內(nèi)容支持以動態(tài)加速的形式到達(dá)服務(wù)端（源站）。連續(xù)節(jié)點(diǎn)與后端的動態(tài)的內(nèi)容交互，分為三種方式：

第一種是后端動態(tài)內(nèi)容返回的是全量的頁面，需要通過注釋標(biāo)記來從內(nèi)容中提取。這種方式的優(yōu)點(diǎn)是對現(xiàn)有業(yè)務(wù)侵入較小，缺點(diǎn)是動態(tài)內(nèi)容傳輸體積大，并且需要下載完整 html 后再截取動態(tài)內(nèi)容。

第二種是后端動態(tài)內(nèi)容只返回動態(tài)區(qū)塊的內(nèi)容，這種方式的優(yōu)點(diǎn)是可以將動態(tài)響應(yīng)流式返回給用戶，缺點(diǎn)時(shí)需要頁面單獨(dú)對外提供一個(gè)只返回動態(tài)區(qū)塊內(nèi)容的 url。

第三種是后端動態(tài)內(nèi)容只返回?cái)?shù)據(jù)，配合靜態(tài)模板中的動態(tài)渲染模板，在邊緣節(jié)點(diǎn)上渲染出動態(tài) html 后返回給用戶。優(yōu)點(diǎn)是與后端傳輸數(shù)據(jù)量小，且不需要后端有 SSR 能力。缺點(diǎn)是需要開發(fā)者多維護(hù)一套模板邏輯，并且在邊緣節(jié)點(diǎn)上做復(fù)雜的模板渲染可能會有 cpu 開銷和限制。

用戶和邊緣節(jié)點(diǎn)的動態(tài)內(nèi)容交互，分為兩種形式：

瀑布流式（對應(yīng)路由配置里的 WATER_FALL ）： 動態(tài)內(nèi)容以瀑布流的形式依次返回。雖然在邊緣節(jié)點(diǎn)上多個(gè)動態(tài)內(nèi)容加載的操作是并行的，但對于用戶來說，會從上到下依次展示頁面內(nèi)容。這種方式優(yōu)點(diǎn)是對 SEO 友好，并且不影響頁面模塊的加載順序。缺點(diǎn)是多個(gè)動態(tài)模塊時(shí)，無法看到整體頁面的框架，首個(gè)動態(tài)塊的內(nèi)容會阻塞后續(xù)動態(tài)塊內(nèi)容的展示，且頁面底部的 js css 資源無法提前加載和執(zhí)行。

嵌入式（對應(yīng)路由配置里的 ASYNC_INSERT ）：靜態(tài)內(nèi)容一次性全部返回，其中動態(tài)部分內(nèi)容會先占一些坑位。后續(xù)動態(tài)內(nèi)容會以 innerHTML 的形式，插入到先前占的坑中。這種方式優(yōu)點(diǎn)是頁面底部的 js css 資源無法提前加載和執(zhí)行，并且頁面可以先看到一個(gè)全貌。缺點(diǎn)是對 SEO 不友好，且頁面模塊的執(zhí)行順序會根據(jù)動態(tài)塊返回速度有所變化，需要在瀏覽器端頁面邏輯里做一些判斷和兼容。

邊緣路由

路由配置：

https://g.alicdn.com/edgerender/config.json

{ version： ‘0.0.1’//配置版本號 origin： ‘us-proxy.alibaba.com’， host： ‘edge.alibaba.com’ pages： ［ { pageName： ‘seo’， //頁面名稱標(biāo)識 match： ‘/abc/efg/.*’， //頁面path匹配正則字符串 renderConf： { //渲染配置 renderType： ‘ESR’， //邊緣渲染 templateType： ‘FULL_HTML’， //模板類型：將SSR出的完整html作為模板 dynamicMode： ‘WATER_FALL|ASYNC_INSERT’， // 動態(tài)內(nèi)容append返回方式：瀑布流返回|異步填坑（innerHTML） templateUrl： ‘’// 模板url } }， { pageName： ‘seo’， match： ‘/abc/efg/.*’， renderConf： { renderType： ‘ESR’， templateType： ‘STATIC’， // 靜態(tài)模板，可通過cdn url獲取 dynamicMode： ‘WATER_FALL|ASYNC_INSERT’， // 動態(tài)內(nèi)容append返回方式：瀑布流返回|異步填坑（innerHTML） templateUrl： ‘https://g.alicdn.com/@g/xxx.html’ } }， { pageName： ‘jump’， match： ‘/jump/.*’， renderConf： { renderType： ‘REDIRECT_302’， // 302跳轉(zhuǎn) rewriteUrl： ‘https://jump’ } }， { pageName： ‘proxy’， match： ‘/proxy/.*’， renderConf： { renderType： ‘PROXY_PASS’， // 301跳轉(zhuǎn) rewriteUrl： ‘https://proxypassurl’ } } ］}

路由可以認(rèn)為是邊緣計(jì)算的一個(gè)入口，只有在路由配置中的頁面，才會走對應(yīng)的渲染流程。否則頁面會直接走回源，獲取頁面完整內(nèi)容。上面的 json 是目前設(shè)計(jì)的路由配置文件。配置文件最終會在一個(gè)靜態(tài)資源的方式，走覆蓋式發(fā)布發(fā)到 assets cdn 上。同時(shí)，為了支持配置發(fā)布灰度，線上會存在灰度版本和全量版本的兩個(gè)配置，在路由代碼里配置固定比例，加載灰度或者全量版本的配置。

目前在路由里設(shè)計(jì)了三種渲染模式，分別是流式渲染、重定向和反向代理。重定向和反向代理的配置比較簡單，與 nginx 配置類似，只需要提目標(biāo) url 即可。

穩(wěn)定性

影響范圍控制

CDN 開關(guān)：域名按區(qū)域、按比例切流，同時(shí)可隨時(shí)從 cdn 上把流量切回統(tǒng)一接入。

邊緣計(jì)算 SCOPE 開關(guān)：cdn 上配置邊緣計(jì)算覆蓋路徑，控制邊緣計(jì)算只運(yùn)行在部分路徑下。

邊緣計(jì)算路由開關(guān)：邊緣計(jì)算中通過讀取路由配置，控制只有部分頁面走流式渲染，否則請求直接走動態(tài)加速獲取完整頁面內(nèi)容。

異常處理

dns 開關(guān)，如出現(xiàn) cdn 嚴(yán)重問題，直接 dns 回切到統(tǒng)一接入。

如果邊緣計(jì)算基礎(chǔ)功能出現(xiàn)異常，在 cdn 配置平臺上關(guān)閉所有路徑的邊緣計(jì)算，走默認(rèn)的動態(tài)加速。

如果在進(jìn)了邊緣渲染，在沒有返回任何響應(yīng)內(nèi)容給客戶端前，就出現(xiàn)了錯(cuò)誤，捕獲錯(cuò)誤并降級到獲取完整頁面內(nèi)容。

如果進(jìn)了邊緣渲染，已經(jīng)返回了靜態(tài)部分的響應(yīng)給客戶端，然后在邊緣節(jié)點(diǎn)了加載動態(tài)內(nèi)容出了問題（超時(shí)、http 錯(cuò)誤碼、與靜態(tài)內(nèi)容版本號不匹配），返回一個(gè) location.reload（） 的 script 標(biāo)簽，并結(jié)束響應(yīng)，讓頁面強(qiáng)制刷新。刷新時(shí)可帶上 bypass 邊緣計(jì)算的 query 參數(shù)以保證刷新時(shí)不走邊緣渲染。

灰度

1）邊緣計(jì)算代碼灰度

本身平臺支持灰度發(fā)布邊緣計(jì)算代碼。

2）路由配置灰度

在邊緣計(jì)算代碼里，根據(jù)固定比例，加載灰度版本和正式版本的兩個(gè)配置 url?；叶劝l(fā)布時(shí)只發(fā)布灰度配置，全量發(fā)布時(shí)發(fā)布全量配置。發(fā)布的同時(shí)清空 cdn 緩存。

3）頁面內(nèi)容灰度

給灰度頁面一個(gè)特殊的模板版本號，遇到這個(gè)版本號的話，就不走邊緣渲染。

平滑發(fā)布

前后端分離的發(fā)模式下，有一個(gè)普遍存在的問題：平滑發(fā)布。當(dāng)頁面的靜態(tài)資源（js，css ）的發(fā)布，不是與后端一起發(fā)布時(shí)，可能引起后端返回的 HTML 內(nèi)容與前端的 js，css 內(nèi)容不匹配的問題。如果兩者之間的不匹配沒做兼容處理，可能會出現(xiàn)樣式錯(cuò)亂或者 document 選擇器找不到元素的問題。

解決平滑發(fā)布的一種方式是，在做前后端同時(shí)變更的需求時(shí)，在代碼上做兼容。這樣先后發(fā)布就不影響頁面可用性。

另一種方式是通過版本號。在后端頁面上手動配置版本號。當(dāng)有不兼容發(fā)布時(shí)，先發(fā)前端資源，然后后端手動修改版號，保證只有發(fā)布成功的后端機(jī)器， HTML 里引用的才是新版本的靜態(tài)資源。

平滑發(fā)布的問題其實(shí)在分批發(fā)布和 Beta 發(fā)布的場景一直存在。只是在 ESR 的場景，我們把靜態(tài)部分緩存在 cdn 上，會使前后端不一致的可能性更大。為了解決這個(gè)問題，需要對應(yīng)業(yè)務(wù)的開發(fā)者進(jìn)行發(fā)布時(shí)的風(fēng)險(xiǎn)識別。如果已經(jīng)做了兼容，可以不用做特殊處理。但如果沒有兼容，需要在修改頁面模板的版本號，新版本的動態(tài)內(nèi)容，在遇到版本號不匹配的靜態(tài)內(nèi)容時(shí)，會放棄本次流式渲染，保證頁面不出動態(tài)內(nèi)容和靜態(tài)內(nèi)容的兼容問題。

邊緣 cdn 服務(wù)商

目前各大 cdn 服務(wù)商對邊緣計(jì)算的支持情況如下：

alicdn

支持類 service worker 環(huán)境的邊緣計(jì)算，功能滿足需求。

海外節(jié)點(diǎn)目前還有限，部分區(qū)域性能可與akamai 對標(biāo)甚至超過，但有些域名性能因節(jié)點(diǎn)少的原因還是比 akamai 稍差。

akamai

只支持簡單的請求改寫計(jì)算，不滿足邊緣渲染的需求。

ESI 可以組裝動態(tài)和靜態(tài)內(nèi)容，但不支持流式，動態(tài)內(nèi)容會阻塞首屏。

海外節(jié)點(diǎn)多，在一些地區(qū)下相比于 alicdn 有性能優(yōu)勢。

cloudfare

支持類 service worker 環(huán)境的邊緣計(jì)算，功能滿足需求。

沒有使用經(jīng)驗(yàn)，如果要用的話可能流程比較復(fù)雜。

落地計(jì)劃

我們會在一個(gè)典型的首跳場景進(jìn)行實(shí)驗(yàn)。目前已經(jīng)在灰度上線，通過 webpagetest 在印尼測試進(jìn)方案和不進(jìn)方案的對比，可以看出優(yōu)化效果：

ttfb 減少 1s

白屏?xí)r間減少 1s

核心內(nèi)容展示時(shí)間減少 500ms
編輯：hfy