如何加速您的網站：15 個快速簡便的減少網頁加載時間的修復程序

在今天的帖子中，我將向您展示如何快速輕鬆地減少您的網站加載時間（以及為什麼它很重要）。

實際上：

我將要展示的技術與我用來將頁面速度從 3 秒以上的完全加載時間提高到 1.2 秒銳利的頁面速度的策略完全相同。

但這是最好的部分：

這些網站加載改進都不需要開發人員的專業知識，即使是新手 SEO 也可以超快速地實施。

如果您想提高網站速度、排名更高、提高參與度並轉化更多流量，這篇文章適合您。 但首先，為什麼快速的網頁加載時間很重要？

網站加載時間統計

• 如果網站加載緩慢，59.2% 的用戶會在前 6 秒內離開網站 – Unbounce
• 隨著頁面加載時間從 1 秒開始，跳出的概率會增加 32% – Think With Google
• 將加載時間減少 0.1 秒會導致潛在客戶生成頁面的跳出率提高 8.3%——谷歌、五十五和德勤
• 當加載時間僅減少 0.1 秒時：
  • 零售客戶參與度提高了 5.2%。
  • 零售和旅遊類別產品列表頁面的跳出率分別提高了 5.7% 和 5.4%——谷歌、五十五和德勤
• 網站轉化率平均下降 4.42%，每增加一秒的加載時間在 0 到 5 秒之間 - 預兆
• 將網站加載時間增加十分之一秒會導致轉化率降低 7% – Akamai
• 將網站加載時間減少十分之一秒會導致零售網站的轉化率提高 8.4%，旅遊網站（谷歌、五十五和德勤）的轉化率提高 10.1%
• 如果電子商務網站的加載速度比預期慢，超過 45% 的人承認他們不太可能進行購買 – Unbounce
• 大約 70% 的人表示頁面的速度會影響他們從在線零售商處購買的意願 – Unbounce
• 77% 的智能手機購物者表示，他們更有可能從能夠讓他們快速購物的移動網站進行購買 – Think with Google
• 當加載時間減少十分之一秒時，零售網站的平均訂單價值增加了 9.2% – 德勤
• 移動網頁視覺完成加載所需的平均時間為 21.6 秒 – Backlinko
• 桌面網頁視覺完成加載所需的平均時間為 8.2 秒 – Backlinko
• 完全加載網頁的平均頁面加載速度在移動設備上為 27.3 秒 – Backlinko
• 在桌面上完全加載網頁的平均頁面加載速度為 10.3 秒 – Backlinko
• 平均網頁在移動設備上與桌面設備完全加載的時間要長 87.84% – Backlinko
• 與桌面頁面相比，加載緩慢的移動頁面導致跳出率提高兩倍，頁面瀏覽量減少 27% – Perficient

現在您了解了快速加載網站的重要性，讓我們介紹一下頁面速度（準確地說）以及如何改進它。

什麼是頁面速度？

頁面速度是網頁加載所需的時間。

也稱為加載時間，頁面速度是通過瀏覽器請求網頁和瀏覽器呈現頁面之間的時間間隔來衡量的。

頁面的加載速度受數據傳輸距離、網站服務器速度、代碼複雜程度、頁面文件大小和連接類型等多種因素的影響。

更不用說文件壓縮、緩存、渲染阻塞和許多其他影響頁面速度和 SEO 的因素。

正如您開始所說，提高頁面速度並不像安裝頁面速度插件那麼簡單。

影響速度的因素有很多，有時甚至很複雜- 或慢 - 您的網站加載。

不僅如此，也沒有“一種方法”來衡量頁面的加載時間，有很多。

以下是最常見的三種：

頁面加載時間

這是頁面完全加載所需的時間。

完全加載時間測量頁面所有可見部分的加載，以及腳本和代碼等隱藏元素的加載——基本上它測量頁面上所有資源的 100% 的加載時間。

