什麼是FCP以及如何針對您的網站優化

首次內容繪製 (FCP) 是Google Core Web Vitals中最有意義的指標之一。與其他繪製和載入指標相比，FCP不是關於響應時間的純技術指標。FCP以使用者體驗和他們在網站上首先感知的內容為中心，而不是後臺載入的內容。通過優化您網站的First Contentful Paint，您不僅可以加快整體載入時間並提高頁面速度評級，還可以從字面上向訪問者展示他們的請求正在處理中並且載入沒有停止。

在本教學中，我們將深入探討什麼是First Contentful Paint，如何衡量和優化它，並回答一些關於FCP的常見問題，以便您可以確保您的網站儘可能高效和可用。

什麼是首次內容繪製 (FCP)？

網站的首次內容繪製是瀏覽器在您的頁面上呈現第一個DOM元素的時間。這包括影象、畫布元素（非白色）或文字。通俗地說，FCP是指使用者可以看到頁面的某些部分發生變化。通常，這是作為標題欄或背景影象出現的。此元素可能不是從伺服器呈現或載入的第一個元素，但它是使用者可以看到的第一個元素，因此它對您網站的UX至關重要。

網站在iframe 中包含的任何內容都不會被FCP考慮在內。也不是非內容繪畫，例如背景顏色的變化。那是First Paint，而不是 First  Contentful Paint。

FCP是一個有趣的指標。雖然您可以定量衡量它，但它也相對主觀。擁有快速的首次內容繪製很重要，因為它會使使用者感覺到您的網站正在快速載入。不管是不是真的。您的站點的首次互動延遲（使用者可以與站點互動的時間）可能比競爭對手長得多，但由於您的FCP更快，因此在使用者看來它可能更快。

也就是說，FCP並不是要欺騙您的使用者。較低的FCP時間通常是頁面速度的良好指標，優化它的方法也會影響其他頁面速度指標（例如最大內容繪製）。

First Contentful Paint，通常簡稱為 FCP，是一個以使用者體驗為中心的效能指標，用於衡量頁面的第一部分在使用者螢幕上顯示所需的時間。

FCP 是一個重要指標，因為它會影響感知效能。當訪問者第一次訪問您的網站時，他們的瀏覽器會顯示一個空白螢幕，這對訪問者來說不是一個好的體驗。

一旦內容開始載入，訪問者至少會感覺 “有東西” 在發生，頁面的全部內容很快就會載入完畢。因此，快速的 FCP 時間可以讓使用者感覺網站速度很快，即使載入其他內容仍需要一些時間。

相比之下，FCP 時間過慢則會讓使用者感到沮喪，因為這會讓使用者真正意識到頁面載入時間過長。沒有什麼比讓訪問者坐在那裡盯著空白的螢幕，懷疑你的網站是否還在執行更糟糕的了。

首次內容繪製 vs 最大內容繪製

最大內容繪製（LCP）是另一個以使用者體驗為中心的流行指標，其執行方式與首次內容繪製類似。

由於這兩個指標非常相似，因此很難理解 First Contentful Paint 與 Largest Contentful Paint 之間的區別。

以下是它們之間的基本區別：

• FCP — 衡量第一個物件出現所需的時間。它可以是任何東西，只要頁面上出現了某種型別的內容。
• LCP — 衡量頁面主要內容出現所需的時間。

由於存在這種差異，頁面的 FCP 時間至少應比頁面的 LCP 時間快一點。根據指標的定義，LCP 時間不可能快於 FCP 時間。雖然如果載入的 “第一個” 元素與 “主要” 元素相同，兩者在技術上可以相等，但這在大多數頁面上都不會發生。

為了說明這一點，下面是我們在閃電博主頁上執行的 WebPageTest 分析的視覺化時間軸。

• FCP 出現在 1.0 秒的影片帶中（準確地說是 0.924 秒）。這是它第一次從空白的白頁變成有一些可視內容。
• LCP 出現在 1.3 秒的影片帶中（準確時間為 1.217 秒）。此時頁面的 “主要” 內容可見。

FCP 和 LCP 時間的差異

First Contentful Paint 時間為多少才算好？

谷歌建議您將網站頁面的首次內容繪製時間控制在 1.8 秒以內。

谷歌認為，FCP 時間在 1.8 至 3.0 秒之間為 “需要改進”，而 FCP 時間超過 3.0 秒為 “差”。

谷歌的 FCP 時間指南

