📍 WDQWDWQD987AAAAA:216.73.217.43
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d28ce2db0357.html
📄

如何建网站 - 图片与资源加载的排查清单

图片与资源加载安排的核心，是让首屏需要的图片尽早被浏览器发现并请求，让非首屏、非关键资源延后加载，同时避免因为尺寸、格式或请求数量拖慢页面。下面这份清单按“查什么、怎么查、结果说明什么”组织，适合已有页面或项目在此基础上改进。

先查首屏图片是否被延迟

浏览器解析到 <img> 标签才会发起请求，如果首屏主图使用懒加载，它可能等脚本执行后才开始下载，反而拖慢首屏呈现。要查的是首屏范围内第一张或前两张主要图片有没有被加上懒加载属性。

• 查什么：首屏主图、商品头图、文章头图对应的 <img> 标签。
• 怎么查：在浏览器开发者工具的 Elements 面板搜索 loading="lazy"，看是否落在首屏图片上；再看 Network 面板中该图片请求的发起时间。
• 结果说明什么：如果首屏主图的请求时间明显晚于 HTML 文档请求，说明它可能被脚本或懒加载推迟了。把首屏关键图片改为立即加载，非首屏图片保留懒加载，是更合理的分工。

再查图片尺寸与显示尺寸是否匹配

一张实际宽度 2000 像素的图片，被塞进 400 像素宽的容器里显示，多出来的像素就是浪费。要查的是图片文件的实际像素尺寸与它在页面上占据的显示尺寸是否接近。

1. 查什么：每张主要图片的自然宽度和渲染宽度。
2. 怎么查：在浏览器控制台对图片元素读取 naturalWidth 和 clientWidth，或直接在开发者工具中查看该图片的尺寸信息。
3. 结果说明什么：如果 naturalWidth 远大于 clientWidth，例如超过两倍，说明图片被过度放大使用。此时应准备更小尺寸的版本，或使用响应式图片让浏览器按视口选择合适文件。

需要留意的是，高分辨率屏幕下适当放大是正常的，判断时要结合设备像素比，而不是只追求两个数字相等。

检查图片格式与压缩是否合理

格式选择影响体积，体积影响加载时间。要查的是现有图片用了什么格式、压缩程度如何、是否存在明显可优化的空间。

• 查什么：图片格式（JPEG、PNG、WebP、AVIF 等）和文件大小。
• 怎么查：在 Network 面板按 Size 排序，找出体积最大的若干张图片，记录它们的格式和大小。
• 结果说明什么：照片类图片用 PNG 通常偏大，改用有损压缩格式往往更合适；带透明通道的图才需要 PNG 或 WebP。若某张装饰图体积异常大，先确认它是否真的必要。

格式转换和压缩属于可以实际执行的步骤：把原图导出为适合的格式，控制质量参数，再对比转换前后的文件大小和肉眼观感，确认没有明显失真后再替换。

查看请求数量与加载顺序

资源加载不只是图片，还包括样式表、脚本、字体和图标。要查的是页面初始加载阶段发出了多少请求、哪些资源阻塞了渲染。

• 查什么：Network 面板中初始加载的请求总数，以及样式表和同步脚本的位置。
• 怎么查：刷新页面，观察瀑布图中各请求的先后关系；重点看 CSS 是否阻塞了首屏渲染，同步脚本是否放在文档头部。
• 结果说明什么：如果大量小图标各自发起请求，可以考虑合并为雪碧图或使用图标字体、内联 SVG；如果非关键脚本阻塞了内容显示，可以改为异步加载或移到文档末尾。

用实际指标验证改动效果

调整之后需要验证，而不是凭感觉判断。可以执行的检查是：在开发者工具的 Network 面板勾选禁用缓存，重新加载页面，记录首屏图片出现的时间和总请求数；再与改动前的数据对比。

判断标准可以设为：首屏主图请求是否更早发起、总体积是否下降、首屏内容是否更早可见。如果某项指标没有改善，回到对应环节重新检查，而不是一次性改动所有变量。

下一步建议先只处理首屏图片这一项：确认它没有被懒加载、尺寸与显示匹配、格式和体积合理，然后再逐项推进其他资源。