這是最容易理解的頁面速度指標，但不一定是最有用的，因為頁面可能在頁面完全加載之前很久就已經加載給用戶（並且實際上可以工作）。

最大的內容塗料

最大內容繪製 (LCP) 是從用戶的角度確定頁面加載時間的更有價值的指標。

它測量網頁在屏幕上向用戶顯示最大內容所需的時間。

通常是頁面標題、特色圖片或正文內容。

簡而言之，LCP 測量重要的首屏內容對用戶完全可見的時間。

例如，假設一個頁面需要 10 秒才能完全加載。

只要在幾秒鐘內出現第一個內容繪製，頁面就不會“出現”緩慢加載。

簡而言之，只要您最大的內容繪製速度快，您就可以擺脫緩慢的滿載時間。

第一個字節的時間

簡而言之，這是衡量網絡瀏覽器在從網站服務器接收其第一個數據字節之前必須等待多長時間。

TTFB 並不真正衡量頁面加載所需的時間，但它確實會影響頁面加載時間。

瀏覽器從服務器接收數據所需的時間越長，顯示頁面所需的時間就越長。

如何計算頁面加載時間？

有很多不同的方法可以測量頁面速度：

• 到第一個字節的時間 (TTFB)
• 最大含量塗料 (LCP)
• 第一次有意義的油漆（FMP）
• 互動時間 (TTI)
• 首次輸入延遲 (FID)

名單還在繼續……

而且因為這些指標中沒有一個比另一個更好。

我建議您努力加快所有網站的速度。

不用擔心。 稍後我將向您展示如何，但首先：

為什麼頁面速度對 SEO 很重要？

不可否認，谷歌痴迷於頁面加載速度。

自 2010 年以來，Google 一直使用網站速度（以及頁面速度）作為其搜索引擎算法的排名因素。

然後在 2018 年，谷歌推出了“速度更新”，進一步影響了加載緩慢頁面的搜索引擎排名。

最近一次是在 2021 年，谷歌推出了頁面體驗，其中一個主要組成部分是核心網絡生命力和加載速度。

谷歌非常關心頁面速度——他們為什麼不呢？

如果谷歌要向您的網站發送大量免費流量，他們希望用戶享受到極好的體驗。 其中很大一部分是快速加載的網頁。

簡單的說：

加載緩慢的網站會損害您的 Google 排名。

快速加載的網站將有助於您的 Google 排名。

唯一的問題是，您如何改善頁面加載時間？ 我們接下來會介紹。

如何加速您的網站：減少網頁加載時間的 15 個最佳實踐

無法逃避它，許多有助於提高頁面速度的因素都深深植根於代碼中並且技術含量很高。

創建 AMP 頁面、最小化 HTTP 請求和使用異步加載——所有這些都需要開發人員級別的專業知識。 而且，正因為如此，我不會在這篇文章中討論那些頁面速度優化。

相反，我分享了 15 種易於實施（但經常被遺忘）的方法來以前所未有的方式提高您的網站速度。

讓我們跳進去：

(1)。 執行頁面速度測試，以便您可以對加載時間進行基準測試（並知道要改進什麼）

在您嘗試提高頁面速度之前，了解您的網站加載速度有多快或多慢會很有幫助。

畢竟，如果你不知道你當前的頁面速度，你怎麼知道你的速度優化是否成功呢？

您可以使用多種工具來評估您的頁面速度改進，我建議您全面運行您的網站。

但是一個簡短的警告：

您的分數會因工具而異。

那是因為每個網頁速度測試工具使用不同的方法來評估性能。 不僅如此，他們服務器的位置在不同的城市——正如你稍後會發現的——服務器位置對網站加載時間有巨大的影響。

沒有必要關注細節。 現在，只需使用每個工具進行測試並記下您的分數。

王國

一個易於使用的站點速度測試，它模仿網頁在 Web 瀏覽器中的加載方式。 Pingdom 目前提供七個服務器位置，您可以從中測試您的站點。