在您深入研究用於檢查FCP的各種工具之前，您需要了解什麼才是好的FCP分數。從Google關於確定指標分數的文件中，我們可以看到他們將FCP時間分為三類——好、需要改進和差——並討論了他們如何實現Lighthouse工具使用的百分位評分。

• 好– 在 0 秒到 1.8 秒之間
• 需要改進– 在 1.8 秒到 3 秒之間
• 差– 超過 3 秒

如何測量首次內容繪製（FCP）

最簡單的方法是使用 Google 的 PageSpeed Insights 工具來測量網站頁面的首次內容繪製時間，當然您也可以使用其他工具。

PageSpeed Insights 的好處在於，它既能提供模擬測試結果，也能提供真實使用者的 FCP 資料（如果你的網站有足夠的流量，可以包含在 Chrome 使用者體驗報告中）。

它還涵蓋桌面和移動效能，因為頁面的 FCP 時間會因使用者的裝置和連線速度而異。

以下是測試頁面的方法：

1. 開啟 PageSpeed Insights 頁面。
2. 輸入要測試的網站頁面的 URL。
3. 單擊 “Analyze（分析）” 按鈕。

稍等片刻，您就會看到結果。

如果您的網站有足夠的流量被納入 Chrome 瀏覽器使用者體驗報告，您將看到兩個不同的 FCP 時間：

• “發現真實使用者的體驗”部分中的時間是網站真實訪問者的平均 FCP 時間。
• “診斷效能問題” 部分中的時間基於模擬測試。您可以在數字下方的灰色框中看到模擬測試的條件。

您還可以使用頂部的選項卡在移動和桌面結果之間進行切換。

谷歌 PageSpeed Insights 工具中的 FCP 時間

要測試網站上的其他頁面，可以重複同樣的過程。

頁面不同，FCP 時間也會不同，因此我們建議測試多個頁面，以便對網站效能有一個良好的感覺。

例如，您可以測試主頁、部落格列表頁、單篇部落格文章等。同樣，確保同時檢視移動和桌面資料。

儘管FCP由於使用者感知而很重要，但它是一個可以衡量和評分的可量化指標。儘管如此，您可以使用這些工具來指示FCP在現場（對真實使用者）與實驗室（用於測試目的的模擬頁面載入）的影響。

測量 FCP 時間的其他方法

PageSpeed Insights 提供了一種最簡單的方法來檢視網站的真實和模擬 FCP 時間，但您也可以使用其他效能測試工具來補充或替代 PageSpeed Insights。

• WebPageTest – 可讓您使用不同的連線速度、裝置和位置執行模擬測試。
• Chrome開發者工具 – 可讓您直接從瀏覽器執行效能測試。
• DebugBear – 可讓您從桌上型電腦和移動裝置執行模擬測試，除 FCP 外還包括大量資料。
• GTmetrix – 可讓你在不同地點執行模擬測試。你可以在 “效能 “選項卡中看到 FCP 時間，我們的 GTmetrix 測試完整指南對此有更詳細的介紹。

對於使用工具對網站速度進行測試時，我們應該根據實際情況選擇現場工具，還是實驗室工具。

現場工具

現場工具是您可以用來跟蹤頁面對使用者的顯示方式的工具。真實使用者。這些工具不依賴於API和關於您網站的假設。它們直接在您的伺服器上實時執行，以便您儘可能獲得最準確和最新的資訊。

Google在https://web.dev上的FCP文件顯示這些是確定FCP的最佳現場工具：

• PageSpeed Insights
• Chrome使用者體驗報告
• Search Console（速度報告）
• Web Vitals JavaScript 庫

此外，也許最好的工具是真實使用者監控 (RUM)。這是您跟蹤和觀看真實使用者與您的網站互動的地方。您可以使用上面列出的工具定量跟蹤他們的載入時間，然後您可以直接從他們那裡獲得他們對FCP和您的頁面載入速度的主觀看法。就FCP的最完整檢視及其對訪問者的影響而言，RUM絕對是榜首。然而，它也是最複雜和最難進行的。

實驗室工具

用於FCP檢測的實驗室工具傾向於模擬理想情況下 FCP 的結果。Google推薦的這些實驗室工具不是在實際情況下發生延遲、頻寬、網路擁塞和其他障礙的情況，而是讓您瞭解您的網站在最佳執行時的表現。

• Lighthouse
• Chrome開發者工具
• PageSpeed Insights

