这是一篇纯测试文：20 张图片，分辨率从 320×320 到 4000×3000，格式覆盖 JPEG / PNG / WebP / AVIF，单张体积从 11 KB 到 1.5 MB，另有两个极端长宽比（1200×400 横幅、1440×2560 竖长）。
关于本页的图片渲染方式
本页图片全部用 Astro 的
Image组件渲染，并显式指定了widths/sizes/quality={75}。这么写是有原因的：Astro 6 的image配置里没有全局quality字段（schema 只有layout、objectFit、objectPosition、breakpoints、responsiveStyles），而 Vercel 图片服务在未指定质量时默认q=100；同时 Markdown 正文图的sizes会被算成100vw，浏览器在视网膜屏上会去取最大的那档。所以「大图降质量」只能在组件层做，这也正是本页的写法。
怎么看这篇文档#
- 打开 DevTools → Network → 过滤
Img，刷新页面，按 Size 排序看每张图实际传输了多少字节。 - 慢慢往下滚，图片进入视口附近才开始下载，说明懒加载生效。
- 观察图片区域在加载前后有没有跳动（布局偏移）；每张图都带了宽高，理论上不应该跳。
- 点任意一张图，看是否有放大灯箱（主题的 medium-zoom，靠
.zoomable类触发）。 - 在 Network 里点开某张图的
srcset，改窗口宽度或切到移动端模拟，看请求的宽度档位是否随之变化。 - 最后跑一次 Lighthouse，看首屏 LCP 是否被头图拖累。
素材总览#
| # | 文件 | 分辨率 | 格式 | 体积 |
|---|---|---|---|---|
| 01 | 01-thumb-400x300.jpg | 400×300 | JPEG | 17 KB |
| 02 | 02-small-800x600.jpg | 800×600 | JPEG | 50 KB |
| 03 | 03-medium-1200x800.jpg | 1200×800 | JPEG | 300 KB |
| 04 | 04-hd-1600x900.jpg | 1600×900 | JPEG | 170 KB |
| 05 | 05-fhd-1920x1080.jpg | 1920×1080 | JPEG | 432 KB |
| 06 | 06-wide-2400x1600.jpg | 2400×1600 | JPEG | 331 KB |
| 07 | 07-large-3000x2000.jpg | 3000×2000 | JPEG | 335 KB |
| 08 | 08-ultra-4000x3000.jpg | 4000×3000 | JPEG | 1572 KB |
| 09 | 09-square-600x600-png.png | 600×600 | PNG | 689 KB |
| 10 | 10-portrait-800x1200.jpg | 800×1200 | JPEG | 72 KB |
| 11 | 11-banner-1200x400.jpg | 1200×400 | JPEG | 121 KB |
| 12 | 12-square-1000x1000-webp.webp | 1000×1000 | WebP | 210 KB |
| 13 | 13-webp-2000x1400.webp | 2000×1400 | WebP | 160 KB |
| 14 | 14-avif-2400x1600.avif | 2400×1600 | AVIF | 47 KB |
| 15 | 15-png-1600x1200.png | 1600×1200 | PNG | 1165 KB |
| 16 | 16-tiny-320x320.jpg | 320×320 | JPEG | 11 KB |
| 17 | 17-2k-2560x1440.jpg | 2560×1440 | JPEG | 130 KB |
| 18 | 18-vertical-1440x2560.jpg | 1440×2560 | JPEG | 845 KB |
| 19 | 19-squared-2048x2048.jpg | 2048×2048 | JPEG | 634 KB |
| 20 | 20-4k-3840x2160.jpg | 3840×2160 | JPEG | 367 KB |
合计 7.48 MB（仓库里的原始文件）。注意分辨率高不等于体积大——图 14（2400×1600 的 AVIF，47 KB）比图 06（同样 2400×1600 的 JPEG，331 KB）小 7 倍，而图 09（仅 600×600 的 PNG，689 KB）比很多大图都重。
一、分辨率阶梯#
从最小的缩略图一路到 4K，观察同一个页面上不同像素量的图在清晰度和耗时上的差别。
观察点：这几张里图 20 的像素量是图 16 的 81 倍，但体积只差 33 倍（367 KB vs 11 KB）——说明源图压缩率也在影响体积。留意图 20 在桌面端实际取到的是哪一档（按上面的 sizes，视网膜屏应该落在 1600 那一档，而不是 3840）。
二、长宽比与布局#
横幅、竖图、正方、4:3 混排，用来检查不同比例下的容器表现、图片是否有拉伸变形、以及竖向长图会不会把页面撑得很长。
观察点：图 18（845 KB）和图 19（634 KB）是这一组里的重货，注意它们进入视口后滚动是否卡顿；竖长图在小屏上会占掉整屏，看看懒加载是否让它在滚动到之前完全不请求。
三、大体积压力测试#
单张过 MB 的图片，专门用来量加载耗时。
观察点：图 08 是本页最重的一张（源文件 1572 KB）。按上面的写法，桌面端最多只会取到 1920 宽的变体、质量 75，实际传输应该远小于源文件；如果 Network 里看到接近 1.5 MB 的传输量，那就说明这张图没走到优化路径。图 15 是「像素不多但格式吃亏」的典型：PNG 存照片，1165 KB。
四、格式对比#
同样的画面内容，不同编码格式的体积差异。
观察点：把图 14（AVIF，47 KB）和第一节的图 06（同为 2400×1600 的 JPEG，331 KB）放在一起看，体积差了 7 倍，肉眼看清晰度差异大不大？另外注意浏览器对 AVIF/WebP 的解码开销——体积小不等于渲染快，低端设备上有时反而更吃 CPU。
收尾#
测完可以直接删掉整个 src/content/blog/image-loading-test/ 目录（连同这篇文档），它不影响其他内容。素材取自 picsum.photos ↗（Unsplash 免费图库），仅用于加载测试。