我以 50 MB 的預算使用了一天的網絡

這篇文章是我嘗試在各種限制下使用網絡的系列文章的一部分，代表給定的用戶群體。 我希望提高真實人們面臨的困難的形象，如果我們以一種同情他們需求的方式進行設計和開發，這些困難是可以避免的。

上次，我使用 Internet Explorer 8 瀏覽了一天的網頁。這次，我以 50 MB 的預算瀏覽了一天的網頁。

為什麼是 50 MB？

我們中的許多人都很幸運能夠使用每月允許數 GB 數據傳輸的移動計劃。 如果做不到這一點，我們通常能夠連接到高速寬帶連接上的家庭或公共 WiFi 網絡，並且有效地擁有無限數據。

但在世界上有些地方，移動數據非常昂貴，而且寬帶基礎設施很少或根本沒有。

人們通常一次只購買數十兆字節的數據包，這使得千兆字節成為相對較大且因此購買昂貴的數據量。
——Cable.co.uk 的消費電信分析師 Dan Howdle

我們說的到底有多貴？

移動數據的成本

cable.co.uk 2018 年的一項研究發現，津巴布韋是世界上移動數據成本最高的國家，1 GB 的平均成本為 75.20 美元，從 12.50 美元到 138.46 美元不等。 價格的巨大範圍是由於少量數據非常昂貴，您承諾的數據計劃越大，價格就越便宜。 您可以閱讀研究方法以獲取更多信息。

津巴布韋絕不是一次性的。 赤道幾內亞、聖赫勒拿和福克蘭群島緊隨其後，1 GB 的數據成本分別為 65.83 美元、55.47 美元和 47.39 美元。 這些國家/地區的技術基礎設施通常較差，採用率較低，這意味著數據的交付成本很高，而且沒有規模經濟來降低成本。

歐洲部分地區的數據也很昂貴。 希臘一千兆字節的數據將花費您 32.71 美元； 在瑞士，20.22 美元。 相比之下，相同數量的數據在英國的成本為 6.66 美元，在美國為 12.37 美元。 另一方面，印度是世界上數據最便宜的地方，平均成本為 0.26 美元。 吉爾吉斯斯坦、哈薩克斯坦和烏克蘭緊隨其後，分別為每 GB 0.27 美元、0.49 美元和 0.51 美元。

移動網絡的速度也因國家而異。 也許令人驚訝的是，在全球至少 30 個國家，包括澳大利亞和法國，用戶通過移動網絡體驗到比 WiFi 更快的速度。 韓國的移動下載速度最快，平均為 52.4 Mbps，但伊拉克最慢，平均下載速度為 1.6 Mbps，上傳速度為 0.7 Mbps。 美國在移動下載速度方面排名世界第 40 位，約為 34 Mbps，隨著世界向 5G 邁進，美國有進一步落後的風險。

在移動網絡連接類型方面，英國 84.7% 的用戶連接使用 4G，而美國為 93%，韓國為 97.5%。 相比之下，烏茲別克斯坦不到 50%，阿爾及利亞、厄瓜多爾、尼泊爾和伊拉克不到 60%。

寬帶數據的成本

與此同時，一項對 2018 年寬帶成本的研究表明，尼日爾的寬帶連接“每月每兆比特”成本為 263 美元。 這個指標有點難以理解，所以舉個例子：如果一個國家寬帶套餐的平均成本是 22 美元，而套餐提供的平均下載速度是 10 Mbps，那麼“每月每兆比特”的成本將是為 2.20 美元。

這是一個有趣的指標，承認寬帶速度與數據上限一樣重要。 263 美元的成本表明寬帶速度極慢且成本極高。 作為參考，該指標在英國為 1.19 美元，在美國為 1.26 美元。

也許更容易理解的是寬帶套餐的平均成本。 請注意，這項研究正在尋找最便宜的寬帶套餐，忽略這些套餐是否有數據上限，因此提供了一個有用的大致數字，而不是數據本身的成本。

僅就套餐成本而言，毛里塔尼亞擁有世界上最昂貴的寬帶，平均為 768.16 美元（範圍為 307.26 美元至 1,368.72 美元）。 這筆巨大的成本包括為該物業建造物理線路，因為毛里塔尼亞已經很少有線路了。 毛里塔尼亞的寬帶網絡速度為 0.7 Mbps，也是世界上最慢的寬帶網絡之一。

