如何令網站加快：實用檢查清單

要令網站加快，先用 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"，並確保佢唔係延遲載入。將摺疊線以下嘅所有圖片改為延遲載入。唔好改動設計。

審核呢個應用程式嘅依賴項目。列出每個套件、邊個用到佢，以及大概令套件增加幾多容量。移除未使用嘅套件，並將 /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 方案下於程式碼編輯器中修改。請檢查已發布嘅網址，而唔係預覽，因為預覽運行嘅係開發伺服器。靜態前端發布時會以靜態網站部署（靜態網站），適合內容頁面。有伺服器嘅應用程式會縮減至零：閒置時休眠，下次有人訪問時喚醒，所以長時間冇人用之後嘅第一個請求會較慢；而附加嘅資料庫會喺閒置 5 分鐘後休眠（託管限制）。如果某個公開頁面只有第一次訪問時慢，就好可能係呢個原因。令行銷頁面保持靜態有幫助。改動之後，重新發布並強制重新整理。

常見問題