如何讓網站更快：實用檢查清單

要讓網站變快，請先用 PageSpeed Insights 測量，然後修正它指出的最大原因，通常是過大的圖片、過多的 JavaScript、過重的字型或第三方腳本。目標是 Google Core Web Vitals 的「良好」標準：主要內容在 2.5 秒內可見，對點擊的回應在 200 毫秒內完成，並且幾乎沒有版面跳動。大多數網站只要做幾項修改就能達標，不需要重寫。

先測量，再改任何東西

憑猜測做事只會浪費時間。兩個免費工具幾乎能涵蓋所有需求：

• PageSpeed Insights（pagespeed.web.dev）——貼上一個即時網址。它會顯示來自真實 Chrome 使用者的現場資料（如果你的網站流量足夠），以及來自模擬載入的實驗室資料，並列出具體的問題。
• Chrome 開發者工具中的 Lighthouse——同樣的實驗室測試，可以在任何你能開啟的頁面上執行，包括預覽。請使用行動模式測試；在較慢網路下使用手機時，問題最容易顯現。

真正重要的數字是 Google 的 Core Web Vitals。截至 2026 年 9 月，Google 在 web.dev 上的文件以第 75 百分位數的頁面載入為準，給出以下「良好」門檻：

INP 在 2024 年取代了較舊的 First Input Delay 指標。如果某個工具仍然回報 FID，那它已經過時了。

請記下你的起始數字。每次修正後都要重新測試，這樣你才知道什麼真的有幫助。

時間花在哪裡：選項與取捨

每一個常見原因都有對應的修正方法，而每種修正都有其代價。請從最上面的開始——它們最便宜，也最常見。

圖片

圖片是最常見的問題，也是最容易修正的。一張 4,000 像素的照片若以 800 像素寬度顯示，會讓每位訪客下載的內容比實際看到的多五倍。

• 以顯示的尺寸提供圖片，並為手機與桌機使用響應式 srcset 尺寸。
• 使用現代格式（WebP 或 AVIF）與合理的壓縮率。
• 為每張圖片設定 width 與 height，讓瀏覽器預留空間。光這一項就能修正大部分的版面位移。
• 首屏以下的圖片使用 loading="lazy" 延遲載入。
• 絕對不要延遲載入頁面頂部的主視覺圖片。 Google 的 LCP 指南對此說得很直接：延遲載入 LCP 圖片一定會拖慢它。應改為設定 fetchpriority="high"。

JavaScript

許多 AI 建置的網站都是單頁應用程式（SPA）：瀏覽器先下載一個 JavaScript 套件，然後才繪製頁面。套件越大，空白畫面就停留越久。修正方法依工作量由小到大排列：

1. 移除不需要的東西。 請要求列出相依套件，並刪除曾經加入後就被遺忘的函式庫——為了一個日期而用的日期函式庫，為了五個圖示而載入的整套圖示包。
2. 依路由拆分。 只在有人打開管理後台時才載入其程式碼，而不是在首頁就全部載入。
3. 預渲染公開頁面。 行銷頁面以真正的 HTML 出現，在任何 JavaScript 執行之前就能顯示。這也有助於搜尋引擎；請參閱AI 建置網站的 SEO。

INP 變慢通常是因為某個長時間任務阻塞了頁面——例如每次按鍵都過濾一份龐大的清單，或是某個儲存格改變時就重新渲染整張表格。Chrome 開發者工具的效能面板能告訴你是哪一項。

字型

每個字型家族與字重都是另一個檔案。兩個字型家族與三到四種字重通常就足夠了。預先載入首屏使用的字型，使用 font-display: swap 讓文字能立即顯示，若外部字型服務對你的訪客來說太慢，就自行託管字型。

第三方腳本

聊天小工具、分析工具、熱圖、廣告像素、嵌入影片與社群動態，都會從其他伺服器載入程式碼。每一個看起來都很小，但加總起來，它們常常是頁面中最慢的部分。保留你真正會查看的那些。其餘的在頁面可互動之後再載入，並把沉重的嵌入內容（例如 YouTube 播放器、地圖）替換成輕量的預覽，點擊後才載入真正的內容。

伺服器回應