台灣擁有世界上最快的寬帶，平均速度為 85 Mbps。 也門的速度最慢，為 0.38 Mbps。 但即使是擁有完善的寬帶基礎設施的國家也有所謂的“非熱點”。 英國的寬帶速度在 207 個國家中排名第 34 位，但 2019 年 7 月，英國仍有一所學校沒有寬帶。

英國寬帶套餐的平均成本為 39.58 美元，美國為 67.69 美元。 世界上最便宜的平均價格是烏克蘭的，僅為 5 美元，儘管其中最便宜的寬帶交易是在吉爾吉斯斯坦（1.27 美元，而全國平均水平為 108.22 美元）。

津巴布韋是移動數據成本最高的國家，其寬帶數據也好不到哪裡去，平均成本為 128.71 美元，“每月每兆位”成本為 6.89 美元。

絕對成本與實際成本

根據研究時的匯率，到目前為止列出的所有成本都是以美元計的絕對成本。 這些成本尚未計入生活成本，這意味著對於許多國家而言，實際成本實際上要高得多。

我將今天的瀏覽限制為 50 MB，在津巴布韋，移動數據資費約為 3.67 美元。 這聽起來可能不多，但津巴布韋的教師今年正在罷工，因為他們的工資已降至每天 2.50 美元。

相比之下，3.67 美元大約是美國最低工資 7.25 美元的一半。 作為津巴布韋人，我必須工作大約一天半才能賺到錢來購買這 50MB 的數據，而在美國祇需半小時。 比較國家之間的生活成本並不容易，但僅就工資而言，津巴布韋 50 MB 數據的 3.67 美元成本對於美國人來說就像最低工資標準的 52 美元。

設置實驗

我啟動了 Chrome 並打開了開發工具，在那裡我將網絡限制為緩慢的 3G 連接。 我想模擬烏茲別克斯坦用戶體驗的那種慢速連接，看看網站會給我什麼樣的體驗。 我還限制了我的 CPU 以模擬在低端設備上。

我安裝了 ModHeader 並設置了“Save-Data”標題，讓網站知道我想盡量減少數據使用量。 這也是 Chrome 為 Android 的“精簡模式”設置的標頭，我將在稍後詳細介紹。

我下載了 TripMode； 適用於 Mac 的應用程序，可讓您控制 Mac 上的哪些應用程序可以訪問互聯網。 任何其他應用程序的 Internet 訪問都會被自動阻止。

我預測我的 50 MB 預算能走多遠？ 一個網頁的平均重量接近 1.7 MB，這表明我的預算中有大約 29 個頁面，但如果我能夠留在相同的站點並利用瀏覽器緩存，可能會比這更多。

在整個實驗過程中，我將提出一些性能提示，以加快頁面的第一次內容繪製和感知加載時間。 其中一些技巧可能不會影響直接傳輸的數據量，但通常會延遲下載不太重要的資源，這在慢速連接時可能意味著永遠不會下載資源並保存數據。

本實驗

事不宜遲，我加載了 google.com，使用了 402 KB 的預算並花費了 0.03 美元（大約是我津巴布韋預算的 1%）。

總而言之，頁面大小不錯，但我想知道這 24 個網絡請求來自哪裡，以及頁面是否可以變得更輕。

谷歌主頁——DOM

查看頁面標記，沒有外部樣式表——所有的 CSS 都是內聯的。

性能提示 #1：內聯關鍵 CSS

這對性能有好處，因為它節省了瀏覽器必鬚髮出額外的網絡請求才能獲取外部樣式表，因此可以解析樣式並立即應用於第一個內容繪製。 這裡需要權衡取捨，因為外部樣式表可以被緩存，但內聯樣式表不能（除非你對 JavaScript 很聰明）。

一般的建議是你的關鍵樣式（任何首屏樣式）是內聯的，你的其餘樣式是外部的並異步加載。 CSS 的異步加載可以通過一行非常巧妙的 HTML 來實現：

 <link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">

