這篇研究文章將分析了500萬+個桌面和移動頁面，以瞭解哪些因素會影響頁面速度。
首先，我們為TTFB、Visual Complete和完全載入時間指標建立了全球基準。
然後，我們研究了影象壓縮、CDN和託管如何影響網站載入速度。
我們的資料揭示了一些非常有趣（且令人驚訝）的見解。
以下是我們主要發現的摘要：
1. 在我們對520萬頁的分析中，桌面端的平均首位元組時間 (TTFB) 速度在桌面端為1.286秒，在移動端為2.594秒。完全載入網頁所需的平均時間在桌上型電腦上為10.3秒，在移動裝置上為27.3秒。
2. 平均網頁在移動裝置上的載入時間比在桌面裝置上多87.84% 。
3. 在比較主要的CMS時，Squarespace和Weebly具有最佳的整體移動頁面速度效能。Wix和WordPress排名接近底部。
4. 在桌面上，CDN對TTFB的影響最大。然而，在移動裝置上，HTML請求的數量似乎對TTFB的影響最大。
5. 整體頁面大小對桌面和移動“Visual Complete”載入速度有顯著影響。與較小頁面相比，較大頁面的視覺載入時間要長318%。我們還發現gzip壓縮有助於在桌面和移動裝置上更快地載入影象。
6. 總頁面重量是完全載入頁面速度的第一決定因素。輕型頁面的完全載入速度比大型頁面快486%。
7. Wink和Gatsby是最快的Javascript框架。Meteor和Tweenmax是最慢的。最快的框架比最慢的.
8. 檔案壓縮率非常低或非常高的頁面具有高於平均水平的頁面速度效能（通過First Contextual Paint測量）。
9. 第三方指令碼顯著降低頁面載入速度。新增到頁面的每個第三方指令碼都會將載入時間增加34.1毫秒。
10. 我們發現使用響應式影象可以帶來最佳的整體影象載入效能。使用WebP在減少影象載入時間方面效果明顯較差。
11. GitHub和Weebly網路主機具有最快的整體TTFB效能。在我們分析的託管服務提供商中，Siteground和Wix是最慢的。
12. 中國、日本和德國的TTFB載入時間最快。澳大利亞、印度和巴西的TTFB時間最慢。
13. CDN使用與較差的頁面速度效能相關。這可能是因為某些CDN的效能明顯優於其他CDN。
關鍵頁面速度載入時間指標的基準
我們的首要任務是為重要的頁面速度指標建立基準。
您可能知道，“頁面速度”實際上由幾個不同的階段組成。
其中一些階段發生在伺服器級別。其他的發生在使用者的瀏覽器中。
為了充分了解頁面載入的速度，我們需要深入研究每個階段。
具體來說，我們確定了以下情況的平均速度：
- TTFB：到HTML文件響應的第一個位元組的時間
- StartRender：渲染開始時
- Visual Complete：使用者可以看到所有頁面資產
- Speed Index：使用者看到頁面載入的速度
- onLoad：當所有頁面資源（CSS、圖片等）都下載完成時
- Fully Loaded：當頁面在使用者瀏覽器中100%載入時
桌面上的平均TTFB速度為1.286秒，移動裝置上為2.594秒。
桌面上的平均開始渲染速度為2.834秒，移動裝置上為6.709秒。
平均視覺完成速度在桌面上為8.225秒，在移動裝置上為21.608秒。
桌面上的平均速度指數速度為 4.782 秒，移動裝置上為11.455秒。
桌面上的平均載入速度為8.875秒，移動裝置上為23.608秒。
平均滿載速度在桌上型電腦上為10.3秒，在移動裝置上為27.3秒。
關鍵要點：網頁的平均頁面載入速度在桌面上為10.3秒，在移動裝置上為27.3秒。平均而言，頁面在移動裝置上的載入時間比在桌面裝置上的載入時間長87.84%。
Weebly和Squarespace整體速度效能最佳，WordPress墊底
談到頁面速度，哪個CMS最好？
為了回答這個問題，我們確定了用於我們資料集中所有站點的CMS。然後，我們比較了我們發現的每個CMS的TTFB效能。
根據我們的資料，Weebly和Squarespace在桌上型電腦上名列前茅。
在移動頁面速度方面，Squarespace排名第一…… Adobe Experience Manager和Weebly位列前三。
值得注意的是，在移動速度方面，WordPress僅排在我們分析的CMS第14位。
另一個流行的CMS，Wix，在桌面和移動載入速度方面的評價也很差。
儘管WordPress為大約30%的網站提供支援，但它顯然沒有針對頁面載入速度進行優化。這並不是說WordPress是一個糟糕的CMS。它具有其他優勢（例如易用性、龐大的外掛庫和SEO），使其成為許多網站所有者的首選CMS。
但是，當嚴格檢視網站載入速度時，其他CMS似乎比WordPress具有明顯的優勢。
要點：在主要的CMS中，Squarespace和Weebly的移動頁面速度效能最好。WordPress和Wix排名接近底部。當然，WordPress網站可以通過一系列的優化，比如CDN、快取、效能外掛等方式來進行加速。
使用CDN可能有助於桌面TTFB。最小化HTML請求是移動TTFB的關鍵
我們分析了各種頁面特徵對TTFB（第一個位元組的時間）的影響。
這是我們發現的：
如您所見，使用CDN似乎可以改善桌面和移動裝置的TTFB。但是，與移動裝置相比，CDN在桌面裝置上似乎更有幫助。在通過移動裝置載入的頁面上，HTML請求的數量對TTFB的影響最大。
雖然我們確實發現了各種頁面特徵和TTFB時間之間的關係，但頁面級別的因素不會成就或破壞TTFB。TTFB很大程度上取決於伺服器的響應時間，我們稍後會介紹。
關鍵要點：使用CDN並最小化HTML請求可能會加速桌面和移動裝置上的TTFB。
與小頁面相比，大頁面“Visual Complete”的載入時間要長381%
“Visual Complete”是指載入使用者瀏覽器內網頁的所有視覺內容。
可能有指令碼和其他資產在螢幕外載入。但從使用者的角度來看，頁面已載入。
Visual Complete是一個重要的頁面速度指標，因為它會影響使用者對頁面載入速度有多快或多慢的主觀體驗。
只要使用者可以看到和使用該頁面，它就已完全載入……即使在幕後可能仍有資產載入和渲染。
我們發現頁面大小（bytesTotal）對移動和桌面視覺完成載入時間有顯著影響。
但是，與桌面相比，移動裝置上的頁面大小更為重要。
在桌面上，CDN的使用與更快的Visually Complete載入速度密切相關。頁面大小緊隨其後。
在移動裝置上，CDN只是第五個最重要的因素。
因此，如果提高移動載入速度是您的首要任務，我會考慮儘可能減少頁面大小。這可能意味著刪除第三方指令碼。或壓縮影象。具體步驟取決於您的站點。但是，很明顯，當涉及到Visually Complete速度時，這完全與HTML大小有關。
關鍵要點： CDN可以顯著提高桌面和移動裝置上的Visually Complete頁面速度。但是，CDN對桌面載入的影響要大得多。對於移動裝置，總頁面大小是Visually Complete載入時間的最重要因素。
總頁面大小與“Fully Loaded”頁面速度密切相關
最後，我們研究了影響“Fully Loaded”頁面速度的因素。
顧名思義，Fully Loaded是指100%的頁面資源被載入和渲染。
當談到完全載入的頁面速度時，頁面的總大小是迄今為止桌面和移動裝置上最重要的因素。
請求的數量也會影響頁面完全載入的速度。
這些資料的有趣之處在於桌面和移動裝置之間有很強的重疊。與我們分析的許多其他指標不同，桌面端和移動端完全載入似乎受到同一組變數（即頁面大小和HTML請求總數）的影響。
然而，頁面大小和HTML請求的重要性不應該讓人大吃一驚。
壓縮影象、快取和其他步驟通常會減少頁面載入所需的時間。但他們只能走這麼遠。歸根結底，要使頁面“Visual Complete”，瀏覽器必須載入頁面上的所有資產。而且要載入的資產越多，頁面載入所需的時間就越長。
這可能就是為什麼CDN似乎對完全載入頁面速度沒有太大影響的原因（在桌面上的總體重要性排名第三，在移動裝置上排名第十）。CDN可以提高影象載入時間。但是它們對3rd方指令碼和其他可能減慢速度的資產沒有多大幫助。
關鍵要點：總大小對完全載入頁面速度的影響大於桌面和移動裝置上的任何其他變數。與小頁面 (<0.83 MB) 相比，大頁面 (>3.49 MB) 的完全載入時間要長486%。
Wink和Gatsby是用於中等大小網頁的最快JavaScript框架
當談到優先載入頁面上的內容（以及何時）時，JavaScript框架做了很多繁重的工作。
這就是為什麼幾乎76%的網站使用這些框架來建立高效、安全和標準化的頁面。
我們首先收集了每個框架在網路上使用頻率的基準。
React是迄今為止最常用的JS框架（25.3%的網站使用它）。TweenMax (10.3%) 和RequireJS (9.5%) 也相當受歡迎
接下來，我們想弄清楚哪些JavaScript框架在小型（<1,264,374位元組）中型（1,264,374至4,019,332位元組）和大型（>4,019,332位元組）頁面上表現最佳。
對於小頁面，RightJS名列前茅。
對於中等頁面，Wink和Gatsby表現最好。
對於大頁面，Gatsby和Riot的FCP時間最快。
總的來說，JavaScript框架的選擇會對FCP時間產生重大影響。事實上，對於中等大小的頁面，最好的JS框架（Wink）的載入速度比最慢的框架（Meteor）快213%。
儘管表現最好的和最差的有很多重疊（例如，Gatsby和RightJS在所有三個頁面大小類別中都排在前5位），但似乎某些JS框架在某些大小的頁面上效果最好。
例如，Riot是一個很棒的大頁面框架（總體排名第二）。
然而，對於小頁面，Riot的表現要差得多（總體排名第15）。
要點：沒有適用於所有情況的“最佳”JavaScript框架。對於有很多小頁面的網站，RightJS是你最好的選擇。對於大部分頁面較大的網站，Gatsby看起來是理想的選擇。
具有低或高壓縮級別的頁面具有最快的載入時間
在伺服器上壓縮頁面檔案是一把雙刃劍。一方面，壓縮檔案顯著降低了頁面重量。
但是，在從伺服器傳送檔案之前壓縮檔案需要在瀏覽器上進行額外的工作，因為客戶端需要在渲染檔案之前解壓縮檔案。
作為此分析的一部分，我們著手回答這個問題：壓縮檔案真的能提高頁面速度嗎？
為了回答這個問題，我們將FCP分為三類（Fast、Average、Slow）：
- 閃電：0-1000ms
- 平均：1000ms-2500ms
- 龜速：< 2500ms
然後，我們比較了小、中和大頁面之間的FCP速度和壓縮級別。
對於小頁面，較低階別的壓縮與更快的FCP載入時間相關聯。但是，在非常高 (90-100%) 的壓縮級別下，載入時間再次增加。
中等大小的頁面也有類似的分佈：
大頁面的反向鐘形曲線分佈更為極端：
儘管頁面大小之間的確切分佈不同，但要點很清楚：壓縮水平非常低或非常高的頁面載入速度最快。
事實上，您可以看到壓縮適量檔案的頁面的FCP效能下降。
具體來說，壓縮60%-80%檔案的頁面效能最差。
因此，在提高頁面速度時，超低或超高壓縮水平往往效果最好。低階別的壓縮減少了瀏覽器所需的工作。高水平的壓縮比負載更小的客戶端上的繁重工作更重要。
關鍵要點：與具有中等壓縮水平的頁面相比，具有非常低或非常高壓縮的頁面具有更好的效能。
第三方指令碼會對載入時間產生負面影響
毫不奇怪，我們發現第三方指令碼（如Google Analytics、社交分享按鈕和視訊主機）會導致FCP時間變慢。
事實上，我們發現每個第3方指令碼都會將頁面載入時間增加34.1毫秒。
我們的發現與其他發現第三方指令碼對頁面速度有巨大影響的人（like this）一致。
顯然，影響取決於所使用的指令碼。某些第三方指令碼（如Hotjar）載入速度相對較快。包括Salesforce在內的其他公司的速度非常慢。
簡而言之，第三方指令碼會導致載入時間更長。頁面擁有的指令碼越多，載入速度就越慢。
關鍵要點：頁面上使用的每個3rd方指令碼都會將頁面載入時間增加34.1毫秒。
響應式影象似乎比延遲載入和使用WebP更能改善頁面載入時間
影象在網站效能中起著極其重要的作用，主要原因有兩個：
首先，影象佔據了頁面整體大小的相當一部分。
其次，使用者的注意力往往集中在頁面上出現的影象上。如果這些影象載入緩慢，則會對使用者體驗產生負面影響。
因為影象可以決定網站的載入速度，我們決定比較 4 種不同的影象優化方法的效能：
- WebP： 由Google開發，WebP是一種影象格式，與其他檔案格式相比，它的大小可以更小，但仍能產生類似水平的影象質量。
- 優化影象： “優化影象”是指根據使用者的裝置、位置等提供不同版本的影象。我們在此類別下使用了內容交付網路 (CDN)、影象壓縮和其他影象優化Web服務。
- 延遲離屏影象當使用者滾動到頁面上的該點時載入摺疊下方的影象。也稱為“延遲載入”。
- 響應式影象：當影象動態適應瀏覽器視窗大小時。
當我們比較這些不同的Lighthouse速度得分方法時，響應式影象名列前茅。
我們還分析了哪種方法獲得了最多滿分的Lighthouse。結果非常相似。
關鍵要點：雖然WebP與PNG和JPEG相比可能會改進影象壓縮，但目前很少有網站實現了這種新的影象格式。
GitHub和Weebly託管TTFB效能最佳，Siteground和Wix墊底
我們比較了主要網路託管服務提供商的頁面速度效能。
考慮到伺服器響應時間對TTFB的影響最大，我們分析了不同主機在該關鍵指標上的執行情況。
具體來說，我們將TTFB分為三類（快速、平均、慢速）。我們檢視了每個主機出現在每個類別中的百分比。
以下是每個網路託管服務提供商在桌面上的TTFB效能：
Github、Weebly和Acquia是桌面TTFB的前3名。Automattic、Wix和Siteground的表現最差。
我們對移動TTFB進行了同樣的分析。結果如下：
如您所見，Github在移動端和桌面端的表現都非常出色。考慮到Github Pages只提供靜態資源，這不足為奇。這意味著，在許多方面，Github理論上不能夠作為比較項，否則非常不公平。
Seravo、Netlify和Weebly排在前4位。Wix和Automattic位於列表的底部。
從這個分析中得出什麼結論？
TTFB只是選擇主機時要考慮的眾多因素之一。還有成本、正常執行時間、客戶支援、功能等。
也就是說，當談到桌面和移動裝置上的快速頁面載入時間時，Github Pages是迄今為止主要主機中的最佳選擇。Wix和Automattic主機的TTFB時間往往很慢。
要點：在主要的託管服務提供商中，Github和Weebly在桌面端的表現最好。根據我們的分析，GitHub和Seravo是最快的移動主機。但是，應該注意的是，Github Pages僅提供靜態頁面，這使其與我們分析的其他主機相比具有固有的優勢。
中國、日本和德國的TTFB載入時間最快
我們從我們的資料集中比較了11個國家的TTFB載入時間。
以下是桌面速度的逐個國家/地區細分：
手機端：
要點：中國擁有最好的移動和桌面TTFB效能。其次是頁面速度快於全球平均水平的日本和德國。法國、英國、加拿大、美國和俄羅斯的頁面速度平均。澳大利亞、巴西和印度的速度低於全球平均水平。
有CDN的頁面比沒有CDN的頁面表現更差
我們最令人驚訝的發現之一是，使用CDN的頁面實際上比不使用CDN的頁面表現更差。
這對於兩個桌面都是如此：
和手機：
這怎麼可能？
從理論上講，因為它提供的內容接近使用者所在的位置，所以CDN應該全面提高頁面速度。
然而，在我們的分析中並非如此。
我們假設並非所有CDN都是平等的。在許多情況下，使用優化不佳的CDN實際上會減慢速度。
當我們分析前18名頂級CDN提供商的效能時，我們確實發現了效能上的巨大差異。
具體來說，我們注意到（在桌面上）最好的CDN的效能比最差的CDN好3.6倍。這有助於解釋為什麼CDN不會自動提高效能。
為了讓表現不佳的人更容易被發現，我們將CDN效能與全球平均水平進行了比較。
然後，我們將每個CDN放入三個buckets之一：
- 好（快% 和慢%優於所有提供商的平均值）
- 平均（快%或慢%優於所有提供商的平均值）
- 差（快%和慢%比所有提供商的平均值差）
以下是每個提供商的效能摘要：
桌面端
- 優秀： Airee、Amazon Cloudfront、Azure CDN、CacheFly、EdgeCast、Fastly、GitHub Pages、Google Cloud、KeyCDN、MaxCDN、Netlify
- 平均： CDN77
- 糟糕： Akamai、ArvanCloud、Cloudflare、Fireblade、Incapsula、Sucuri
移動端
- 優秀： Airee、Amazon Cloudfront、Azure CDN、CDN77、EdgeCast、Fastly、GitHub Pages、Google Cloud、KeyCDN、MaxCDN、Netlify
- 平均： Fireblade 、Incapsula、Sucuri
- 糟糕： Akamai、ArvanCloud、Cloudflare
關鍵要點：使用CDN不會自動提高頁面速度效能。某些CDN的效能明顯優於其他CDN。因此，使用在桌面和移動裝置上都表現良好的CDN很重要。
小結
雖然通過搜尋排名分析文章，我們知道頁面速度與谷歌搜尋引擎排名關係不大，但是頁面速度的快慢會影響使用者頁面停留時間和跳出率，搜尋引擎爬取頁面等。
如果頁面速度過慢，相信也會間接影響搜尋引擎排名，總而言之，更快的網站速度，絕對是利，而非弊。
評論留言