前端图片加载优化全链路方案文章目录前端图片加载优化全链路方案一、先理解图片慢的本质二、全链路优化方案环节 1上传时压缩源头控体积环节 2格式选对体积立省 30%~80%环节 3按需缩放别让用户下载原图环节 4加载时机懒加载与预加载环节 5长缓存解决「每次进来都重新加载」环节 6占位与降级提升感知体验环节 7外链与安全别忘了非自有图片三、如何验证优化效果四、一条判断清单你的图片该优先优化哪一环五、进阶方案再往深做六、本项目完整实践对照七、总结这篇文章从「图片为什么慢」出发系统梳理前端图片优化的完整链路与各类方案并用我的线上项目 Prompt Galler图片提示词的真实实践作为案例。文中大部分方案是通用的不绑定任何具体框架或云厂商可直接套用到你自己的项目。Prompt Galler线上地址http://prompt.gouxinjie.com/一、先理解图片慢的本质一张图片从用户点开页面到显示出来经历了几个环节① 图片体积多大 → ② 有多少张要下载 → ③ 走没走缓存 → ④ 渲染时机对不对任何一个环节没做好都会让用户感觉「图片加载慢」或「每次进来都重新加载」。所以图片优化不是单点动作而是一条全链路上传时压缩 → 格式选对 → 按需缩放 → 懒加载/预加载 → 长缓存 → 占位与降级下面按这条链路逐个讲每个环节都给出通用做法和本项目的落地参考。把「一张图的一生」完整画出来能看到优化点分布在哪① 上传压缩 → ② 格式选对 → ③ 按需缩放 → ④ 加载时机 → ⑤ 长缓存 → ⑥ 占位降级 另⑦ 外链与安全环节一句话优化目标① 上传压缩源头控制体积存储/带宽↓② 格式选对选体积更小的格式体积↓③ 按需缩放别下载原图流量↓④ 加载时机首屏抢、非首屏缓减少首屏请求数⑤ 长缓存别反复下载减少重复请求⑥ 占位降级稳住体验体验↑⑦ 外链与安全识别自有/第三方资源安全↑①②③ 决定「每张图传多大」④ 决定「什么时候传」⑤ 决定「还要不要重复传」⑥⑦ 决定「传的过程中体验稳不稳、安不安全」。二、全链路优化方案环节 1上传时压缩源头控体积图片优化最好从源头做起——在用户上传时就控制原始体积而不是等展示时再补救。通用做法前端用 Canvas 对图片做「压缩后上传」常见库有browser-image-compression、compressorjs。压缩要点限制最大边长如 2000px、JPG 质量 0.8 左右、EXIF 方向修正。好处原始存储体积变小后续所有环节都受益。顺手可用的线上压缩工具TinyPNG最经典的 PNG/JPG 压图工具网页拖拽即用对「单张几十张图、不想写代码」的场景最省事。它的压缩原理是智能降低色彩数量并优化编码属于人眼几乎无感的近无损有损压缩视觉几乎不变但体积能降一大截。也有 API需注册 key可集成到上传流程。SquooshGoogle 出品的在线图片压缩器支持 AVIF/WebP/JPEG/PNG 等多种格式互转可实时对比压缩前后质量与体积适合「挑格式 调质量」一起完成。TinyPNG 同族的 SVGO面向 SVG 图标的压缩工具适合压缩矢量图标资源。其他可参考Kraken.io、CompressOrDie支持 GIF。用法提示设计稿或批量素材可以先用 TinyPNG/Squoosh 压一轮再上传如果流程要求自动压缩则优先考虑browser-image-compression前端或对象存储的图片处理能力后端/云函数线上工具更多是「人工批量处理」的兜底手段。本项目现状目前是 OSS 浏览器直传原图上传时没做压缩但限制了单图不超过 8MB。原图较大时靠「展示时缩放」兜底见环节 3。若运营/管理员手动传图可先用上面的线上工具压一遍再走直传能进一步省存储与带宽。结论如果追求极致上传压缩是最值得做的一环能从根本上减小存储与带宽成本。线上工具适合人工批量处理自动化流程则用前端库或服务端图片处理。环节 2格式选对体积立省 30%~80%图片格式对体积影响巨大优先级大致是AVIF WebP JPEG PNG同画质下通用做法有透明通道的图形 → PNG / WebP。无透明通道的照片 → JPEG / WebP / AVIF。动图 → GIF / WebP动画。现代浏览器基本都支持 WebP条件允许上 AVIF。本项目现状通过阿里云 OSS 图片处理服务在加载时用?x-oss-processimage/format,jpg把 PNG 实时转成 JPG 返回原图保持不变。好处不改原图、不引入服务端处理能力代价是 JPG 对透明 PNG 会产生黑/白底、体积不如 WebP。启示格式转换不一定非要在上传时做死像本项目这样「按需动态转换」也是一种灵活思路但要注意透明背景和动图两个边界。环节 3按需缩放别让用户下载原图这是本仓库最近重点优化的部分也是最容易被忽略的一环。核心问题一张 3000px 的原图在 400px 的卡片里展示如果直接把原图地址塞给img浏览器下载的是完整原图——浪费了大量流量和时间。通用做法给不同展示尺寸准备不同大小的图片响应式图片用img srcset sizes让浏览器按视口挑合适的。或用云厂商的图片处理服务在 URL 上追加缩放参数实时生成缩略图本项目正是这种。本项目落地封装了统一的图片地址工具toDisplayImageUrl第二个参数指定目标宽度// 列表缩略图用 900px大图位用 1600px小格子用 200pxtoDisplayImageUrl(caseItem.coverUrl,900);// 首页卡片toDisplayImageUrl(activeCover,1600);// 详情主图toDisplayImageUrl(image,200);// 封面缩略图这些w_XXX数字是什么它们是 OSS 图片处理 URL 参数的一部分原图 URL ? x-oss-processimage/format,jpg/resize,w_900 ↑ ↑↑ ↑↑ ↑↑↑ 原始图片地址 转JPG 限制宽度900px也就是resize,w_900告诉 OSS把这张图在服务端实时缩到 900px 宽再返回高度等比不拉伸。这样浏览器拿到的就是一张 900px 的小图而不是几 MB 的原图。项目里为什么用1200 / 1600 / 900 / 480 / 200这几档因为不同展示位的「物理需要」不同档位就是按「该位置的渲染宽度 × DPR」来定的档位用在哪对应渲染宽度CSS px覆盖 DPRw_1600详情主图、首页 Hero 大图约 600~8002x 高清屏w_1200中等大图默认档未指定 width 时的兜底约 500~6002xw_900首页卡片、收藏卡片、详情参考图/相关推荐约 300~5002xw_480后台表格缩略图、投稿小图约 80~2402xw_200详情页封面切换小缩略图约 76~1002x档位偏低如 400px 卡片却给w_200→ 图被浏览器放大 →发糊本项目就踩过把卡片从w_480提到w_900。档位偏高小格子却给w_1600→ 等于下载接近原图的图 →白费流量。默认档w_1200当调用方不传 width 时如大图预览弹层、上传组件预览兜底用 1200保证「不放任下载原图」又足够清晰。宽度的选择依据是一个朴素的公式目标宽度 图片实际渲染 CSS 宽度 × 设备像素比(DPR)普通屏 DPR 1渲染宽度即可。Retina 屏 DPR 2需要渲染宽度 × 2的源图才不糊。这也是为什么本项目把卡片从w_480提到w_900、大图位用到w_1600——低档会糊高档费流量要取「刚好覆盖 DPR 又不过度」的值。关键点OSS 的resize默认「只缩小不放大」所以即使传了比原图还大的宽度也会原样返回不用担心放大变糊。环节 4加载时机懒加载与预加载下载体量确定后还要控制「什么时候下载」。通用做法懒加载非首屏图片用loadinglazy滚动到才加载减少首屏请求。预加载首屏最重要的图用fetchpriorityhigh或link relpreload asimage尽早抢占带宽。优先加载首屏前几张大图可设置较高的加载优先级。本项目现状首页 Hero 前 2 张图loadingeager 首张fetchPriorityhigh其余卡片loadinglazy。列表卡片统一loadinglazydecodingasync避免阻塞主线程解码。口诀首屏关键图抢加载非首屏图片缓加载。环节 5长缓存解决「每次进来都重新加载」用户最常抱怨的「我明明看过了怎么每次进来还重新加载」多半是缓存策略没做好。通用做法给图片这类「内容不可变」的资源设长缓存Cache-Control: public, max-age31536000, immutable首次拿到后一年不再重新请求。文件名带 hash内容变化自动换 URL配合immutable实现「内容不变永远不重新下载」。在哪配、怎么配任选一层即可对象存储OSS控制台 → Bucket → 传输管理 → 设置 HTTP 头对图片目录追加上面的Cache-Control。CDN控制台 → 域名管理 → 缓存配置 → 添加规则对图片扩展名/目录设 TTL如 365 天。若图片 URL 带x-oss-process等处理参数需确认 CDN透传参数并单独给这类路径配缓存。本项目踩过的坑开发时发现图片「每次进来都重新加载」排查后是DevTools 勾了 Disable cache导致浏览器强制不走缓存——不是代码问题。生产环境静态图由浏览器磁盘缓存兜底配合 OSS/CDN 长缓存即可。排障口诀遇到「图片没缓存」先看浏览器设置和 Network 响应头别急着改代码。环节 6占位与降级提升感知体验即使前面都做了图片加载仍有个空窗期需要「占位」和「降级」兜底。通用做法占位固定width/height或aspect-ratio避免图片加载期间布局抖动CLS。骨架/占位色图片未到前显示底色或模糊占位LQIP。降级图片加载失败时切到占位图或提示不让页面出现破图。本项目现状卡片用aspect-ratio: 4/5占位防止瀑布流列高塌陷。首页热门条对加载失败的封面图做onError切换占位样式。环节 7外链与安全别忘了非自有图片前面的优化都假设图片存自己的 OSS/CDN但真实项目里经常有外链图片用户粘贴的 GitHub、Gitee、其他 CDN 链接这一类要单独考虑。通用做法外链不盲目追加处理参数第三方图片的域名、规则不受你控制乱拼参数可能返回错误或被拒绝。识别是否自有资源判断域名是否属于你的 OSS/CDN白名单属于才处理否则原样返回。安全若做「同源代理下载」本项目的/api/download-image必须校验目标域名白名单防 SSRF也要限制下载大小防超大文件拖垮服务。本项目现状toDisplayImageUrl先判断是否 OSS 图片优先看objectKey非空即 OSS老数据按域名特征.aliyuncs.com等兜底非 OSS 外链直接返回原 URL、不追加任何参数。下载走/api/download-image同源代理服务端白名单校验目标域名、限制最大 20MB、限制重定向次数防 SSRF 与超大资源。三、如何验证优化效果优化做完要有办法确认「真的变快了」别凭感觉Network 面板看每张图的Size传输体积、Time耗时、Content Download下载耗时。命中缓存会显示(from disk cache)、Size 列变0 B。Lighthouse跑 Performance看LCP最大内容绘制和图片加载字节数。首屏图优化直接体现在 LCP 上。Performance 面板 / 真实用户监控RUM看图片请求瀑布流、是否有被阻塞或超时的大图。体积预算给首页设「首屏图片总字节数」红线如 500KB超了就报警防止后续迭代又把原图塞回来。记住一个反直觉的坑开发时勾选 DevTools 的 Disable cache会强制所有图片重新下载让你误以为「图片没缓存、每次重载」。验证缓存效果时务必取消勾选看真实响应头。四、一条判断清单你的图片该优先优化哪一环现象优先排查对应环节图片很大、加载很慢是不是直接用了原图环节 3 按需缩放首屏一堆请求是不是没做懒加载/预加载环节 4每次进来都重新加载是不是没有长缓存 / 开了 Disable cache环节 5图片发糊缩略图档位是不是低于渲染宽度 × DPR环节 3图片多、存储贵上传时压缩 / 换 WebP 有没有做环节 1、2页面图片来回跳动有没有给 img 定宽高 / aspect-ratio环节 6有外链图片是否误给第三方图追加参数 / 代理下载有无白名单校验环节 7五、进阶方案再往深做如果上面的基础优化做完还嫌不够可以考虑响应式图片srcset/sizes让同一张图在不同屏幕密度下选不同档位比「单一固定宽度」更精细。CDN 边缘缓存与动态转换用 CDN 的图片处理能力把「格式转换 缩放 缓存」都在边缘节点完成回源压力小。Service Worker Cache Storage离线可用、二次访问秒开但对静态图片这种「本来就该长缓存」的资源收益有限慎用。图片统计与预算给关键页如首页设「首屏图片体积预算」用 Lighthouse / Performance 持续监控防止优化被后续迭代破坏。智能格式协商服务端根据请求头的Accept返回 WebP/AVIF现代浏览器优先拿小格式。六、本项目完整实践对照优化点本项目做法上传压缩未做限制单图 8MB建议用线上工具/前端库补充格式转换OSS 加载时实时转 JPGformat,jpg按需缩放公共工具toDisplayImageUrl(url, width)分级缩放加载时机首屏 eagerhigh非首屏 lazyasync长缓存依赖浏览器磁盘缓存 OSS/CDN 长缓存占位降级aspect-ratio占位 加载失败切占位样式外链与安全非 OSS 外链不追加参数代理下载白名单 限大小七、总结前端图片优化是一条从上传到展示的全链路不是一个点上传时压缩 → 格式选对 → 按需缩放 → 懒加载/预加载 → 长缓存 → 占位与降级源头控制原始体积展示按需缩放时机上首屏抢加载、非首屏缓加载缓存上让静态资源长驻兜底上用占位与降级稳住体验安全上对外链资源做识别与白名单校验。最容易被忽略也最值得先做的两件事按需缩放别下载原图和长缓存别反复下载。遇到「图片每次重新加载」这类问题先查浏览器设置和响应头再考虑改代码。优化做完要用数据验证Network / Lighthouse / LCP别只凭「感觉快了不少」。一句话图片优化的本质是用最小的传输体积 最合适的加载时机 最持久的缓存复用换最快的首屏与最省的成本。 感谢阅读想了解更多 我的博客网站 | 记录思考分享干货 我的个人主页 | 关于我、开源项目 前端图片加载优化全链路方案
前端图片加载优化全链路方案文章目录前端图片加载优化全链路方案一、先理解图片慢的本质二、全链路优化方案环节 1上传时压缩源头控体积环节 2格式选对体积立省 30%~80%环节 3按需缩放别让用户下载原图环节 4加载时机懒加载与预加载环节 5长缓存解决「每次进来都重新加载」环节 6占位与降级提升感知体验环节 7外链与安全别忘了非自有图片三、如何验证优化效果四、一条判断清单你的图片该优先优化哪一环五、进阶方案再往深做六、本项目完整实践对照七、总结这篇文章从「图片为什么慢」出发系统梳理前端图片优化的完整链路与各类方案并用我的线上项目 Prompt Galler图片提示词的真实实践作为案例。文中大部分方案是通用的不绑定任何具体框架或云厂商可直接套用到你自己的项目。Prompt Galler线上地址http://prompt.gouxinjie.com/一、先理解图片慢的本质一张图片从用户点开页面到显示出来经历了几个环节① 图片体积多大 → ② 有多少张要下载 → ③ 走没走缓存 → ④ 渲染时机对不对任何一个环节没做好都会让用户感觉「图片加载慢」或「每次进来都重新加载」。所以图片优化不是单点动作而是一条全链路上传时压缩 → 格式选对 → 按需缩放 → 懒加载/预加载 → 长缓存 → 占位与降级下面按这条链路逐个讲每个环节都给出通用做法和本项目的落地参考。把「一张图的一生」完整画出来能看到优化点分布在哪① 上传压缩 → ② 格式选对 → ③ 按需缩放 → ④ 加载时机 → ⑤ 长缓存 → ⑥ 占位降级 另⑦ 外链与安全环节一句话优化目标① 上传压缩源头控制体积存储/带宽↓② 格式选对选体积更小的格式体积↓③ 按需缩放别下载原图流量↓④ 加载时机首屏抢、非首屏缓减少首屏请求数⑤ 长缓存别反复下载减少重复请求⑥ 占位降级稳住体验体验↑⑦ 外链与安全识别自有/第三方资源安全↑①②③ 决定「每张图传多大」④ 决定「什么时候传」⑤ 决定「还要不要重复传」⑥⑦ 决定「传的过程中体验稳不稳、安不安全」。二、全链路优化方案环节 1上传时压缩源头控体积图片优化最好从源头做起——在用户上传时就控制原始体积而不是等展示时再补救。通用做法前端用 Canvas 对图片做「压缩后上传」常见库有browser-image-compression、compressorjs。压缩要点限制最大边长如 2000px、JPG 质量 0.8 左右、EXIF 方向修正。好处原始存储体积变小后续所有环节都受益。顺手可用的线上压缩工具TinyPNG最经典的 PNG/JPG 压图工具网页拖拽即用对「单张几十张图、不想写代码」的场景最省事。它的压缩原理是智能降低色彩数量并优化编码属于人眼几乎无感的近无损有损压缩视觉几乎不变但体积能降一大截。也有 API需注册 key可集成到上传流程。SquooshGoogle 出品的在线图片压缩器支持 AVIF/WebP/JPEG/PNG 等多种格式互转可实时对比压缩前后质量与体积适合「挑格式 调质量」一起完成。TinyPNG 同族的 SVGO面向 SVG 图标的压缩工具适合压缩矢量图标资源。其他可参考Kraken.io、CompressOrDie支持 GIF。用法提示设计稿或批量素材可以先用 TinyPNG/Squoosh 压一轮再上传如果流程要求自动压缩则优先考虑browser-image-compression前端或对象存储的图片处理能力后端/云函数线上工具更多是「人工批量处理」的兜底手段。本项目现状目前是 OSS 浏览器直传原图上传时没做压缩但限制了单图不超过 8MB。原图较大时靠「展示时缩放」兜底见环节 3。若运营/管理员手动传图可先用上面的线上工具压一遍再走直传能进一步省存储与带宽。结论如果追求极致上传压缩是最值得做的一环能从根本上减小存储与带宽成本。线上工具适合人工批量处理自动化流程则用前端库或服务端图片处理。环节 2格式选对体积立省 30%~80%图片格式对体积影响巨大优先级大致是AVIF WebP JPEG PNG同画质下通用做法有透明通道的图形 → PNG / WebP。无透明通道的照片 → JPEG / WebP / AVIF。动图 → GIF / WebP动画。现代浏览器基本都支持 WebP条件允许上 AVIF。本项目现状通过阿里云 OSS 图片处理服务在加载时用?x-oss-processimage/format,jpg把 PNG 实时转成 JPG 返回原图保持不变。好处不改原图、不引入服务端处理能力代价是 JPG 对透明 PNG 会产生黑/白底、体积不如 WebP。启示格式转换不一定非要在上传时做死像本项目这样「按需动态转换」也是一种灵活思路但要注意透明背景和动图两个边界。环节 3按需缩放别让用户下载原图这是本仓库最近重点优化的部分也是最容易被忽略的一环。核心问题一张 3000px 的原图在 400px 的卡片里展示如果直接把原图地址塞给img浏览器下载的是完整原图——浪费了大量流量和时间。通用做法给不同展示尺寸准备不同大小的图片响应式图片用img srcset sizes让浏览器按视口挑合适的。或用云厂商的图片处理服务在 URL 上追加缩放参数实时生成缩略图本项目正是这种。本项目落地封装了统一的图片地址工具toDisplayImageUrl第二个参数指定目标宽度// 列表缩略图用 900px大图位用 1600px小格子用 200pxtoDisplayImageUrl(caseItem.coverUrl,900);// 首页卡片toDisplayImageUrl(activeCover,1600);// 详情主图toDisplayImageUrl(image,200);// 封面缩略图这些w_XXX数字是什么它们是 OSS 图片处理 URL 参数的一部分原图 URL ? x-oss-processimage/format,jpg/resize,w_900 ↑ ↑↑ ↑↑ ↑↑↑ 原始图片地址 转JPG 限制宽度900px也就是resize,w_900告诉 OSS把这张图在服务端实时缩到 900px 宽再返回高度等比不拉伸。这样浏览器拿到的就是一张 900px 的小图而不是几 MB 的原图。项目里为什么用1200 / 1600 / 900 / 480 / 200这几档因为不同展示位的「物理需要」不同档位就是按「该位置的渲染宽度 × DPR」来定的档位用在哪对应渲染宽度CSS px覆盖 DPRw_1600详情主图、首页 Hero 大图约 600~8002x 高清屏w_1200中等大图默认档未指定 width 时的兜底约 500~6002xw_900首页卡片、收藏卡片、详情参考图/相关推荐约 300~5002xw_480后台表格缩略图、投稿小图约 80~2402xw_200详情页封面切换小缩略图约 76~1002x档位偏低如 400px 卡片却给w_200→ 图被浏览器放大 →发糊本项目就踩过把卡片从w_480提到w_900。档位偏高小格子却给w_1600→ 等于下载接近原图的图 →白费流量。默认档w_1200当调用方不传 width 时如大图预览弹层、上传组件预览兜底用 1200保证「不放任下载原图」又足够清晰。宽度的选择依据是一个朴素的公式目标宽度 图片实际渲染 CSS 宽度 × 设备像素比(DPR)普通屏 DPR 1渲染宽度即可。Retina 屏 DPR 2需要渲染宽度 × 2的源图才不糊。这也是为什么本项目把卡片从w_480提到w_900、大图位用到w_1600——低档会糊高档费流量要取「刚好覆盖 DPR 又不过度」的值。关键点OSS 的resize默认「只缩小不放大」所以即使传了比原图还大的宽度也会原样返回不用担心放大变糊。环节 4加载时机懒加载与预加载下载体量确定后还要控制「什么时候下载」。通用做法懒加载非首屏图片用loadinglazy滚动到才加载减少首屏请求。预加载首屏最重要的图用fetchpriorityhigh或link relpreload asimage尽早抢占带宽。优先加载首屏前几张大图可设置较高的加载优先级。本项目现状首页 Hero 前 2 张图loadingeager 首张fetchPriorityhigh其余卡片loadinglazy。列表卡片统一loadinglazydecodingasync避免阻塞主线程解码。口诀首屏关键图抢加载非首屏图片缓加载。环节 5长缓存解决「每次进来都重新加载」用户最常抱怨的「我明明看过了怎么每次进来还重新加载」多半是缓存策略没做好。通用做法给图片这类「内容不可变」的资源设长缓存Cache-Control: public, max-age31536000, immutable首次拿到后一年不再重新请求。文件名带 hash内容变化自动换 URL配合immutable实现「内容不变永远不重新下载」。在哪配、怎么配任选一层即可对象存储OSS控制台 → Bucket → 传输管理 → 设置 HTTP 头对图片目录追加上面的Cache-Control。CDN控制台 → 域名管理 → 缓存配置 → 添加规则对图片扩展名/目录设 TTL如 365 天。若图片 URL 带x-oss-process等处理参数需确认 CDN透传参数并单独给这类路径配缓存。本项目踩过的坑开发时发现图片「每次进来都重新加载」排查后是DevTools 勾了 Disable cache导致浏览器强制不走缓存——不是代码问题。生产环境静态图由浏览器磁盘缓存兜底配合 OSS/CDN 长缓存即可。排障口诀遇到「图片没缓存」先看浏览器设置和 Network 响应头别急着改代码。环节 6占位与降级提升感知体验即使前面都做了图片加载仍有个空窗期需要「占位」和「降级」兜底。通用做法占位固定width/height或aspect-ratio避免图片加载期间布局抖动CLS。骨架/占位色图片未到前显示底色或模糊占位LQIP。降级图片加载失败时切到占位图或提示不让页面出现破图。本项目现状卡片用aspect-ratio: 4/5占位防止瀑布流列高塌陷。首页热门条对加载失败的封面图做onError切换占位样式。环节 7外链与安全别忘了非自有图片前面的优化都假设图片存自己的 OSS/CDN但真实项目里经常有外链图片用户粘贴的 GitHub、Gitee、其他 CDN 链接这一类要单独考虑。通用做法外链不盲目追加处理参数第三方图片的域名、规则不受你控制乱拼参数可能返回错误或被拒绝。识别是否自有资源判断域名是否属于你的 OSS/CDN白名单属于才处理否则原样返回。安全若做「同源代理下载」本项目的/api/download-image必须校验目标域名白名单防 SSRF也要限制下载大小防超大文件拖垮服务。本项目现状toDisplayImageUrl先判断是否 OSS 图片优先看objectKey非空即 OSS老数据按域名特征.aliyuncs.com等兜底非 OSS 外链直接返回原 URL、不追加任何参数。下载走/api/download-image同源代理服务端白名单校验目标域名、限制最大 20MB、限制重定向次数防 SSRF 与超大资源。三、如何验证优化效果优化做完要有办法确认「真的变快了」别凭感觉Network 面板看每张图的Size传输体积、Time耗时、Content Download下载耗时。命中缓存会显示(from disk cache)、Size 列变0 B。Lighthouse跑 Performance看LCP最大内容绘制和图片加载字节数。首屏图优化直接体现在 LCP 上。Performance 面板 / 真实用户监控RUM看图片请求瀑布流、是否有被阻塞或超时的大图。体积预算给首页设「首屏图片总字节数」红线如 500KB超了就报警防止后续迭代又把原图塞回来。记住一个反直觉的坑开发时勾选 DevTools 的 Disable cache会强制所有图片重新下载让你误以为「图片没缓存、每次重载」。验证缓存效果时务必取消勾选看真实响应头。四、一条判断清单你的图片该优先优化哪一环现象优先排查对应环节图片很大、加载很慢是不是直接用了原图环节 3 按需缩放首屏一堆请求是不是没做懒加载/预加载环节 4每次进来都重新加载是不是没有长缓存 / 开了 Disable cache环节 5图片发糊缩略图档位是不是低于渲染宽度 × DPR环节 3图片多、存储贵上传时压缩 / 换 WebP 有没有做环节 1、2页面图片来回跳动有没有给 img 定宽高 / aspect-ratio环节 6有外链图片是否误给第三方图追加参数 / 代理下载有无白名单校验环节 7五、进阶方案再往深做如果上面的基础优化做完还嫌不够可以考虑响应式图片srcset/sizes让同一张图在不同屏幕密度下选不同档位比「单一固定宽度」更精细。CDN 边缘缓存与动态转换用 CDN 的图片处理能力把「格式转换 缩放 缓存」都在边缘节点完成回源压力小。Service Worker Cache Storage离线可用、二次访问秒开但对静态图片这种「本来就该长缓存」的资源收益有限慎用。图片统计与预算给关键页如首页设「首屏图片体积预算」用 Lighthouse / Performance 持续监控防止优化被后续迭代破坏。智能格式协商服务端根据请求头的Accept返回 WebP/AVIF现代浏览器优先拿小格式。六、本项目完整实践对照优化点本项目做法上传压缩未做限制单图 8MB建议用线上工具/前端库补充格式转换OSS 加载时实时转 JPGformat,jpg按需缩放公共工具toDisplayImageUrl(url, width)分级缩放加载时机首屏 eagerhigh非首屏 lazyasync长缓存依赖浏览器磁盘缓存 OSS/CDN 长缓存占位降级aspect-ratio占位 加载失败切占位样式外链与安全非 OSS 外链不追加参数代理下载白名单 限大小七、总结前端图片优化是一条从上传到展示的全链路不是一个点上传时压缩 → 格式选对 → 按需缩放 → 懒加载/预加载 → 长缓存 → 占位与降级源头控制原始体积展示按需缩放时机上首屏抢加载、非首屏缓加载缓存上让静态资源长驻兜底上用占位与降级稳住体验安全上对外链资源做识别与白名单校验。最容易被忽略也最值得先做的两件事按需缩放别下载原图和长缓存别反复下载。遇到「图片每次重新加载」这类问题先查浏览器设置和响应头再考虑改代码。优化做完要用数据验证Network / Lighthouse / LCP别只凭「感觉快了不少」。一句话图片优化的本质是用最小的传输体积 最合适的加载时机 最持久的缓存复用换最快的首屏与最省的成本。 感谢阅读想了解更多 我的博客网站 | 记录思考分享干货 我的个人主页 | 关于我、开源项目