devtools 顯示了 DOM 的美化版本。 如果您想查看實際下載到瀏覽器的內容，請切換到 Sources 選項卡並找到該文檔。

你可以看到這裡有很多內聯 JavaScript。 值得注意的是，它已經被醜化了，而不僅僅是縮小了。

性能提示 #2：縮小和醜化您的資產

縮小刪除了不必要的空格和字符，但醜化實際上“破壞”了代碼更短。 明顯的跡像是代碼包含簡短的、機器生成的變量名，而不是未經修改的源代碼。 這很好，因為這意味著腳本更小，下載速度更快。

即便如此，內聯腳本看起來大約是 210 KB 頁面資源的 120 KB（大約是 60 KB gzip 大小的一半）。 此外，在下載的 402 KB 中，還有 5 個外部 JavaScript 文件，總計 291 KB：

這意味著 JavaScript 約佔整個頁面重量的 80%。

這不是無用的 JavaScript； 谷歌必須有一些才能在您輸入時顯示建議。 但我懷疑其中很多是跟踪代碼和廣告設置。

為了比較，我禁用了 JavaScript 並重新加載了頁面：

禁用 JS 的 Google 搜索版本只有 102 KB，而不是 402 KB。 儘管 Google 無法在這些情況下提供自動建議，但該網站仍然可以正常運行，而且我剛剛將數據使用量減少到原來的四分之一。 如果我真的不得不長期限制我的數據使用量，我要做的第一件事就是禁用 JavaScript。 它並不像聽起來那麼糟糕。

性能提示 #3：少即是多

內聯、醜化和縮小資產都很好，但最好的性能來自於一開始就不發送資產。

• 在添加任何新功能之前，您是否制定了性能預算？
• 在將 JavaScript 添加到您的站點之前，您的功能是否可以使用純 HTML 來完成？ （例如，HTML5 表單驗證）。
• 在將大型 JavaScript 或 CSS 庫拉入您的應用程序之前，請使用類似 bundlephobia.com 之類的工具來衡量它的大小。 便利值得重量嗎？ 你能用更小數據量的普通代碼完成同樣的事情嗎？

分析資源信息

這裡有很多東西要解壓，所以讓我們開始吧。 我只有 50 MB 的空間可以玩，所以我要擠滿這個頁面加載的每一點。 接受簡短的 Chrome Devtools 教程。

傳輸了 402 KB，但傳輸了 1.1 MB 資源：這實際上意味著什麼？

這意味著實際下載了 402 KB 的內容，但是以壓縮形式（使用 gzip 或 brotli 等壓縮算法）。 然後瀏覽器必須做一些工作才能將其解壓縮成有意義的東西。 解壓縮數據的總大小為 1.1 MB。

這種解包不是免費的——解壓資源需要幾毫秒的開銷。 但與發送 1.1MB 的數據相比，這只是微不足道的開銷。

性能提示 #4：壓縮基於文本的資源

作為一般規則，請始終使用 gzip 之類的方式壓縮您的資產。 但是不要對你的圖像和其他二進製文件使用壓縮——你應該提前在源代碼上優化它們。 壓縮實際上最終會使它們變大。

並且，如果可以，請避免壓縮 1500 字節或更小的文件。 最小的 TCP 數據包大小為 1500 字節，因此通過壓縮到 800 字節，您什麼也沒有保存，因為它仍然在同一個字節數據包中傳輸。 同樣，成本可以忽略不計，但浪費了服務器上的一些壓縮 CPU 時間和客戶端上的解壓縮 CPU 時間。

現在回到 Chrome 中的“網絡”選項卡：讓我們深入研究這些優先事項。 請注意，資源的優先級從“最高”到“最低”——這些是瀏覽器對要下載的更重要資源的最佳猜測。 優先級越高，瀏覽器越早嘗試下載資產。

性能提示 #5：向瀏覽器提供資源提示

瀏覽器會猜測最高優先級的資產是什麼，但您可以使用<link rel="preload">標籤提供資源提示，指示瀏覽器盡快下載資產。 預加載字體、徽標和其他任何出現在首屏的內容是個好主意。

讓我們談談緩存。 我將按住 ALT 並右鍵單擊以更改列標題以解鎖更多有趣的信息。 我們將檢查 Cache-Control。

