在當今的 Web 生態中，性能即功能。用户期望網站加載瞬間完成，交互無比流暢。搜索引擎（尤其是 Google）也將核心 Web 指標 (Core Web Vitals) 等性能因素作為排名的重要依據。一個緩慢的網站會直接導致用户流失、轉化率下降和品牌形象受損。

這份前端性能檢查清單旨在為你提供一個系統性的框架，幫助你識別、診斷並修復影響網站速度的關鍵瓶頸。它涵蓋了從基礎測量到高級優化的各個環節。請將此清單視為一個持續改進的起點，而非一次性的任務。

📊 第一部分：測量與監控 (Measurement & Monitoring)

1. 定義關鍵性能指標 (KPIs):

• 核心 Web 指標 (Core Web Vitals):
• LCP (Largest Contentful Paint, 最大內容繪製): \< 2.5 秒 (良好)。測量主要內容加載時間。
• FID (First Input Delay, 首次輸入延遲): \< 100 毫秒 (良好)。測量頁面可交互性。
• CLS (Cumulative Layout Shift, 累計佈局偏移): \< 0.1 (良好)。測量視覺穩定性。
• 其他重要指標:
• TTFB (Time to First Byte, 首字節時間): 服務器響應速度。
• FCP (First Contentful Paint, 首次內容繪製): 用户看到任何內容的時間。
• TTI (Time to Interactive, 可交互時間): 頁面完全可交互的時間。
• TBT (Total Blocking Time, 總阻塞時間): FCP 和 TTI 之間主線程被阻塞的總時長。
• 頁面加載總時間: 從導航開始到所有資源加載完畢。
• 頁面大小 (Page Weight): HTML、CSS、JS、圖片、字體等所有資源的總字節數。
• 請求數: 頁面加載過程中發起的 HTTP 請求總數。

1. 選擇合適的測量工具:

• 實驗室工具 (Lab Tools): 在受控環境下模擬測試。
• Lighthouse (Chrome DevTools, PageSpeed Insights, WebPageTest, CLI): 綜合性能、可訪問性、最佳實踐、SEO 審計。
• WebPageTest: 功能強大的深度測試，支持多地點、多瀏覽器、自定義網絡條件（如 3G/4G）、視頻捕獲、瀑布圖分析。強烈推薦！
• Chrome DevTools Performance Tab: 詳細分析運行時性能（腳本、渲染、繪製）、記錄並分析用户交互。
• Chrome DevTools Network Tab: 分析資源加載順序、大小、時間、請求瀑布流。
• React Profiler / Vue DevTools: 分析框架組件的渲染性能。
• 真實用户監控 (RUM - Real User Monitoring): 捕獲真實用户在各種設備和網絡條件下的體驗。
• CrUX (Chrome User Experience Report): Google 提供的真實用户核心 Web 指標數據。
• 商業 RUM 工具: New Relic, Datadog RUM, Dynatrace, Sentry, SpeedCurve, Akamai mPulse 等。
• 自建 RUM: 使用 web-vitals JS 庫收集數據併發送到你自己的分析平台。
• Google Analytics: 通過配置可追蹤部分性能事件。

1. 建立性能預算 (Performance Budgets):

• 為關鍵指標（如 LCP、CLS、頁面總大小、JS/CSS 總大小、圖片總大小、請求數）設定具體的、可衡量的上限目標。
• 將預算集成到 CI/CD 流程中，在 PR 合併或部署前自動檢查預算是否超支。
• 使用工具如 bundlesize、Lighthouse CI、Webpack Performance Hints 等來強制執行預算。

1. 持續監控:

• 定期（如每天/每週）運行實驗室測試（尤其是在關鍵用户路徑上）。
• 持續收集和分析 RUM 數據，關注核心 Web 指標達標率（Good / Needs Improvement / Poor）。
• 設置性能告警（例如，當 LCP 中位數超過 3 秒或 CLS 超過 0.15 時觸發警報）。
• 監控性能隨時間的變化趨勢，識別迴歸點。

⚙ 第二部分：核心優化策略 (Core Optimization Strategies)

🧩 資源加載 (Resource Loading)

1. 最小化關鍵渲染路徑:

• 識別渲染首屏內容所必需的資源（關鍵 CSS、關鍵 JS、關鍵圖片/字體）。
• 優先加載這些關鍵資源。