此外，當您正在開發尚未投入生產的網站時，不可能在實際條件下對其進行測試。使用實驗室工具還可以幫助您在專案整個開發週期中建立基準和里程碑。

哪些因素會影響網站的 FCP 時間？

從高層次來看，有兩個 “方面” 的問題會導致 FCP 速度變慢：

• 伺服器響應時間過慢 — 如果您的伺服器向使用者瀏覽器提供網站資料的時間過長，您的頁面的 FCP 時間就會過慢。這可能包括託管或 DNS 速度慢、未使用快取（需要伺服器做更多工作後才能提供頁面）、未使用內容分發網路（CDN）等問題。
• 網站程式碼優化不佳 —即使伺服器響應速度很快，但如果網站程式碼優化不佳，FCP 時間仍然會很慢。例如，您的頁面可能包含大量 JavaScript，從而阻礙了可見內容的載入。CSS、圖片或網站程式碼的其他部分也可能存在問題。

根據您網站的具體情況，您可能只在一個方面遇到問題，也可能在兩個方面都遇到問題。

如何優化網站FCP分數

既然您已經進一步瞭解了什麼是 First Contentful Paint 以及為什麼它很重要，那麼我們就來介紹一些您可以實施的可行技巧，以提高您網站的執行時間。

實施這些技巧的好處在於，它們將改善網站的所有效能指標，而不僅僅是 FCP。

以下是該列表的快速摘要，我們將在下文中詳細介紹：

1. 改用速度更快的主機
2. 使用頁面快取（最好是在伺服器級別）
3. 實施內容交付網路（CDN）
4. 使用速度更快的 DNS 提供商
5. 優化網站的 CSS
6. 優化網站的 JavaScript
7. 禁用頁面首屏的懶載入功能
8. 優化字型交付
9. 儘量縮小 DOM 大小
10. 避免重定向（尤其是多重重定向）

1. 使用更快的主機

說到 FCP，有一個無法迴避的事實：

如果您網站的底層主機速度慢，即使您的網站經過完美優化，您的 FCP 仍然會很慢。

實施本列表中的其他提示會使您網站的 FCP 更好，但您網站的效能始終會受到主機質量的制約。

因此，您可以先實施本列表中的其他提示。但如果您在採取了其他一切措施後，仍在為 FCP 速度慢而苦惱，那麼您可能只需要換一個速度更快的主機了。

2. 使用頁面快取（最好是在伺服器級別）

如果您使用 WordPress 建立網站，那麼它需要為每一位訪問者動態處理伺服器端程式碼（預設情況下）。

當訪問者訪問您的網頁時，您的主機伺服器需要執行 WordPress 的 PHP 並查詢您網站的資料庫，以便生成完整的 HTML 文件並傳送到使用者的瀏覽器。

這需要時間，尤其是在低功率主機上，這會對網站的 FCP 時間產生很大影響。

通過頁面快取，您可以 “快取” 每個頁面的 HTML 成品。每次訪問時，您的伺服器無需處理伺服器端程式碼，而是會立即響應快取中的 HTML 完成版。

伺服器級別的頁面快取是在伺服器上配置快取，而不依賴於WordPress外掛。這通常可以通過使用Nginx或Apache的快取模組來實現更高效的快取。以下是如何為WordPress網站實現伺服器級快取策略的一些基本步驟。

使用 Nginx 的 FastCGI 快取

1. 安裝和配置 Nginx：確保 Nginx 已安裝，並在 WordPress 網站的配置檔案中啟用 FastCGI 快取。通常這些配置檔案位置在 /etc/nginx/sites-available/  目錄。

2. 配置快取路徑和引數：在 Nginx 配置檔案中，你需要指定快取的路徑和一些快取行為引數。以下是配置 FastCGI 快取的示例：

fastcgi_cache_path /etc/nginx/cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "\$scheme\$request_method\$host\$request_uri";

server {
    # ... 其他配置 ...

    location ~ \.php\$ {
        # ... 其他配置 ...

        fastcgi_cache WORDPRESS;
        fastcgi_cache_valid 200 60m;
    }

    location ~ /purge(/.*) {
        fastcgi_cache_purge WORDPRESS "\$scheme\$request_method\$host\$1";
    }
}

這將定義 FastCGI 快取的位置、大小、何時視為失效以及快取鍵的配置。

3. 設定清除快取邏輯（可選）：你可能還會想要配置一個機制來手動或自動清除快取。在 Nginx 中，你可以使用 fastcgi_cache_purge 指令（需要額外的 Nginx 模組）。