Cache-Control 表示是否可以緩存資源，可以緩存多長時間，以及在重新驗證時應該遵循哪些規則。 設置適當的緩存值對於降低重複訪問的數據成本至關重要。

性能提示 #6：在所有可緩存資產上設置緩存控制標頭

請注意，緩存控制值以public或private指令開頭，後跟過期值（例如max-age=31536000 ）。 該指令是什麼意思，為什麼會有奇怪的特定max-age值？

值31536000是一年中的秒數，是緩存控制規範允許的理論最大值。 通常會看到此值應用於所有靜態資產，並且實際上意味著“此資源不會改變”。 實際上，沒有瀏覽器會緩存一整年，但只要有意義，它就會緩存資產。

為了解釋 public/private 指令，我們必須解釋存在於服務器之外的兩個主要緩存。 首先，有傳統的瀏覽器緩存，其中資源存儲在用戶的機器（“客戶端”）上。 然後是位於客戶端和服務器之間的 CDN 緩存； 資源被緩存在 CDN 級別，以防止 CDN 一遍又一遍地向源服務器請求資源。

public的Cache-Control指令允許將資源緩存在客戶端和 CDN 中。 private值意味著只有客戶端可以緩存它； CDN 不應該這樣做。 後一個值通常用於身份驗證後存在的頁面或資產，可以將其緩存在客戶端上，但我們不希望通過將其緩存在 CDN 中並將其傳遞給其他用戶來洩漏私人信息。

引起我注意的一件事是 Google 徽標具有“私人”的緩存控制。 頁面上的其他圖像確實有公共緩存，我不知道為什麼會以不同方式處理徽標。 如果您有任何想法，請在評論中告訴我！

我刷新了頁面，大部分資源都是從緩存中提供的，除了頁面本身，正如你已經看到的那樣，它是private, max-age=0 ，這意味著它不能被緩存。 這對於動態網頁來說是正常的，在這些網頁中，用戶在刷新時始終獲得最新的頁面很重要。

正是在這一點上，我不小心點擊了 devtools 中的“說明”URL，這將我帶到了網絡分析參考，花費了我大約 5 MB 的預算。 哎呀。

谷歌開發文檔

這個新的 5 MB 頁面中有 4.2 MB 用於圖像； 特別是 SVG。 其中最重的是 186 KB，這並不是特別大——它們太多了，而且它們都是一次下載的。

5 MB 的頁面加載量是我今天預算的 10%。 到目前為止，我已經使用了 5.5 MB，包括 Google 主頁的無 JavaScript 重新加載，並且花費了 0.40 美元。 我什至沒有打開這個頁面的意思。

這裡有什麼更好的用戶體驗？

性能提示 #7：延遲加載圖像

通常，如果我不小心點擊了一個鏈接，我會點擊瀏覽器中的後退按鈕。 下載這些圖像對我沒有任何好處——浪費了 4.2 MB！

除了視頻，您通常知道自己在做什麼，圖像是迄今為止網絡上數據使用的最大罪魁禍首。 一項對世界 500 強網站的研究發現，圖片佔據了平均頁面重量的 53%。 “這意味著它們對頁面加載時間和隨後的整體性能有很大影響”。

與其在頁面加載時下載所有圖像，不如延遲加載圖像，以便只有與頁面互動的用戶支付下載它們的費用。 因此，選擇不在首屏下方滾動的用戶不會浪費任何不必要的帶寬下載他們永遠不會看到的圖像。

有一個很棒的 css-tricks.com 指南，用於為圖像推出延遲加載，它在連接良好的圖像、連接不良的圖像和禁用 JavaScript 的圖像之間提供了良好的平衡。

如果此頁面按照上面的指南實現了延遲加載，則默認情況下，38 個 SVG 中的每一個都將由 1 KB 佔位符圖像表示，並且僅在滾動時加載到視圖中。

性能提示 #8：為您的圖像使用正確的格式

我認為谷歌沒有使用 WebP，這是一種圖像格式，它的大小比 PNG 小 26%（質量沒有損失），比 JPEG 小 25-34%（以及質量相當）。 我想我會嘗試將 SVG 轉換為 WebP。