1. 延遲加載非關鍵資源 (Lazy Loading):

• 圖片和 iframe: 使用原生 loading="lazy" 屬性。
• JavaScript: 使用 async 或 defer 屬性加載非關鍵腳本。動態 import() 代碼分割。
• 組件/內容: 使用 Intersection Observer API 或框架特性（如 React lazy + Suspense, Vue defineAsyncComponent）實現按需加載。

1. 資源預加載/預連接 (Preloading/Prefetching/Preconnecting):

• \<link rel="preload"\>: 強制瀏覽器高優先級獲取後續頁面渲染必需的資源（如關鍵字體、首屏大圖、關鍵路由的 JS）。
• \<link rel="preconnect"\>: 提前建立與重要第三方源的連接（DNS 查找、TCP 握手、TLS 協商）。
• \<link rel="dns-prefetch"\>: 提前解析第三方源的 DNS。
• \<link rel="prefetch"\>: 低優先級獲取用户未來可能需要的資源（如下一頁面的資源）。謹慎使用。

1. 優化資源加載優先級:

• 確保 HTML 中資源的順序合理（關鍵 CSS 放 \<head\>，非關鍵 JS 放底部或異步加載）。
• 使用 fetchpriority="high" 提示瀏覽器優先加載關鍵資源（如圖片）。

📦 JavaScript 優化

1. 代碼分割 (Code Splitting):

• 利用 Webpack、Rollup、Vite、Parcel 等打包工具的代碼分割功能。
• 基於路由分割：每個路由加載所需的代碼塊。
• 基於組件分割：延遲加載非首屏組件。
• 使用動態 import() 語法。

1. 減少/最小化 JavaScript:

• Tree Shaking: 移除未使用的導出代碼（確保使用 ES 模塊語法）。
• Minification (壓縮): 使用 Terser 等工具移除空白、註釋、縮短變量名。
• 移除死代碼 (Dead Code Elimination): 刪除永遠不會執行的代碼。
• 避免大型庫/框架的膨脹: 評估依賴項的成本，考慮輕量級替代方案或僅導入所需部分（如 lodash-es 的按需導入）。

1. 優化 JavaScript 執行:

• 避免長任務 (Long Tasks): 將複雜任務拆分成小塊，使用 setTimeout、requestIdleCallback 或 Web Workers 在主線程外執行。
• 優化啓動時間: 延遲執行非關鍵初始化邏輯。
• 使用高效的算法和數據結構。
• 減少 DOM 操作: 批量更新，使用 DocumentFragment，避免強制同步佈局 (Layout Thrashing)。
• 利用 Web Workers: 將密集型計算（如圖像處理、複雜排序）移出主線程。
• 優化事件處理: 使用事件委託，避免高頻事件（如 scroll, resize, mousemove）上的繁重操作，合理使用防抖 (Debounce) 和節流 (Throttle)。

1. 謹慎使用第三方腳本:

• 審計和精簡: 定期審查所有第三方腳本（分析、廣告、跟蹤器、小工具），移除不必要的。
• 延遲加載: 使用 async/defer 加載非關鍵第三方腳本。
• 尋找更輕量的替代品。
• 考慮自託管: 對於關鍵庫（如 Google Analytics），在可行的情況下自託管以控制加載。
• 使用 rel="preconnect" 或 rel="dns-prefetch" 優化連接。
• 設置資源提示 (fetchpriority) 和 crossorigin 屬性。
• 考慮使用 iframe 沙盒隔離性能影響大的腳本。

🎨 CSS 優化

1. 最小化/壓縮 CSS:

• 使用 CSSNano、csso、PostCSS 插件等工具進行壓縮。
• 移除未使用的 CSS（使用 PurgeCSS、UnCSS 或類似工具，注意動態生成類名的處理）。

1. 優化 CSS 交付:

• 內聯關鍵 CSS: 將渲染首屏內容所需的最小 CSS 直接內聯在 HTML 的 \<head\> 中。使用工具（如 Critical, Penthouse）自動化提取。
• 異步加載非關鍵 CSS:
• 方法 1: 使用 \<link rel="preload" as="style" onload="this.rel='stylesheet'"\> + noscript 回退。
• 方法 2: 使用 media="print" 加載，然後在 onload 後切換為 media="all"。
• 避免 @import: 在 CSS 文件中使用 @import 會阻塞渲染。使用 \<link\> 標籤替代。