使用 Apache 的 mod_cache 模組

若你使用的是 Apache 伺服器，可以使用 mod_cache  和  mod_cache_disk 。

1. 啟用 Apache 快取模組：確保 mod_cache 和  mod_cache_disk 已安裝並啟用。

2. 配置快取設定：在 Apache 的配置檔案中，通常是 .htaccess  或 /etc/apache2/sites-available/  目錄下的虛擬主機檔案，新增如下配置：

<IfModule mod_cache.c>
    CacheEnable disk /
    CacheRoot /var/cache/apache2/mod_cache_disk
    CacheDefaultExpire 600
    CacheMaxExpire 86400
    CacheLastModifiedFactor 0.5
</IfModule>

上述指令設定了快取的目錄、預設過期時間、最大過期時間和 Last-Modified 頭資訊佔快取時間的係數。

3. 清除快取邏輯（可選）：同Nginx一樣，你可能還需要配置一個手動或自動清除快取的機制，這通常需要一些伺服器端指令碼來完成。

不論使用哪種伺服器軟體，建議同時託管靜態檔案（如圖片、CSS 和 JavaScript）通過 CDN，並啟用瀏覽器快取，以進一步提升網站載入速度。

注意：伺服器快取配置非常依賴於你的伺服器設定和具體需求，上述指令僅供參考。在正式環境中進行此類修改之前，務必進行備份，並在測試環境中進行測試，確保配置正確，不會影響網站功能。如果對伺服器不熟悉，建議由有經驗的系統管理員或專業人士操作。

如果您對伺服器配置優化感到困難，可以檢視您的主機是否具有伺服器級快取功能，或者使用眾多 WordPress 快取外掛之一，如 WP Rocket 和 FlyingPress。

3. 實施內容交付網路（CDN）

內容交付網路（CDN）是一個由伺服器組成的全球網路，用於儲存網站部分或全部內容/檔案的副本。

當訪問者訪問您的網站時，CDN 會自動從距離訪問者最近的位置提供網站檔案。

Cloudflare 擁有由 300 多個地點組成的龐大全球網路。

由於物理距離對載入時間仍有影響（我們還沒有超越光速！），訪問者的瀏覽器將更快地接收到網站檔案，從而縮短 FCP 時間。

如果您的網站面向的是國內訪客，可以使用阿里雲、騰訊雲、百度雲、華為雲、七牛雲、又拍雲等提供商的 CDN 服務；面向國外或者全球使用者，則可以使用 Cloudflare、Amazon CloudFront、Fastly 等提供商自行實施 CDN。

4. 使用速度更快的 DNS 提供商

在使用者的瀏覽器連線到網站伺服器之前，首先需要使用域名系統（DNS）找到與網站域名相關的實際網路伺服器。

您配置域名時使用的 DNS 提供商會影響這一過程所需的時間，從而影響網站的 FCP。

例如，根據 DNSPerf 的資料，速度最快的提供商和速度最慢的提供商之間的差距超過 130 毫秒，這是一個相當大的差距。

如果您使用阿里雲託管域名，可以使用阿里雲的雲解析 DNS 個人版或者企業標準版；騰訊雲，則可以考慮他們 DNSpod 的專業版或者企業版 DNS 雲解析。

海外伺服器，可以優先考慮亞馬遜或者 Cloudflare 提供的 DNS 解析服務。

注：本質上，TTFB 是將資料的第一個位元組傳輸到瀏覽器的時間。FCP取決於這個指標，所以它越快，你的First Contentful Paint就越快。減少TTFB和加快頁面速度的最佳方法非常簡單：

• 使用優質伺服器主機
• 通過CDN交付內容
• 使用速度更快的DNS
• 啟用瀏覽器快取（使用WP Rocket等外掛）

確保這三個元素得到充分照顧可以顯著降低TTFB，進而降低您的FCP。

5. 優化網站的 CSS

現在，您已經解決了伺服器響應時間問題，是時候開始優化網站程式碼了，從 CSS 開始。

CSS 控制頁面元素的設計和樣式。雖然 CSS 是任何網站都不可或缺的一部分，但如果 CSS 的載入方式未經優化，和/或在不需要 CSS 的頁面上載入了不必要的 CSS，則可能會拖慢 FCP 的執行速度。

我們有一整篇文章介紹如何優化 CSS，下面讓我們來看看加速 FCP 的最重要策略。

刪除未使用的 CSS

