性能優化一向是前端面試中的常見問題，很多同學面對性能優化問題時都回答的不好。所以，咱們今天就把 前端性能優化問題 進行 全解析。

像什么 頁面加載慢、白屏時間長、滾動卡頓、圖片加載緩慢…… 的，一篇文章，咱們全部帶大家了解下！

完整腦圖鎮樓

一、首屏加載優化

首屏加載是指用戶打開頁面到第一個可視內容呈現出來之間的時間。它直接影響用戶對網站的第一印象，因此在前端性能優化中具有最高的優先級。

優化首屏加載的目標是盡可能快地把關鍵內容展示給用戶，減少白屏時間，提升首屏體驗。

常見的優化方式包括資源按需加載、預加載關鍵資源、使用服務端渲染或靜態生成等。

1. 資源按需加載（Lazy Load）

在前端應用中，JS、CSS、圖片等資源如果全部打包在一起加載，會極大拖慢頁面的加載速度。按需加載的核心思路是：只加載當前頁面渲染所必須的資源，其余資源延后加載或在需要時再加載。

• JavaScript 按需加載使用構建工具（如 Webpack 或 Vite）時，可以借助動態導入（import()）來實現路由級別或組件級別的代碼拆分（Code Splitting）。例如，在 Vue 或 React 應用中，每個路由頁面或大型模塊可以被拆分成獨立的 chunk 文件，只有用戶進入該頁面時才會加載對應的 JS 文件。
• 圖片懶加載頁面中不在首屏展示的圖片可以使用懶加載技術，延遲到滾動進入視口時再進行加載。可以直接使用 loading="lazy" 屬性，無需引入第三方庫。但是，如果想要做到更好可控性的懶加載，擇校使用 IntersectionObserver 來監聽元素是否進入視口，從而決定是否加載圖片。
• 第三方模塊按需引入大型庫如 Lodash、Moment 等可以按需導入，例如使用 lodash-es 代替整個 lodash。日期處理可以使用 dayjs 替代體積龐大的 moment。這類優化通常可以通過 Tree Shaking 和構建工具的配置實現。

2. 預加載關鍵資源

即使按需加載能夠減少首屏資源的體積，但某些資源仍然是“一定會用且必須盡早使用”的，例如首屏字體、主視覺圖、關鍵 JS 腳本等。這些資源可以通過預加載機制提前告知瀏覽器加快加載節奏。

• preload<link rel="preload"> 用于告訴瀏覽器某個資源是高優先級資源，應該盡早加載。例如：

<link rel="preload" href="/fonts/main.woff2" as="font" type="font/woff2" crossorigin="anonymous">

PS：as 屬性指定了資源的類型，有助于瀏覽器進行更好的優先級調度。

• preconnect 與 dns-prefetch當頁面需要請求第三方資源（如 CDN、第三方接口等）時，可以使用 <link rel="dns-prefetch"> 和 <link rel="preconnect"> 來減少 DNS 查詢和 TCP 建連的耗時。前者預解析域名，后者預建立連接。

<link rel="preconnect"  crossorigin>
<link rel="dns-prefetch" >

特別是在頁面初始階段要從多個域名拉取資源時，這項優化能有效減少網絡延遲。

3. 服務端渲染（SSR）或靜態站點生成（SSG）

現代單頁應用（SPA）由于前端 JS 執行完成之后才會渲染頁面內容，因此在網絡較差或設備性能較弱的情況下容易出現長時間白屏的現象。

為了解決這一問題，可以考慮使用 服務端渲染或靜態站點生成 的方式，提升首屏內容呈現速度。

