然我們生活在一個寬帶無處不在、4/5G 幾乎全覆蓋的時代，但網站加載緩慢還是常態，就算我們打開一個以文本為中心的新聞網站，都可能需要至少 30 秒才能開始閱讀。畢竟在內容膨脹時代，一張照片就能輕易超過 1MB 大小，許多網站為了顯示幾段文本，還會單獨加載至少 10MB 的 JS 和自定義字體。

對此，對優化和極簡主義充滿熱情的資深 Web 開發 Nathaniel 告訴我們，你應該讓你的網頁盡力控制在 14KB 以內，而且即使對于以富媒體為中心的網站，這條 14KB 的規則可能仍然值得遵循。如果 14KB 不足以用于最終布局，則需要優先考慮“首屏”字節，可以用發送給訪問者的前 14KB 數據來渲染一些有用的東西，減少用戶還沒有開始閱讀就流失掉的機會。

網頁越小，加載速度就越快——這一點都不奇怪。

但令人感到驚訝的是，14KB 網頁的加載速度比 15KB 要快得多——可能快 612 毫秒——而 15KB 和 16KB 網頁之間的加載速度差異微乎其微。

這是 TCP 慢啟動算法導致的。本文將介紹這個算法、它的原理以及為什么你應該關注它。但首先我們需要快速過一遍一些基礎知識。

TCP 是什么

傳輸控制協議（Transmission Control Protocol，TCP）是一種使用 IP 協議可靠地發送數據包的方法——有時被稱為 TCP/IP。

當瀏覽器向你的網站（或圖像或樣式表）發出請求時，它會使用 HTTP 請求。HTTP 建立在 TCP 之上，一個 HTTP 請求通常由許多 TCP 數據包組成。IP 只是一個將數據包從互聯網上的一個位置發送到另一個位置的系統。IP 沒有檢查數據包是否成功到達目的地的方法。

對于網站來說，確保所有的數據到達請求端是非常關鍵的，否則我們可能會因為丟失數據包無法獲得完整的網頁。但在網絡的其他應用場景中，這一點并不那么重要——比如流媒體直播視頻。

TCP 是 IP 的擴展，瀏覽器和網站服務器通過它告訴對方哪些數據包已經成功到達。

服務器發送一些數據包，然后等待瀏覽器已經收到數據包的響應（這叫確認或 ACK），然后它繼續發送更多的數據包——或者如果它沒有收到 ACK，將再次發送相同的數據包。

什么是 TCP 慢啟動

TCP 慢啟動是一種算法，服務器用它來確定一次可以發送多少數據包。

當瀏覽器第一次連接到服務器時，服務器無法知道它們之間的帶寬是多少。帶寬是指在單位時間內網絡可以傳輸的數據量。通常以比特/秒（b/s）為單位。我們可以用管道來作類比——把帶寬想象成每秒從管道流出多少水。

服務器不知道網絡連接可以處理多少數據——所以它先發送少量且安全的數據——通常是 10 個 TCP 數據包。如果這些數據包成功地到達網站訪問者，他們的計算機返回確認（ACK），表示數據包已經被收到了。然后，服務器發送更多的數據包，但這一次它將數據包的數量增加了一倍。

這個過程會不斷重復，直到數據包丟失，服務器沒有收到 ACK。（此時，服務器會繼續發送數據包，但速度較慢）。

這就是 TCP 慢啟動的要點——在現實當中，雖然算法各不相同，但這是它的基本原理。

那么 14KB 這個數字是怎么來的

大多數 Web 服務器的 TCP 慢啟動算法都是從發送 10 個 TCP 數據包開始的。

TCP 數據包最大長度為 1500 字節。這個最大值不是由 TCP 規范設置的，它來自于以太網標準。

每個 TCP 數據包的標頭占了 40 個字節，其中 16 個字節用于 IP，另外 24 個字節用于 TCP。

這樣每個 TCP 數據包還剩下 1460 個字節。10 x 1460 = 14600 字節，或大約 14KB！

因此，如果你能把網站的網頁——或網頁的關鍵部分——壓縮到 14KB，就可以為訪問者節省大量的時間——他們和網站服務器之間的往返時間。

一個數據往返能有多糟糕？但人們非常沒有耐心——一個數據往返可能會出奇地長，具體多長取決于延遲……延遲是指數據包從源傳輸到目的地所花費的時間。如果帶寬是每秒鐘可以通過管道的水的數量，那么延遲就是一滴水進入管道后從另一端流出所花費的時間。

下面是一個關于延遲有多糟糕的例子。

衛星網絡