首先，您需要刪除頁面中不需要的 CSS。

其中一種方法是手動方法。PurifyCSS 等工具可以掃描頁面中未使用的 CSS，然後手動刪除這些程式碼。PageSpeed Insights 也會在其診斷中的 “減少未使用的 CSS “部分標記出未使用的 CSS。

不過，如果你使用的是 WordPress，有一些有用的外掛可以幫你自動完成整個過程，這就方便多了（尤其是對於非開發人員來說）。WP Rocket、FlyingPress 和 Perfmatters 都是不錯的選擇。

所有這些外掛都是高階工具。不過，我們認為它們值得投資，因為它們還能幫你實現本列表中的許多其他提示。

注：如果您的樣式表中有未被使用的程式碼，那麼為什麼要保留它呢？應刪除任何舊的或未使用的程式碼，以免每次請求您的網站時都載入它。Chrome DevTools（我們在上面連結到）可以在Coverage選項卡下向 您顯示CSS的哪些部分正在載入但未呈現。

移除WordPress未使用的CSS，對於一般站長來說，最好的方式是通過外掛來實現！

如何在 WP Rocket 中移除未使用的 CSS。

內聯關鍵 CSS 並延遲非關鍵 CSS

預設情況下，您的網站可能會等到載入完所有 CSS 程式碼後才開始渲染頁面上方的內容。不過，從使用者體驗的角度來看，這並不是最佳的做法，因為您只需要頁面上方內容所需的 CSS，其他的都可以稍後再用。

頁面上部內容的 CSS 被稱為關鍵 CSS。

為了加快頁面的 FCP 和其他效能指標，可以直接將關鍵 CSS 放在頁面的 <head> 部分（又稱內聯），而不是作為外部樣式表的一部分載入。

對於更高階的使用者，你可以使用類似這樣的工具手動生成頁面的關鍵 CSS。

同樣，在 WordPress 上，您可以使用 FlyingPress 或 WP Rocket 為網站上的每個頁面自動生成關鍵 CSS。

一旦在頁面上內聯了關鍵 CSS，就可以安全地推遲載入頁面的其他 CSS，直到頁面載入過程的稍後階段（頁面首屏已經渲染完畢之後）。

作為關鍵 CSS 功能的一部分，WP Rocket 和 FlyingPress 都會自動為您完成這項工作，這也是考慮使用它們的另一個原因。

如何在 FlyingPress 中內聯關鍵 CSS。

最小化 CSS 程式碼

最後，另一種提高網站 CSS 程式碼效能的方法是將其最小化。在對 CSS 程式碼進行最小化時，可以刪除不必要的字元和空格，從而節省更多的空間。

WP Rocket 和 FlyingPress 等外掛可以幫你做到這一點。您還可以找到專門的最小化外掛，如 Fast Velocity Minify。

6. 優化網站的 JavaScript

除 CSS 外，網站的 JavaScript 也是您需要花時間優化網站程式碼的另一個領域。

與 CSS 一樣，您可以採用幾種不同的策略來減少 JavaScript 對網站 FCP 時間的影響。

不要在頁面首屏使用依賴 JavaScript 的元素

如果您依賴 JavaScript 來實現頁面上方的重要功能，例如網站的導航選單（這在移動版網站中尤為常見，因為許多移動選單都依賴 JavaScript），這會拖慢您的 FCP 時間，因為使用者的瀏覽器在開始呈現頁面之前需要載入繁重的 JavaScript。

如果您使用的是 WordPress，選擇一個效能優化的主題應該可以幫助您避免這種情況，因為優秀的開發人員會避免在這些功能上依賴 JavaScript。

您還可以儘量避免在頁面首屏區域使用滑塊和其他 JavaScript 驅動的元素。

刪除不必要的 JavaScript

雖然你要特別強調減少摺疊元素中 JavaScript 的使用，但一般來說，從每個頁面中刪除儘可能多的不必要 JavaScript 也是一個好主意。

首先，你要刪除任何對網站沒有實際意義的 WordPress 外掛，因為許多 WordPress 外掛的功能都依賴 JavaScript。

另一種方法是使用 Asset CleanUp 或 Perfmatters 這樣的指令碼管理器外掛來逐頁禁用 JavaScript，這樣就可以在不需要指令碼的頁面上禁用指令碼，而在其他頁面上仍然啟用指令碼。

我們還有一份技術性更強的指南，介紹如何逐頁禁用外掛。

