懒加载完全指南：图片 / 视频 / 组件 / 路由

懒加载（lazy loading）是把非关键资源的下载、解析、执行延迟到真正需要时再做。它能把首屏数据传输量砍掉一半甚至更多，直接拉低 LCP，提升感知速度，节省用户流量。但懒加载并不是「越多越好」——首屏图片、关键脚本、主转化路径上的组件如果懒加载，反而会拖慢 LCP 与 INP。本文按资源类型分四块（图片、视频、组件、路由）系统讲解 2026 年的懒加载技术栈：原生 loading=lazy、IntersectionObserver、动态 import、React.lazy 路由分包、LQIP 与 BlurHash 占位、视频 preload=metadata，以及哪些场景不该懒加载。每个方案都给出可落地的代码思路与坑点提醒。

1. 懒加载的核心收益与代价

核心收益有四：第一，减少首屏带宽。一个含 30 张图的列表页，未优化时首屏要下载 5 到 10MB，懒加载后通常只下载首屏可见的 3 到 5 张约 500KB。第二，缩短 LCP。LCP 元素之外的图片不抢带宽与解析线程，关键资源更快到位。第三，节省用户流量与电量。移动端用户对流量敏感，省下的就是直接的留存。第四，减少初始 JS 解析量。代码分包后首屏 bundle 从 1MB 降到 200KB 是常态，INP 与 TTI 同步改善。

代价：第一，技术复杂度上升，要处理占位、加载错误、滚动抖动等。第二，首次进入懒加载区域时会有一段「白屏到内容」的过渡，没有占位会引起 CLS。第三，过度懒加载会让网络请求与解析任务过于碎片化，反而拖慢整体。判断公式：节省的下载/解析时间是否大于「请求建立 + 占位渲染 + 状态切换」的成本。

2. 图片懒加载：原生 loading=lazy 已是标配

img 标签加上 loading=lazy 属性，浏览器自动在元素接近视口时才发起请求。Chrome 77+、Firefox 75+、Safari 15.4+、Edge 79+ 都已稳定支持，2026 年全球覆盖率超过 95，可以放心用，不再需要 Polyfill。配合 decoding=async 让图片解码不阻塞主线程。原生方案的优势是零运行时开销、与浏览器调度协同好（带宽空闲时预拉取）、与 fetchpriority 配合得最好。

iframe 同样支持 loading=lazy，对内嵌 YouTube、Bilibili、地图等场景效果显著，能省下整个 iframe 的初始资源。注意：首屏可见的图片绝对不要加 loading=lazy，否则浏览器会延后请求 200 到 600ms（等待布局完成确认是否在视口），LCP 直接下降一档。判断方法：开发时用 Lighthouse 跑分，若 LCP 元素是图片，确认它没有 loading=lazy。

3. IntersectionObserver：复杂场景的瑞士军刀

IntersectionObserver 是浏览器提供的「元素是否进入视口」观察 API，由浏览器异步批量上报，不阻塞主线程，比 scroll 监听性能好 5 到 10 倍。使用场景：图片懒加载（兜底老浏览器、需要 LQIP/BlurHash 切换动画）、组件懒加载（接近视口时挂载重型组件）、无限滚动（observer sentinel 节点触发加载下一页）、动画触发（元素入场时启动 GSAP/Framer Motion）。

关键参数：root 默认是视口，可指定为滚动容器；rootMargin 类似 CSS margin，例如「200px 0」表示视口上下各扩 200 像素就触发，实现「提前加载」；threshold 阈值数组，0 表示一进入就触发，1 表示完全进入才触发，[0, 0.5, 1] 三阶段都触发。常用模式：observe 多个元素，回调里判断 isIntersecting 决定加载，加载后调用 unobserve 防止重复触发。

4. 动态 import 与代码分包

动态 import 是 ES2020 标准，浏览器原生支持。语法是 import('./module.js')，返回 Promise。Webpack 与 Vite 都会把动态 import 的模块单独打包成一个 chunk，按需下载。典型场景：弹窗（Modal）、富文本编辑器（CKEditor、Tiptap，体积通常 200KB+）、地图（Leaflet、Mapbox）、图表（ECharts、Chart.js）、PDF 预览（PDF.js）、视频播放器（Video.js）。这些组件常占首屏 bundle 的 30 到 50，懒加载后体积大幅下降。

实战要点：第一，给 chunk 命名，方便排查（webpackChunkName 注释或 Vite 的 splitChunks 配置）。第二，做 prefetch 预热，例如鼠标悬停就开始下载（hover 到 click 通常有 200 到 400ms 间隔，足够下载完）。第三，处理网络错误，加载失败要 fallback，避免组件卡死。第四，检查 chunk 大小，不要把 1KB 的工具函数也独立成 chunk，请求开销大于节省。

5. React.lazy 与路由级分包

React 项目用 React.lazy 把路由组件做代码分包，是性价比最高的优化之一。每个路由变成独立 chunk，用户访问 A 页时不下载 B 页代码。配合 React Router 的 lazy 字段（v6.4+）能做路由级 code splitting + 数据加载并行。Suspense 是必须的容器，捕获挂起态并渲染 fallback。建议在「Layout 内」与「重组件外」各加一层 Suspense，避免单个组件挂起让整页变 loading。

错误处理用 ErrorBoundary 包住 Suspense。原因是网络错误或 chunk 404 时 React 会抛 ChunkLoadError，没有 ErrorBoundary 就直接白屏。常见模式是 ErrorBoundary 内提供「重新加载」按钮，并 reload 页面以清除旧 chunk hash。Vue 用 defineAsyncComponent 与内置 Suspense；Astro 自带 client:visible 指令实现「滚动到视口才水合」，对岛屿架构非常友好。