衛星網絡是由環繞地球軌道的衛星提供的，在人煙稀少的地區、石油鉆井平臺、游輪以及飛機上，人們可以使用這種網絡。

為了說明這種糟糕的延遲，我們想象一群在石油鉆井平臺工作的兄弟把骰子忘在了家里，他們需要通過 missingdice.com（少于 14KB）來玩《龍與地下城》游戲。

首先，他們中的一個用手機發出一個網頁請求……

手機將請求發送到鉆井平臺的 WiFi 路由器，路由器將數據發送給平臺上的衛星天線，我們假設這可能需要 1 毫秒時間。

然后，衛星天線將數據發送到地球軌道上方的衛星。

通常，這是通過在地球表面上方 35786 公里處運行的軌道衛星實現的。光速為 299792458 米/秒，所以信息從地球發送到衛星需要 120 毫秒。然后，衛星將信息傳回地面接收站，這又需要 120 毫秒。

然后，地面站必須將請求發送到位于地球任意位置的服務器（當光通過光纖電纜傳輸時，速度會降至每秒 200000000 米）。如果地面站和服務器之間的距離等于紐約到倫敦之間的距離，那么大約需要 28 毫秒，如果地面站和服務器之間的距離等于紐約到悉尼之間的距離，則需要 80 毫秒——所以我們姑且定一個 60 毫秒的數字（這個數字便于計算）。

然后，服務器需要處理請求，這可能需要 10 毫秒，然后服務器再次將它發送出去。

回到地面站，進入太空，回到衛星天線，然后回到無線路由器，再到手機上。

手機 -> WiFi 路由器 ->衛星天線 ->衛星 -> 地面站 -> 服務器 -> 地面站 -> 衛星 -> 衛星天線 -> WiFi 路由器 -> 手機

如果我們算一下，就是 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612 毫秒。

這是每次往返額外的 612 毫秒——也許這看起來不是很長時間，但你的網站可能只是為了獲取第一個資源就需要許多個往返。

另外，HTTPS 在完成第一個往返之前需要額外的兩次往返——這使延遲達到了 1836 毫秒！

對于生活在陸地上的人，延遲又是怎樣的

衛星網絡似乎是一個極端的例子——我選擇它作為例子是因為它能夠充分說明了網絡延遲這個問題——但對于生活在陸地上的人來說，延遲可能比這更糟糕，原因有很多。

• 2G 網絡的延遲通常在 300 毫秒到 1000 毫秒之間；
• 3G 網絡的延遲可以在 100 毫秒到 500 毫秒之間；
• 嘈雜的移動網絡——比如在一個異常擁擠的地方，比如音樂節；
• 處理大流量的服務器；
• 其他一些不好的東西。

不穩定的網絡連接也會導致數據包丟失——導致需要另一個往返來獲取丟失的數據包。

了解了 14KB 法則，接下來可以做些什么

當然，你應該讓你的網頁盡可能的小——你愛你的訪客，你希望他們開心。將每個頁面的大小控制在 14KB 以內是一個不錯的主意。

這 14KB 可以是壓縮數據——所以實際上可以對應大約 50KB 的未壓縮數據——這已經非常慷慨了。要知道，阿波羅 11 的制導計算機只有 72KB 內存。

去掉自動播放的視頻、彈出窗口、Cookie、Cookie 橫幅、社交網絡按鈕、跟蹤腳本、JavaScript 和 CSS 框架，以及所有其他人們不喜歡的垃圾——你可能就能實現 14KB 法則。

假設你已經盡力將所有內容控制在 14KB 以內，但仍然做不到——但 14KB 法則仍然很有用。

你可以用發送給訪問者的前 14KB 數據來渲染一些有用的東西——例如一些關鍵的 CSS、JS 和解釋如何使用你的應用程序的前幾段文本。

需要注意的是，14KB 法則包含了 HTTP 標頭——這些是未壓縮的（即使是 HTTP/2 的第一個響應），也包含圖片，所以你應該只加載在頁面上方的內容，并保持它們最小，或者使用占位符，讓訪問者知道他們在等待一些更好的內容。

關于這個法則的一些注意事項

14KB 法則更像是一種經驗之談，而不是計算的基本法則。

• 一些服務器已經將 TCP 慢啟動初始窗口從 10 個數據包增加到 30 個；
• 有時服務器知道它可以從更大數量的數據包開始傳輸，因為它使用 TLS 握手來建立一個更大的窗口；
• 服務器可以緩存路由可管理的數據包數量，并在下一次連接時發送更多的數據包；
• 還有其他需要注意的地方——這里有一篇文章更深入地探討關于為什么 14KB 法則并不總是這么回事（https://www.tunetheweb.com/blog/critical-resources-and-the-first-14kb/）。