消除阻塞渲染的 JavaScript（推遲或延遲）

無論如何，您可能仍然需要在頁面上載入至少一些 JavaScript。為了確保這些 JavaScript 不會干擾頁面上方內容的載入，您可以採用兩種常見的策略：

• 推遲載入阻塞渲染的 JavaScript – 通過將 JavaScript 的載入推遲到頁面渲染過程的稍後階段，可以避免阻塞其他內容的載入。您可以使用 defer 或 async，WordPress 外掛可以自動執行此過程。
• 將 JavaScript 推遲到使用者互動之前 – 你可以完全等待載入網站的部分或全部 JavaScript，直到使用者與頁面進行互動（例如點選或滾動）。這種方法能最大限度地提高效能，但您可能需要手動排除某些指令碼，以免造成問題。

您可以通過 WP Rocket 或 FlyingPress 等外掛在 WordPress 上實施這兩種策略。

如何使用 WP Rocket 優化 JavaScript。

我們還有關於如何延遲解析 JavaScript 以及如何消除渲染阻塞資源的指南。

關於渲染阻塞：

這可能是降低FCP時間的第一個頁面因素。呈現阻塞資源是您的網頁必須呈現的網站上的檔案。其中包括HTML、JavaScript、字型和CSS 檔案。使它們“呈現阻塞”的是它們優先於頁面上的任何其他內容，在完成之前停止其他任何內容的載入過程。任何影象、純文字或其他面向使用者的內容都將被擱置，直到重要檔案完成。

這種持有導致FCP急劇增加，原因有兩個：

• 渲染阻塞檔案通常很大
• 渲染阻塞檔案通常不包含站點內容，只包含結構和格式

通過從關鍵渲染路徑中移除這些資源，您可以為內容豐富的繪畫開闢空間。您可以延遲資源的載入，避免對CSS使用@import（改為對條件CSS使用@media），並確保極簡化和合並您的CSS、HTML和JavaScript檔案（我們將在本文後面討論）。

WordPress使用者可以使用快取外掛（如WP Rocket）中找到一些渲染阻止選項，啟用這些選項也有助於減少FCP時間。或者參考如何移除阻塞渲染的JavaScript和CSS進一步對WordPress進行優化。

最小化 JavaScript 程式碼

最後，您需要對網站剩餘的 JavaScript 進行最小化處理，通過刪除不必要的字元來實現一些額外的微小效能優勢。

與對 CSS 進行最小化一樣，大多數快取和效能外掛（包括 WP Rocket 和 FlyingPress）都可以幫您做到這一點。您也可以使用像 Fast Velocity Minify 這樣有針對性的外掛。

注：極簡化是從您網站的HTML、CSS和JavaScript檔案中去除無關的字元（例如空格）。雖然間距使人類更容易閱讀和解析，但瀏覽器和伺服器不需要它們。這些空格仍然是佔用位元組的字元。通過縮小 CSS 檔案之類的內容，您可以減小頁面大小。這提高了頁面速度並縮短了 FCP 的時間。

“WordPress網站CSS、JavaScript和HTML檔案瘦身壓縮教學”深入講解如何進行執行極簡化操作。

7. 禁用頁面首屏圖片的懶載入功能

使用圖片懶載入功能，可以將網站圖片的載入時間推遲到需要時（如使用者向下滾動頁面）。

通常情況下，如果懶載入的是頁面首屏之後的圖片，這對效能來說是件好事。但是，對頁面首屏的圖片使用懶載入實際上會對網站的 FCP 和 LCP 時間產生負面影響。

因此，你需要確保將頁面首屏的圖片排除在懶載入之外。

如果您使用的是 WordPress 的核心懶載入功能，WordPress 應該會自動這樣做。但如果遇到問題，可以使用 wp_omit_loading_attr_threshold 函式手動調整這一行為。

如果您使用的是懶載入外掛，希望該外掛能提供這樣的選項。例如，Perfmatters 可讓您自動排除一定數量的前導圖片，並在需要時手動排除特定圖片。

如何在 Perfmatters 中將前導圖片排除在懶載入之外。

如果您的外掛不提供此功能，請考慮更換為提供此功能的外掛。

溫馨提示：不要忘記儘可能使用SVG或WebP影象

這可能不會影響每個人的網站，這就是為什麼我們將其最後列入列表的原因。影象通常不是首先繪製到頁面上的東西，尤其是在文字或附加框架上，但顯著降低重要/突出影象（例如您的站點徽標）的檔案大小可能有助於FCP。

