资源有限时,不要按图片总数平均处理,而要先找出“尺寸明显过大且出现在重要页面首屏”的图片。假设一个站点有800张图,其中首页横幅图宽4000像素、文件约2.5MB,产品列表图宽1200像素、文件约180KB,那么优先处理首页横幅图,而不是先批量压缩全部缩略图。判断依据是:同一张图被多少重要页面引用、是否位于首屏、显示宽度是多少、实际文件多大。
资源有限意味着不能全站同时改。可以先把页面分成三档:首页、核心栏目页、主要转化页为第一档;有自然流量的文章页和产品详情页为第二档;低频归档页、标签页为第三档。第一档里凡是首屏出现的大图,优先排查。
假设某企业站首页首屏有一张团队合影,原图宽6000像素、文件4MB;页面实际显示宽度约1200像素。处理步骤可以这样安排:
width和height属性,或使用CSS设定显示尺寸,避免浏览器先按大图布局再缩放。常见错误是只改文件名或只改CSS宽度。CSS把图缩小,浏览器仍可能下载原图,文件体积没有下降。另一个错误是直接覆盖原图后不检查缓存,旧图仍可能被CDN或浏览器缓存继续提供,需要确认缓存刷新策略。
图片尺寸包含两个概念:像素尺寸(宽×高)和文件体积(KB或MB)。像素尺寸决定清晰度上限,文件体积决定下载成本。资源有限时,优先保证“显示尺寸够用”,再压缩体积。判断方法很简单:把图片放到实际页面中,在常见笔记本和手机屏幕上查看,若看不出明显模糊,就不必保留更高像素。
对于文字截图、带细线的图表,压缩过度会出现边缘发虚,可以适当提高质量或改用PNG;对于照片类图片,WebP或JPEG通常更合适。不要为了追求统一格式而把所有图都转成同一种,先看内容类型。
图片尺寸只是页面体验的一部分。完成第一档页面的图片优化后,下一步用同一套方法检查首屏的字体文件、脚本文件和视频封面,看是否还有体积明显偏大的资源。若图片已经变小但页面仍然慢,问题可能不在图片,而在阻塞渲染的脚本或服务器响应。此时应记录修改前后的加载数据,再决定是否继续投入图片处理。