轉換為 WebP 確實使其中一個 SVG 從 186 KB 減少到僅 65 KB，但實際上，並排查看圖像時，WebP 出現顆粒狀：

然後我嘗試將其中一個 PNG 轉換為 WebP，它應該是無損的，並且應該更小。 然而，WebP 輸出*重*（127 KB，從 109 KB）！

這讓我很驚訝。 WebP 不一定是我們認為的靈丹妙藥，甚至 Google 也忽略了在此頁面上使用它。

所以我的建議是：在可能的情況下，在每個圖像的基礎上嘗試不同的圖像格式。 以最小尺寸保持最佳質量的格式可能不是您期望的格式。

現在回到 DOM。 我遇到了這個：

注意到 Google 分析腳本上的async關鍵字了嗎？

儘管這是文檔開頭的第一件事，但它的優先級很低，因為我們已經通過使用async關鍵字明確選擇不成為阻塞請求。

阻塞請求是停止頁面呈現的請求。 <script>調用默認是阻塞的，在腳本下載、編譯和執行之前停止 HTML 的解析。 這就是我們傳統上將<script>調用放在文檔末尾的原因。

性能提示 #9：避免編寫阻塞腳本調用

通過將async屬性添加到我們的<script>標記，我們告訴瀏覽器不要停止呈現頁面，而是在後台下載腳本。 如果在下載腳本時 HTML 仍在解析中，則在執行腳本時暫停解析，然後恢復。 這比在遇到<script>時立即阻止渲染要好得多。

還有一個defer屬性，略有不同。 <script defer>告訴瀏覽器在後台加載腳本時渲染頁面，即使在下載腳本時 HTML 仍在解析中，腳本也必須等到頁面渲染完成後才能執行. 這使得腳本完全非阻塞。 閱讀“使用延遲和異步高效加載 JavaScript”以獲取更多信息。

無論如何，足夠的谷歌剖析。 是時候嘗試另一個網站了。 我的預算還剩將近 45 MB！

亞馬遜

亞馬遜主頁加載的總重量約為 6 MB。 其中之一是我什至在頁面上找不到的 587 KB 圖像。 這是一個PNG，大概有清晰的文本，但在攝影背景上——一個經典的組合，對性能來說很糟糕。

事實上，在我的網絡選項卡中有幾個幾百 KB 的圖像，我在頁面上實際上是看不到的。 我懷疑亞馬遜某處的配置錯誤，但這些不可見的圖像結合在一起至少吞噬了我的 1 MB 數據。

英雄形象呢？ 它是頁面上的主圖像，僅傳輸了 94 KB - 但如果直接在文本和足球運動員周圍裁剪，它的大小可能會減少約 15%。 然後我們可以在 CSS 中應用與圖像中相同的背景顏色。 這具有額外的優勢，即可以調整到更小的屏幕，同時保持文本的易讀性。

我已經說過一次，我會再說一遍：優化和延遲加載您的圖像是您可以為網站的頁面權重帶來的最大好處。

到目前為止，優化圖像提供了最顯著的數據減少。 你可以證明 JavaScript 對整體性能的影響更大，但對數據減少沒有影響。 優化或刪除圖像是確保更輕鬆體驗的最安全方式，也是流量節省程序所依賴的主要優化方式。
— Tim Kadlec，了解 Chrome Lite 頁面

公平地說，如果我將瀏覽器調整為移動設備大小並刷新頁面，則該網站針對移動設備進行了優化，總頁面重量僅為 2.1 MB。

但這讓我想到了下一點……

性能提示 #10：不要對數據連接做出假設

很難檢測桌面上的某人是否正在使用寬帶連接，或者是否正在通過數據受限的加密狗或移動設備進行網絡共享。 很多人就是這樣在火車上工作，或者生活在寬帶基礎設施較差但移動信號強的地區。 在亞馬遜的案例中，在桌面網站上可以節省一些大數據，我們不應該僅僅因為屏幕尺寸表明我不在移動設備上而自滿。

是的，如果我們的視口是“桌面大小”，我們應該期待更大的頁面加載，因為與顆粒狀的移動圖像相比，圖像會更大，並且針對屏幕進行了更好的優化。 但是頁面不應該大幾個數量級。