HTTP/2 和 14KB 法則

有一種觀點認為，在使用 HTTP/2 時，14KB 法則不再適用。我已經讀了所有我能讀到的關于這個問題的東西，但我還沒有看到任何證據表明使用 HTTP/2 的服務器已經停止使用 TCP 慢啟動（從 10 個數據包開始）。

HTTP/3 和 QUIC

與 HTTP/2 類似，有一種觀點認為 HTTP/3 和 QUIC 將廢除 14KB 法則——事實并非如此。實際上，QUIC 仍然建議使用 14KB 法則。

原文鏈接：

https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/

有一個最佳的屏幕尺寸可以設計。網站應在不同的瀏覽器和平臺上以所有屏幕分辨率快速響應地進行轉換。無障礙。移動友好。首先為您的訪客設計。從360×640到1920×1080的設計。

• 適用于1024×768至1920×1080的臺式顯示器的設計
• 適用于360×640至414×896的移動顯示器的設計
• 適用于601×962至1280×800的平板顯示器的設計
• 檢查百度統計并針對目標受眾的最常見分辨率大小進行優化
• 不要設計一種顯示器尺寸或屏幕分辨率。屏幕大小和瀏覽器窗口狀態因訪問者而異。
• 設計應該響應迅速。使用可轉換為當前用戶窗口大小的自適應或響應式布局。
• 監控百度站長工具的移動設備友好性和可用性警告

它仍然應該看起來不錯，并且在所有尺寸下都可以正常工作，現在我們的建議是建設一個自適應/響應式網站。

針對特定屏幕尺寸優化頁面布局的三個主要標準是：

• 網頁的初始可見性：屏幕上方是否可見所有關鍵信息，以便用戶無需滾動即可查看？這是在顯示多少個項目與每個項目顯示多少細節之間的權衡。
• 網頁可讀性：給定頁面寬度，閱讀各列中的文本是否容易？
• 網頁美學：當元素的大小和屏幕大小合適時，頁面的外觀如何？是否所有元素都正確對齊？標題是否緊挨著圖片等？

可用性準則還建議您考慮所有大小的所有三個條件。檢查瀏覽器窗口的屏幕分辨率為360×640到1920×1080。

在整個分辨率范圍內，您的網頁在所有條件上的得分都應該很高。

您的頁面也應該以更大或更小的尺寸工作，盡管這種極端情況不那么重要。

盡管此類用戶當然應該能夠訪問您的網站，但為他們提供小于設計的外觀有時是可以接受的折衷方案。

十大最常見的屏幕分辨率

2020年的前6個月中，對451,027個訪客進行了訪客分析：

屏幕分辨率測試用戶數11920×108088,378（19.53％）21366×76867,912（15.01％）31440×90043,687（9.65％）41536×86432,872（7.26％）52560×144025,954（5.73％）61680×105020,068（4.43％）71280×72015,138（3.34％）81280×80014,007（3.09％）9360×64011,085（2.45％）101600×90010,193（2.25％）

響應式網站模板是一個很好的選擇

響應式Web設計：在相同的URL上提供相同的HTML代碼，而不管用戶的設備（例如，臺式機，平板電腦，移動設備，非可視瀏覽器）如何，但是可以根據屏幕大小來不同地呈現顯示。 百度建議使用響應式Web設計，因為它是最容易實現和維護的設計模式。

在當今世界，許多人正在使用手持設備（平板電腦和智能手機）瀏覽網頁，而響應式網站設計（RWD）已經成為解決屏幕尺寸挑戰的極有可能的解決方案。

此方法不再使用固定寬度的網站，而是使用CSS樣式表中的“媒體查詢”來創建一個網站，該網站在大小上響應手持設備的不同視口以及人們使用的較小屏幕。

因此，無論人們使用什么設備來查看您的網站，您都可以為他們提供最完整的體驗。

百度首選適合移動設備的網站

如果您想為高競爭力的關鍵詞在百度獲得高排名，您就需要一個適合移動設備的網站。

網站對移動設備的友好程度如何影響各種設備對網站的排名效果。如果您為小型企業創建網站，您會知道他們想要一個在百度自然搜索中表現良好的網站。

目前從本質上講，這意味著網站設計具有響應性并且對移動設備友好，尤其是對于百度而言。

全球桌面屏幕分辨率統計，2019年5月– 2020年5月

作為參考，以下是最近（2020年）記錄的當前全球頂級屏幕分辨率的列表：

