網(wǎng)頁的性能，大部分情況下是影響用戶使用體驗的第一要素，特別是對于很多電商、金融網(wǎng)站，可能幾秒的性能提升就意味著更大的轉化率和收益。

所以優(yōu)化網(wǎng)頁的性能，一直是前端工程師最熱衷的工作之一。今天我們來看看 Google 提出的一種新的性能優(yōu)化方案，現(xiàn)在已經(jīng)在 Google Search 中得到了實踐。

什么影響了 LCP？

在之前的文章中，我介紹了 Google 新提出的 Core Web Vitals，其中包括了 LCP、FID、CLS 三大指標。

Core Web Vitals

Largest Contentful Paint (LCP)(最大內容渲染)，又是其中最重要的指標。這個指標很好理解，也就是一個網(wǎng)頁當前視口中可見的最大元素的渲染時間。為了良好的用戶體驗，這個時間應該盡量控制在 2.5S 之內。

那么有哪些因素會影響網(wǎng)頁的 LCP 呢？

當用戶訪問網(wǎng)頁時，瀏覽器從服務器請求 HTML。服務器返回 HTML 響應，然后 HTML 會告訴瀏覽器下一步的工作，包括請求 CSS、JavaScript、字體和圖像等資源。這些資源返回后嗎，瀏覽器還會做一些其他的評估工作，最終在頁面上進行布局和渲染。

實際上，大部分時間都花費在了從瀏覽器到服務器之間的傳輸上了。根據(jù) Google Chrome 的統(tǒng)計顯示，網(wǎng)頁大約 40% 的可見延遲都花費在瀏覽器等待服務器返回的第一個字節(jié)上了。

數(shù)據(jù)預取

那么， 如果可以預取網(wǎng)頁上所需的資源文件，也就是在用戶訪問這些頁面之前就獲取它們，這將給網(wǎng)頁帶來巨大的性能提升。

數(shù)據(jù)預取后，網(wǎng)頁在可以正常顯示之前只剩下了評估、布局和渲染工作了。

數(shù)據(jù)預取

實際上，我們一些常見的性能優(yōu)化的手段：

• rel="dns-prefetch"：向瀏覽器聲明在接下來的頁面中即將用到某個域名下的資源，要求瀏覽器盡可能早的提前發(fā)起對該域名的 dns 解析操作。
• rel="preconnet"：告訴瀏覽器頁面即將使用某域名下的資源，可以讓瀏覽器提前建立網(wǎng)絡連接，在頁面真正發(fā)起資源請求時，會使用已經(jīng)建立的網(wǎng)絡連接，直接跳過這些耗時建連操作。

這些都屬于數(shù)據(jù)預取的措施，我們可以做到預取一些我們當前站點的主要資源。

在同站的情況下，這些手段很容易實施，但是對于跨站的常見，就不那么簡單了。

跨站數(shù)據(jù)預取

什么是跨站的場景的數(shù)據(jù)預取呢呢，比如我們當前的網(wǎng)站只是個導航，或者搜索引擎，大部分情況下我們不會在當前的網(wǎng)站停留太久，而是從當前網(wǎng)站跳到其他網(wǎng)站上去，比如 Google Search：

我們當前的網(wǎng)站的性能優(yōu)化已經(jīng)做的很好了，現(xiàn)在我們要考慮的是怎么讓這些跨站的第三方站點也能快速打開。

把所有可以打開的第三方網(wǎng)站的數(shù)據(jù)都提前下載一遍?這當然可以讓用戶打開這些頁面的時候更快一點，但我們還要考慮一些其他的因素：

• 用戶不一定會點擊這些鏈接，那我們提前預取的數(shù)據(jù)不就屬于資源浪費了嗎？
• 這些網(wǎng)站如果攜帶用戶的 IP 地址或者 Cookie 怎么辦?不會對用戶隱私造成威脅嗎？

私有預取代理方案

為了實現(xiàn)更安全隱私的數(shù)據(jù)預取，Google 提出了一種新的數(shù)據(jù)預取方案：Private prefetch proxy(私有預取代理)，Google Search 已經(jīng)實施了這項方案，導航的 LCP 預計有 20%-30% 的提升！

安全的通信

