图片与资源加载的安排,核心不是“尽量少放图”,而是让首屏可见内容优先拿到带宽,让非首屏和非关键资源延后。判断顺序是:先确认每个资源是否影响首屏渲染,再决定是内联、预加载、懒加载还是异步加载,最后用浏览器开发者工具核对实际请求时序。
把页面上的图片和资源按对首屏的影响分成三类,分类结果直接决定策略:
preload 提前声明。分类依据是“用户不看到它,页面是否还能正常使用”。如果答案是不能,它就是关键资源;如果能,就往后排。这个判断不需要工具,但需要你实际打开页面,看首屏在常见屏幕尺寸下显示了什么。
图片加载慢,常见原因不是图片数量多,而是单张图片体积过大。安排图片时依次检查:
loading="lazy",浏览器会在接近视口时才请求。首屏图片不要加懒加载,否则会推迟首屏渲染。width 和 height,浏览器能提前预留空间,避免图片加载完成后页面跳动。假设一个页面首屏有一张横幅图和二十张商品图,商品图都在首屏下方。合理的安排是:横幅图正常加载并预加载,商品图全部懒加载,同时每张图都写明宽高。这样首屏只需要等一张图,而不是二十一张。这是假设示例,用于说明优先级差异,不代表任何真实项目的效果数据。
普通脚本默认会阻塞 HTML 解析,样式表会阻塞渲染。安排资源时先确认阻塞是否必要:
defer 或 async,或移到页面底部。两者区别是:defer 按顺序在解析完成后执行,async 下载完就执行、顺序不保证。有依赖关系的脚本用 defer,独立统计类脚本可用 async。这里要区分“可能原因”和“已经定位的原因”。页面慢可能是图片太大,也可能是脚本阻塞、服务器响应慢、DNS 解析慢。不要看到慢就断定是图片问题,应先在 Network 面板看时间主要花在哪个阶段:是等待服务器响应,还是内容下载,还是脚本执行。
安排完之后必须验证,而不是凭感觉认为已经优化。可执行步骤:
判断结果的标准:首屏关键资源应尽早开始且不被非关键资源挤占;非首屏资源不应在初次加载时集中请求;页面在图片加载前后不应出现明显跳动。如果某项不符合,回到对应分类调整,而不是一次性改所有资源。
没有一套安排适合所有页面。内容型页面首屏文字为主,图片可以大量懒加载;电商列表页首屏就有多张商品图,需要权衡首屏图数量和单图体积;工具型页面交互复杂,脚本加载策略比图片更重要。取舍时问自己:当前页面用户最先要看到什么,最不能等的是什么。先保证那部分,再压缩其余部分。
下一步:打开你要处理的页面,在开发者工具中记录一次完整加载的请求列表,按上面的三类给每个资源标注,找出排在首屏关键资源之前、但实际不影响首屏的请求,优先调整它们。