• 1366×768 – 23.49％
• 1920×1080 – 19.91％
• 1536×864 – 8.65％
• 1440×900 – 7.38％
• 1280×720 – 4.89％
• 1600×900 – 4.01％
• 1280×800 – 3.33％

全球移動屏幕分辨率統計，2019年5月– 2020年5月

• 360×640 – 17.91％
• 375×667 – 7.61％
• 414×896 – 6.52％
• 360×780 – 5.56％
• 360×760 – 5.06％
• 414×736 – 3.74％

全球平板電腦屏幕分辨率統計，2019年5月– 2020年5月

• 768×1024 – 51.98％
• 1280×800 – 7.11％
• 800×1280 – 5.34％
• 601×962 – 4.47％
• 600×1024 – 2.85％
• 1024×1366 – 1.96％

臺式機，手機與平板電腦的全球市場份額2019年5月– 2020年5月

1. 手機– 50.48％
2. 臺式機– 46.51％
3. 平板電腦– 3.0％

如何設計在每個瀏覽器和分辨率下看起來都相同的網站？

你不能。不可能將網站設計成在每個瀏覽器，平臺和屏幕分辨率下看起來都一樣，所以請避免嘗試。

您可以選擇不帶表格的流暢布局來進行設計，其寬度百分比可以擴展和收縮以適合訪問者瀏覽器的設置，或者您可以考慮研究能夠實現相同效果的響應式設計解決方案。

搜索引擎偏愛響應式設計，這對于采用它的人來說是個好消息。移動技術正在興起-因此，如果要開發一個新網站-您必須從一開始就考慮您的網站對移動設備的友好程度。

在實際編寫代碼時，我們的目標是使事情簡單。從經驗中我們知道的是， 對于您而言，確定您的受眾及其使用的設備，并從整體上構建適合該受眾的網站至關重要，受眾也包括搜索引擎。

您的移動網站是否重定向到您網站的另一個URL和版本？

好吧，那不是理想的。實際上，它從未如此。

追溯到今天-一些人使用網站的純文本版本為不支持其網站元素的用戶/瀏覽器生成內容-試圖（通常是徒勞的）使他們的內容更易于訪問。

W3C甚至曾經推薦它，我們認為如果其他所有方法都失敗了：

為訪問者目的而向訪問者傳遞一個URL始終是理想的選擇，并且如果您正在考慮創建網站的“移動”版本，則在傳遞移動或智能手機內容時沒有任何區別。

百度可能會在不久的將來對您的移動體驗做出主要評價-因此，我們所有人都確實需要意識到我們可能很快會在百度的SERP中看到巨大的變化。

當百度作為“訪問者”時，由于搜索引擎的典型URL挑戰，通常只提供一個URL甚至更為重要-在前一段時間實施規范鏈接元素之前就是這種情況。

因此，理想的情況是始終提供一個URL。

百度在這方面給出了建議：“如果您具有“智能手機”內容（我們將其視為普通的Web內容，因為它通常是普通的HTML頁面，只是在布局上進行了調整以顯示較小的內容），則可以使用rel = canonical指向您的桌面版本。這有助于我們專注于網絡搜索的桌面版本。當用戶使用智能手機訪問該桌面版本時，您可以將他們重定向到移動版本。無論URL結構如何，此方法均有效，因此您無需為智能手機移動網站使用子域/子目錄。 然而，更好的方法是使用相同的URL并顯示內容的適當版本而無需重定向。”

百度還提供了以下提示，以檢查您的網站是否準備好使用移動優先索引，但是從本質上講，如果您正在為網站使用響應式網頁設計模板，則此更改的問題應該很小：

• 確保網站的移動版本還具有重要的高質量內容。這包括文本，圖像（帶有alt屬性）和視頻-采用通常的可檢索和可索引格式。
• 結構化數據對于用戶喜歡的索引和搜索功能很重要：它應該同時在網站的移動版和臺式機上。確保結構化數據中的URL已更新為移動頁面上的移動版本。
• 元數據應同時存在于網站的兩個版本中。它提供有關頁面內容的提示，以供索引和投放。例如，確保網站上所有頁面的兩個版本的標題和元描述都相同。
• 與單獨的移動網址（單點網站）相互鏈接無需更改。對于使用單獨移動URL的網站，請在這些版本之間保留現有的鏈接rel = canonical和鏈接rel = alternate元素。
• 檢查單獨的移動網址上的hreflang鏈接。當使用link rel = hreflang元素進行國際化時，移動URL和桌面URL之間分別進行鏈接。您的移動URL的hreflang應該指向其他移動URL上的其他語言/區域版本，并且類似地使用hreflang鏈接元素將桌面與其他桌面URL鏈接。
• 確保承載站點的服務器有足夠的容量來處理可能增加的爬網速度。這不會影響使用響應式網頁設計和動態服務的網站，只會影響移動版本位于單獨主機上的網站，例如m.example.com。