與其他根據頁面完全加載時間測量加載時間的工具不同，Pingdom 使用 On Load Time 記錄頁面上所有資源的下載時間。 此時，頁面將是交互式的，但腳本可能仍在後台運行。

GT Metrix

一種頁面速度測試工具，提供桌面和移動測量以及跨多個瀏覽器進行測試的選項。 GT Metrix 提供各種服務器位置，包括免費計劃中的 7 個和專業計劃中的另外 15 個。

默認測量是滿載時間，加載時間是可選的。

網頁測試

WebPageTest 是另一個很棒的工具，可以顯示您的網站在不同瀏覽器中的速度和性能。

WebPageTest 擁有最多的測試位置，共有 38 個。 與 GT Metrix 一樣，WebPage Test 默認使用完全加載時間，加載時間（也稱為文檔完成時間）可選。

PageSpeed 見解

這是 Google 用於評估頁面速度性能的工具。 與上面提到的三種工具不同，谷歌在其分數中使用現場數據而不是實驗室數據——假設現場數據可用。

這意味著什麼：

Google PageSpeed Insights 不是運行模擬真實用戶加載時間的測試，而是從 Chrome 瀏覽器用戶那裡收集真實用戶數據。 這些數據是在 30 天內匯總的，這意味著在優化加載時間後的 30 天內，您的分數可能不會有所提高。

了解 Google 對您的加載時間的評估非常重要。 他們將這個分數用於核心 Web Vitals - 頁面體驗信號的關鍵部分，有助於搜索引擎排名性能。

也就是說，其他三個工具（Pingdom、GT Metrix 和 WebPageTest）對於快速測量頁面速度性能之前和之後更有用。

幾個指針：

首先，選擇目標受眾附近的測試地點。 如果您的測試是在美國運行的，但您的用戶在澳大利亞，您將無法獲得頁面速度性能的實際衡量標準。

其次，不要犯只測試你的主頁的錯誤。

Pagespeed 對於每個頁面都是獨一無二的。

我建議您測試所有最重要的 URL，並使用 Google Analytics 快速識別加載速度最慢的頁面。

提示 – 您可以在 GA 的“行為”菜單中的“站點速度”下找到“頁面計時”。

了解？ 涼爽的。

讓我們開始優化我們的頁面速度。

(2)。 為閃電般快速的 DNS 主機切換您的免費域名系統

將域名系統 (DNS) 主機想像成電話簿。

它將您的可讀域名映射到 IP 地址（您的網站實際所在的位置）。

簡而言之：

每次用戶在瀏覽器的 URL 欄中鍵入您的網址時，瀏覽器都會進行 DNS 查找，將網址轉換為 IP 地址，並通過此操作找到託管您網站的服務器。

默認情況下，您將使用您的域名註冊商提供的免費 DNS 服務。

NameCheap、GoDaddy、Google Domains（以及幾乎所有其他域名註冊商）為您提供了設置您的域名服務器並將您的域路由到您的網絡主機的 IP 地址的能力。

這些免費的 DNS 服務有什麼問題嗎？

他們真的很慢。

如果您想要一個快速的網站，我建議您將 DNS 切換到 Cloudflare。

我從 Namecheap 的 DNS 服務轉移，查詢時間為 26 毫秒：

達到驚人的 13 毫秒。

換句話說，我減少了 50% 的 DNS 處理時間。

最重要的是，它沒有花我一毛錢。

一旦您註冊了一個免費的 Cloudflare 帳戶，您只需登錄您的域註冊商並將默認名稱服務器替換為 Cloudflare 的。

有了這個，你就完成了。

(3)。 實施這種緩存雙重打擊並加快加載時間

當用戶登陸您的網站時（通常）會發生以下情況：

• 他們的瀏覽器與您的網絡服務器聯繫
• 您的內容管理系統從您的數據庫中提取最新數據（例如您最近的帖子和頁面）
• 您的網絡服務器將數據編譯成 HTML 頁面並將其提供給訪問者

