2026-10-27 · 技術
使用者說網站慢，不一定是頻寬或伺服器的問題。本文先教用一個指標區分“伺服器慢”還是“頁面重”，再從圖片、JS與CSS、字型、第三方指令碼、資源優先順序五處給出可執行的最佳化順序。
使用者說網站慢，第一反應常常是“加頻寬”或者“上 CDN”。但在動手之前，得先分清是伺服器響應慢，還是頁面本身太重。判斷方法很簡單：看 TTFB（首位元組時間）。如果 TTFB 只有兩三百毫秒，而頁面整體載入要五六秒，那問題基本不在伺服器和網路，而在前端。 下面這五處，是前端側最常見的拖慢原因。 第一處是圖片。很多站點直接上傳相機原圖或設計稿，一張 3MB 的圖掛在列表頁，十張就是 30MB。處理辦法是三件事：按實際展示尺寸裁切、轉成 WebP 或 AVIF、非首屏圖片加懶載入。僅這一項，通常就能讓頁面體積下降一大半。 第二處是 JS 和 CSS 的載入順序。瀏覽器遇到同步指令碼會暫停解析，一個放在 head 裡的第三方指令碼卡住，整頁白屏時間就被拉長。把非關鍵的指令碼改成 defer 或 async，把首屏必需的樣式內聯，其餘樣式非同步載入，體感差別很明顯。 第三處是字型。自定義中文字型動輒幾 MB，未載入完時文字要麼不顯示要麼閃爍。可行的做法是隻保留實際用到的字重、做字型子集化，或者乾脆用系統字型棧。首屏標題用自定義字型、正文用系統字型，是成本最低的折中。 第四處是第三方指令碼。統計、客服、廣告、熱力圖，每個都只有幾十 KB，加起來可能超過主站程式碼。建議定期清理：開啟瀏覽器的網路面板按體積排序，把一年沒看過資料的工具摘掉。 第五處是首屏關鍵資源的優先順序。首屏用到的字型、主圖、關鍵 CSS，可以用 preload 提前宣告；首屏之外的資源，用懶載入延後。優先順序排對了，使用者感知的“開啟速度”會明顯改善。 工具上，瀏覽器開發者工具的網路瀑布圖足夠用：看誰在阻塞、誰體積大、誰排隊久。Lighthouse 可以給一個整體評分和具體建議，適合最佳化前後對比。 最佳化的順序建議是：先減體積，再調順序，最後才考慮網路層。頁面本身有 5MB，再好的 CDN 也只能讓這 5MB 到得更快一點。 加速IDC 的 CDN 加速服務覆蓋東南亞多個節點，配合合理的快取策略，可以把靜態資源的重複傳輸降到最低。前端和網路兩側一起最佳化，效果通常比只做一邊更實在。