此外，我在請求中發送了Save-Data標頭。 此標頭明確表示傾向於減少數據使用，我希望將來有更多網站開始注意到它。

最初的“桌面”負載可能為 6 MB，但在觀看了一分鐘後，隨著較低優先級的資源和事件跟​​踪開始起作用，它已攀升至 8.6 MB。 此頁面重量包括近 1.7 MB 的縮小 JavaScript。 我什至不想開始看那個。

性能提示 #11：為您的 JavaScript 使用 Web Workers

哪個會更糟——1.7 MB 的 JavaScript 或 1.7 MB 的圖像？ 答案是 JavaScript：這兩種資產在性能方面並不等同。

JPEG 圖像需要在屏幕上進行解碼、光柵化和繪製。 需要下載 JavaScript 包，然後對其進行解析、編譯、執行——引擎還需要完成許多其他步驟。 請注意，這些成本並不完全相等。
— Addy Osmani， 2018 年 JavaScript 的成本

如果您必鬚髮布這麼多 JavaScript，請嘗試將其放入 web worker 中。 這使大部分 JavaScript 遠離主線程，現在可以釋放主線程來重新繪製 UI，幫助您的網頁在低功率設備上保持響應。

我現在的預算大約有 15.5 MB，並且已經花費了津巴布韋數據預算中的 1.14 美元。 我必須要當老師半天才能掙到錢才能走到這一步。

Pinterest

我聽說 Pinterest 的表現不錯，所以我決定對其進行測試。

也許這不是最公平的測試； 我被帶到了登錄頁面，在該頁面上，一個異步過程發現我已登錄 Facebook 並自動登錄。 頁面加載相對較快，但隨著越來越多的內容被預加載，請求逐漸增加。

然而，我看到在隨後的頁面加載中，Service Worker 顯示了大部分內容——節省了大約一半的頁面重量：

Pinterest 網站是一個漸進式網絡應用程序； 它安裝了一個服務工作者來手動處理 CSS 和 JS 的緩存。 我現在可以關閉我的 WiFi 並繼續使用該網站（儘管不是很有用）：

性能提示 #12：使用 Service Worker 提供離線支持

如果我只需要通過網絡加載一次網站，現在即使我離線也可以獲得我需要的所有信息，那不是很好嗎？

一個很好的例子是顯示本週天氣預報的網站。 我應該只需要下載該頁面一次。 如果我關閉我的移動數據並隨後在某個時候返回該頁面，它應該能夠為我提供最後已知的內容。 如果我再次連接到 Internet 並加載頁面，我將獲得更新的預測，但 CSS 和圖像等靜態資產仍應由 service worker 在本地提供。

這可以通過設置具有良好緩存策略的服務工作者來實現，以便可以離線重新訪問緩存的頁面。 lodash 文檔網站是野外服務工作者的一個很好的例子：

很少更新並且很可能經常使用的內容是服務人員治療的完美候選者。 具有不斷變化的新聞提要的動態站點不太適合離線體驗，但仍然可以從中受益。

當您的數據預算緊張時，服務人員可以真正為您節省一天的時間。 我不相信 Pinterest 體驗在數據使用方面是最佳的——即使在圖像很少的頁面上，後續頁面也在 0.5 MB 左右——但讓你的 JavaScript 為你處理頁面請求並保持相同的導航元素到位可以非常高效。 對於可通過單頁應用程序呈現的文章的回訪，BBC 管理的傳輸大小僅為 3.1 KB。

到目前為止，僅 Pinterest 就已經消耗了 14 MB，這意味著我已經花掉了大約 30 MB 的預算，或者津巴布韋預算的 2.20 美元（幾乎是一天的工資）。

我最好小心我最後的 20 MB……但那有什麼樂趣呢？

遊戲點

我之所以選擇這個，是因為過去在我的手機上感覺明顯遲緩，我想深入了解原因。 果然，加載主頁會消耗 8.5 MB 的數據。

其中 6.5 MB 是頁面中間的一個自動播放視頻，公平地說，直到我開始滾動時才開始下載。 儘管如此…