用戶期望向下滾動頁面

過去的網頁用戶通常不需要滾動，但多年來，這種情況已經改變。

因此，在設計時，應考慮如果用戶只滾動一個完整屏幕或兩個屏幕，可以看到多少內容。超過五個屏幕的長度可能表示您頁面上的內容過多。當然，用戶希望等待更短的時間來查看更全面的內容。

滾動和初始可見性顯然都取決于屏幕尺寸：較大的屏幕在屏幕上方會顯示更多內容，并且需要較少的滾動。

對響應式移動網站的更改會導百度帶來更多流量嗎？

不一定，但是有可能。

與百度優化有關的許多事情–建立一個適合移動設備的網站或多或少可以確保您保持已經獲得的訪問量，并不一定能為您提供來自百度的更多免費訪問量。

百度及其用戶再次提高了質量標準，如果您想在更具競爭力的SERP中競爭，這是小企業克服困難的又一個障礙。

從長遠來看，這種移動轉化僅對您的用戶來說是一件好事，但從短期來看，對小型企業的轉化率不會產生什么影響，因為通過移動設備獲得的轉化率通常低于桌面。

百度表示，這種適用于移動設備的算法對SERP的影響更大，隨著時間的流逝，我們將發現更多信息。

如何在您的網站上檢查重要的移動可用性問題

百度站長工具

您應該能夠在百度站長工具中跟蹤移動設備錯誤，并且如果您的網站配置正確，錯誤會隨著時間的流逝而消失。

體查詢

響應式網頁是這幾年很流行的網頁風格之一，他能夠以一套網頁代碼，面對不同的條件，例如改變瀏覽器的寬度，手機橫豎屏，作出不同的樣式調整。

最出名的響應式框架是Bootstrap，來自Twitter。也是每個剛入門前端開發師必學的框架，利用這個框架可以很輕松實現響應式效果。

要實現響應式，關鍵在于使用媒體查詢 Media！

語法

@media （媒體特性）and （媒體特性） {你的樣式}

看起來好像很復雜，先看完整的代碼

@media  (max-width:480px){ 
    body{background-color:green}
 }

上面這句話的意思，瀏覽器的寬度小于或等于480px時，背景顏色是綠色。

再來多一個，如下

@media  (min-width:481px){ 
    body{background-color:red}
}

上面這句話的意思，瀏覽器的寬度大于或等于481px時，背景顏色是紅色。

媒體特性

媒體特性就是依據什么樣的條件來進行更改樣式，是根據屏幕寬度大小、還是橫豎屏呢。這些條件都是官方定的，非常多。但實際上，真正有用的就是 min-width和max-width，根據瀏覽器寬度來設定不同的樣式。

這里會很容易混淆min-width和max-width的意義。min-width表示大于等于，max-width表示小于等于。

@media (max-width: 500px) {
    /** 窗口寬度小于等于500像素的樣式 **/
}

@media (min-width: 800px) {
    /** 窗口寬度大于等于800像素的樣式 **/
}

當有多個媒體特性時，用and連接，就可以形成一個區間范圍

@media (min-width: 600px) and (max-width: 700px) {
    /** 窗口寬度在600-700像素的樣式 **/
}

這就是他最基本的用法，凡是有兩面性，下面來說說他的優缺點。

優點

（1）面對不同分辨率設備靈活性強

（2）能夠快捷解決多設備顯示適應問題

缺點

（1）兼容各種設備工作量大，效率低下

（2）代碼累贅，會出現隱藏無用的元素，加載時間加長

案例

全局布局

下面這種響應式布局最為常見，通過媒體查詢定義不同的樣式，讓其能夠適應手機瀏覽器和桌面瀏覽器：

1、電腦端大屏幕下，網頁元素全部展示

2、手機端下，因為屏幕有限，只能讓主體內容呈現出來，其余部分隱藏起來，并且讓字體縮小。

柵格布局

一提起響應式，絕對離不開強大的柵格布局，根據瀏覽器的寬度，設置容器不同的列寬。

<div class="row">
  <div class="col-xs-12 col-sm-6 col-md-8"></div>
  <div class="col-xs-12 col-sm-6 col-md-8"></div>
</div>

柵格布局的原理其實也是利用了媒體查詢，這樣你就可以自定義一份自己的柵格布局。

總結