• 服務端渲染（SSR）SSR 的原理是前端框架（如 Vue、React）在服務器端完成首屏 HTML 的渲染并返回給客戶端，瀏覽器接收到完整的 HTML 后可立即展示頁面，之后再加載 JS 接管頁面行為。常見框架如 Next.js（React）、Nuxt（Vue）等都支持 SSR。SSR 可顯著減少白屏時間，提升 SEO 表現，但會增加服務器負擔和架構復雜度。
• 靜態站點生成（SSG）SSG 會在構建階段生成每個頁面的靜態 HTML 文件并部署到 CDN。當用戶訪問頁面時，直接從 CDN 讀取 HTML，無需等待服務器實時渲染，響應速度極快。適合內容基本固定的展示型網站，如博客、文檔站等。
• 混合渲染現代框架如 Next.js、Nuxt3 支持按頁面配置渲染模式，可以為不同路由選擇 SSR、SSG 或客戶端渲染，提升靈活性。

二、資源壓縮與合并

前端頁面性能的瓶頸很大一部分來源于資源的傳輸效率，而資源壓縮與合并正是減少資源體積和請求次數的有效手段。

1. HTML / CSS / JS 壓縮

前端構建工具默認都會對代碼進行壓縮處理，包括移除空格、注釋、換行符，以及對變量名、函數名進行混淆，從而減少文件體積。不同的資源類型采用不同的壓縮工具：

• JS 壓縮：常用工具包括 Terser、UglifyJS。現代構建工具如 Vite 和 Webpack 內部默認集成了 Terser 插件，生產環境自動開啟壓縮。
• CSS 壓縮：使用 cssnano、clean-css 等工具壓縮 CSS，去除重復規則、空格、注釋等。PostCSS 的生態中也有大量 CSS 優化插件。
• HTML 壓縮：可以使用 html-minifier 工具。雖然 HTML 本身體積不大，但在 SSR 或 SSG 輸出的靜態頁面中，壓縮可以減少每次請求的內容大小。

2. 圖片壓縮與格式優化

圖片通常是頁面體積中占比最大的資源，特別是在內容展示型或電商類網站中，一張未壓縮的大圖就可能有數 MB，大量圖片會嚴重拖慢頁面加載速度。

• 圖片壓縮工具：可以在構建流程中引入 imagemin 插件實現自動壓縮。也可以使用一些在線壓縮工具，比如：Squoosh、TinyPNG、ImageOptim（Mac）等
• 格式優化：傳統格式如 PNG、JPEG 已無法滿足現代 Web 的性能要求。可以使用新一代圖像格式，比如：WebP、AVIF
• SVG 圖像優化：對于圖標類圖片，優先使用 SVG。配合 svgo 工具進行壓縮，可顯著減小 SVG 文件體積。

3. 減少請求數

瀏覽器對于同一域名下的并發請求數是有限的（HTTP/1.1 下約為 6 個），如果頁面請求過多會被排隊執行，影響加載速度。那么此時，就可以通過資源合并可以減少請求數量。

需要注意的是，合并資源的策略在 HTTP/2 中發生了變化。由于 HTTP/2 支持多路復用，多個請求可并發傳輸，合并的必要性有所降低，但資源體積越小仍然越好，因為請求數雖不再是瓶頸，傳輸大小和解析速度依舊重要。

4. 使用 CDN 分發資源

資源壓縮之后，部署方式同樣影響加載速度。將靜態資源托管在 CDN（內容分發網絡）上，可以有效提升資源的下載速度，特別是面向全國或全球用戶時。

三、緩存機制優化

緩存機制的核心目標是“減少重復資源的網絡請求”，從而提升頁面加載速度，減輕服務器壓力。

前端常見的緩存方式主要包括：HTTP 緩存、本地存儲緩存、Service Worker 離線緩存等。

1. HTTP 緩存

HTTP 緩存是瀏覽器最基礎、最重要的緩存方式，主要通過響應頭信息進行控制。常見的緩存方式分為兩種：強緩存和協商緩存。

• 強緩存（強制使用緩存）通過設置 Cache-Control: max-age=xxx 或 Expires 響應頭，瀏覽器在設定時間內不再向服務器發起請求，而是直接使用本地緩存。例如：

Cache-Control: max-age=31536000

當用戶在有效期內再次訪問頁面時，請求不會發送，直接命中本地緩存，速度極快。

