1. 加载卡顿的根源：浏览器凭什么卡住你的页面
我做过不少图片密集型的前端项目，说句实话：图片加载是前端性能体验里最容易被低估的一环。文字和样式渲染得再快，只要首屏出现几张没加载出来的大图，用户感知到的就是“白屏”“卡顿”“怎么还没好”。很多开发者在排查性能问题时，优先盯接口响应时间、JS执行耗时，却忽略了浏览器在图片加载这件事上的真实机制——它不是你写一个<img>标签就完事的。
图片加载导致卡顿的原因，通常不是“下载图片”本身慢，而是两个容易被忽视的环节：解压和绘制。一张几MB的JPG或PNG，下载到本地只是第一步，浏览器还需要把它解压成位图数据，再做尺寸缩放、格式转换，最后交给GPU合成绘制。这个过程在主线程上发生时，会直接阻塞用户的滚动、点击和交互。换句话说，哪怕你的网络带宽已经拉满，图片文件已经缓存到本地，只要浏览器在“不该绘制的时候”被逼着绘制，卡顿一样会出现。
另一个原因更隐蔽：浏览器在解析HTML时，遇到<img>标签并不会立即从服务器拉图，它会参考自身的加载优先级算法，把当前视口附近的资源标记为High优先级，视口外的标记为Low优先级。这个“优先级调度”本身没问题，但问题在于——页面在切换路由、弹层展开、用户滚动到某个区域时，才临时发起图片请求，此时图片才开始下载，整个过程完全暴露在用户的等待窗口里。
所以预加载的核心目的，不是把图片“提前下载完”这么简单，而是把图片下载、解码、缓存这三个阶段的一部分，挪到用户还没看到它的时间窗口里去完成。这样做之后，当用户真正需要看某张图时，图片来源可能不是网络，而是内存缓存或磁盘缓存，显示速度极快，体验上就像“秒开”。
理解了这一点，你就可以看穿市面上很多极端做法的问题。比如有人为了“预加载”，一上来就把整个页面所有图片全部加载一遍，结果首屏带宽被抢，本应优先显示的文字和样式反而变慢，整体评分更难看。真正合理的预加载，应该像缓存一样有策略、有优先级、有数量控制，而不是“全部提前拉取”。
我去年做过一个图片画廊类型的项目，每张作品图平均2MB左右，用户翻页时每翻一屏就要卡顿一到两秒，体验非常糟糕。后来我用JavaScript预加载方案解决了这个问题，首屏图片加载完成后，后台静默预取后两屏的图片，翻页时几乎无感知。这篇文章就把这套思路完整拆开，从原理到代码，再到容易踩坑的细节，全部讲清楚。
2. 预加载的底层机制：HTTP缓存与浏览器加载引擎之间的博弈
在写任何预加载代码之前，你需要先理解一个底层事实：浏览器对图片资源是有记忆的。这个记忆机制由HTTP缓存协议控制，主要由Cache-Control响应头、ETag、Last-Modified这几个字段决定。当你用JavaScript预加载一张图片时，本质上是让浏览器去做一次HTTP请求，并把响应结果存入缓存；之后<img>标签引用同一个URL时，浏览器直接从缓存读取，不会重复下载。
这意味着预加载真正的工作对象，并不是“图片文件本身”，而是浏览器缓存。你提前发请求的目的，是把这条URL塞进浏览器的HTTP缓存里，让后续引用可以走缓存路径。
但这里有一个关键细节：浏览器缓存分为内存缓存和磁盘缓存。预加载的图片在比较长的一段时间里都不被显示时，它可能被挤出内存缓存，落到磁盘缓存中。磁盘缓存的读取速度比内存缓存慢，但仍然远快于网络请求。如果你的预加载代码只是简单地new Image()赋值src，然后什么都不管，那么图片会在内存缓存中驻留一段时间。等用户真正滚动到该图片时，大概率还是能命中缓存，只是命中的层级可能从内存降到磁盘。
理解了这个问题之后，推荐先做一件事：打开Chrome DevTools，把Network面板的Disable cache选项勾掉，然后用无痕窗口访问你的页面，观察图片请求的状态码。正常的预加载后，第二次访问同一张图片时，状态码应该是200 (from memory cache)或200 (from disk cache)。如果你看到的是304，说明缓存协商成功但还是会经过服务器验证；如果你看到的是200，说明缓存策略没有生效，预加载白做了。
还有个容易踩的坑：图片服务端如果返回的Cache-Control是no-store或者private, no-store，那么浏览器压根不会缓存这张图片，预加载也就失去了意义。我碰到过一次类似情况——某客户的图片存储服务默认返回了Cache-Control: no-cache，导致预加载后二次“命中”仍然要完整下载一遍，页面卡顿依旧。排查了半天，最后发现是响应头的问题，调整了服务端配置才算解决。
再来说说浏览器加载引擎本身。现代浏览器对图片请求有自己的调度策略，这个策略在Chrome里被叫作“资源加载优先级”。你可以打开DevTools的Network面板，找到Priority列，观察不同图片的加载优先级。一般情况下，首屏图片是High，视口外的图片是Low，而<script>脚本资源默认是Medium到High。JavaScript预加载图片时，这些图片请求的优先级通常会被标记为Low，这其实是好事——它不会跟首屏的核心资源抢带宽，同时又能在后台悄悄把图片缓存好。
不过，优先级调度只在网络请求阶段生效。图片一旦下载完毕进入解码阶段，浏览器的行为就不受这个调度策略管了。尤其是大尺寸PNG或高分辨率JPG的解码，在主线程上耗时比较长，会造成掉帧。预加载代码把下载提前了，但解码通常发生在图片真正被渲染的那一刻，这一点在后面实战部分我会单独说，有对应的缓解方案。
3. 三种主流的JavaScript预加载实现：从最基础的到最高级的
预加载的实现方案不止一种，不同方案适合不同场景。我按“简单到复杂”的顺序逐一拆解，你可以根据自己项目的实际情况来选。
3.1Image()对象预加载：最基础、兼容性最好的方案
这是最经典的预加载方式，原理简单直白：创建一个Image实例，把图片URL赋给它的src属性，浏览器就会立刻发起请求，并把结果存入缓存。
function preloadImage(url) { return new Promise((resolve, reject) => { const img = new Image(); img.onload = () => resolve(img); img.onerror = () => reject(new Error(`Failed to load image: ${url}`)); img.src = url; }); } // 批量预加载 const imageUrls = [ '/images/gallery/photo-1.jpg', '/images/gallery/photo-2.jpg', '/images/gallery/photo-3.jpg' ]; Promise.allSettled(imageUrls.map(preloadImage)).then((results) => { const successCount = results.filter(r => r.status === 'fulfilled').length; const failCount = results.filter(r => r.status === 'rejected').length; console.log(`预加载完成：成功 ${successCount} 张，失败 ${failCount} 张`); });这段代码里用Promise.allSettled而不是Promise.all，是因为我们不希望某一张图加载失败导致整个预加载流程崩溃。失败要记录，但不要阻塞其他图片的预加载。
关键细节：Promise构造器里的代码是同步执行的，也就是说new Image()创建实例后，img.src = url这一行的赋值操作会立刻触发浏览器发起请求。所以Image()对象预加载在执行时机上有一个特点——只要代码执行到这一行，请求就发了。你不需要把图片插入到DOM里，也不需要设置display:none之类的样式，它就是一个纯后台操作。
3.2link rel="preload"预加载：浏览器原生支持，优先级可控制
如果你使用的是现代浏览器并且不需要兼容IE，那么<link rel="preload">是一个非常好的方案。它是浏览器原生的预加载机制，比JavaScript脚本预加载的好处在于：浏览器是解析到<link>标签就立刻发起请求，不需要等待JavaScript执行。这在页面加载早期尤其重要。
实现方式有两种。
第一种是静态写在HTML里：
<link rel="preload" as="image" href="/images/hero.jpg">第二种是用JavaScript动态插入：
function preloadImageWithLink(url) { const link = document.createElement('link'); link.rel = 'preload'; link.as = 'image'; link.href = url; document.head.appendChild(link); }使用link rel="preload"的时候，有一个很重要的配置项叫fetchpriority。这个属性可以告诉浏览器该资源的加载优先级：
<link rel="preload" as="image" href="/images/hero.jpg" fetchpriority="high">首屏关键图片建议设置fetchpriority="high"，后台预加载的非关键图片保持默认或设置fetchpriority="low"。这样可以避免预加载的图片抢占了首屏其他核心资源的带宽。
需要特别提醒的是：link rel="preload"的兼容性虽然已经很好，但有一个特有的坑——如果as属性写错了，浏览器不会加载这个资源。最常见的错误是把as="image"写成as="images"，或者漏写。此外，preload的资源如果最终没有被页面使用，浏览器会打印一条警告：The resource ... was preloaded but not used within a few seconds。这在开发调试时看到不用慌，只要确认后续确实用到了这些图片就行。
3.3fetch()API预加载：兼顾下载和解码，适合更精细的控制
fetch()方式预加载图片相对少有人用，但它有一个独特优势：你可以拿到实际的文件数据流，进而控制解码时机。这种方式其实更适用于一种边界场景——预加载的图片体积特别大，你希望下载完成后主动控制解码时机，避免一次解码太多导致主线程卡死。
基本的实现如下：
async function preloadImageWithFetch(url) { const response = await fetch(url); if (!response.ok) { throw new Error(`HTTP error! status: ${response.status}`); } const blob = await response.blob(); return URL.createObjectURL(blob); }通过fetch拿到的blob数据，可以用URL.createObjectURL生成一个临时URL，赋值给<img>标签的src使用。这样图片的数据完全由你控制，绕过了浏览器的HTTP缓存机制，走的是应用层缓存。这个做法的代价是代码更复杂、内存管理需要手动处理（用完记得URL.revokeObjectURL），所以日常项目里我不会首选它，但在某种特定场景下它是唯一解——比如你的图片接口需要带自定义鉴权Header，<img>和Image()对象都无法自定义Header，这时候fetch()是唯一方式。
三种方式的选型参考如下表：
| 预加载方式 | 兼容性 | 请求优先级控制 | 自定义请求头 | 主动控制解码 | 适用场景 |
|---|---|---|---|---|---|
Image()对象 | IE6+ | 不可控 | 不支持 | 不支持 | 通用后台预加载，兼容要求高 |
link rel="preload" | Chrome/Edge/FF/Safari 11.1+ | 支持fetchpriority | 不支持 | 不支持 | 页面早期预加载首屏关键图 |
fetch()API | Chrome/Edge/FF/Safari 10.1+ | 支持priority选项 | 支持 | 支持 | 需要鉴权、大图解码控制场景 |
我个人在实际项目中的组合用法是：首屏关键图用link rel="preload"写在HTML里，后两屏的图片用Image()对象在JavaScript里做后台预加载。既不抢占首屏带宽，又能保证滚动切换时图片已经就绪。
4. 实战封装：一个可复用的图片预加载管理器
把预加载逻辑直接写在业务代码里当然可以，但更好的是封装成一个独立的管理器，统一处理加载队列、并发控制、错误重试和状态上报。这样不管是项目里一个页面用，还是多个页面共享，调用方只需要关注“我要哪些图片先准备好”，剩下的细节全部由管理器接管。
我写一个比较完整的管理器示例，你可以直接抄：
class ImagePreloadManager { constructor(options = {}) { this.concurrency = options.concurrency || 4; this.retryCount = options.retryCount || 1; this.timeout = options.timeout || 15000; this.cache = new Map(); this._queue = []; this._activeCount = 0; } // 添加预加载任务 add(url, { priority = 'normal' } = {}) { if (this.cache.has(url)) { return Promise.resolve(this.cache.get(url)); } return new Promise((resolve, reject) => { this._queue.push({ url, resolve, reject, priority }); if (priority === 'high') { // 高优先级任务插队 this._queue.sort((a, b) => { const weight = { high: 0, normal: 1, low: 2 }; return weight[a.priority] - weight[b.priority]; }); } this._processNext(); }); } // 批量添加 addBatch(urls, options) { return Promise.allSettled(urls.map(url => this.add(url, options))); } // 处理下一个任务 _processNext() { while (this._activeCount < this.concurrency && this._queue.length > 0) { const task = this._queue.shift(); this._activeCount++; this._loadWithRetry(task.url, 0) .then(() => { this.cache.set(task.url, 'loaded'); task.resolve(); }) .catch((error) => { task.reject(error); }) .finally(() => { this._activeCount--; this._processNext(); }); } } // 加载图片并支持重试 _loadWithRetry(url, retry) { return new Promise((resolve, reject) => { const timer = setTimeout(() => { reject(new Error(`Image load timeout: ${url}`)); }, this.timeout); const img = new Image(); img.onload = () => { clearTimeout(timer); resolve(); }; img.onerror = () => { clearTimeout(timer); if (retry < this.retryCount) { resolve(this._loadWithRetry(url, retry + 1)); } else { reject(new Error(`Image load failed after ${retry + 1} attempts: ${url}`)); } }; img.src = url; }); } // 查询加载状态 getStatus(url) { if (this.cache.has(url)) { return this.cache.get(url); } return 'pending'; } }这个管理器解决了几个实际问题：
并发控制。如果不控制并发，一次性发起30个图片请求，浏览器会全部建立连接，不仅图片服务器压力大，浏览器本身的连接池也会被打满，导致其他关键资源（比如接口请求）等待。默认4个并发是比较稳妥的数值，网络条件好的情况下可以提高到6到8个。
失败重试。图片加载偶发性失败常见于弱网环境，一次失败不代表永久失败，所以我加了重试机制。但重试次数不能太多，否则会对服务器造成无意义的压力。1到2次是合理的范围。
超时处理。有些图片请求可能会长时间挂起（服务端问题或网络问题），如果没有超时控制，预加载队列会被一直占住，后续图片无法执行。15秒是一个合理的阈值。
结果缓存。同一个URL在短时间内被多次调用add时，不需要重复发请求，直接从缓存结果拿，避免重复加载。
调用方式很直接：
const preloadManager = new ImagePreloadManager({ concurrency: 4, retryCount: 1 }); // 用户停留在首页时，预加载列表页可能用到的图片 preloadManager.addBatch([ '/list/photo-1.jpg', '/list/photo-2.jpg', '/list/photo-3.jpg' ]); // 某个关键图片提高优先级 preloadManager.add('/detail/hero.jpg', { priority: 'high' });这里我特别说明一下“高优先级”的处理逻辑。虽然排序实现得比较粗糙（按数组sort），但在实际项目中，高优先级图片通常是用户马上要看到的图片，把它排到队列前面，可以让它更早进入加载流程。
5. 预加载与懒加载的搭配：别把两者对立起来
很多前端开发者有一种误解：预加载和懒加载是两个互相矛盾的方案——一个要提前加载，一个要延迟加载。但实际上，两者在真实项目里是完全可以配合使用的，关键在于给不同位置的图片设定不同的加载策略。
懒加载的主流实现方式有两种：一种是loading="lazy"这个HTML属性，另一种是使用IntersectionObserver来动态给图片设置src。
loading="lazy"是最简单的方案：
<img src="placeholder.jpg">const observer = new IntersectionObserver((entries) => { entries.forEach((entry) => { if (entry.isIntersecting) { const img = entry.target; const realSrc = img.dataset.src; if (realSrc) { // 这里对应预加载管理器：如果图片已经在缓存里，直接赋值src即可 img.src = realSrc; } observer.unobserve(img); } }); }, { rootMargin: '200px' }); document.querySelectorAll('img[data-src]').forEach((img) => { observer.observe(img); });在这个模式里，预加载管理器的任务就是提前把未来可能出现在视口里的图片URL请求一遍。当IntersectionObserver触发回调时，图片的下载已经完成，赋值src的瞬间浏览器只是从缓存里读取，完全没有网络延迟。
一个典型的配合场景是图片列表的无限滚动。用户在第一屏看到图片1到10，你可以在首屏加载完成后，立即预加载图片11到20（下一屏的内容）；当用户滚动到第二屏时，图片11到20其实已经缓存好了，显示速度极快。而图片21到30可以在用户滚动到第二屏时再开始预加载。这种“滚动到哪里就预加载到哪里”的策略，是解决长列表图片卡顿的核心手段。
这里有一个我反复试验过的数值参考：预加载的窗口一般设置在“当前视口往后2到3屏”比较合适。预加载太多，浪费带宽和内存；预加载太少，用户滚动太快时还是会看到占位图。2到3屏是体验和资源消耗的平衡点。
6. 解码性能优化：预加载之后，卡顿的另一半来源
如果预加载都做好了，页面还是卡，那问题大概率出在图片解码上。图片下载完成和图片呈现在屏幕上之间，隔着一个解码步骤。这个步骤通常发生在主线程，而且——重要的事情我再强调一遍——解码发生在图片被绘制的那个时刻，不是你预加载完成的那个时刻。
大尺寸图片的解码会阻塞主线程，导致滚动掉帧、点击响应延迟。这个问题在移动端尤其明显，因为手机的CPU性能远弱于桌面端。优化解码性能有几个实操手段。
使用decode()方法主动控制解码时机。现代浏览器为HTMLImageElement提供了一个decode()方法，它返回一个Promise，在图片解码完成后resolve。正确的姿势是：图片预加载完成后，不要立刻显示，而是先把图片数据准备好，等真正要显示的时候再调用decode()解码，或者提前调用decode()把解码结果缓存起来。
async function preloadAndDecode(url) { const img = new Image(); img.src = url; await img.decode(); // 主动解码 return img; }上面的代码在预加载图片的同时完成了解码。当你在界面上使用这张图片时，就不再需要等待解码，可以直接绘制。
不过要注意：decode()方法虽然好用，但不能对图片列表里的每一张图都无脑调用。如果图片数量多且体积大，同时解码几十张图，主线程的瞬时渲染压力反而会更大。正确的做法是：对即将进入视口的那几张图片提前调用decode()，其他的只预加载不预解码。
把解码和预加载合起来，可以封装一个更精细的预加载函数：
async function preloadImageSmart(url, { decode = false } = {}) { const img = new Image(); img.src = url; if (decode) { try { await img.decode(); } catch (error) { // 解码失败不影响原有加载逻辑，兜底处理 console.warn('Image decode failed, will load regularly', url); } } else { await new Promise((resolve, reject) => { img.onload = resolve; img.onerror = reject; }); } return img; }另一个比较实用的技巧是：提前设置图片的width和height属性。很多图片在真实展示前，浏览器不知道它的尺寸，必须等图片解码完成后才能确定布局位置，这会造成布局偏移（CLS），严重影响用户体验。你在预加载时就可以从服务器端接口拿到图片的宽高比，直接给<img>标签设置好width和height，或者用CSS的aspect-ratio属性锁定比例。这样即使图片还没有加载完，页面布局也是稳的，不会出现加载完成后的跳动。
7. 移动端弱网环境下的预加载策略调整
移动端的网络环境远比桌面端复杂。用户可能在Wi-Fi、4G、5G信号之间切换，也可能在地铁、电梯等弱信号环境下使用页面。预加载策略如果一成不变，很容易在弱网环境下起反作用——把用户宝贵的带宽耗费在“未来才可能看到的图片”上，结果当前正在看的内容反而加载变慢。
针对弱网环境，我建议从两个维度调整预加载策略：一是根据网络类型调整预加载数量，二是根据当前网络实时状态暂停或恢复预加载。
navigator.connectionAPI可以帮你拿到网络信息。这个API在Chrome和Edge中支持良好，Safari的支持相对差一些，做功能增强时需要加能力检测：
function getNetworkType() { if ('connection' in navigator) { return navigator.connection.effectiveType; } return 'unknown'; } function isSlowNetwork() { const type = getNetworkType(); return type === 'slow-2g' || type === '2g' || type === '3g'; } function adjustPreloadStrategy() { if (isSlowNetwork()) { // 弱网环境下，只预加载即将进入视口的图片（1屏） return { preloadDistance: 1, concurrency: 2 }; } else { // 正常网络下，预加载后2-3屏的图片 return { preloadDistance: 3, concurrency: 4 }; } }在此基础上，你还可以监听网络类型变化事件，在用户从Wi-Fi切换到弱网络时，暂停或降低预加载的频率：
if ('connection' in navigator) { navigator.connection.addEventListener('change', () => { const { preloadDistance } = adjustPreloadStrategy(); updatePreloadDistance(preloadDistance); }); }除了网络类型，navigator.connection还能提供downlink（当前下行带宽估计值）和rtt（估计往返时间）。你可以配合这两个字段做更细粒度的判断。例如当downlink低于1.5Mbps时，就是典型的弱网信号，此时要限制预加载的图片数量。
另外，还有一个容易被忽略的点：移动端的内存限制比桌面端严格得多。桌面浏览器给一张图片分配几十MB内存没问题，移动端则可能出现内存压力。预加载的图片如果长时间不显示，一直占据内存，浏览器可能触发内存回收机制，反而引起页面性能抖动。更好的做法是：在移动端限制预加载图片的总数量（比如最多预加载15到20张），并适时清理不再需要的预加载缓存。
8. 实测数据：同一个页面，预加载前后的体验变化
我在一个真实的图片类项目上做了完整的预加载改造。这个页面是一个画廊首页，首屏有4张大图，往下翻有12张小图组成的瀑布流，点击任意小图会进入详情页并显示大图。改造前的主要问题是：首屏4张大图加载完需要2到3秒，用户翻到第二屏时小图一张张弹出来，体验非常难看。
改造方案分三步：第一，首屏4张大图用link rel="preload"在HTML头部声明，提升优先级；第二，首屏加载完成后再用Image()预加载后面12张小图；第三，用户点击小图进入详情页时，详情页的大图用fetchpriority="high"的预加载。
改造前后的关键数据如下（测试环境为MacBook Pro + Chrome模拟4G网络）：
| 指标 | 改造前 | 改造后 | 变化 |
|---|---|---|---|
| 首屏图片显示完成时间 | 2.8s | 1.6s | 提升42% |
| 第二屏图片显示完成时间 | 4.5s | 1.9s | 提升58% |
| 详情页大图显示时间 | 2.2s | 0.8s | 提升64% |
| LCP（最大内容绘制） | 3.1s | 1.8s | 提升42% |
| 滚动到第二屏时的空白等待 | 明显可感知 | 几乎无感知 | 体验飞跃 |
值得说明的是，这些数据的提升不只是“提前加载”带来的，还有一个因素是浏览器缓存的命中率。预加载把图片请求提前了，用户后续刷新页面时，图片可能直接从磁盘缓存读取，不再走网络。我在测试时刷新页面，第二屏图片的状态码变成了200 (from memory cache)，这在实际体验中就等同于秒开。
但我也要提醒你：预加载不是银弹。如果你的图片服务器本身没有开HTTP缓存（响应头没有Cache-Control），预加载只在单次页面会话内有效，刷新后还是要重新下载。所以我给这个项目做的另一个改动，就是让图片服务端正确配置了缓存响应头：
Cache-Control: public, max-age=2592000max-age设为30天，对图片这类不常变化的资源来说是一个比较合理的数值，可以显著提高缓存命中率。
9. 从一次线上事故看预加载的边界：什么时候不该用
我在一个项目中曾经因为滥用预加载，把页面搞得更糟，那次事故让我长了记性。
当时做一个图片社区的专题页，图片非常多，我为了追求“顺畅体验”，在页面加载后一次性预加载了所有图片，整整36张高清大图，每张1.5MB左右，加起来50多MB。结果呢？页面首屏的图片加载确实快了，但下拉加载其他模块的接口响应明显变慢，用户滚动时还出现了帧率下降。后来一查，原因是预加载任务把浏览器的网络连接池占满了，同时几十张图片的解码也占用了大量主线程时间。
那次经历让我总结出几条预加载的边界原则。
单次预加载的图片数量要卡阈值。我个人习惯是在非移动端场景单次预加载不超过20张，移动端不超过10张。超过这个数量，边际收益很低，边际成本却很高。
高分辨率大图不要无脑预加载。尤其是那种几MB甚至十几MB的超大图，预加载两三张就能把带宽吃光。对于大图，更好的策略是：先用压缩后的缩略图做展示，用户点击查看大图时才开始加载原图。
预加载不适用于用户可能永远不会看到的资源。电商网站的每个商品都有多张详情图，但用户通常只关心前两张，第三张、第四张的点击查看率非常低。这种资源做预加载就是浪费。判断标准很简单：用户到达这个页面的概率越大、越快，预加载的优先级越高。
要考虑图片的时效性。如果图片资源本身频繁变化（比如用户头像、实时截图），预加载缓存的数据可能已经过期，展示出来反而造成错误信息。这类资源需要设置更短的缓存时间，或者干脆不预加载。
这些边界条件其实比预加载代码本身更重要。代码是固定的逻辑，边界条件才是决定一个方案成败的关键。
10. 调试与验证：怎么确认预加载真的生效了
很多人写完预加载代码，看都不看就上线了，结果预加载根本没生效，白忙活。验证预加载是否生效的方法很简单，但需要细心观察。
打开DevTools的Network面板，在页面上找一张预加载的图片URL，刷新页面。观察它的加载时序。如果这张图片在页面请求的早期就出现了（比如在HTML解析阶段就发起请求），并且第二次刷新时状态码是200 (from memory cache)或200 (from disk cache)，说明预加载生效了。
还有一个方法是使用DevTools的Coverage面板，它能够展示资源的使用情况。预加载的资源如果最终被使用了，Coverage会高亮标记，说明预加载是有效的。如果Coverage显示这个资源虽然预加载了但从未被使用，说明预加载策略里有浪费。
Chrome的DevTools还提供了一个表格视图，叫Network > Priority列。你可以排序查看所有图片的加载优先级，确认预加载的图片优先级是否符合预期。比如fetchpriority="high"的图片应该是High，普通预加载的图片应该是Low。
在实际项目中，我还会在预加载管理器里加一个埋点，统计预加载图片的成功率、失败率、平均加载耗时。上线后观察这些数据，能及时发现问题。比如某一天图片服务器的某个CDN节点出现故障，预加载失败率飙升，埋点数据就能反映出来。
11. 预加载之外：顺手能做的图片性能优化清单
预加载只是图片性能优化中的一环，如果你的项目本身图片优化没做到位，预加载只能缓解表面症状，治标不治本。我整理了和预加载配合使用的几个优化手段，建议一起做。
图片格式选型。现代浏览器支持WebP和AVIF格式，同等画质下比JPG和PNG体积小很多。如果你有图床或CDN，建议开启自动格式转换。部署一张WebP图片，体积比同画质JPG减少25%到35%，AVIF减少50%以上。体积小了，预加载的负担自然就小了。
响应式图片。用srcset和sizes属性让浏览器根据设备屏幕宽度选择合适尺寸的图片。移动端加载小图，桌面端加载大图，避免2倍屏和3倍屏都去加载同一张大图。
CDN图片裁切参数。很多CDN服务支持URL参数实时裁切图片，比如阿里云OSS、腾讯云COS的图片处理功能。你在请求图片时可以指定目标宽度和高度，CDN动态返回对应尺寸的图片。这会减少大量不必要的带宽消耗。
WebP兼容方案。如果图片服务器支持WebP，可以用<picture>元素提供多格式的源，让浏览器自行选择最合适的格式：
<picture> <source type="image/webp" srcset="/images/photo.webp"> <img src="/images/photo.jpg" alt="示例图片"> </picture>这些工作做完之后，预加载的收益会进一步放大。因为图片体积更小，同样带宽下能预加载更多图片，解码时间也更短，整个加载链路都会更流畅。
图片性能优化是一个系统工程，预加载是其中非常重要的一环，但不是全部。我自己在项目里通常把预加载比喻成“提前把货放进仓库”，但如果货本身又大又重，仓库放不了几件，速度也快不起来。先把货做小了，再把货提前放进仓库，才是最优解。