我只能在視口中看到一半的視頻——右側被剪掉了。 它也是 30 秒長，我敢打賭大多數人不會坐下來觀看整件事。 這一單一資產使頁面大小增加了兩倍多。

性能提示 #13：不要預加載視頻

通常，除非您網站的主要通信方式是視頻，否則不要預加載它。

如果您是 YouTube 或 Netflix，可以合理地假設訪問您頁面的人希望視頻自動加載和自動播放。 人們期望視頻會咀嚼一些數據，但這是對內容的公平交換。 但是，如果您是一個主要媒體是文本和圖像的網站——而你恰好提供了額外的視頻內容——那麼不要預加載視頻。

想想帶有嵌入視頻的新聞文章。 許多用戶只想瀏覽文章標題，然後再繼續下一步。 其他人將閱讀該文章，但忽略任何嵌入。 其他人會努力點擊並觀看每個嵌入的視頻。 我們不應該假設他們想要觀看這些視頻而佔用每個用戶的帶寬。

重申：用戶不喜歡自動播放視頻。 作為開發人員，我們這樣做只是因為我們的經理告訴我們這樣做，他們之所以告訴我們這樣做只是因為所有最酷的應用程序都在這樣做，而最酷的應用程序這樣做只是因為視頻廣告產生的收入是傳統廣告的 20 到 50 倍廣告。 谷歌瀏覽器已開始根據個人喜好阻止某些網站的自動播放視頻，因此即使您將網站開發為自動播放視頻，也不能保證您的用戶會獲得這種體驗。

如果我們同意讓視頻成為一種選擇加入體驗（點擊播放）是個好主意，我們可以更進一步，讓它也點擊加載。 這意味著使用播放按鈕模擬視頻佔位符圖像，並且僅在單擊播放按鈕時下載視頻。 使用快速連接的人應該注意到緩衝速度沒有差異，而使用慢速連接的人會欣賞站點其餘部分的加載速度，因為它不必預加載大型視頻文件。

Anyway, back to Gamespot, where I was indeed forced to preload a large video file I ended up not watching. I then clicked through to a game review page that weighed another 8.5 MB, this time with 5.4 MB of video, before I even started scrolling down the page.

What was really galling was when I looked at what the video actually was. It was an advert for a Samsung TV! This advert cost me $0.40 of my Zimbabwe wages. Not only was it pre-loaded, but it also didn't end up playing anywhere as far as I'm aware, so I never actually saw it.

The 'real' video — the gameplay footage (in other words, the content) — wasn't actually loaded until I clicked on it. And that ploughed through my remaining data in seconds.

而已。 That's my 50 MB gone. I'll need to work another 1.5 days as a Zimbabwean schoolteacher to repeat the experience.

Performance Tip #14: Optimize For First Page Load

What's striking is that I used 50 MB of data and in most cases, I only visited one or two pages on any given site. If you think about it, this is true of most user journeys today.

Think about the last time you Googled something. You no doubt clicked on the first search result. If you got your answer, you closed the tab, or else you hit the back button and moved onto the next search result.

With the exception of a few so-called 'destination sites' such as Facebook or YouTube, where users habitually go as a starting point for other activities, the majority of user journeys are ephemeral. We stumble across random sites to get the answers to our questions, never to return to those sites again.

Web development practices are heavily skewed towards optimising for repeat visitors. “Cache these assets — they'll come in handy later”. “Pre-load this onward journey, in case the user clicks to read more”. “Subscribe to our mailing list”.

Instead, I believe we should optimize heavily for one-off visitors. Call it a controversial opinion, but maybe caching isn't really all that important. How important can a cached resource that never gets surfaced again be ? And perhaps users aren't actually going to subscribe to your mailing list after reading just the one article, so downloading the JavaScript and CSS for the mail subscription modal is both a waste of data and an annoying user experience.

The Decline Of Proxy Browsers

I had hoped to try out Opera Mini as part of this experiment. Opera Mini is a mobile web browser which proxies web pages through Opera's compression servers. It accounts for 1.42% of global traffic as of June 2019, according to caniuse.com.