緩存插件完全刪除了前兩個步驟。

為了避免每次訪問者查看頁面時都向您的服務器發出新請求，緩存插件將保存您網頁的預構建版本並將其提供給訪問者。

這樣做可以加快用戶的加載時間。

我對 WordPress 緩存插件的推薦是：

• WP Rocket（我用的）
• W3 總緩存
• WP 超級緩存

由於緩存插件刪除了數據庫查找，它可以減少 1-3 秒的網站加載時間。

不錯。

但是，如果您希望您的頁面快速加載，我建議您這樣做：

邊緣緩存 (CDN)

與頁面緩存不同，頁面緩存將網站的緩存版本存儲在中央 Web 服務器上……

邊緣緩存將整個 HTML 頁面存儲在位於全球服務器網絡上的“邊緣節點”上。

這意味著什麼：

而不是向地球另一端的服務器發出請求……

當訪問者請求打開頁面時，它會從附近的服務器傳送。

與頁面緩存一樣，保存網頁的預構建版本以供立即訪問，並且不需要調用數據庫。

正如您可以想像的那樣，如果數據只需要傳輸幾百公里而不是幾千公里——並且頁面是為用戶預先構建的——它將導致更快的加載時間。

不僅如此，由於邊緣緩存做了很多工作，它還減輕了您的網絡託管的壓力，這可以進一步提高您的網站速度。

我推薦你使用的邊緣緩存服務是 Cloudflare 的 CDN：

在全球擁有 200 多台服務器：

而且，每月只需 20 美元，這絕對是一次偷竊。

(4)。 優化您的圖像以減少巨大的有效負載

沒有什麼比臃腫的圖片更能減慢網站速度了。

而且，這不足為奇。

圖像佔頁面大小的很大一部分。

（我們的 SEO 服務頁面總頁面重量的近 40%）。

因此，您可以優化圖像越多，頁面加載速度就越快。

唯一的問題是如何？

首先，您想將所有圖像的大小調整為它們需要的最大尺寸——而不是更大

例如：

此頁面上的圖像的最大寬度為 640 像素。

如果我要加載 650 像素寬的圖像，我會為頁面添加不必要的重量。

不僅如此，由於我的 CMS 需要將圖像的大小調整為 640 像素寬以適應頁面的尺寸，因此加載時間會進一步減慢。

考慮到這一點，我建議您在將圖像上傳到您的網站之前將它們調整為最大尺寸。

您可以使用 Pixlr 等在線圖像編輯工具或計算機原生工具。 機制無關緊要——您需要與最大可視區域大小相同的圖像。

您要做的第二件事是選擇正確的文件類型。

選擇錯誤的文件格式可能會增加額外的重量或導致圖像質量低下。

除非您的圖像是動畫的，否則 PNG 或 JPEG 是最輕的，因此加載速度最快。

以下是如何知道選擇哪種文件類型：

第三，您希望從圖像文件中去除所有不必要的膨脹，同時盡可能保持質量。

不要擔心技術問題。

只需安裝 Imageoptim 並讓該工具完成其餘的工作。

它可以幫助您將文件大小減少大約一半。

可是等等！

如果你的圖片已經加載了怎麼辦？

好消息。 如果您使用 WordPress，我有一個解決方案：

WP 糊塗！

WP Smush 會自動壓縮您上傳到 WordPress 媒體庫的任何圖像。

並將文件大小減少 2 倍以上，而視覺質量沒有任何明顯下降。

很酷，對吧？

壓縮圖像文件大小後，您可以使用另一種圖像優化技巧來改善網頁加載時間。

(5)。 實現延遲加載（但不在您的徽標上）！

即使您的圖像輕如鴻毛，但如果您在帖子中使用大量圖形（如我），您的頁面重量仍然會很重。