1. 優化 CSS 選擇器與結構:

• 避免過於複雜或深層嵌套的選擇器（如 .header .nav ul li a .icon）。
• 優先使用類選擇器 (Class)，ID 選擇器效率高但複用性差且權重高。
• 減少不必要的通配符 (*) 和屬性選擇器的使用。
• 遵循 BEM 等命名方法論有助於保持選擇器簡潔和低特異性。

🖼 圖片與媒體優化

1. 選擇合適的格式:

• JPEG: 適用於照片和色彩豐富的圖像（有損壓縮）。
• PNG: 適用於需要透明度的圖像（無損或有損如 PNG-8）。
• WebP: 強烈推薦！ 在保持或接近同等質量下，通常比 JPEG 和 PNG 小 25-35%。現代瀏覽器廣泛支持。
• AVIF: 下一代格式，壓縮率比 WebP 更高（尤其在高質量下），但編碼解碼更慢，兼容性仍在增長。
• SVG: 適用於圖標、徽標和簡單圖形（矢量，無限縮放無損）。
• GIF: 僅用於簡單動畫，其他情況用視頻替代（MP4/WebM）。

1. 壓縮與優化:

• 始終使用工具壓縮圖像！ 即使選擇了現代格式。
• 工具推薦：Squoosh (在線), ImageOptim (Mac), RIOT (Windows), Sharp (Node.js), libvips, imagemin 插件。
• 調整質量設置以平衡視覺保真度和文件大小。
• 移除元數據 (EXIF, XMP 等)。

1. 響應式圖片:

• 使用 \<picture\> 元素和 srcset / sizes 屬性。
• 為不同屏幕尺寸和分辨率（1x, 2x, 3x）提供不同尺寸（寬度）的圖片源。
• 結合現代格式：\<picture\>\<source type="image/webp" srcset="..."\>\<img src="fallback.jpg" ...\>\</picture\>。

1. 延遲加載 (Lazy Loading):

• 使用 loading="lazy" 屬性（對 \<img\> 和 \<iframe\> 有效）。
• 為不支持原生延遲加載的瀏覽器提供 JavaScript polyfill（但通常不再必需）。

1. 尺寸屬性 (Dimensions):

• 始終為 \<img\> 和 \<iframe\> 指定 width 和 height 屬性。
• 這可以顯著減少 CLS（佈局偏移），因為瀏覽器在圖片加載前就能預留正確空間。
• 使用 CSS 控制最終渲染尺寸（width: 100%; height: auto;）。

1. 考慮 CDN 的圖像優化:

• 利用 Cloudflare, Cloudinary, Imgix, Akamai Image Manager 等 CDN 提供的實時圖像轉換、優化和格式轉換功能。

🔤 字體優化

1. 精簡字體使用:

• 評估是否真的需要多個字重和變體。限制使用的字重（如 Regular, Bold）和字符集（如 \&subset=latin）。
• 考慮系統字體棧作為性能友好的備選方案。

1. 字體加載策略:

• \<link rel="preload"\>: 對關鍵 Web 字體使用預加載：\<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin\>。
• font-display 策略:
• font-display: swap;: 最常用。 先顯示後備字體，Web 字體加載後立即交換。可能導致 FOIT (Flash of Invisible Text) 或 FOUT (Flash of Unstyled Text)，但通常可接受。
• font-display: optional;: 僅在短時間內可用時才使用 Web 字體，否則永久使用後備字體。適合非關鍵字體或對 FOIT/FOUT 零容忍的場景。
• 內聯小圖標字體 (如果使用): 考慮將小圖標字體轉換為 SVG sprite 並內聯，減少請求。

1. 本地存儲 (Local Storage):

• 使用 localStorage 或 IndexedDB 緩存已加載的字體文件，避免重複下載（需要實現緩存邏輯）。

🔗 網絡優化 (Network Optimizations)

1. 啓用 HTTP/2 或 HTTP/3:

• HTTP/2 支持多路複用 (Multiplexing)、頭部壓縮 (HPACK)、服務器推送 (Server Push - 謹慎使用)，顯著提升資源加載效率。
• HTTP/3 (基於 QUIC) 在弱網環境下表現更優（減少隊頭阻塞，更快連接建立）。優先使用支持 HTTP/3 的主機和 CDN。

1. 啓用壓縮:

• Brotli (br): 首選！ 比 Gzip 壓縮率更高（尤其對文本資源）。確保服務器配置支持 Brotli。
• Gzip (gzip): 廣泛支持，作為 Brotli 的備選方案。確保服務器為文本資源（HTML, CSS, JS, SVG, JSON 等）啓用了 Gzip。

1. 利用瀏覽器緩存:

• 為靜態資源（圖片、字體、CSS、JS）設置強緩存（Cache-Control: max-age=31536000, immutable - 一年）。
• 為帶有哈希指紋的文件名設置 immutable，防止重新驗證。
• 為 HTML 文檔設置合適的協商緩存（Cache-Control: no-cache 或較短的 max-age 配合 ETag/Last-Modified）。

1. 使用 CDN (Content Delivery Network):

• 將靜態資源（和動態內容）分發到全球邊緣節點，減少用户到資源的物理距離和延遲。
• 提供 DDoS 防護、智能緩存、HTTP/2/3 支持、Brotli 壓縮、圖像優化等附加功能。

1. 優化 TLS/SSL:

• 使用現代、快速的加密套件。
• 啓用 OCSP Stapling 減少握手延遲。
• 考慮使用 TLS 1.3，其握手速度更快。

🧱 渲染性能 (Rendering Performance)

1. 優化關鍵渲染路徑 (CRP):

• 最小化關鍵資源數量、大小和往返次數 (RTTs)。
• 優先加載關鍵 CSS（內聯），延遲加載非關鍵 CSS 和 JS。

1. 減少重排 (Reflow) 與重繪 (Repaint):

• 批量 DOM 操作: 使用 documentFragment 或在脱離文檔流的元素上操作，然後一次性插入。
• 避免強制同步佈局 (Layout Thrashing): 避免在讀取佈局屬性（如 offsetWidth, offsetHeight, getComputedStyle()）後立即寫入樣式，這會導致瀏覽器強制提前計算佈局。應先批量讀取，再批量寫入。
• 使用 transform 和 opacity 做動畫: 這些屬性通常由合成器 (Compositor) 線程處理，不會觸發主線程的 Layout 和 Paint，效率極高。優先使用 CSS Transitions/Animations。
• 使用 will-change 屬性: 謹慎使用以提示瀏覽器對即將變化的元素進行優化（如 will-change: transform;）。
• 使用 content-visibility: auto;: 現代 CSS 屬性，延遲屏幕外內容的渲染，顯著提升初始加載和滾動性能（注意對可訪問性和 CLS 的影響）。

1. 優化 JavaScript 動畫:

• 優先使用 CSS 動畫。
• 如果必須用 JS，務必使用 requestAnimationFrame() 而非 setTimeout/setInterval。
• 考慮高性能的 JS 動畫庫（如 GSAP）。

1. 虛擬化長列表 (Virtualization):

• 對於渲染大量列表項（數千行）的場景，使用“虛擬滾動”技術（如 React react-window / react-virtualized, Vue vue-virtual-scroller）。只渲染當前視口可見的項。

🛠 框架與庫特定優化 (Framework-Specific - 以 React 為例)

1. 避免不必要的渲染:

• 使用 React.memo() 包裹函數組件，僅在 props 淺比較變化時渲染。
• 類組件中使用 shouldComponentUpdate() 進行精細控制。
• 確保傳遞給子組件的回調函數（尤其作為 prop 時）使用 useCallback 進行記憶化，避免因父組件渲染導致子組件不必要的渲染（如果子組件用了 React.memo）。
• 記憶化複雜計算：使用 useMemo。

1. 優化狀態更新:

• 將狀態提升到合理的位置，避免不必要的向下傳遞。
• 使用 Context API 時，確保 Provider 的值穩定（使用 useMemo 包裹對象）或將不同狀態拆分成多個 Context，避免無關更新導致所有消費者重渲染。
• 考慮使用狀態管理庫（如 Redux, Zustand, Jotai）進行更精細的更新控制。

1. 代碼分割 & 延遲加載組件:

• 使用 React.lazy(() =\> import('./MyComponent')) 和 \<Suspense fallback={...}\> 實現組件的動態導入和延遲加載。

1. 分析工具:

• 使用 React DevTools Profiler 組件識別渲染瓶頸。
• 使用 why-did-you-render 庫檢測不必要的組件渲染。

📱 移動端特定優化

