多人协作时,图片与资源加载安排的核心不是“把图片压小”这一件事,而是先约定目录、命名和引用方式,再决定压缩、尺寸与加载顺序。只做压缩不统一路径,换人接手后仍会返工。
很多人把资源加载问题等同于图片体积。实际返工往往来自引用路径不一致:同一张图在页面里写成三种路径,本地能看,交付后失效;或者不同人各自上传一份同名图,覆盖后无法追溯。压缩只解决传输量,解决不了协作一致性。
判断依据很简单:让另一位协作者只拿到项目文件夹,不问你任何问题,能否直接打开页面并看到全部图片。如果做不到,问题在约定,不在压缩率。
/assets/images/,样式和脚本放在 /assets/css/、/assets/js/,不要散落在页面同级目录。hero-banner-01.webp;不用中文、空格和“最终版2”。<img src="assets/images/hero-banner-01.webp">,避免有人写绝对路径导致换环境失效。适用条件:项目规模不大、没有构建工具时,这三条就能覆盖大部分返工。若使用框架或打包工具,路径规则以工具配置为准,但命名与目录约定仍然有效。
不要给所有图设同一个宽度。按展示位置决定:
格式选择看内容:照片类用有损格式,图标和纯色图形用矢量或无损格式。是否使用新格式,取决于目标浏览器支持情况,不能只因为“更新”就全站替换。检查方法是:替换后在不同浏览器打开同一页面,确认显示正常再合并。
资源加载不是越快越好,而是优先级要对。首屏图片应尽早请求,首屏之外的图片可以延迟加载。判断结果的方式是:打开页面后不滚动,首屏内容是否完整出现;滚动后才加载的图片是否正常补上。
多人协作时,把这条写进交付清单:谁负责首屏图,谁负责延迟加载属性,避免两人同时改同一段代码。若出现图片不显示,先查路径拼写,再查文件是否真的上传,最后查是否被延迟加载逻辑跳过——这是三个不同原因,不要一上来就归为“服务器问题”。
下一步:把上面的目录、命名、引用三条约定写成一份简短说明,放进项目根目录,再开始批量处理图片。这样后续任何人接手,都能按同一套规则继续,而不是重新猜。