不僅如此，如果每個圖像都需要加載頁面才能呈現 - 您的頁面加載時間將被延長。

進入延遲加載。

延遲加載是瀏覽器延遲加載圖像，直到它們需要顯示在屏幕上。

換句話說，並非所有圖像都一次加載。

某些圖像（以及視頻和嵌入等其他資產）僅在需要時才被推遲和加載——即，當用戶向下滾動到頁面的該部分時。

如果你仔細看我的博客文章，你會看到延遲加載的實際效果：

延遲加載很強大。 它確實可以加快網站速度。 但是，延遲加載存在一個大問題：

當它打開時，它會延遲加載所有圖像。

由於大多數網站——比如我的網站——都有應該在加載時顯示的圖像，使用延遲加載實際上會損害最大的內容繪畫。

這裡的要點是默認的延遲加載設置會將延遲加載標籤應用於頁面上的所有圖像，包括那些應該立即顯示給用戶的頂部圖像。

意思是：

“首屏”圖像必須等待延遲加載 JavaScript 庫執行，然後才能加載頁面頂部的圖像。 換句話說，lazyload JavaScript 阻止了快速最大內容繪製 (LCP) 所需的資產渲染。

要解決此問題，請獲取您的徽標的 URL 和任何其他首屏圖片（提示！您的特色圖片）並將其添加為延遲加載插件中的排除項。

我使用 WP Rocket，以下是設置：

無論您使用 WP Rocket，還是 Autoptimize（另一個出色的延遲加載插件），請務必推遲加載圖像並將您的徽標設置為排除項。

有了這個，就應該設置為“延遲加載”的另一件事。

(6) 延遲 JavaScript 文件並提高頁面速度

如果您曾經通過 PageSpeed Insights 或 GT Metrix 運行過您的網站，您會熟悉此警告：

沒有逃避它。 JavaScript 是影響網站加載時間的最大罪魁禍首之一。

但為什麼？

當有人訪問您的網站時，您的網絡服務器會將您網站的 HTML 內容傳送到用戶的瀏覽器。

然後，用戶的瀏覽器從上到下通過 HTML 來呈現頁面。

如果它在該過程中發現任何 JavaScript，它將停止呈現頁面的其餘部分，直到它獲取並解析完整的 JavaScript 文件。

由於腳本文件很大並且可能需要一些時間來加載，它們確實會影響加載時間。

這是交易：

大多數 JavaScript 文件（如實時聊天、彈出窗口、小部件，甚至跟踪腳本）都不需要頁面來正確呈現。

這就是為什麼我建議您將 JavaScript 文件的解析延遲到頁面加載之後。

這樣，頁面上的所有基本內容都會被加載，然後腳本會稍後執行。

如果您使用 WordPress，WP Rocket 和 Perfmatters 都允許您延遲 JavaScript 渲染。

如果你好奇，這裡是我的 Perfmatters 設置：

您在網站上延遲的腳本將是您獨有的。

對 GT Metrix 建議的快速回顧將向您展示減慢加載時間的罪魁禍首。

(7)。 升級您的主機

並非所有的網絡主機都是平​​等的。 離得很遠。

快速和慢速託管服務提供商之間的響應時間差異很容易達到 800 毫秒。

聽起來可能不多，但這是 4 倍的差異：

我不會打電話給個別託管服務提供商，因為我只測試了其中的一小部分，但如果您每月花費 4.99 美元在託管服務上，您的網站可能不會快速加載。

這是因為大多數預算託管計劃將您的網站與數百個其他網站放在同一台（負擔過重的）服務器上，從而導致速度減慢、滯後甚至停機。

我無法談論大多數主機的性能，但作為一般經驗法則，你得到你所支付的。

不過，如果您正在尋找託管建議，這裡有兩個我使用的高級主機，可以親自推薦：

• Cloudways – 在速度優化的服務器堆棧上託管雲託管，為全球 60 多個地點提供服務。 我對客戶的首選建議。
• WP Engine – 用於 WordPress 網站的託管主機，在服務器級別具有頁面緩存。 託管此站點的同一虛擬主機。