私有預取代理方案使用 CONNECT 代理在 Chrome 和存儲了要預取內容的服務器之間建立安全通信通道。

這個安全通信通道可以防止任何 Proxy 從中間抓取任何數(shù)據(jù)傳輸。另外，雖然私有預取代理必須看到主機名才能建立安全的通信通道，但它隱藏了完整的請求 URL，也看不到資源本身。

此外，由于安全通信通道是端到端加密的， 一些代理或者中介既不能抓取到主機名稱，也不能抓取到預取站點的內容。代理本身也會阻止目標服務器查看用戶的 IP 地址。

防止用戶識別

除了前面詳述的網(wǎng)絡安全方面，私有預取代理還可以防止服務器在預取時通過先前存儲在其設備上的信息來識別用戶。目前，Chrome 會限制只有用戶沒有 Cookie 或其他本地狀態(tài)的網(wǎng)站才能使用私有預取代理方案。以下是通過 Private Prefetch Proxy 發(fā)出的預取請求的限制：

(1) Cookies：預取請求不允許攜帶 Cookies。

• 如果資源有 Cookie，Chrome 只會發(fā)送不帶 Cookie 的請求，也不會使用響應內容。
• 對預取請求的響應中可以包含 Cookie，但只有在用戶跳轉到預取頁面時才會在瀏覽器保存這些 Cookie。

(2) 指紋識別：其他可用于指紋識別的數(shù)據(jù)(例如 User-Agent)也進行了調整。Prefetch Proxy 發(fā)送的 Header 只攜帶有限的信息。

Google 也正在計劃將 Private Prefetch Proxy 擴展到帶有 Cookie 的網(wǎng)站，同時利用一些其他的方案來保障用戶隱私。

緩存

即使資源已經(jīng)在緩存中了，Chrome 也會預取資源，但它們不會攜帶任何條件請求頭，例如 ETag 或 If-Modified-Since(這些 Header 中包含服務器設置的值，即使沒有 Cookie 也可用于用戶跟蹤)。進行這樣的預取措施是為了防止將客戶端的緩存狀態(tài)泄漏到預取的網(wǎng)站。此外，如果用戶決定跳轉到已經(jīng)預取的網(wǎng)站，Chrome 只會將預取的資源提交到緩存中。

開始使用私有預取代理

對于需要數(shù)據(jù)預取的網(wǎng)站

對于大部分普通站點，我們希望在其他網(wǎng)站導航到我們網(wǎng)站的時候更快。

目前 Private Prefetch Proxy 還處于眾測階段，想要提前體驗的話需要在服務器部署一份 traffic-advice 配置：

[{
  "user_agent": "prefetch-proxy",
  "google_prefetch_proxy_eap": {
    "fraction": 1.0
  }
}]

• google_prefetch_proxy_eap 選項可以讓我們的網(wǎng)站加入數(shù)據(jù)預取代理。
• fraction 字段可以控制私有預取代理的流量百分比。

這個配置應該放在我們服務器的 /.well-known/ 路徑下，(即 /.well-known/traffic-advice )。

對于導航網(wǎng)站

對于像 Google 這樣的導航網(wǎng)站，我們需要用戶在我們的網(wǎng)站打開其他網(wǎng)站的時候更快，我們可以在頁面上增加下面的配置，這可以讓 Chrome 知道應該通過數(shù)據(jù)預取代理提取哪個頁面：

<script type="speculationrules">
{
  "prefetch": [
    "source": "list",
    "urls": ["https://conardli.top/blog"],
    "requires": ["anonymous-client-ip-when-cross-origin"]
  ]
}
</script>

這里需要注意的是，增加了數(shù)據(jù)預取意味著，即使在沒有用戶實際請求的情況下也會給我們網(wǎng)站增加額外的流量。

這可能需要具體的網(wǎng)站負責人具體評估，如果覺得額外浪費一些流量換取更好的用戶體驗是值得的，那就沒問題。

但是我們也可以通過一些措施來環(huán)節(jié)一些，比如限制瀏覽器只預取相對關鍵的資源(例如 Script、CSS 等)，本質上就是網(wǎng)頁性能和額外流量之前的權衡。

另外，我們也可以為網(wǎng)站添加一些推薦規(guī)則，讓瀏覽器可以自己推斷用戶可能會訪問的頁面。