整合營銷服務(wù)商
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數(shù)據(jù)同步管理
免費咨詢熱線：
然我們生活在一個寬帶無處不在、4/5G 幾乎全覆蓋的時代，但網(wǎng)站加載緩慢還是常態(tài)，就算我們打開一個以文本為中心的新聞網(wǎng)站，都可能需要至少 30 秒才能開始閱讀。畢竟在內(nèi)容膨脹時代，一張照片就能輕易超過 1MB 大小，許多網(wǎng)站為了顯示幾段文本，還會單獨加載至少 10MB 的 JS 和自定義字體。
對此，對優(yōu)化和極簡主義充滿熱情的資深 Web 開發(fā) Nathaniel 告訴我們，你應(yīng)該讓你的網(wǎng)頁盡力控制在 14KB 以內(nèi)，而且即使對于以富媒體為中心的網(wǎng)站，這條 14KB 的規(guī)則可能仍然值得遵循。如果 14KB 不足以用于最終布局，則需要優(yōu)先考慮“首屏”字節(jié)，可以用發(fā)送給訪問者的前 14KB 數(shù)據(jù)來渲染一些有用的東西，減少用戶還沒有開始閱讀就流失掉的機會。
網(wǎng)頁越小，加載速度就越快——這一點都不奇怪。
但令人感到驚訝的是，14KB 網(wǎng)頁的加載速度比 15KB 要快得多——可能快 612 毫秒——而 15KB 和 16KB 網(wǎng)頁之間的加載速度差異微乎其微。
這是 TCP 慢啟動算法導(dǎo)致的。本文將介紹這個算法、它的原理以及為什么你應(yīng)該關(guān)注它。但首先我們需要快速過一遍一些基礎(chǔ)知識。
傳輸控制協(xié)議（Transmission Control Protocol，TCP）是一種使用 IP 協(xié)議可靠地發(fā)送數(shù)據(jù)包的方法——有時被稱為 TCP/IP。
當瀏覽器向你的網(wǎng)站（或圖像或樣式表）發(fā)出請求時，它會使用 HTTP 請求。HTTP 建立在 TCP 之上，一個 HTTP 請求通常由許多 TCP 數(shù)據(jù)包組成。IP 只是一個將數(shù)據(jù)包從互聯(lián)網(wǎng)上的一個位置發(fā)送到另一個位置的系統(tǒng)。IP 沒有檢查數(shù)據(jù)包是否成功到達目的地的方法。
對于網(wǎng)站來說，確保所有的數(shù)據(jù)到達請求端是非常關(guān)鍵的，否則我們可能會因為丟失數(shù)據(jù)包無法獲得完整的網(wǎng)頁。但在網(wǎng)絡(luò)的其他應(yīng)用場景中，這一點并不那么重要——比如流媒體直播視頻。
TCP 是 IP 的擴展，瀏覽器和網(wǎng)站服務(wù)器通過它告訴對方哪些數(shù)據(jù)包已經(jīng)成功到達。
服務(wù)器發(fā)送一些數(shù)據(jù)包，然后等待瀏覽器已經(jīng)收到數(shù)據(jù)包的響應(yīng)（這叫確認或 ACK），然后它繼續(xù)發(fā)送更多的數(shù)據(jù)包——或者如果它沒有收到 ACK，將再次發(fā)送相同的數(shù)據(jù)包。
TCP 慢啟動是一種算法，服務(wù)器用它來確定一次可以發(fā)送多少數(shù)據(jù)包。
當瀏覽器第一次連接到服務(wù)器時，服務(wù)器無法知道它們之間的帶寬是多少。帶寬是指在單位時間內(nèi)網(wǎng)絡(luò)可以傳輸?shù)臄?shù)據(jù)量。通常以比特/秒（b/s）為單位。我們可以用管道來作類比——把帶寬想象成每秒從管道流出多少水。
服務(wù)器不知道網(wǎng)絡(luò)連接可以處理多少數(shù)據(jù)——所以它先發(fā)送少量且安全的數(shù)據(jù)——通常是 10 個 TCP 數(shù)據(jù)包。如果這些數(shù)據(jù)包成功地到達網(wǎng)站訪問者，他們的計算機返回確認（ACK），表示數(shù)據(jù)包已經(jīng)被收到了。然后，服務(wù)器發(fā)送更多的數(shù)據(jù)包，但這一次它將數(shù)據(jù)包的數(shù)量增加了一倍。
這個過程會不斷重復(fù)，直到數(shù)據(jù)包丟失，服務(wù)器沒有收到 ACK。（此時，服務(wù)器會繼續(xù)發(fā)送數(shù)據(jù)包，但速度較慢）。
這就是 TCP 慢啟動的要點——在現(xiàn)實當中，雖然算法各不相同，但這是它的基本原理。
大多數(shù) Web 服務(wù)器的 TCP 慢啟動算法都是從發(fā)送 10 個 TCP 數(shù)據(jù)包開始的。
TCP 數(shù)據(jù)包最大長度為 1500 字節(jié)。這個最大值不是由 TCP 規(guī)范設(shè)置的，它來自于以太網(wǎng)標準。
每個 TCP 數(shù)據(jù)包的標頭占了 40 個字節(jié)，其中 16 個字節(jié)用于 IP，另外 24 個字節(jié)用于 TCP。
這樣每個 TCP 數(shù)據(jù)包還剩下 1460 個字節(jié)。10 x 1460 = 14600 字節(jié)，或大約 14KB！
因此，如果你能把網(wǎng)站的網(wǎng)頁——或網(wǎng)頁的關(guān)鍵部分——壓縮到 14KB，就可以為訪問者節(jié)省大量的時間——他們和網(wǎng)站服務(wù)器之間的往返時間。
一個數(shù)據(jù)往返能有多糟糕？但人們非常沒有耐心——一個數(shù)據(jù)往返可能會出奇地長，具體多長取決于延遲……延遲是指數(shù)據(jù)包從源傳輸?shù)侥康牡厮ㄙM的時間。如果帶寬是每秒鐘可以通過管道的水的數(shù)量，那么延遲就是一滴水進入管道后從另一端流出所花費的時間。
下面是一個關(guān)于延遲有多糟糕的例子。
衛(wèi)星網(wǎng)絡(luò)是由環(huán)繞地球軌道的衛(wèi)星提供的，在人煙稀少的地區(qū)、石油鉆井平臺、游輪以及飛機上，人們可以使用這種網(wǎng)絡(luò)。
為了說明這種糟糕的延遲，我們想象一群在石油鉆井平臺工作的兄弟把骰子忘在了家里，他們需要通過 missingdice.com（少于 14KB）來玩《龍與地下城》游戲。
首先，他們中的一個用手機發(fā)出一個網(wǎng)頁請求……
手機將請求發(fā)送到鉆井平臺的 WiFi 路由器，路由器將數(shù)據(jù)發(fā)送給平臺上的衛(wèi)星天線，我們假設(shè)這可能需要 1 毫秒時間。
然后，衛(wèi)星天線將數(shù)據(jù)發(fā)送到地球軌道上方的衛(wèi)星。
通常，這是通過在地球表面上方 35786 公里處運行的軌道衛(wèi)星實現(xiàn)的。光速為 299792458 米/秒，所以信息從地球發(fā)送到衛(wèi)星需要 120 毫秒。然后，衛(wèi)星將信息傳回地面接收站，這又需要 120 毫秒。
然后，地面站必須將請求發(fā)送到位于地球任意位置的服務(wù)器（當光通過光纖電纜傳輸時，速度會降至每秒 200000000 米）。如果地面站和服務(wù)器之間的距離等于紐約到倫敦之間的距離，那么大約需要 28 毫秒，如果地面站和服務(wù)器之間的距離等于紐約到悉尼之間的距離，則需要 80 毫秒——所以我們姑且定一個 60 毫秒的數(shù)字（這個數(shù)字便于計算）。
然后，服務(wù)器需要處理請求，這可能需要 10 毫秒，然后服務(wù)器再次將它發(fā)送出去。
回到地面站，進入太空，回到衛(wèi)星天線，然后回到無線路由器，再到手機上。
手機 -> WiFi 路由器 ->衛(wèi)星天線 ->衛(wèi)星 -> 地面站 -> 服務(wù)器 -> 地面站 -> 衛(wèi)星 -> 衛(wèi)星天線 -> WiFi 路由器 -> 手機
如果我們算一下，就是 10 + ( 1 + 120 + 120 + 60 ) x 2 = 612 毫秒。
這是每次往返額外的 612 毫秒——也許這看起來不是很長時間，但你的網(wǎng)站可能只是為了獲取第一個資源就需要許多個往返。
另外，HTTPS 在完成第一個往返之前需要額外的兩次往返——這使延遲達到了 1836 毫秒！
衛(wèi)星網(wǎng)絡(luò)似乎是一個極端的例子——我選擇它作為例子是因為它能夠充分說明了網(wǎng)絡(luò)延遲這個問題——但對于生活在陸地上的人來說，延遲可能比這更糟糕，原因有很多。
不穩(wěn)定的網(wǎng)絡(luò)連接也會導(dǎo)致數(shù)據(jù)包丟失——導(dǎo)致需要另一個往返來獲取丟失的數(shù)據(jù)包。
了解了 14KB 法則，接下來可以做些什么
當然，你應(yīng)該讓你的網(wǎng)頁盡可能的小——你愛你的訪客，你希望他們開心。將每個頁面的大小控制在 14KB 以內(nèi)是一個不錯的主意。
這 14KB 可以是壓縮數(shù)據(jù)——所以實際上可以對應(yīng)大約 50KB 的未壓縮數(shù)據(jù)——這已經(jīng)非常慷慨了。要知道，阿波羅 11 的制導(dǎo)計算機只有 72KB 內(nèi)存。
去掉自動播放的視頻、彈出窗口、Cookie、Cookie 橫幅、社交網(wǎng)絡(luò)按鈕、跟蹤腳本、JavaScript 和 CSS 框架，以及所有其他人們不喜歡的垃圾——你可能就能實現(xiàn) 14KB 法則。
假設(shè)你已經(jīng)盡力將所有內(nèi)容控制在 14KB 以內(nèi)，但仍然做不到——但 14KB 法則仍然很有用。
你可以用發(fā)送給訪問者的前 14KB 數(shù)據(jù)來渲染一些有用的東西——例如一些關(guān)鍵的 CSS、JS 和解釋如何使用你的應(yīng)用程序的前幾段文本。
需要注意的是，14KB 法則包含了 HTTP 標頭——這些是未壓縮的（即使是 HTTP/2 的第一個響應(yīng)），也包含圖片，所以你應(yīng)該只加載在頁面上方的內(nèi)容，并保持它們最小，或者使用占位符，讓訪問者知道他們在等待一些更好的內(nèi)容。
14KB 法則更像是一種經(jīng)驗之談，而不是計算的基本法則。
有一種觀點認為，在使用 HTTP/2 時，14KB 法則不再適用。我已經(jīng)讀了所有我能讀到的關(guān)于這個問題的東西，但我還沒有看到任何證據(jù)表明使用 HTTP/2 的服務(wù)器已經(jīng)停止使用 TCP 慢啟動（從 10 個數(shù)據(jù)包開始）。
與 HTTP/2 類似，有一種觀點認為 HTTP/3 和 QUIC 將廢除 14KB 法則——事實并非如此。實際上，QUIC 仍然建議使用 14KB 法則。
原文鏈接：
https://endtimes.dev/why-your-website-should-be-under-14kb-in-size/
有一個最佳的屏幕尺寸可以設(shè)計。網(wǎng)站應(yīng)在不同的瀏覽器和平臺上以所有屏幕分辨率快速響應(yīng)地進行轉(zhuǎn)換。無障礙。移動友好。首先為您的訪客設(shè)計。從360×640到1920×1080的設(shè)計。
它仍然應(yīng)該看起來不錯，并且在所有尺寸下都可以正常工作，現(xiàn)在我們的建議是建設(shè)一個自適應(yīng)/響應(yīng)式網(wǎng)站。
針對特定屏幕尺寸優(yōu)化頁面布局的三個主要標準是：
可用性準則還建議您考慮所有大小的所有三個條件。檢查瀏覽器窗口的屏幕分辨率為360×640到1920×1080。
在整個分辨率范圍內(nèi)，您的網(wǎng)頁在所有條件上的得分都應(yīng)該很高。
您的頁面也應(yīng)該以更大或更小的尺寸工作，盡管這種極端情況不那么重要。
盡管此類用戶當然應(yīng)該能夠訪問您的網(wǎng)站，但為他們提供小于設(shè)計的外觀有時是可以接受的折衷方案。
2020年的前6個月中，對451,027個訪客進行了訪客分析：
屏幕分辨率測試用戶數(shù)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％）
響應(yīng)式Web設(shè)計：在相同的URL上提供相同的HTML代碼，而不管用戶的設(shè)備（例如，臺式機，平板電腦，移動設(shè)備，非可視瀏覽器）如何，但是可以根據(jù)屏幕大小來不同地呈現(xiàn)顯示。 百度建議使用響應(yīng)式Web設(shè)計，因為它是最容易實現(xiàn)和維護的設(shè)計模式。
在當今世界，許多人正在使用手持設(shè)備（平板電腦和智能手機）瀏覽網(wǎng)頁，而響應(yīng)式網(wǎng)站設(shè)計（RWD）已經(jīng)成為解決屏幕尺寸挑戰(zhàn)的極有可能的解決方案。
此方法不再使用固定寬度的網(wǎng)站，而是使用CSS樣式表中的“媒體查詢”來創(chuàng)建一個網(wǎng)站，該網(wǎng)站在大小上響應(yīng)手持設(shè)備的不同視口以及人們使用的較小屏幕。
因此，無論人們使用什么設(shè)備來查看您的網(wǎng)站，您都可以為他們提供最完整的體驗。
如果您想為高競爭力的關(guān)鍵詞在百度獲得高排名，您就需要一個適合移動設(shè)備的網(wǎng)站。
網(wǎng)站對移動設(shè)備的友好程度如何影響各種設(shè)備對網(wǎng)站的排名效果。如果您為小型企業(yè)創(chuàng)建網(wǎng)站，您會知道他們想要一個在百度自然搜索中表現(xiàn)良好的網(wǎng)站。
目前從本質(zhì)上講，這意味著網(wǎng)站設(shè)計具有響應(yīng)性并且對移動設(shè)備友好，尤其是對于百度而言。
作為參考，以下是最近（2020年）記錄的當前全球頂級屏幕分辨率的列表：
你不能。不可能將網(wǎng)站設(shè)計成在每個瀏覽器，平臺和屏幕分辨率下看起來都一樣，所以請避免嘗試。
您可以選擇不帶表格的流暢布局來進行設(shè)計，其寬度百分比可以擴展和收縮以適合訪問者瀏覽器的設(shè)置，或者您可以考慮研究能夠?qū)崿F(xiàn)相同效果的響應(yīng)式設(shè)計解決方案。
搜索引擎偏愛響應(yīng)式設(shè)計，這對于采用它的人來說是個好消息。移動技術(shù)正在興起-因此，如果要開發(fā)一個新網(wǎng)站-您必須從一開始就考慮您的網(wǎng)站對移動設(shè)備的友好程度。
在實際編寫代碼時，我們的目標是使事情簡單。從經(jīng)驗中我們知道的是， 對于您而言，確定您的受眾及其使用的設(shè)備，并從整體上構(gòu)建適合該受眾的網(wǎng)站至關(guān)重要，受眾也包括搜索引擎。
好吧，那不是理想的。實際上，它從未如此。
追溯到今天-一些人使用網(wǎng)站的純文本版本為不支持其網(wǎng)站元素的用戶/瀏覽器生成內(nèi)容-試圖（通常是徒勞的）使他們的內(nèi)容更易于訪問。
W3C甚至曾經(jīng)推薦它，我們認為如果其他所有方法都失敗了：
為訪問者目的而向訪問者傳遞一個URL始終是理想的選擇，并且如果您正在考慮創(chuàng)建網(wǎng)站的“移動”版本，則在傳遞移動或智能手機內(nèi)容時沒有任何區(qū)別。
百度可能會在不久的將來對您的移動體驗做出主要評價-因此，我們所有人都確實需要意識到我們可能很快會在百度的SERP中看到巨大的變化。
當百度作為“訪問者”時，由于搜索引擎的典型URL挑戰(zhàn)，通常只提供一個URL甚至更為重要-在前一段時間實施規(guī)范鏈接元素之前就是這種情況。
因此，理想的情況是始終提供一個URL。
百度在這方面給出了建議：“如果您具有“智能手機”內(nèi)容（我們將其視為普通的Web內(nèi)容，因為它通常是普通的HTML頁面，只是在布局上進行了調(diào)整以顯示較小的內(nèi)容），則可以使用rel = canonical指向您的桌面版本。這有助于我們專注于網(wǎng)絡(luò)搜索的桌面版本。當用戶使用智能手機訪問該桌面版本時，您可以將他們重定向到移動版本。無論URL結(jié)構(gòu)如何，此方法均有效，因此您無需為智能手機移動網(wǎng)站使用子域/子目錄。 然而，更好的方法是使用相同的URL并顯示內(nèi)容的適當版本而無需重定向。”
百度還提供了以下提示，以檢查您的網(wǎng)站是否準備好使用移動優(yōu)先索引，但是從本質(zhì)上講，如果您正在為網(wǎng)站使用響應(yīng)式網(wǎng)頁設(shè)計模板，則此更改的問題應(yīng)該很小：
過去的網(wǎng)頁用戶通常不需要滾動，但多年來，這種情況已經(jīng)改變。
因此，在設(shè)計時，應(yīng)考慮如果用戶只滾動一個完整屏幕或兩個屏幕，可以看到多少內(nèi)容。超過五個屏幕的長度可能表示您頁面上的內(nèi)容過多。當然，用戶希望等待更短的時間來查看更全面的內(nèi)容。
滾動和初始可見性顯然都取決于屏幕尺寸：較大的屏幕在屏幕上方會顯示更多內(nèi)容，并且需要較少的滾動。
不一定，但是有可能。
與百度優(yōu)化有關(guān)的許多事情–建立一個適合移動設(shè)備的網(wǎng)站或多或少可以確保您保持已經(jīng)獲得的訪問量，并不一定能為您提供來自百度的更多免費訪問量。
百度及其用戶再次提高了質(zhì)量標準，如果您想在更具競爭力的SERP中競爭，這是小企業(yè)克服困難的又一個障礙。
從長遠來看，這種移動轉(zhuǎn)化僅對您的用戶來說是一件好事，但從短期來看，對小型企業(yè)的轉(zhuǎn)化率不會產(chǎn)生什么影響，因為通過移動設(shè)備獲得的轉(zhuǎn)化率通常低于桌面。
百度表示，這種適用于移動設(shè)備的算法對SERP的影響更大，隨著時間的流逝，我們將發(fā)現(xiàn)更多信息。
百度站長工具
您應(yīng)該能夠在百度站長工具中跟蹤移動設(shè)備錯誤，并且如果您的網(wǎng)站配置正確，錯誤會隨著時間的流逝而消失。
體查詢
響應(yīng)式網(wǎng)頁是這幾年很流行的網(wǎng)頁風格之一，他能夠以一套網(wǎng)頁代碼，面對不同的條件，例如改變?yōu)g覽器的寬度，手機橫豎屏，作出不同的樣式調(diào)整。
一套代碼走天下
最出名的響應(yīng)式框架是Bootstrap，來自Twitter。也是每個剛?cè)腴T前端開發(fā)師必學的框架，利用這個框架可以很輕松實現(xiàn)響應(yīng)式效果。
面對不同的瀏覽器寬度，作出界面調(diào)整
要實現(xiàn)響應(yīng)式，關(guān)鍵在于使用媒體查詢 Media！
@media （媒體特性）and （媒體特性） {你的樣式}
看起來好像很復(fù)雜，先看完整的代碼
@media (max-width:480px){
body{background-color:green}
}上面這句話的意思，瀏覽器的寬度小于或等于480px時，背景顏色是綠色。
再來多一個，如下
@media (min-width:481px){
body{background-color:red}
}上面這句話的意思，瀏覽器的寬度大于或等于481px時，背景顏色是紅色。
媒體特性
媒體特性就是依據(jù)什么樣的條件來進行更改樣式，是根據(jù)屏幕寬度大小、還是橫豎屏呢。這些條件都是官方定的，非常多。但實際上，真正有用的就是 min-width和max-width，根據(jù)瀏覽器寬度來設(shè)定不同的樣式。
這里會很容易混淆min-width和max-width的意義。min-width表示大于等于，max-width表示小于等于。
@media (max-width: 500px) {
/** 窗口寬度小于等于500像素的樣式 **/
}@media (min-width: 800px) {
/** 窗口寬度大于等于800像素的樣式 **/
}當有多個媒體特性時，用and連接，就可以形成一個區(qū)間范圍
@media (min-width: 600px) and (max-width: 700px) {
/** 窗口寬度在600-700像素的樣式 **/
}這就是他最基本的用法，凡是有兩面性，下面來說說他的優(yōu)缺點。
優(yōu)點
（1）面對不同分辨率設(shè)備靈活性強
（2）能夠快捷解決多設(shè)備顯示適應(yīng)問題
缺點
（1）兼容各種設(shè)備工作量大，效率低下
（2）代碼累贅，會出現(xiàn)隱藏無用的元素，加載時間加長
全局布局
下面這種響應(yīng)式布局最為常見，通過媒體查詢定義不同的樣式，讓其能夠適應(yīng)手機瀏覽器和桌面瀏覽器：
1、電腦端大屏幕下，網(wǎng)頁元素全部展示
電腦端樣式
2、手機端下，因為屏幕有限，只能讓主體內(nèi)容呈現(xiàn)出來，其余部分隱藏起來，并且讓字體縮小。
手機端樣式
柵格布局
一提起響應(yīng)式，絕對離不開強大的柵格布局，根據(jù)瀏覽器的寬度，設(shè)置容器不同的列寬。
<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>只需要按照填寫bootstrap參數(shù)，即可匹配不同的寬度
柵格布局的原理其實也是利用了媒體查詢，這樣你就可以自定義一份自己的柵格布局。
部分源代碼
*請認真填寫需求信息，我們會在24小時內(nèi)與您取得聯(lián)系。
