運用用戶端提示根據使用者進行調整

Jeremy Wagner

開發隨時隨地都能快速建立的網站，對潛在客戶來說可能不容易。彼索拉 裝置功能以及所連線網路的品質 而且做起來實在不可行。雖然我們可以 如何使用瀏覽器功能提高載入效能，我們如何知道 使用者的裝置效能或網路品質 連線？解決方案是用戶端 提示！

用戶端提示是一組可供選用的 HTTP 要求標頭，可讓我們深入瞭解 使用者裝置和連線網路的各種功能變更者： 即時入侵這項資訊，我們就能變更 根據裝置和/或網路條件顯示內容這有助於我們 更多元包容的使用者體驗

內容協商是關鍵

用戶端提示是另一種內容協商方法，也就是說 根據瀏覽器要求標頭產生內容回應

其中一個內容協商的範例就是 Accept敬上 要求標頭。用於說明瀏覽器可理解的內容類型； 伺服器就能用來交涉回應圖片要求 Chrome 的 Accept 標頭如下：

Accept: image/webp,image/apng,image/*,*/*;q=0.8

雖然所有瀏覽器都支援 JPEG、PNG 和 GIF 等圖片格式，但接受 在此情況下，瀏覽器也支援 WebP 和 APNG。我們可以利用這些資訊 協商最適合各種瀏覽器的圖片類型：

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

和 Accept 一樣，用戶端提示是協商內容的另一個管道， 以便掌握裝置功能和網路狀況的背景資訊透過用戶端提示 能根據使用者的 例如決定是否提供非關鍵資源 網路狀況不佳的使用者本指南將說明 可用的提示及一些運用方式 為使用者提供服務

啟用

與 Accept 標頭不同，用戶端提示不只會巧妙顯示 (透過 Save-Data 除外，我們稍後會說明)。為了保持 要求標頭時，請選擇要採用哪些用戶端提示 而希望在使用者要求Accept-CH 資源：

Accept-CH: Viewport-Width, Downlink

Accept-CH 的值是以半形逗號分隔的網站要求提示清單 會用來判斷後續資源要求的結果。當 用戶端讀取這個標頭後，系統將收到「這個網站想使用 Viewport-Width 和 Downlink 個客戶提示。」別害怕提示本身。 我們稍後就會提供協助。

您可以使用任何後端語言來設定這些選用標頭。例如 PHP 可以使用 header 函式。 甚至可以使用 http-equiv 屬性 對 <meta> 標記：

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

所有客戶提示！

「用戶端提示」描述了兩種狀態：使用者、「使用者」，和 以及目前用來存取您網站的網路以下簡單說明 畫面上會顯示一些提示

裝置提示

部分用戶端提示會描述使用者裝置的特性，通常是螢幕 部分工具可協助您 指定使用者螢幕，但不一定全都是以媒體為中心。

在進一步探討前，建議你先瞭解有哪些重要詞彙 描述螢幕和媒體解析度：

內建大小：媒體資源的實際尺寸。舉例來說 您在 Photoshop 中開啟圖片時，系統會在圖片大小對話方塊中顯示圖片大小 描述內在大小。

密度修正內建函式大小：媒體資源的尺寸 已經修正像素密度問題這是圖片的內建大小 除以裝置像素 比例。 以以下這個標記為例：

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

假設 1x 圖片的內建尺寸為 320x240， 「2x」圖片的內建大小為 640x480。如果用戶端剖析此標記 安裝在螢幕裝置像素比例為 2 (例如 Retina) 的裝置上 螢幕)，則需要 2x 圖片。密度修正的內建函式大小 2x 圖片的大小是 320x240，因為 640x480 除以 2 就是 320x240。

極端大小：CSS 和其他版面配置之後的媒體資源大小 因素 (例如 width 和 height 屬性) 已套用。我們來 假設您有一個 <img> 元素，會載入經過密度修正的圖片 內建尺寸為 320x240，但也提供 CSS width 和 height 屬性 並分別套用 256px 和 192px 的值在這個例子中 該 <img> 元素的外在大小會變成 256x192。

