JavaScript图片预加载实战：从浏览器缓存到解码优化的完整指南

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 relpreload预加载浏览器原生支持优先级可控制如果你使用的是现代浏览器并且不需要兼容IE那么link relpreload是一个非常好的方案。它是浏览器原生的预加载机制比JavaScript脚本预加载的好处在于浏览器是解析到link标签就立刻发起请求不需要等待JavaScript执行。这在页面加载早期尤其重要。实现方式有两种。第一种是静态写在HTML里link relpreload asimage 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 relpreload的时候有一个很重要的配置项叫fetchpriority。这个属性可以告诉浏览器该资源的加载优先级link relpreload asimage href/images/hero.jpg fetchpriorityhigh首屏关键图片建议设置fetchpriorityhigh后台预加载的非关键图片保持默认或设置fetchprioritylow。这样可以避免预加载的图片抢占了首屏其他核心资源的带宽。需要特别提醒的是link relpreload的兼容性虽然已经很好但有一个特有的坑——如果as属性写错了浏览器不会加载这个资源。最常见的错误是把asimage写成asimages或者漏写。此外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所以日常项目里我不会首选它但在某种特定场景下它是唯一解——比如你的图片接口需要带自定义鉴权Headerimg和Image()对象都无法自定义Header这时候fetch()是唯一方式。三种方式的选型参考如下表预加载方式兼容性请求优先级控制自定义请求头主动控制解码适用场景Image()对象IE6不可控不支持不支持通用后台预加载兼容要求高link relpreloadChrome/Edge/FF/Safari 11.1支持fetchpriority不支持不支持页面早期预加载首屏关键图fetch()APIChrome/Edge/FF/Safari 10.1支持priority选项支持支持需要鉴权、大图解码控制场景我个人在实际项目中的组合用法是首屏关键图用link relpreload写在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. 预加载与懒加载的搭配别把两者对立起来很多前端开发者有一种误解预加载和懒加载是两个互相矛盾的方案——一个要提前加载一个要延迟加载。但实际上两者在真实项目里是完全可以配合使用的关键在于给不同位置的图片设定不同的加载策略。懒加载的主流实现方式有两种一种是loadinglazy这个HTML属性另一种是使用IntersectionObserver来动态给图片设置src。loadinglazy是最简单的方案img srcplaceholder.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 relpreload在HTML头部声明提升优先级第二首屏加载完成后再用Image()预加载后面12张小图第三用户点击小图进入详情页时详情页的大图用fetchpriorityhigh的预加载。改造前后的关键数据如下测试环境为MacBook Pro Chrome模拟4G网络指标改造前改造后变化首屏图片显示完成时间2.8s1.6s提升42%第二屏图片显示完成时间4.5s1.9s提升58%详情页大图显示时间2.2s0.8s提升64%LCP最大内容绘制3.1s1.8s提升42%滚动到第二屏时的空白等待明显可感知几乎无感知体验飞跃值得说明的是这些数据的提升不只是“提前加载”带来的还有一个因素是浏览器缓存的命中率。预加载把图片请求提前了用户后续刷新页面时图片可能直接从磁盘缓存读取不再走网络。我在测试时刷新页面第二屏图片的状态码变成了200 (from memory cache)这在实际体验中就等同于秒开。但我也要提醒你预加载不是银弹。如果你的图片服务器本身没有开HTTP缓存响应头没有Cache-Control预加载只在单次页面会话内有效刷新后还是要重新下载。所以我给这个项目做的另一个改动就是让图片服务端正确配置了缓存响应头Cache-Control: public, max-age2592000max-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列。你可以排序查看所有图片的加载优先级确认预加载的图片优先级是否符合预期。比如fetchpriorityhigh的图片应该是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 typeimage/webp srcset/images/photo.webp img src/images/photo.jpg alt示例图片 /picture这些工作做完之后预加载的收益会进一步放大。因为图片体积更小同样带宽下能预加载更多图片解码时间也更短整个加载链路都会更流畅。图片性能优化是一个系统工程预加载是其中非常重要的一环但不是全部。我自己在项目里通常把预加载比喻成“提前把货放进仓库”但如果货本身又大又重仓库放不了几件速度也快不起来。先把货做小了再把货提前放进仓库才是最优解。