Opera Mini claims to save up to 90% of data by doing some pretty intensive transcoding. HTML is parsed, images are compressed, styling is applied, and a certain amount of JavaScript is executed on Opera's servers. The server doesn't respond with HTML as you might expect — it actually transcodes the data into Opera Binary Markup Language (OBML), which is progressively loaded by Opera Mini on the device. It renders what is essentially an interactive 'snapshot' of the web page — think of it as a PDF with hyperlinks inside it. Read Tiffany Brown's excellent article, “Opera Mini and JavaScript” for a technical deep-dive.

It would have been a perfect way to eek my 50 MB budget as far as possible. Unfortunately, Opera Mini is no longer available on iOS in the UK. Attempting to visit it in the app store throws an error:

It's still available “in some markets” but reading between the lines, Opera will be phasing out Opera Mini for its new app — Opera Touch — which doesn't have any data-saving functionality apart from the ability to natively block ads.

Opera desktop used to have a 'Turbo mode', acting as a traditional proxy server (returning a HTML document instead of OBML), applying data-saving techniques but less intensively than Opera Mini. According to Opera, JavaScript continues to work and “you get all the videos, photos and text that you normally would, but you eat up less data and load pages faster”. However, Opera quietly removed Turbo mode in v60 earlier this year, and Opera Touch doesn't have a Turbo mode either. Turbo mode is currently only available on Opera for Android.

Android is where all the action is in terms of data-saving technology. Chrome offers a 'Lite mode' on its mobile browser for Android, which is not available for iPhones or iPads because of “platform constraints“. Outside of mobile, Google used to provide a 'Data Saver' extension for Chrome desktop, but this was canned in April.

Lite mode for Chrome Android can be forcibly enabled, or automatically kicks in when the network's effective connection type is 2G or worse, or when Chrome estimates the page will take more than 5 seconds to reach first contentful paint. Under these conditions, Chrome will request the lite version of the HTTPS URL as cached by Google's servers, and display this stripped-down version inside the user's browser, alongside a “Lite” marker in the address bar.

I'd love to try it out — apparently it disables scripts, replaces images with placeholders, prevents loading of non-critical resources and shows offline copies of pages if one is available on the device. This saves up to 60% of data. However, it isn't available in private (Incognito) mode, which hints at some of the privacy concerns surrounding proxy browsers.

Lite 模式與 Google 共享 HTTPS URL，因此這種模式在 Incognito 中不可用是有道理的。 然而，根據 ghacks.net 的說法，cookie、登錄信息和個性化頁面內容等其他信息不會與穀歌共享，並且“永遠不會破壞 Chrome 和網站之間的安全連接”。 有人想知道為什麼在 iOS 上似乎不允許使用這些數據保存服務（並且沒有關於 Lite 模式是否會在 iOS 上可用的消息）。

數據保護代理需要高度信任； 您的瀏覽活動、cookie 和其他敏感信息被委託給某些服務器，通常位於另一個國家/地區。 許多代理根本不再工作，因為很多網站已經轉向 HTTPS，這意味著 Turbo 模式等舉措在很大程度上已成為“無用功能”。 HTTPS 阻止了這種中間人行為，這是一件好事，儘管它意味著其中一些代理服務的消亡，並使那些連接不良的人更難訪問網站。

我找不到任何 OSX 或 iOS 兼容的數據保存工具，除了 Bandwidth Hero for Firefox（它需要設置您自己的數據壓縮服務——遠遠超出大多數用戶的技術能力！）和 skyZIP 代理（最後更新於2017 年充滿了錯別字，我無法讓自己相信）。

結論

減少網站的數據足跡與提高前端性能齊頭並進。 這是您可以做的最可靠的事情來加速您的網站。

除了數據成本之外，還有很多充分的理由關注性能，正如 GOV.UK 關於該主題的博客文章所述：

• 如果加載時間超過 3 秒，53% 的用戶會放棄移動網站。
• 嘗試使用慢速連接在網站上完成簡單任務時，人們必須多集中 50% 的注意力。
• 性能更高的網頁更能延長用戶設備的電池壽命，並且通常需要更少的服務器電源來提供服務。 高性能站點對環境有益。

我們無權改變數據不平等的全球成本。 但我們確實有能力減輕它的影響，改善過程中每個人的體驗。