插圖：內建函式尺寸和 外部大小方塊中顯示一個大小為 320x240 像素的方塊，並標示「情報」標籤 SIZE。內含一個大小為 256x192 像素的小型方塊，代表 套用 CSS 的 HTML img 元素。這個盒子標有「EXTRINSIC」字樣 SIZE。右側是包含 CSS 至 元素的方塊 修改 img 元素的版面配置，讓外界大小 與內建函式的大小相關
圖 1.插圖：固體與 外部大小因為在版面配置因素造成的 圖片會獲得外部大小 。在本例中，會套用 width: 256px; 的 CSS 規則 ，height: 192px; 則轉換 320x240 內建大小圖片 擴展為 256x192 的極端尺寸

我們帶過一些術語後，接著來看看裝置專用的清單 可用的用戶端提示

可視區域寬度

Viewport-Width 是使用者的可視區域寬度 (以 CSS 像素為單位)：

Viewport-Width: 320

這個提示可搭配其他螢幕專屬提示，提供不同的 對特定螢幕大小呈現最佳的圖片處理方式 (例如裁剪) (例如， 方向)； 或省略目前畫面寬度不需要的資源。

DPR

DPR 是裝置像素比例的短，回報實體像素與 CSS 的比率 使用者螢幕的像素：

DPR: 2

當您要選取與畫面內容相對應的圖片來源時，這項提示就能派上用場 像素密度 (例如 srcset 中的 x 描述元是 屬性)。

寬度

要求圖片資源由 <img> 或 <img> 觸發時，會顯示 Width 提示 使用 sizes 的 <source> 標記 屬性。 sizes 會告知瀏覽器資源的外部大小； Width 會使用該極端大小來要求內建函式大小的圖片 呈現出最佳狀態

舉例來說，假設使用者要求頁面寬度為 320 CSS 像素的網頁 並將 DPR 設為 2。裝置會載入內含 <img> 元素的文件 sizes 屬性值為 85vw (例如佔所有可視區域寬度的 85% 螢幕大小)。如果已啟用 Width 提示，用戶端會傳送 此 Width 提示要向伺服器發出 <img> 的 src 要求：

Width: 544

在這種情況下，用戶端會提示伺服器 要求圖片的寬度為可視區域寬度的 85% (272 像素) 乘以螢幕的 DPR (2)，等於 544 像素。

這項提示功能特別實用，因為系統不但會將 與螢幕密度正確的寬度進行協調 圖片的外在大小資訊。如此一來 有機會協商出最適合兩者的圖片回應 在螢幕「和」版面配置中

內容 DPR

您已經知道螢幕具有裝置像素比例，但資源也會 也有各自的像素比例在最單純的資源選取用途中 裝置和資源之間的比率可能相同。不過，如果同時 DPR 和 Width 標頭正在執行中，資源的外部大小 兩種結果不同這是 Content-DPR 提示的位置 相關做法。

有別於其他用戶端提示，Content-DPR 並不是要求使用的 request 標頭 伺服器，而回應標頭伺服器，則必須在每次 DPR 與 Width 提示可用來選取資源。Content-DPR 的值應該 等於這個方程式的結果：

Content-DPR = [所選圖片資源大小] / ([Width] / [DPR])

傳送 Content-DPR 要求標頭時，瀏覽器會知道如何縮放 螢幕裝置像素比例和版面配置的指定圖片。如果沒有這項功能 圖片可能無法正確縮放

裝置記憶體

技術上來說是裝置記憶體的一部分 API，Device-Memory會顯示 大約 記憶體 目前裝置的 GiB：

Device-Memory: 2

這類提示的可能用途是減少 JavaScript 數量 傳送到記憶體有限的瀏覽器，因為 JavaScript 是 大量資源類型的瀏覽器 load。 或者，您可以傳送較低的 DPR 圖片，因為解碼時會使用較少的記憶體。

網路提示

Network Information API 提供 描述使用者網路效能的用戶端提示類別 以獲得最佳效能和最安全的連線我認為這些是最實用的提示組合，有了 Cookie 能夠藉由調整 Google Cloud 的供應方式 將資源提供給連線速度較慢的用戶端。