無論您是否接受我的建議或其他建議，您都應該尋找幾個因素。

首先，您需要一個使用固態硬盤 (SSD) 的託管服務提供商。

固態驅動器比標準硬盤驅動器快得多，這意味著頁面加載時間更短。

其次，選擇一個服務器位於您所在國家或至少您所在大陸的主機。

網站在服務器所在國家/地區之外的運行速度通常會慢 1 秒以上。

考慮到這一統計數據，如果您當前使用的是位於很遠很遠的廉價共享服務器，那麼是時候升級到專用的本地 SSD 服務器了。

(8)。 清理和壓縮你的代碼

簡而言之，您希望縮小頁面上的資源。

縮小（如果這實際上是一個詞）是刪除不必要的空格、字符和註釋（實際上是任何不需要的元素）以減小文件大小的過程。

更輕的文件意味著要傳輸的數據更少——加載時間更快。

縮小文件的過程通常側重於 JavaScript 和 CSS，但也可以包括 HTML。

但是，在您想到梳理網站上的每一行代碼以查找冗餘元素之前，請不要擔心。

您可以通過安裝 WP Rocket 並勾選幾個框來輕鬆縮小代碼：

WP Rocket 會自動縮小你的代碼！

減少文件的第二種方法是 GZIP 壓縮。

GZIP 的工作方式類似於您在計算機上使用的 ZIP 和 RAR 壓縮，但由您的服務器處理。

基本上，當訪問者登陸您的網站時，他們的瀏覽器會從您的網絡服務器請求該網站的文件。 啟用 GZIP 後，您的服務器將壓縮這些文件，然後再將它們發送到用戶的瀏覽器。

而且，因為這些文件被壓縮並且更輕——傳輸速度更快。

由於我使用 WP Engine 託管，因此 GZIP 已啟用。

如果您的主機不支持 GZIP 壓縮，您可以通過 WP Rocket 或 W3 Total Cache 啟用它。

或者，如果您精通此類事情，請手動執行。

(9)。 拋棄過時的 HTTP 以利用更快的 HTTP2 協議

我不敢相信我在這個時代這麼說。

但是，如果您仍然在 HTTP（而不是 HTTPS）協議上運行您的網站，請立即進行轉換。

您可能知道 HTTPS 是一種排名信號。

基本上，如果您的網站使用安全且加密的 HTTPS 協議，Google 將為您的網站提供小幅排名提升。 相反，如果您使用 HTTP，您的排名性能會略有下降。

但這並不是獲得 SSL 證書並切換到 HTTPS 託管的唯一原因。

您知道 HTTPS 也更快嗎？

當您的站點以 HTTPS 模式（加密）運行時，您的 Web 瀏覽器軟件將使用較新的 HTTP2 協議（假設您的主機支持它），這比早期的 HTTP 1.1 協議快得多。

事實上，使用 HTTPS 將使您的網站下載速度提高 14.3%：

不是太寒酸！

在使用您當前的 Web 主機倉促切換到 HTTPS 之前，請考慮許多廉價的託管服務提供商仍然不支持 HTTP2。

如果你沒有，這肯定表明他們的基礎設施已經過時，也是跳槽到像 Cloudways、WP Engine 或 Kinsta 這樣的高級託管公司的另一個原因。

專業提示：訂閱 Cloudflare 的 0-RTT（零往返時間）功能，進一步加快 HTTPS 加密協商！

(10)。 使用您的網站允許的最高版本 PHP（並鎖定更快的處理時間）

PHP 是 Joomla、Drupal 和 WordPress 等流行 CMS 使用的編程語言。

信不信由你，這是每 5 個網站中有 4 個使用的代碼庫：

PHP 的一個優點是它不斷更新以增強安全性和改進性能。