• 協商緩存（驗證緩存）設置 ETag 或 Last-Modified 響應頭，瀏覽器會在下一次請求時攜帶 If-None-Match 或 If-Modified-Since，服務器比對后決定資源是否更新。如果資源未修改，返回 304 Not Modified，瀏覽器繼續使用本地緩存；如果已更新，則返回新的資源。

2. 本地存儲緩存（localStorage / sessionStorage / IndexedDB）

• localStorage永久存儲，除非手動清除或用戶清空瀏覽器緩存，適合存儲體積小、不會頻繁更新的數據，如用戶設置、Token、主題配置等。
• sessionStorage會話級別的緩存，頁面關閉即失效。適用于需要臨時緩存的數據，如一次會話中的表單步驟進度等。
• IndexedDB結構化本地數據庫，支持大體積數據存儲，適合緩存復雜結構的數據，比如離線文檔、列表數據緩存、圖片緩存等。

3. Service Worker 離線緩存

Service Worker 是一種運行在瀏覽器背后的獨立線程，配合 Cache API，可以實現更高級的緩存控制和離線訪問能力，是構建 PWA（漸進式 Web 應用）的核心技術之一。

四、渲染性能優化

渲染性能是指瀏覽器將 HTML、CSS、JavaScript 等資源轉化為可視頁面的能力。即便資源加載速度足夠快，若渲染效率低下，依然會導致頁面卡頓、滾動不流暢、動畫掉幀等問題。渲染性能優化的目標是減少不必要的計算、繪制和布局重排，讓瀏覽器更高效地完成頁面呈現工作。

常見的優化方式包括控制重排重繪、使用高效的渲染方式、虛擬列表技術、避免冗余 DOM 等。

1. 減少重排與重繪

瀏覽器渲染流程中，每次修改 DOM 或 CSS 都可能引發「重排（Reflow）」或「重繪（Repaint）」，這兩者都伴隨性能開銷，尤其是重排最為昂貴。過多或頻繁的重排，會直接導致頁面掉幀、卡頓。

• 避免頻繁讀寫 DOMJavaScript 中讀取 DOM 信息（如 offsetHeight、getBoundingClientRect）后立即修改樣式，會觸發強制同步計算，阻塞渲染線程。應將 DOM 讀寫操作分批處理，避免交錯執行。
• 合理使用 CSS 屬性使用 transform 和 opacity 等屬性修改樣式，可避免觸發重排，只會產生 GPU 層級上的合成操作，性能更優。例如：

/* 推薦 */
.fade-in {
  transition: opacity 0.3s ease;
}

.move {
  transform: translateX(100px);
}

/* 不推薦 */
.resize {
  width: 100px; /* 會觸發重排 */
}

• 動畫使用 requestAnimationFrameCSS 動畫雖然流暢，但 JS 動畫時應使用 requestAnimationFrame 來確保動畫與瀏覽器刷新節奏同步，提升流暢性并避免資源浪費。

2. 虛擬列表與虛擬滾動

虛擬列表技術通過只渲染可視區域內的內容，大幅降低 DOM 節點數量。用來解決 頁面中存在大量重復結構的 DOM（如長列表、數據表格等） 的問題

大致實現方案如下：

• React：react-window、react-virtualized；
• Vue：vue-virtual-scroller；
• 自研方案：基于 scrollTop 和 offsetHeight 手動控制渲染區間。

3. 控制 DOM 數量與嵌套層級

DOM 節點越多，瀏覽器構建渲染樹的時間越長，布局計算復雜度越高。一般建議頁面的有效 DOM 數量控制在 1500 以內，嵌套層級控制在 5 層以內。

4. 減少樣式計算與復雜選擇器

CSS 渲染過程中的「樣式計算」會遍歷 DOM 樹與樣式規則表，選擇器越復雜，匹配效率越低。

• 避免過深的選擇器，例如 .app .container .list .item .label；
• 避免使用通配符 * 和后代選擇器 div div div；
• 優先使用類選擇器，且盡量不要使用 ID、屬性選擇器等難以復用的選擇器。