即時文字訊息

RTT 提示提供約略的「封包往返時間」(以毫秒為單位)， 應用程式層RTT 提示與傳輸層 RTT 不同，包含： 伺服器處理時間

RTT: 125

這個提示很實用，因為載入效能中扮演的角色會延遲。 利用 RTT 提示，我們就能根據網路回應、 加快整體體驗的推送速度 (例如 省略某些要求)。

儘管延遲是載入效能的重要關鍵，但頻寬固然重要 。Downlink 提示以每秒百萬位元 (Mbps) 表示， 使用者連線的「近」下游速度：

Downlink: 2.5

搭配 RTT 使用時，Downlink 可用於改變內容的方式 並根據網路連線品質向使用者提交內容。

ECT

ECT 提示代表「有效連線類型」。其值是 列舉連線類型清單，每個類型都說明連線 在 RTT 和 Downlink 的指定範圍內 值。

這個標頭並未說明「實際」連線類型， 舉例來說，裝置不會回報閘道為行動通信基地台或 Wi-Fi 連線 點。而是分析目前連線的延遲時間和頻寬 決定系統最相似的網路設定檔類型舉例來說，假設您 經由 Wi-Fi 連線速度較慢的網路，ECT 可能會填入 2g、 這會是離有效連線的近似值：

ECT: 2g

ECT 的有效值為 4g、3g、2g 和 slow-2g。這個提示的 做為評估連線品質的起點 運用 RTT 和 Downlink 提示進行修正

儲存資料

Save-Data 並非只提供使用者網路條件的提示 表示網頁傳送的資料應該較少。

我偏好將「Save-Data」歸類為網路提示，因為這樣 方法與其他網路提示類似使用者可能也 但可能會在高延遲/低頻寬環境中啟用這項功能這個提示 一律看起來會像這樣：

Save-Data: on

Google剛才談論了你可以運用的功能 Save-Data。 成效微乎其微。也就是使用者 其實有人要求你少一點東西！如果你仔細聆聽並採取行動 給予使用者良好的閱讀體驗

融會貫通、靈活運用

用戶端提示要採取的行動，則取決於您。因為這類產品 提供的方法有很多種為了協助你解決問題 用戶端提示可用來 Sconnie 虛構木材 公司位於中西部郊區像遠端的情況一樣 區域 網路連線相當脆弱。這時用戶端提示會派上用場 這些功能可以造福使用者

回應式圖片

然而，最單純的回應式圖片用途可能不容易。如果您 針對不同螢幕呈現同一張圖片提供多種處理方式「和」變化版本 尺寸，以及不同格式？這個標記十分複雜 迅速。 這可能造成錯誤，容易忘記或誤解重要內容 (例如 sizes)。

雖然 <picture> 和 srcset 是不可否認的優質工具，但 對複雜的用途進行開發和維護都相當耗時我們可以自動執行 標記生成功能，但這樣做也相當困難，因為這項功能 <picture> 和 srcset 十分複雜，具備自己的自動化需求 以維持現有作業的靈活性

客戶提示可以簡化這項工作。與客戶協商圖片回應 提示應如下所示：

  1. 如果適用於您的工作流程，請先選取圖片處理方式 (例如 藝術導向圖像)，只要查看 Viewport-Width 提示即可。
  2. 查看 Width 提示和 DPR 提示，選擇圖片解析度，以及 選擇符合圖片版面配置大小與螢幕密度的來源 (類似 x 和 w 描述元在 srcset 中的運作方式)。
  3. 選取瀏覽器支援的最佳檔案格式 (如 Accept) 通常適用於大多數的瀏覽器)。

我為一間虛構公司的客戶設計了一個陌生人 使用用戶端提示的 PHP 中的回應式圖片選取常式。這意味著 而不要傳送給所有使用者：

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

根據個別瀏覽器的支援情況，我能將問題縮減為下列事項：

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

本例中的 /image 網址為 PHP 指令碼，後面接有參數 重寫者 mod_rewrite 操作。這項服務 擷取圖片檔案名稱和其他參數，以便輔助後端指令碼 根據指定條件選擇最適合的圖片。