事實上，新版本的 PHP 每隔 6-12 個月左右就會發布一次——每次新的 PHP 更新通常比以前的版本快 10-30%。

由於一次可以處理的數據庫請求數量增加，每個版本的運行速度都比上一個版本快。

例如，比較 PHP 7.3 和 PHP 5.6，更高版本每秒可以處理 3 倍的事務。

如果您的網站使用 WordPress，將您的網站更新到最新的 PHP 版本是一個明智的決定。

已經提到的專業託管服務提供商會自動更新您的 PHP 版本。

或者，您可以在 WordPress 的工具菜單下檢查您的站點健康設置。 從那裡，您將看到您正在運行的 PHP 版本：

並且可以相應地更新它。

(11)。 將此服務用於視頻 - 它會顯著加快您的網站速度

不可否認； 視頻是吸引觀眾的絕佳方式。

但問題是，它們佔用了大量的服務器資源來加載。

而且，正如您開始學習的那樣，服務器上的壓力越小越好，因為您的頁面速度會越快。

所以，在視頻的情況下......

不要在您的網站上自行託管視頻，而是使用獨立的視頻託管服務，例如 YouTube、Vimeo 或 Wistia。

然後使用嵌入代碼將視頻添加到您的網站。

這樣，您的服務器就不會忙於加載繁重的視頻文件，並且可以利用時間來處理頁面上的其他元素。

但是在這些服務中，哪一個更好？

根據 WP Rocket 的說法，Vimeo 的速度比 YouTube 和 Wistia 略快，而且比最慢的播放器 Daily Motion 快得多。

儘管如此，這些前 3 名之間的差異很小，這就是為什麼我為我的大部分視頻選擇 Wistia。

它具有出色的分析功能並支持視頻站點地圖——這對 SEO 來說是一個很棒的功能。

(12)。 查找（並修復）3XX 重定向

301 和 302 重定向很有用。

它們用於將冗餘頁面重定向到備用工作 URL。

問題是它們對於頁面速度來說是卑鄙的。

為什麼？

因為每當用戶嘗試訪問 3XX 狀態代碼頁時，都會向服務器發出兩個請求。

一個用於原始（重定向） URL，另一個用於最終目標 URL。

這可能意味著網站加載時間顯著增加。

但事情是這樣的……

您不能完全取消 3XX 重定向。 這將對您的 SEO 造成極大的不利影響。

但是，您可以盡量減少不必要的 3XX 狀態代碼：

（一個）。 內部重定向

當具有指向它的內部鏈接的頁面被重定向到另一個頁面時，就會發生內部重定向。

例如：

在您的主頁上，您鏈接到一篇關於生酮飲食的文章（例如，healthyfitness.com/keto-diet/）

稍後您決定創建一篇關於該主題的新文章並將舊文章重定向到新文章（301 重定向從 healthfitness.com/keto-diet/ 到 healthfitness.com/new-keto-diet/）

幹得好——這是 SEO 的好習慣。

問題是，您放置在主頁上的內部鏈接現在經過了不必要的“跳躍”——雖然它對用戶有效——但它為那些跟隨該鏈接的人增加了額外的加載時間。

值得慶幸的是，有一個簡單的解決方法。 只需將原始鏈接更新為最終目標 URL。

在您的網站上查找重定向的一種簡單方法是安裝 Check My Links。 此瀏覽器擴展程序將抓取您的頁面並突出顯示所有正在重定向的鏈接。

對 SEO Sherpa 主頁的快速掃描發現頁腳中有多個內部重定向：

我需要做的就是登錄 WordPress 並將這些頁腳鍊接更新到最終目的地。

(b)。 重定向鏈

重定向對加載時間不利，但在鏈中時甚至更糟。

當一個重定向頁面重定向到另一個重定向頁面時，確實會發生重定向鏈 - 依此類推。

它們通常是隨著時間的推移對站點所做的更改的結果。

例如：

