更快網站技術分析洞察

　　快速網站技術分析見解高級搜索引擎優化SEOpagespeed見解可能有用，但完美的成就并不** 快速網站。有更聰明的方法來評估和提高網站速度。

　　谷歌pagespeed是一個易于使用的工具，深國商網站則讓公司測試網頁是否可能比它慢。它給出了量化頁面性能的分數。因為這個分數是具體的，pagespeed意見分數經常被用作網站表現的衡量標準。同樣的pageRank在這一年又出現了，村民們認為優化這個數字只是因為它存在。事實上，這篇文章的熱門話題是：如何實現100/100和谷歌web速度測試工具。

　　在普通CMSes小網站（思想WordPress），這是可以做到的。如果是你，pagespeed這個想法是一個很好的開始。對于大多數人網站，完美的分數是不現實的。那我們從哪里開始呢

　　這就是這個職位的意義所在。我想談三點：

　　延遲會破壞帶寬上的加載時間

　　pagespeed意見達成不應受到重視

　　改進始于測量、目標設定和優先順序

　　我寫了SEO還記得。我將跳過一些技術方面的內容。你應該帶著足夠的視角離開，開始問正確的問題。因此，你可以提出更好的建議。

　　免責聲明：http2改進了本文討論的一些問題。具體來說，對同一服務器的請求較少。這不是萬能藥。

　　延遲會破壞帶寬上的加載時間

　　當我們第一次看到pagespeed規則時，您可以認為它是關于服務的字節數更少的用戶。收縮，優化，壓縮。只有一半大小的故事。您的請求到達服務器也需要時間。然后服務器需要時間來響應您！

　　你問的時候會發生什么

　　如果用戶在瀏覽器地址欄中鍵入URL并單擊enter，則請求。當很多事情發生的時候，要主動要求。** 后一部分是發送請求的內容。只有** 后一個比特受帶寬和內容大小的影響。

　　這些步驟（或多或少）是滿足請求所必需的：

　　找到服務器

　　連接到服務器

　　正在等待響應

　　接收響應

　　每一步都需要時間，而不僅僅是** 后一步。前三個獨立于文件大小，是有效的固定成本。無論負載是小的、減少的CSS文件還是巨大的未壓縮圖像，每次請求都會產生這些成本。

　　為什么需要時間才能得到回應

　　我們無法避免的因素是，網絡信號的傳播速度不能超過光速。這是一個理論上的** 大值，而在現實中，它將需要比數據傳輸更長的時間。例如，它使用光在巴黎和紐約之間傳輸40毫秒，如果它實際穿越大西洋所需的時間數據是它實際穿越大西洋所需時間的兩倍，那么** 短時間將是服務器80ms的響應。

　　這就是為什么CDN是常用的CDN物理接近用戶是減少服務器時間的唯一方法。

　　多少錢

　　請看這張圖片（來自Chrome工具）：

　　壽命要求，用鉻開發工具測量。

　　紅色框中的所有值是什么；延遲；。它們總是220毫秒，內容實際上被0.7ms傳輸，沒有壓縮文件大小可以幫助；減少請求所花費時間的唯一方法是減少延遲。

　　我們不需要提出很多請求來加載頁面嗎

　　加載頁面所需的所有內容需要多個請求。如果URL對應于網頁，瀏覽器通常會發現需要加載更多資源來呈現該頁面。這些文件可以是CSS、JavaScript或字體文件。它必須通過上面列出的相同步驟遞歸地加載每個文件。

　　幸運的是，一旦發現服務器，即DNS；在上面的圖像中，瀏覽器將不再需要找到它。它仍然需要連接，我們將不得不等待回應。

　　對質疑閱讀測試pagespeed的看法

　　所有pagespeed見解都會影響網站速度。對于大型網站，其中一些并不容易實現。根據你網站的設計方式，有些人會比其他人更有效。這不是說你有理由不去做這些事情——它們都是** 好的做法，它們都在幫助你。但它們并不代表整個網站速度圖片。

　　記住，這里；懷疑；閱讀每個pagespeed意見規則。

　　降低帶寬使用率的測試

　　規則

　　懷疑的閱讀

　　優化圖像

　　除非你有巨大的圖像，否則這可能不是一個大問題。這只是一個衡量圖像是否可以進一步壓縮的度量，如果加載太多，則不可以。

　　壓縮

　　壓縮很容易。你應該用它。它也可能沒有什么大的區別，除非您有（例如）一個巨大的JavaScript文件要加載。

　　減少的HTML

　　可能只減少幾十KB的開銷。延遲將比響應大小產生更大的影響。

　　收縮CSS

　　可能只減少幾十KB的開銷。延遲將比響應大小產生更大的影響。

　　壓縮JS文件

　　它可能不如將JS合并到單個文件中那么重要，從而減少了請求的數量。

　　減少延遲測試

　　規則

　　懷疑的閱讀

　　瀏覽器緩存

　　當然，讓我們緩存自己的文件。許多可能從緩存中受益的文件可能托管在第三方服務器上。你必須自己改變緩存時間。

　　縮短服務器響應時間

　　閾值太高。它還嘗試排除服務器的物理延遲，只查看服務器對請求的響應時間。

　　避免登錄頁重定向

　　對。

　　消除上面的渲染阻塞JavaScript和折疊內容CSS

　　一個有效的焦點，但可能很難。在初始頁面加載的頂部呈現零請求，并在折疊內容上呈現，對于滿足大多數性能目標來說，不必如此。

　　放置可見內容

　　這真的很重要。

　　不要把這當成網站性能的** 后一個字！獨立于這些測試，有一些事情要考慮。部分不包括在所有pagespeed意見中，有的只涵蓋其中一半：

　　緩存內容控件。

　　減少從第三方域加載的內部容量。

　　將服務器響應時間減少到超出要求的范圍，通過pagespeed意見測試的** 小值。

　　移動服務器接近** 終用戶。基本上，使用CDN。

　　減少阻塞請求。確保使用http2將在這里提供幫助。

　　如何開始改進

　　測量

　　在本文中，屏幕截圖工具創建了chrome。它內置在瀏覽器中，允許您檢查頁面加載時發生的情況。

　　他們不相信pagespeed意見工具來加載Chrome瀏覽器中的頁面。檢查它的工作原理。看看需要什么實際上似乎需要更多的時間。答案通常是顯而易見的：例如，加載廣告會花費太多時間。

　　目標設定

　　如果一個完美的pagespeed意見分數不是你的目標，你需要知道你的目標是什么。這一點很重要，因為它允許您將當前績效與目標進行比較。您可以看到減少帶寬需求是否真的能實現您的目標，或者您是否需要采取其他措施來減少延遲（使用CDN，處理更少的請求，并首先加載高優先級內容）。

　　優先

　　優先頁面速度；修理；這很重要-這不是唯一的優先權。還有一個問題是，實際需要加載什么pagespeed，并嘗試找出您是否比內容具有優先級。這是一個偉大的目標。這也不是一個完美的評估。它更可能被分成“1”；鑰匙；“和”；非關鍵的；褶皺表面的路徑內容。

　　例如：如果你的網站依賴于廣告收入，你可以在開始加載廣告之前加載頁面上的所有內容。畢竟，pagespeed的想法是一對一的解決方案。

　　結論

　　到目前為止，pagespeed見解可能有用，但也有更聰明的方法來評估和加速網站。一個完美的分數不能** 一個快速網站。

　　如果您有興趣了解更多信息，我強烈建議您查看Ilyagrigorik's網站來介紹這個古老而很好的deck格里高利克是谷歌中的Web性能測試工程師，也是網站速度問題的很好溝通者。