我理解「但這不只是在 <picture> 和 srcset 上 Back-end? 是你的第一題。

在某種程度上來說確實如此，但有一個重要差異：當應用程式使用 客戶如何撰寫媒體回應提示，不過如果工作非常繁瑣， 較易於自動化，這也包含能達成此目的的服務 (例如 CDN) 管理。使用 HTML 解決方案時，則需要將新的標記寫入 適用於各種用途當然，您可以自動產生標記。如果您的 但是隨著您的設計或需求改變 因此建議日後重新審視自動化策略。

用戶端提示能讓你一開始先以不失真、高解析度的做法開始著手 隨後由系統動態調整大小，成為最適用於「任何」組合的圖片 螢幕和版面配置的尺寸與 srcset 不同，您必須列舉固定值 可能供瀏覽器選擇的可能圖片清單，此方法 變得更加靈活srcset 會強制提供瀏覽器概略設定 變體 (例如 256w、512w、768w 和 1024w) 是用戶端提示 我們的解決方案可以在不大量標記的情況下提供所有寬度。

當然，您不必自行編寫圖片選取邏輯。雲朵 當您使用 w_auto 時，會根據用戶端提示生成圖片回應 參數、 觀察到，中位數使用者透過瀏覽器 輔助用戶端提示。

但請小心！我們已停止支援電腦版 Chrome 67 適用於跨來源用戶端 提示。 請放心，這些限制不會影響 Chrome 行動版。 使用這些功能時，這些資源適用於所有平台功能 政策填寫完畢。

協助使用者連線速度緩慢的網路

適應性效能：我們可以調整提供資源的方式 做出選擇具體來說 與使用者網路連線目前狀態的相關資訊。

針對 Sconnie Timber 的網站，我們會採取相應措施來減輕 網路速度緩慢，Save-Data、ECT、RTT 和 Downlink 標頭 已修復在後端程式碼完成這項作業後，系統會產生網路品質 我們可以使用分數來判斷是否該介入 無須專人管理這個網路分數介於 0 至 1 之間，其中 0 為最差 網路品質最佳，1 是最佳選擇。

一開始，我們會檢查 Save-Data 是否存在。如果是，分數會設為 0，因為我們假設使用者希望我們能執行必要動作， 並享受更快速流暢的使用體驗

但是，如果缺少 Save-Data，我們會繼續衡量 ECT 的值。 RTT 和 Downlink 提示：計算描述網路的分數 連線品質網路分數產生來源 程式碼 您可以在 GitHub 取得。重點是，如果我們在 更是如此

未使用用戶端的網站比較 提示對網路連線緩慢 (左側) 和使用需要 (右)。
圖 2：在地服務的「關於我們」頁面 商家網站。基本體驗包括網路字型、可強化 輪轉介面和輔助行為，以及內容圖片。這些都代表了 當網路狀況太慢而無法載入時就可以省略

網站會根據用戶端提示提供的資訊進行調整時，我們不必採用 採用「完全或完全不」的做法我們就能聰明地決定要在哪些資源中 傳送。我們可以修改回應式圖片選取邏輯，傳送較低的畫質 網路品質時，特定螢幕的圖像以加速載入效能 不好。

在這個例子中，可以看到用戶端提示 改善網路速度較慢的網站效能。以下是 WebPagetest 網站速度較慢，且無法配合用戶端提示而調整網站的刊登序列：

Sconnie 的 WebPagetest 瀑布 網路速度較慢時載入所有資源。
圖 3：資源耗用大量資源 即使連線速度緩慢，腳本和字型也會變慢。

現在連線速度緩慢，在同一個網站的刊登序列 時，網站會使用用戶端提示來排除非關鍵的網頁資源：

Sconnie 的 WebPagetest 瀑布 使用用戶端提示，決定不在 網路連線速度過慢。
圖 4：使用同一個連線 只排除「可有可無」的資源，且資源更快 載入。

用戶端提示可將網頁載入時間從 45 秒以上縮短為不到 第 10 次。在這個情境中，客戶提示的益處 能對尋求 提供高於網路速度的資訊