1. 網絡感知優化:

• 使用 Network Information API (navigator.connection) 檢測用户網絡類型（慢速 2G/3G/4G/5G/WiFi）和設備內存，動態調整資源加載策略（如低網速下加載更低分辨率圖片）。
• 考慮為慢速網絡用户提供“精簡模式”。

1. 觸控與滾動優化:

• 確保點擊目標大小足夠（至少 44x44px），間距合適。
• 監聽 touchstart/touchend 而非 click 以更快響應（注意無障礙）。
• 使用 { passive: true } 選項添加 touch 和 wheel 事件監聽器，提高滾動流暢度（element.addEventListener('touchstart', handler, { passive: true });）。
• 避免在滾動容器上使用 overflow: hidden，這通常會禁用原生彈性滾動 (bounce) 並可能引入卡頓。

1. 電池與 CPU 考慮:

• 減少後台任務、動畫和輪詢的頻率。
• 優化複雜的計算，使用 Web Workers。

🔍 SEO 與性能

1. 服務器端渲染 (SSR) / 靜態站點生成 (SSG):

• SSR (如 Next.js, Nuxt.js, Angular Universal): 在服務器生成完整 HTML 發送給客户端，改善首屏加載速度（尤其是 TTFB、FCP、LCP）和 SEO。注意水合 (Hydration) 成本。
• SSG (如 Next.js, Gatsby, Hugo, Eleventy): 在構建時預渲染所有頁面為靜態 HTML，提供最佳性能（極快加載）和安全性。適合內容相對固定的站點。
• 增量靜態再生 (ISR - Next.js) / 按需重新驗證: SSG 的增強，允許在構建後更新或添加頁面。

1. 流式 SSR:

• 將 HTML 內容分成多個塊 (chunks) 逐步發送到瀏覽器，允許瀏覽器在接收到整個頁面之前就開始渲染內容，顯著改善 LCP 和 TTI 感知。Next.js 等框架支持。

🧪 測試與驗證

1. 在不同環境和條件下測試:

• 設備: 多種真實設備（高/中/低端手機、平板、桌面）。
• 網絡: 模擬慢速網絡（3G, 甚至 2G - 使用 DevTools 或 WebPageTest）。
• 位置: 測試不同地理區域的訪問速度（使用 WebPageTest 的多地點測試）。
• 瀏覽器: 主要瀏覽器（Chrome, Firefox, Safari, Edge）及其版本。

1. 測試用户旅程 (User Journeys):

• 不要只測首頁。測量關鍵業務路徑的性能（如產品詳情頁 -\> 加入購物車 -\> 結賬流程）。

1. 無障礙 (Accessibility) 與性能:

• 許多性能優化（如語義化 HTML、合理的加載順序）也有益於無障礙。確保優化措施不會損害無障礙性（如延遲加載內容應能被屏幕閲讀器正確訪問）。

🎯 結論

前端性能優化是一個持續的旅程，而非一勞永逸的目標。這份清單為你提供了全面的視角和具體的行動項。

關鍵步驟：

1. 測量 (Measure): 使用實驗室工具和 RUM 確定基線性能。
2. 設定目標 (Set Goals): 基於核心 Web 指標和業務需求定義性能預算。
3. 分析 (Analyze): 使用工具（Lighthouse, WebPageTest, DevTools）找出瓶頸。
4. 優化 (Optimize): 根據清單中的策略，優先處理影響最大的瓶頸（通常是圖片、JS、網絡請求）。
5. 監控與迭代 (Monitor & Iterate): 持續監控性能，建立告警，防止迴歸，並不斷尋找新的優化機會。

擁抱性能文化，將性能考量融入開發的每個階段（設計、開發、測試、部署），你的用户（和搜索引擎）將會感謝你！開始行動吧，優化你的網站，贏得速度之戰！💪

寫在最後

譯者按： 本文翻譯自 Crystallize 的技術博客，原作者提供了非常全面且實用的前端性能優化思路。在實際項目中，務必根據自身應用的特點和用户羣體，有側重地選擇和實施這些策略，並通過工具量化優化效果。性能優化永無止境，保持關注新技術（如 Partytown, Islands Architecture）和最佳實踐的演進。

版權聲明： 本文翻譯自 Crystallize 博客文章 "Frontend Performance Checklist"，版權歸原作者所有。中文翻譯內容僅供學習和交流。