雖然.gif、.jpg和 .png是您使用的最常見的影象檔案，但如果將它們轉換為.webp或.svg檔案，您將節省大量時間。有時檔案大小在 位元組範圍內而不是 千位元組，您的影象將在眨眼間載入。如果您是 WordPress 使用者，5.8版內建了.webp支援，此前我們也撰寫過關於WordPress使用SVG影象的文章。

最有可能的是，與FCP相比，這種方法對您的最大內容繪製 (LCP) 的影響更大，但足夠小的SVG徽標肯定會成為您的使用者首先看到的東西。

影響網站FCP分數是方方面面的，如果你著迷於WordPress網站速度優化，建議你閱讀“如何做到Google PageSpeed Insights測試滿分”一文。

8. 優化字型交付

為確保文字內容在載入時可見（這會影響 FCP 的執行時間和使用者體驗），如果使用自定義字型（如在 Google Fonts 上找到的字型），還必須優化字型的載入方式。

為避免出現問題，您可以使用 Font-Display: Optional 或 Font-Display: Swap CSS 描述符。

使用 Font-Display: Optional：如果自定義字型載入速度不夠快，您可以告訴使用者瀏覽器使用後備字型。

如果你不想使用自己的 CSS 新增此功能，有許多 WordPress 外掛可以為你優化字型載入，包括 WP Rocket、FlyingPress 和 Perfmatters。

如何通過 FlyingPress 優化字型。

注：您是否見過這樣的網站，當所有其他內容已經存在時，頁面上的所有文字都會神奇地同時出現？

那是因為瀏覽器隱藏了它。網站的文字內容在準備好閱讀之前不會載入。文字通常只有少量位元組的內容。但是在許多站點上，載入時間可能會呈指數級增長。因為字型檔案還沒有“準備好”顯示。在擁有極快的 FCP 時間的所有方法中，繪製您網站的文字內容可能是最好的。

您可以使用各種字型顯示引數，您可以告訴瀏覽器立即使用系統字型載入站點的文字，然後在載入後將其替換為您指定的顯示字型。

文字內容的檔案大小很小，通常只有幾個位元組，並且通過告訴瀏覽器立即顯示它有可能使您的FCP幾乎不存在。只需將font-display:swap新增 到您擁有的任何@font-face CSS。僅此一項就可以解決很多首次內容繪製時間問題。

9. 儘量減小 DOM 大小

根據 Mozilla 的說法，文件物件模型（DOM）是 “構成網路文件結構和內容的物件的資料表示”。

雖然人類訪問者不會直接與 DOM 互動，但頁面的 DOM 對於幫助網路瀏覽器理解和顯示頁面內容非常重要。

一般來說，如果 DOM 較大、較複雜，FCP 的速度會比 DOM 結構較短、經過優化的 DOM 慢。

以下是一些減少網站 DOM 大小的技巧：

• 使用效能優化的 WordPress 主題 – 在 WordPress 中，主題對網站 DOM 的大小影響很大。請檢視我們的資料支援文章，瞭解最快的 WordPress 主題和最快的 WooCommerce 主題。
• 使用分頁符區塊 – 您可以使用分頁符區塊分割長頁面。
• 優化分頁 – 您可以在 WordPress 中使用分頁來分割列出部落格文章（或其他自定義文章型別）的頁面。
• 顯示摘要 – 考慮在列表頁面上顯示摘要，而不是顯示全文。
• 限制或避免使用 “臃腫” 頁面構建工具 – 雖然從設計角度來看，視覺化、拖放式頁面構建工具確實很不錯，但它們也會給 DOM 增加很多負擔。從效能角度來看，使用原生編輯器會更好。你可能會發現，視覺化構建器在效能上的折衷是值得的，因為它增加了設計能力，只要你執行了其他提示，這通常是沒問題的。

這可能是一個噱頭。但通常情況下，快速進行首次內容繪製的最大限制因素之一是DOM過大。你試圖立即做太多事情。谷歌表示“最佳Doom規模應小於32個元素和少於60個子/父元素。”

為了給訪問者留下深刻印象，我們中的許多人將主頁和登入頁面過度複雜化。但是，這些新增的元素會使DOM膨脹並導致更高的FCP時間。您可以通過減少使用的CSS選擇器的數量來幫助實現這一點，也許使用比ID或特殊媒體查詢更多的基於類的CSS。偽選擇器也會使事情複雜化並增加DOM的大小。