五、性能監控與分析

前端性能優化不是一次性的工作，而是一個持續監測、評估、調整的過程。只有建立起完善的性能監控體系，及時發現并定位性能瓶頸，才能持續保障 Web 應用的高可用與高體驗。因此，性能監控與分析在整個性能優化閉環中扮演著至關重要的角色。

性能監控分為兩類：開發階段的性能分析 和 上線后的實時監控。兩者目標不同，但都必須具備。

1. 開發階段：借助工具進行性能分析

在本地開發過程中，開發者可以通過瀏覽器提供的調試工具深入了解頁面加載、渲染、腳本執行等各階段的性能表現，從而發現瓶頸。常見的工具有：

• Chrome DevTools：最常用的瀏覽器性能分析工具，提供以下核心功能模塊：

Performance 面板：可以錄制并分析頁面的加載過程，查看幀率、JS 執行耗時、布局重排次數、渲染瓶頸等信息。

Lighthouse 面板：可一鍵生成頁面性能報告，涵蓋性能（Performance）、可訪問性、SEO、最佳實踐等多個維度，給出具體建議。

Network 面板：查看資源加載時間、大小、狀態碼等，判斷是否存在慢資源、請求阻塞、未壓縮資源等問題。

Coverage 面板：可檢測 JS/CSS 代碼的覆蓋率，找出未使用的代碼，為 Tree-Shaking 和包體積優化提供數據支撐。

• WebPageTest / PageSpeed Insights：Google 提供的在線工具，適合分析線上站點的加載情況，支持不同網絡環境模擬，并能針對 Core Web Vitals 提供評分和優化建議。
• Core Web Vitals（核心指標）：是 Google 推出的關鍵性能指標，衡量真實用戶體驗的關鍵維度，包括：
• LCP（Largest Contentful Paint）：最大內容繪制時間，反映首屏加載速度；
• FID（First Input Delay）：首次輸入延遲，衡量交互響應性；
• CLS（Cumulative Layout Shift）：累積布局偏移，衡量頁面穩定性。

優秀的頁面應該滿足以下標準：

• LCP < 2.5s
• FID < 100ms
• CLS < 0.1

2. 上線階段：實時性能監控與上報

當頁面上線后，由于用戶設備、網絡、行為差異極大，僅靠本地測試無法全面掌握性能表現。因此需要接入性能監控系統，在真實用戶環境中收集關鍵性能數據，以便持續追蹤和告警。

• 自定義監控 SDK，可以通過 PerformanceObserver、performance.getEntriesByType() 等 Web API 收集以下指標：

頁面加載耗時（DNS、TCP、TTFB、DomContentLoaded、Load）

資源加載耗時（圖片、腳本、字體等）

首屏渲染時間（使用打點或 MutationObserver 輔助采集）

首次交互時間、輸入延遲

JS 錯誤、Promise 未處理異常、接口異常

幀率、卡頓檢測（使用 requestAnimationFrame 檢測長任務）

將這些數據結構化后，統一上報到日志服務器，存入數據庫用于可視化展示。

• 接入第三方平臺，例如：

阿里云 ARMS 前端監控

百度 ESee / 字節跳動 Eeyes

騰訊 TARS Frontend Monitor

Sentry / LogRocket / Datadog（國外）

• 性能波動與灰度分析：如某次發版后 LCP 從 1.8s 突然上升到 4s。此時可以結合版本號、地域、終端等維度回溯問題來源，快速定位性能回退的根因。

3. 建立性能指標體系與告警機制

比如：

• 在每次構建后自動跑 Lighthouse 分析；
• 設置性能閾值（如 LCP 超過 3s 告警）；
• 頁面 JS 體積超過 250KB 即阻斷上線流程；
• 配合灰度發布與版本對比，確保性能不回退。
• 等等

除了以上 5 點之外，咱們還需要注意 代碼層面 的一些優化，比如：減少代碼體積，邏輯盡量清晰 等等。不過這一部分的內容更多會因人而異，所以這里就不去展開說啦