首位元組時間（TTFB）——伺服器開始回應所需的時間——位於所有其他指標之下。從 CDN（分佈在離訪客較近位置的伺服器網路；請參閱什麼是 CDN）提供的靜態頁面，幾乎在任何地方都很快。每次請求都由伺服器即時產生的頁面，則取決於該伺服器及其資料庫。快取重複的工作，並為慢查詢加上資料庫索引，是常見的解決方式。

有效的提示詞

具體一點：指出頁面、指標與限制條件。如果你有 PageSpeed Insights 的結果，請一併貼上。

PageSpeed Insights 顯示首頁在手機上的 LCP 為 4.8 秒，而 LCP 元素是主視覺圖片。請把主視覺圖片縮放並轉成 WebP，提供響應式尺寸，設定 width 與 height，加上 fetchpriority="high"，並確保它沒有被延遲載入。首屏以下的所有圖片都要延遲載入。不要改動設計。

請稽核這個 App 的相依套件。列出每個套件、哪裡使用它，以及它大約會增加多少套件大小。移除未使用的套件，並把 /admin 與 /settings 路由拆分成只有造訪時才載入的獨立區塊。

/products 上的搜尋框輸入時感覺很卡。請為過濾加上防抖動（debounce），避免每次按鍵都重新渲染整個清單；如果清單超過 200 項，請加上分頁或虛擬化。

逐步操作

1. 在行動版上測試即時頁面。 在 PageSpeed Insights 中以手機模式測試，記下 LCP、INP、CLS，以及列出的前三個問題。
2. 先修圖片：尺寸、格式、尺寸屬性、首屏以下延遲載入、主視覺設定優先權。
3. 移除你不使用的第三方腳本，並延後載入其餘的。
4. 精簡字型，只保留設計需要的部分。
5. 縮減 JavaScript：移除未使用的套件，依路由拆分。
6. 預渲染公開頁面，前提是它們仍然在用戶端渲染，而且 LCP 依舊很慢。
7. 檢查伺服器：快取、資料庫索引、為不常變動的內容使用靜態主機。
8. 重新發布並重新測試。 PageSpeed Insights 的現場資料會隨真實造訪在接下來幾週逐步更新，因此請以實驗室資料來判斷早期結果。

常見錯誤

• 只在快速的筆電上測試。 你的訪客使用的是中階手機與不穩定的行動數據。請使用行動模式測試。
• 追求完美的 100 分。 實驗室分數只是參考。當 Core Web Vitals 已進入良好範圍後，內容與可用性比多出的幾分更重要。
• 所有東西都延遲載入，包括主視覺圖片。這會讓 LCP 變得更糟。
• 再加一個速度外掛或函式庫。 減少負擔幾乎總是比增加程式碼來管理它更有效。
• 優化了預覽，而不是正式網站。 開發預覽使用的是未優化的建置。請測量已發布的網址。
• 只修一次速度。 每個新的小工具、圖片與功能都會增加負擔。大幅改版後請重新測試。

速度檢查清單

• 行動版 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1
• 圖片已縮放、壓縮、使用現代格式，並設定了 width 與 height
• 主視覺圖片未延遲載入；首屏以下的圖片已延遲載入
• 沒有未使用的 JavaScript 函式庫；大型路由已拆分
• 兩個字型家族或更少，且已預先載入主要字型
• 只保留你真正使用的第三方腳本，並延後載入
• 公開頁面已預渲染或盡可能使用靜態內容
• 發布後已在正式網址上重新測試

速度與行動版版面是相輔相成的；請參閱如何讓網站支援手機響應式設計。若要進行完整的上線前檢查，如何把 AI 原型推進到正式環境涵蓋了其餘的部分。

Mythex 上的速度優化

在 Mythex 上，你可以在聊天中提出要求來進行這些修改，Pro 方案則可以在程式碼編輯器中修改。請檢查已發布的網址，而不是預覽，因為預覽執行的是開發伺服器。靜態前端在發布時會以靜態網站部署（靜態網站），適合內容頁面。帶有伺服器的 App 會縮放到零：閒置時會休眠，並在下次造訪時喚醒，因此長時間沒有人使用後的第一次請求會比較慢；而附加的資料庫在閒置 5 分鐘後會休眠（代管限制）。如果公開頁面只有在第一次造訪時很慢，那很可能就是這個原因。將行銷頁面保持為靜態有助於改善。修改後請重新發布，並強制重新整理。

常見問題