6. LQIP 与 BlurHash：占位的两条路线

LQIP（Low Quality Image Placeholder）是把原图压到极小（20 像素宽，质量 20）作为占位图，base64 内联或独立小文件，文件 200 字节到 2KB 之间。CSS 用 filter blur(20px) 让低质图模糊化看起来像艺术处理，原图加载完后切换。优势：浏览器原生支持，渲染零成本，与 Next.js Image、Astro Image 等组件深度集成。劣势：内联 base64 会占 HTML 体积，多张图会让首屏 HTML 变大。

BlurHash 是 Wolt 开源的算法，把图片编码成 30 到 40 字符的字符串，存数据库一列即可，前端解码生成 ImageData 渲染到 canvas。优势：编码体积极小（一张图占位仅 30 字节），适合大量图片场景（社交流、商品列表）。劣势：解码占 CPU，移动端低端机一次解 100 张要 200 到 400ms。Instagram、Wolt、Mastodon 都在用 BlurHash。新方案 ThumbHash（同作者后续作品）解码更快、色彩还原更好，是 2026 年新建项目首选。

7. 视频懒加载：preload 与封面图技巧

视频比图片更需要懒加载，单个视频首帧请求就可能 1 到 5MB。video 标签的 preload 属性有三档：none（完全不预加载）、metadata（只加载元数据如时长尺寸，约 50KB）、auto（浏览器决定，可能下完整视频）。建议默认用 preload=metadata，除非用户明确点击播放。配合 poster 属性提供封面图，让用户在播放前看到画面预览。

用 IntersectionObserver 实现「滚动到视口才挂载 video 标签」效果更彻底，连 50KB metadata 都省。YouTube/Bilibili 嵌入用 lite-youtube-embed 这类「先显示预览图，点击才加载真 iframe」的轻量库，比直接 iframe 节省 80 资源。如果是 HLS 流（m3u8），用 hls.js 配合「视口可见才 attach media」的策略，避免不可见视频占用解码线程。

8. 何时不该懒加载：三个反例

第一，首屏可见图片（特别是 LCP 元素）。任何在初始视口内的图片都不能懒加载，否则浏览器会延后请求等待布局确认，LCP 至少多 200 到 600ms。Hero 图、产品主图、文章首图、列表前 2 行图都属于这一类。判断方法：用 Chrome DevTools 的 Lighthouse 跑一次，看 LCP 元素是哪一个，确认它没有 loading=lazy。

第二，关键交互路径上的组件。例如登录弹窗、支付按钮的触发组件，懒加载会让点击后多 500ms 到 2s 等待，转化率掉点明显。这类组件应该 prefetch（页面空闲时预下载，不解析），点击时直接命中缓存零延迟。第三，体积小于 30KB 的资源。一次 HTTP 请求建立成本约 100 到 300ms，加上 chunk 加载、解析、模块图重建，固定开销 50 到 150ms。如果资源本身只有 10KB，懒加载省下的下载时间可能不到 50ms，反而把固定开销放大。建议按 50KB 起步做懒加载阈值。优化前后用图片压缩工具把首屏图体积压到极致，用图片转 Base64 生成 LQIP 占位，用 JSON 格式化工具校验 BlurHash 上报数据。

常见问题

loading=lazy 兼容性如何，需要 Polyfill 吗？

2026 年所有主流浏览器都已稳定支持，包括 Chrome 77+、Firefox 75+、Safari 15.4+、Edge 79+，全球覆盖率超过 95。微信内置浏览器、QQ 浏览器、UC 浏览器近三年版本也都支持。不再需要 Polyfill，少数老用户用 IntersectionObserver 兜底即可，没必要为 1 到 2 的兼容多加运行时。

IntersectionObserver 比 scroll 监听好在哪？

scroll 监听每次滚动触发一次回调，需要手动 throttle，且要计算 getBoundingClientRect 触发强制重排，性能差。IntersectionObserver 由浏览器异步批量上报，不阻塞主线程；可设置 rootMargin 提前预加载（例如视口下方 200 像素就触发）；threshold 支持多阈值。在长列表场景性能差距能达到 5 到 10 倍。

React.lazy 必须配合 Suspense 吗？

是的。React.lazy 返回的组件会触发挂起（suspend），必须由上层的 Suspense 边界捕获并渲染 fallback。建议在路由层与重组件层都加 Suspense，避免一个组件挂起把整页变 fallback。错误用 ErrorBoundary 捕获，否则代码块加载失败（404 或网络错误）会让页面白屏。

LQIP 和 BlurHash 选哪个？

LQIP（Low Quality Image Placeholder）是把原图压到 20 像素左右的小缩略图作为占位，文件几百字节，浏览器原生支持，渲染零成本。BlurHash 是把图片编码成 30 到 40 字符的字符串，前端解码生成模糊占位，体积更小但解码占用 CPU。流量敏感且占位多用 BlurHash，渲染开销敏感（移动端低端机）用 LQIP。Next.js Image 组件默认走 LQIP（base64 内联）路线。

什么时候不应该懒加载？

三个场景必须避免：第一，首屏可见图片（特别是 LCP 元素），懒加载会拖慢 LCP 至少 1 秒；第二，关键 CTA 按钮或必经路径上的组件，延迟加载会让用户等待；第三，体积小于 30KB 的资源，建立请求的开销大于节省的下载时间。判断标准：是否在用户首屏视口内、是否在主转化路径上、文件是否足够大。