1字節(jié)=1B，是我們計(jì)算機(jī)總的計(jì)量單位，一般我在中文搜索引擎優(yōu)化的關(guān)鍵詞至少也是4-8個(gè)字節(jié)，如果用到谷歌之類的外文搜索引擎那么每個(gè)單詞可以劃分為多長字節(jié)。而根據(jù)數(shù)據(jù)研究我們發(fā)現(xiàn)網(wǎng)絡(luò)性能對(duì)于谷歌的搜索排名是存在影響的，當(dāng)然在國內(nèi)的中文搜素引擎也是同樣適用的，不過因?yàn)橐粋€(gè)字母代表一個(gè)字節(jié)，而一個(gè)漢字代碼兩個(gè)字節(jié)，為了更清晰的來說明字節(jié)影響所以筆者選擇了谷歌為例來說明。

    在字節(jié)影響排名的研究中，我們發(fā)現(xiàn)更快的首字節(jié)時(shí)間與更高的搜索引擎排名之間存在明顯的相關(guān)性。雖然不能完全證明TTFB的減少直接導(dǎo)致搜索排名的增加，但存在足夠的相關(guān)性，至少可以保證對(duì)該問題進(jìn)行進(jìn)一步的討論。在開始之前我們先來普及一下何為TTFB，它是Time to First Byte的縮寫，指的是瀏覽器開始收到服務(wù)器響應(yīng)數(shù)據(jù)的時(shí)間，后臺(tái)處理時(shí)間+重定向時(shí)間，是反映服務(wù)端響應(yīng)速度的重要指標(biāo)。而且我們發(fā)現(xiàn)一般情況下TTFB速度更快的網(wǎng)站總體上排名比速度較慢的網(wǎng)站更高。而且我們發(fā)現(xiàn)這不僅適用于使用一個(gè)或兩個(gè)關(guān)鍵詞的常規(guī)搜索，而且適用于包含四個(gè)或五個(gè)關(guān)鍵詞的長尾詞的搜索。顯然這些數(shù)據(jù)顯示了一個(gè)有趣的趨勢(shì)——網(wǎng)站速度實(shí)際上影響著搜索排名。

    是什么影響了TTFB呢？通常情況下，我們認(rèn)為能夠影響TTFB指標(biāo)的有下面三個(gè)因素：

    1、我們的請(qǐng)求通過網(wǎng)絡(luò)傳播到Web服務(wù)器所花費(fèi)的時(shí)間

    2、Web服務(wù)器處理請(qǐng)求并生成響應(yīng)所花費(fèi)的時(shí)間

    3、響應(yīng)通過網(wǎng)絡(luò)傳播回我們的瀏覽器所花費(fèi)的時(shí)間。

    那么我們?yōu)榱烁纳芓TFB，是否必須減少每個(gè)組件的時(shí)間呢？要從哪里開始呢？首先我們需要知道的是如何測(cè)量TTFB。盡管現(xiàn)在互聯(lián)網(wǎng)上有許多工具可以測(cè)量TTFB，但我們只使用一種稱為WebPageTest的開源工具。使用WebPageTest是查看站點(diǎn)性能的好方法，以及查看是否需要花費(fèi)精力來優(yōu)化TTFB指標(biāo)。使用它只需訪問www.webpagetest.org，選擇最適合我們的用戶個(gè)人資料的位置，然后對(duì)我們的網(wǎng)站進(jìn)行測(cè)試。在大約30秒內(nèi)，WebPageTest將為我們返回一個(gè)圖，用來顯示我們的網(wǎng)頁加載的所有資源并詳細(xì)評(píng)估每個(gè)響應(yīng)時(shí)間。如果我們看瀑布圖的第一行，該行的綠色部分將顯示根HTML頁面的第一個(gè)字節(jié)的時(shí)間。如果我們的TTFB確實(shí)很慢，那么下一步就是確定導(dǎo)致速度變慢的原因以及可以采取的措施。但是在探討之前，我們需要簡短地談?wù)劇把舆t”。延遲是一個(gè)通常被誤解的概念，延遲是將單個(gè)數(shù)據(jù)從一個(gè)位置傳輸?shù)搅硪晃恢盟ㄙM(fèi)的時(shí)間。一個(gè)普遍的誤解是，如果我們具有快速的互聯(lián)網(wǎng)連接，則應(yīng)始終具有較低的延遲。

    快速的互聯(lián)網(wǎng)連接只是其中的一部分，加載頁面所需的時(shí)間不僅取決于連接的速度，還取決于瀏覽器對(duì)該頁面的遠(yuǎn)近。就好比是將我們的互聯(lián)網(wǎng)連接視為管道。我們的連接帶寬即“速度”越高，管道越寬。管道越寬，可以并行下載的數(shù)據(jù)越多。雖然這有助于整體數(shù)據(jù)吞吐量，但我們的瀏覽器所建立的每個(gè)特定連接仍然需要最小的距離。用圖來說明一下帶寬和延遲之間的差異。

    從圖片上我們可以看到，相同的JPG在較高和較低帶寬的情況下仍必須經(jīng)過相同的距離，其中距離由兩個(gè)主要因素定義：從A到B的物理距離。A和B之間的跳躍數(shù)，因?yàn)榛ヂ?lián)網(wǎng)流量通過越來越多的路由器進(jìn)行重定向，并且必須經(jīng)過更遠(yuǎn)的距離才能進(jìn)行交換。因此，雖然帶寬無疑對(duì)整體吞吐量最有好處，但我們?nèi)匀槐仨毥?jīng)過連接的初始距離才能加載頁面，這就是延遲的來源。那么我們?nèi)绾螠y(cè)量延遲呢？其實(shí)有最簡單的方法，ping它是將延遲與服務(wù)器處理時(shí)間分開的最佳工具。我們可以在大多數(shù)WindowsLinux系統(tǒng)上，默認(rèn)情況下都會(huì)預(yù)安裝ping工具。ping的作用是通過互聯(lián)網(wǎng)將非常小的信息包發(fā)送到我們的目標(biāo)URL，從而測(cè)量該信息到達(dá)和返回所花費(fèi)的時(shí)間。Ping實(shí)際上不占用服務(wù)器端的處理開銷，因此測(cè)量ping響應(yīng)時(shí)間可以使我們對(duì)TTFB的延遲組件有良好的感覺。我們從整個(gè)TTFB時(shí)間中減去ping時(shí)間，然后可以從服務(wù)器后端處理組件中分解網(wǎng)絡(luò)延遲組件以正確地集中優(yōu)化工作。從研究中，我們發(fā)現(xiàn)搜索排名最高的網(wǎng)站的TTFB低至350毫秒，排名較高的網(wǎng)站則將其推高至650毫秒，我們建議總TTFB為500ms或更短。在這500毫秒中，建議往返網(wǎng)絡(luò)延遲不超過100毫秒。如果我們有來自另一個(gè)大陸的大量用戶，則網(wǎng)絡(luò)延遲可能會(huì)高達(dá)200毫秒，但是如果該流量對(duì)我們很重要，那么我們可以采取其他措施來幫助我們，我們將盡快解決?？偠灾?，初始HTML頁面加載的理想目標(biāo)應(yīng)該是：

    1、到第一個(gè)字節(jié)的時(shí)間為500ms或更短

    2、往返網(wǎng)絡(luò)延遲不超過100毫秒

    3、后端處理時(shí)間不超過400毫秒

    那么如果我們的實(shí)際數(shù)字高于此數(shù)字要怎么辦呢？也不是很難解決，我們可以使用CDN改善延遲問題的，解決方案非常簡單，只要減少內(nèi)容與訪問者之間的距離就可以了。就是將我們的靜態(tài)內(nèi)容移動(dòng)到內(nèi)容交付網(wǎng)絡(luò)CDN中。CDN會(huì)自動(dòng)將我們的內(nèi)容復(fù)制到全球各地，并且地理位置更接近我們的用戶。因此，現(xiàn)在如果我們?cè)诿绹l(fā)布內(nèi)容，它將自動(dòng)復(fù)制到Syndey中的服務(wù)器，我們的英國用戶將從中下載該服務(wù)器。如圖所示，CDN在減少用戶請(qǐng)求的距離，從而減少TTFB的延遲部分方面有很大的不同：

    要影響TTFB，請(qǐng)確保我們選擇的CDN可以緩存網(wǎng)站首頁的靜態(tài)HTML不僅僅是圖片，Java和CSS等相關(guān)資源也是如此。因?yàn)檫@是Google bot會(huì)請(qǐng)求并測(cè)量TTFB的初始資源。TTFB中的第二個(gè)因素是服務(wù)器花費(fèi)在處理請(qǐng)求和生成響應(yīng)上的時(shí)間量。實(shí)質(zhì)上，后端處理時(shí)間是構(gòu)成網(wǎng)站的所有其他材料的性能：

    1、運(yùn)行我們的網(wǎng)站的操作系統(tǒng)和計(jì)算機(jī)硬件以及配置方式

    2、在該硬件如CMS上運(yùn)行的應(yīng)用程序代碼及其配置方式

    3、應(yīng)用程序?yàn)樯身撁娑M(jìn)行的任何數(shù)據(jù)庫查詢，其進(jìn)行的查詢次數(shù)，返回的數(shù)據(jù)量以及數(shù)據(jù)庫的配置

    其實(shí)如何優(yōu)化網(wǎng)站的后端是一直是個(gè)問題，雖然網(wǎng)上有不少攻略也不不少相關(guān)的書籍，但是筆者個(gè)人感覺還是要做好TTFB的優(yōu)化效果會(huì)更好一些。想要做好首先我們要有一個(gè)可以的網(wǎng)絡(luò)運(yùn)行設(shè)備，如果可以的話其實(shí)可以使用托管也是不錯(cuò)的選擇。選擇一個(gè)大的平臺(tái)，這樣服務(wù)器本身的有保證的，而且價(jià)格上也相對(duì)比較合適，當(dāng)然與此同時(shí)共享的風(fēng)險(xiǎn)也是存在的，端看我們企業(yè)本身對(duì)成本和風(fēng)險(xiǎn)評(píng)估來進(jìn)行決策。

    再來，我們需要來優(yōu)化后端軟件的性能，檢查一下我們的應(yīng)用程序或CMS的配置，是否有可以禁用的功能或日志記錄設(shè)置？是否處于“調(diào)試模式？我們希望可以擺脫掉這些不必要的操作，因?yàn)檫@些操作可以提高站點(diǎn)響應(yīng)請(qǐng)求的速度。如果我們的應(yīng)用程序或CMS使用的是PHP之類的解釋語言，則應(yīng)研究減少執(zhí)行時(shí)間的方法。解釋的語言具有將它們轉(zhuǎn)換為機(jī)器可理解的代碼的步驟，該代碼由服務(wù)器實(shí)際執(zhí)行。理想情況下，我們希望服務(wù)器執(zhí)行一次此轉(zhuǎn)換，而不是對(duì)每個(gè)傳入請(qǐng)求進(jìn)行一次轉(zhuǎn)換。盡管這些名稱可能會(huì)根據(jù)下劃線技術(shù)而有所不同，但通常稱為編譯或操作碼緩存。如果可能，利用服務(wù)器端緩存是快速生成動(dòng)態(tài)頁面的好方法。如果我們的頁面正在加載不經(jīng)常更改的內(nèi)容，則利用本地緩存返回這些資源是提高頁面加載時(shí)間性能的一種非常有效的方法。

    當(dāng)然，我們也可以使用不同的工具在不同級(jí)別進(jìn)行有效的緩存，并且高度依賴于我們?cè)诰W(wǎng)站后端使用的技術(shù)。一些緩存軟件僅緩存一種數(shù)據(jù)，而其他緩存軟件則進(jìn)行多級(jí)緩存。與我們將要進(jìn)行的任何軟件更改一樣，確保在逐步進(jìn)行每個(gè)更改時(shí)不斷測(cè)試對(duì)TTFB的影響。TTFB有3個(gè)組成部分，請(qǐng)求傳播到Web服務(wù)器所花費(fèi)的時(shí)間； Web服務(wù)器處理請(qǐng)求并生成響應(yīng)所花費(fèi)的時(shí)間；以及響應(yīng)傳播回我們的瀏覽器所花費(fèi)的時(shí)間。延遲捕獲了TTFB的第一部分和第三部分，可以通過WebPageTest和ping之類的工具進(jìn)行有效測(cè)量。服務(wù)器處理時(shí)間就是整個(gè)TTFB時(shí)間減去等待時(shí)間。我們建議TTFB時(shí)間不超過500毫秒，在TTFB中用于網(wǎng)絡(luò)延遲的時(shí)間不應(yīng)超過100 ms，而在后端處理上的時(shí)間不應(yīng)超過400 ms。

    最后，我們可以通過將內(nèi)容在地理位置上更靠近訪問者來改善延遲。只要CDN可用于為動(dòng)態(tài)基本HTML頁面提供服務(wù)，它就是實(shí)現(xiàn)此目標(biāo)的好方法。我們通常可以通過更好的服務(wù)器配置和緩存昂貴的操作來以多種方式提高網(wǎng)站后端的性能。