图片与资源加载的安排,核心是让浏览器尽早拿到首屏真正要显示的内容,同时避免把带宽浪费在暂时看不到的图片、脚本和字体上。对第一次接触这个问题的人来说,起点不是“压缩图片”这一个动作,而是先分清哪些资源阻塞渲染、哪些资源可以延后,再按顺序处理。
打开浏览器开发者工具的“网络”面板,刷新页面,把资源按大小和耗时排序。重点看三类现象:
<head>里同步加载,页面白屏时间被拉长。这一步只做记录,不急着改。判断依据是“资源开始下载的时间”和“页面首次出现内容的时间”之间的差距,而不是单看某个文件有多大。
把资源分成三组来安排:
图片延迟加载通常用原生属性实现:给非首屏图片加上loading="lazy",浏览器会在图片接近视口时才请求它。首屏主图不要加这个属性,否则可能反而拖慢显示。适用条件是图片数量较多、页面较长;如果整页只有一两张图,收益有限。
可以实际执行的步骤:
<img>并放在HTML靠前的位置,而不是用CSS背景图,这样浏览器能更早发现它。loading="lazy",并保留宽高属性。</body>前,或用defer属性,让HTML先解析。这里要注意:defer和异步加载只改变执行时机,不保证一定更快;如果脚本本身很小,改动带来的差别可能看不出来。判断是否值得改,看它在网络面板里占用的阻塞时间。
改完后回到开发者工具,用无痕窗口、相同网络限速重新测一次,对比三个指标:首屏内容出现的时间、首屏图片开始下载的时间、页面总请求数。如果首屏变快但首屏图片出现更晚,说明优先级安排反了,需要把主图提前。如果总请求数下降但首屏没变化,说明省下的是非关键资源,属于正常结果。
复查时不要只看一次结果,网络波动会让单次数据失真,至少对比两三次取大致趋势。
先挑一个页面,按上面的观察方法记录当前资源加载顺序,只改首屏主图和非首屏图片这两处,再复查一次。确认这一处改动有效后,再处理脚本和字体。