• domain.com/about/更新和 301 重定向到：
• domain.com/about-us/更新並 301 重定向到：
• domain.com/about-our-company/更新並 301 重定向到：
• domain.com/company-history/

現在，任何試圖訪問原始頁面的人都會被重定向一次，而不是三次。

我喜歡使用 Ahrefs Site Audit 來查找重定向鏈。 抓取您的網站後，它將識別您遇到的重定向鏈問題的數量（以及其他錯誤）。

您可以深入了解重定向鏈列表以查看發生的鏈：

要修復每條鏈，請使用指向最終目的地的絕對鏈接更新原始 URL 處的 301 重定向——從而移除中間的重定向鏈。

(13)。 消除 404 錯誤

它發生了！

文件被移動（或丟失），鏈接被破壞。

發生這種情況時，由於需要額外的 Web 服務器請求來查找丟失的文件，用戶將經歷更長的頁面加載時間。

最終導致404錯誤。

造成這些錯誤的原因很多且無關緊要。

您只需要知道如何找到它們：

一種方法是使用 Google Search Console 來查找和修復它們。

登錄到您的 GSC 帳戶後，單擊覆蓋範圍，然後單擊錯誤。

單擊未找到提交的 URL ，您將看到導致 404 錯誤的所有鏈接的列表：

或者，您可以使用 Ahrefs 或 Screaming Frog 等站點審核工具。

無論您使用什麼工具，都知道您需要識別指向 404 頁面和媒體文件的鏈接。

然後替換或刪除那些損壞的鏈接。

這樣做會加快您的網站速度。

(14)。 縮減、更新和升級——使用插件提高頁面速度的三個步驟

當涉及到插件和擴展時，越少越好。

大多數附加組件都加載 JavaScript 和 CSS。

而且，正如我已經指出的那樣，這兩件事可以使您的網站進入慢速模式。

所以，只要有可能，我建議你去掉你的插件，只使用（絕對）必要的。

任何對於您網站的功能來說不必要的東西都可以關閉然後刪除。

當然，有些插件比其他插件更能影響網站速度。

因此，即使您絕對需要插件，也可能有更快的替代方案。

ServeBolt 的這篇文章列出了對加載時間性能影響最大的 WordPress 插件，並列出了更好、更快的選項。

如果您找到更快的替代方案，您應該進行切換。

通過插件加速網站的第三步是確保您運行的是最新的插件版本。

很多時候，舊插件與當前版本的 WordPress 或 PHP 不兼容。

這些不兼容性幾乎總是會影響頁面速度性能。

Thankfully, the plugin menu in WordPress makes it easy to spot outdated plugins:

From there, you can simply upgrade to the latest version.

(15)。 Use This Little Known Google Tag Manager Trick to Speed up Your Website

You've probably heard of Google Tag Manager? And, hopefully, you are using it on your website.

Google Tag Manager is a container for all your pixels and tracking scripts, which makes deploying codes simple – and bypasses the need for a developer.

Simply moving your tracking pixels from embedded in your website code to Google Tag Manager can shave up to 2 seconds off your load time.

This is a great page speed improvement, but it doesn't stop there…

Did you know that Google Tag Manager, allows you to control when your tags are fired and thus speed up your load times even further?

As you've learned already, any code that's not required for a fast largest contentful paint should be delayed until after the main content has loaded.

By default, Google Tag Manager will fire your tags on page view.

But, by selecting the 'Window Loaded” trigger your tags are fired once the entire content of the page has been fully loaded, including any embedded resources such as images and scripts.

I set this up on the SEO Sherpa website, and because I have a bunch of tracking set up, it boosted load times significantly.

To implement this page speed trick on your own website, login to GTM and select 'New Trigger' and then 'Window Loaded.'

And once you've done that, you're done.

What Did You Think?

Now I'd like to hear from you:

Which technique from today's post are you going to implement first?

Are you going to fix broken links? Or implement lazy loading?

Either way, let me know by leaving a comment below.