此外，您也可以在不影響體驗的情況下使用用戶端提示。 不支援這些瀏覽器舉例來說，如果要調整資源 發出 ECT 提示的價值，同時確保 對於不支援瀏覽器的使用者，我們可以改回使用預設值 如下所示：

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

此處的 "4g" 代表 ECT 標頭最高品質的網路連線 說明如果我們將 $ect 初始化為 "4g"，表示瀏覽器不支援用戶端 提示不會受到影響選擇加入 FTW！

請留意這些快取！

每當您根據 HTTP 標頭變更回應時，請務必留意 快取會如何處理該資源日後的擷取作業Vary title 是 因為這會將項目快取到要求標頭的值中，所以這是必要的。 任何訓練資料簡單來說，如果您根據特定的 HTTP 要求標頭，通常應一律在 Vary 中加入該標頭的要求 如下所示：

Vary: DPR, Width

不過，這是大型的注意事項：你絕對不會希望 Vary 能快取 接收經常變更標頭 (例如 Cookie) 的回應，因為 實際上也無法快取資源因此，您應該避免 在用戶端提示標頭 (例如 RTT 或 Downlink) 上執行 Vary，因為這些標頭 也可能出現經常變化的因素如要修改 建議您只將 ECT 標頭繫結至這些標頭，這樣就會 盡可能減少在快取中找不到所需資料的情況

當然，這只適用於一開始快取回應的情況。 舉例來說，如果 HTML 素材資源的內容是動態，您就不需要快取 HTML 素材資源，因為 但對於重複造訪的使用者體驗有中斷在這種情況下，請 可以視需要修改這些回覆 關於「Vary」的疑慮。

Service Worker 中的用戶端提示

內容協商不再僅限於伺服器！Service Worker 會執行 就像用戶端和伺服器之間的 Proxy 一樣，您可以控制 會透過 JavaScript 傳送包括用戶端提示。在 Service Worker 中 fetch 事件，您可以使用 event 物件的 request.headers.get敬上 方法來讀取資源要求標頭的方法，如下所示：

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

您選擇啟用的任何用戶端提示標題都能以這種方式閱讀。不過 而不是取得這類資訊的唯一方式網路專屬提示 以下程式碼可在 navigator 物件中讀取這些對等的 JavaScript 屬性：

客戶提示 JS 對等項目
「ECT」 `navigator.connection.effectiveType`
「RTT」 `navigator.connection.rtt`
「儲存資料」 `navigator.connection.saveData`
「向下連結」 `navigator.connection.downlink`
裝置記憶體 `navigator.deviceMemory`
適用於檔案類型的 Imagemin 外掛程式。

這些 API 並非在任何需要進行的功能檢查時提供 in 運算子：

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

您可以在這裡使用與您在伺服器中使用的邏輯類似，除了 也不需要透過用戶端提示來交涉內容。服務 單靠員工就能提升體驗速度與韌性 享有額外功能，可在使用者離線時提供內容。

設定程序即將完成

透過用戶端提示，我們得以為 。我們可以根據使用者的裝置放送媒體 功能，讓顯示回應式圖片更容易 特別是 <picture> 和 srcset，特別是複雜的用途。這讓我們 以減少開發方面的時間和精力 藉由鎖定使用者的螢幕 比 和 srcset 更好。

更重要的是，我們可以篩選網路連線品質不佳和橋接器 修改我們傳送的內容及傳送方式後，資料將出現落差。這可以 ，長讓網路連線不穩的使用者輕鬆存取網站。 透過與服務工作人員相結合，我們打造出速度飛快的網站，且執行速度非常快 以及離線使用

用戶端提示僅適用於 Chrome 和 Chromium 式 但使用者可以在不費力的情況下使用 不支援這些瀏覽器考慮使用用戶端提示 多元包容且容易調整的使用體驗，引入每位使用者的裝置 和連線的網路希望其他瀏覽器供應商 會看到這些元素的價值 以及要實作的意圖

資源

謝謝 Ilya Grigorik 和 Eric Portis、Jeff Posnick、Yoav Weiss 及 Estelle Weyl 管理 這篇評論包含寶貴意見和編輯內容。