1、图片复用概述：为什么需要复用图片资源、复用带来的性能收益、常见的复用策略概览

各位好，咱们开始聊图片复用这个话题。

说实话，我做了这么多年前端性能优化，图片资源一直是绕不开的坎儿。你想想看，一个典型的移动端页面，图片体积能占到总资源量的 60% 以上。页面切换时如果每张图都重新加载，那体验基本就崩了。

今天这第一节课，咱们先把基础打牢。我会从三个角度切入：为什么需要复用、复用能带来什么收益，以及常见的复用策略有哪些。嗯，不搞虚的，全是实战中摸爬滚打出来的经验。

先问一个问题：页面切换时，图片到底发生了什么？

假设你有一个商品列表页，用户点进某个商品详情页，再返回列表页。如果没有复用机制，浏览器会重新请求列表页的所有图片。哪怕这些图片在内存里还热乎着，网络层也得重新走一遍——DNS 查询、TCP 握手、TLS 协商……这一套下来，几百毫秒就没了。

我个人习惯把这个问题拆成三个层面来看：

网络层面：重复请求浪费带宽，尤其在高延迟网络下（比如 3G、弱 Wi-Fi），每次请求都是煎熬。
内存层面：图片解码后的位图数据如果反复创建、销毁，GC 压力会非常大。我在项目中遇到过，一个图片轮播页面因为频繁创建 Image 对象，导致页面卡顿到 10fps 以下。
渲染层面：浏览器解码图片需要时间。如果每次切换都重新解码，用户会看到明显的白屏或闪烁。

核心结论：图片复用的本质，就是用空间换时间——把已经加载、解码好的图片数据缓存起来，避免重复的网络请求和解码开销。

收益到底有多大？我直接给一组我在生产环境实测的数据。

你看，复用不是锦上添花，而是雪中送炭。尤其是页面切换耗时，从 1.2 秒降到 320 毫秒——这个差距，用户的手指能直接感受到。

我曾经在一个电商项目里做过 A/B 测试：A 组不做图片复用，B 组做。结果 B 组的页面跳转跳出率降低了 22%。说白了，用户等得不耐烦了就会走，你留不住他。

小提示：图片复用带来的收益，在列表页 → 详情页 → 列表页这种来回切换的场景下最为明显。如果你做的产品有大量这种交互，一定要把复用机制做扎实。

策略有很多，但万变不离其宗。我按缓存层级把它们分成了四类，下面这张图可以帮你快速建立整体认知。

下面我简单展开说一下每种策略的核心思路：

这是最基础的策略。通过设置 Cache-Control: max-age=31536000 或者配合 ETag 做条件请求，让浏览器在本地缓存图片。页面切换时，只要缓存没过期，浏览器直接从磁盘读取，不走网络。

但有个坑：缓存失效后，所有页面都得重新加载。我曾经在一个活动页面上吃过这个亏——缓存设置得太短，导致高峰期图片请求量暴增，CDN 回源压力巨大。

把图片解码后的 ImageBitmap 或 HTMLImageElement 对象保存在 JavaScript 变量里。页面切换时，直接从内存中取出来绘制到 Canvas 或 DOM 上。

这种策略的优点是速度极快，几乎没有延迟。缺点是占用内存，不适合缓存大量大图。我一般控制在 10-20 张以内。

利用 IndexedDB 或 Cache Storage API 把图片的二进制数据持久化到本地。页面关闭再打开，图片还在。

适合那些不常变化的图片资源，比如 Logo、图标、背景图。我在一个 PWA 项目里用这个方案，把首屏加载时间从 4 秒降到了 1.2 秒。

在用户浏览当前页面时，提前把下一个页面会用到的图片加载到缓存里。等用户真正切换时，图片已经准备好了。

这个策略的关键是时机判断——预加载太早浪费带宽，太晚又来不及。我常用的做法是：用户悬停或触摸某个链接时触发预加载。

注意：以上四种策略不是互斥的，实际项目中往往是组合使用。比如：HTTP 缓存兜底 + 内存缓存加速 + 预加载提前触发。后面几章我会逐一深入讲解每种策略的实现细节和坑点。

这一章咱们把图片复用的为什么和是什么讲清楚了。说白了，复用就是让已经加载过的图片不再重新加载，从而节省时间、带宽和电量。收益是实打实的——页面切换快 70% 以上，用户留存率也能跟着涨。