除此之外，您還可以減少選擇器適用的元素數量。載入和應用樣式5元素所需的時間比10元素少。對於較舊和過時的瀏覽器尤其如此，儘管我們盡了最大努力，人們仍然每天都在使用。

10. 避免重定向（尤其是多重重定向）

重定向可讓你在頁面載入前將流量從一個 URL 傳送到另一個 URL。例如，您可以將訪問 HTTP 版本網站的使用者重定向到 HTTPS 版本。

但是，由於重定向需要在使用者瀏覽器載入頁面之前完成，因此每次重定向通常都會給網站的 FCP 時間（和其他效能指標）增加數百毫秒的延遲。

以下是一些避免不必要重定向的提示：

• 如果從 HTTP 轉為 HTTPS，更新硬編碼 URL – 如果將網站轉為 HTTPS，應實際更新網站資料庫中的所有 URL 以使用 HTTPS，而不是依賴重定向。
• 將 URL 指向正確的 WWW 或非 WWW 版本 – 確保所有 URL 使用正確的版本，避免從 WWW 重定向到非 WWW（反之亦然）。
• 修復損壞的內部連結 – 更新任何損壞的內部連結，而不是依靠重定向將使用者傳送到正確的位置。
• 要求其他網站修復已損壞的外部連結（如果值得的話）– 如果你從第三方網站收到了大量指向已損壞連結的流量，你可以聯絡網站所有者，要求他們修復連結，而不是依賴重定向。

要查詢重定向問題，可以使用免費的重定向檢查工具。我們還有一篇關於 WordPress 重定向最佳實踐的文章。

例如，在這裡你可以看到，當我們輸入 http://www.wordpress.org 作為 URL 時，重定向檢查器檢測到了多個重定向：

• 一次是從 HTTP 重定向到 HTTPS。
• 第二次從 WWW 重定向到非 WWW。

重定向檢查工具檢測到的多重重定向。

如果您看到類似的多重重定向，則需要進行修復。

上面的工具可以為您提供網站速度和FCP的概述和分數，當然。但它們——以及GT Metrix和Pingdom等其他網站測速工具——也讓您深入瞭解如何優化FCP分數並使其繪製速度更快。我們將概述如何修復首次內容繪製時間的一些最常見步驟，以便您知道如何解決測試和工具拍攝的任何問題。

FCP常見問題

FCP如何適應我網站的整體效能？

作為網站效能的直接指標，不是很多。FCP是一種以使用者為中心的感知指標，並不一定代表網站效能。正如我們在文章前面提到的，兩個網站的載入時間可能完全相同，但FCP時間較短的網站可能會被 視為更快。這種看法會影響使用者體驗，如果不是整體網站效能。

然而，為了將整體網站效能提升到更高水平，First Contentful Paint是一個很好的衡量標準。您為降低FCP而採取的任何操作也會降低您的整體頁面速度。所以你幾乎可以把它當作你整體表現的一個訊號。

較低的FCP時間通常不會與較高的整體載入時間一致，因此如果您需要使用單一指標來檢視您的立場，FCP可以成為一個很好的路標。您還可以將其與LCP或最大的內容繪製配對，以更全面地瞭解使用者在訪問您的網站的前幾秒鐘看到的內容。

First Paint和First Contentful Paint有什麼區別？

儘管這兩個術語有時可以互換使用，但從技術上講，它們是兩個不同的指標。正如我們所討論的，First Contentful Paint是當瀏覽器呈現頁面上的第一個DOM元素時。您可以將其視為頁面上任何可用（如果不是互動式）內容。例如，背景影象、文字或標題選單div。

然而，First Paint是瀏覽器呈現資訊的第一個位元組時，無論它是否是內容。背景顏色的變化（不是背景圖片的載入）並不令人滿意。使用者不能將其作為內容消費，因此不是FCP的示例。

First Paint可以與您的First Contentful Paint完全相同。但是您的FCP可能與您的First Paint不同。

小結

FCP是您網站的絕對重要指標。Google將頁面速度視為頁面排名最重要的方面之一。使用者將頁面速度視為他們是否留在您的網站上的決定因素之一。擁有較低的First Contentful Paint可以讓使用者留在您的網站上，並幫助他們首先找到您的網站。儘管FCP通常是一個難以確定和掌握的指標，但任何減少FCP時間的優化都會增加使用者體驗，並減少網站整體載入時間的寶貴秒數和毫秒數。