商品图压小了首屏还是慢？从显示宽度、srcset 到 LCP 分段定位

设计师已经把商品主图压到几百 KB，页面仍然很晚才出现主视觉。继续降低画质之前，先看图片请求是什么时候开始的：如果页面等待脚本完成才插入图片，再小的文件也无法提前被发现。

图片性能优化需要设计、开发与运营分别提供信息：设计说明画面与清晰度要求，开发确认实际显示及加载方式，运营核对用户端的真实体验。只给一个“必须小于多少 KB”的指标，容易让问题停留在错误的环节。

先算显示需求，不要从源图尺寸倒推

假设手机页面里的商品图显示宽度为 360 个 CSS 像素，设备像素比 DPR 为 3。若希望接近逐设备像素提供图像，候选宽度约为：

360 × 3 = 1080 像素

这不是要求所有手机一律下载 1080 像素图片。内容清晰度、压缩、浏览器策略与网络条件都会影响选择，关键是区分显示宽度和源图片宽度。

同一张图若以 2400 × 2400 而非 1200 × 1200 提供，像素数量是四倍，但文件字节不一定恰好四倍。编码格式和画面复杂度也会影响体积，不能把像素比例当作带宽比例。

让浏览器知道有哪些候选，以及会显示多大

srcset 用宽度描述符列出候选文件，sizes 告诉浏览器预计的 CSS 显示宽度。它们共同帮助浏览器选择资源；sizes 本身不负责设置页面布局，布局仍由 CSS 决定。

以下是假设商品主图的代码示例：图片最大显示 600 个 CSS 像素，小屏图片宽度为视口宽度减 32 像素，留白位置由实际容器布局决定；所有候选都是相同构图的正方形图片。示例文件名不是本站已有资源，实际接入时需替换成真实文件，并按真实容器布局修改。

<style>
  .product-hero {
    display: block;
    width: min(600px, calc(100vw - 32px));
    height: auto;
  }
</style>
<img
  class="product-hero"
  src="lamp-front-1200.webp"
  srcset="lamp-front-360.webp 360w,
          lamp-front-720.webp 720w,
          lamp-front-1200.webp 1200w,
          lamp-front-1800.webp 1800w"
  sizes="(min-width: 632px) 600px, calc(100vw - 32px)"
  width="1200"
  height="1200"
  alt="黑色台灯正面图，展示底座与灯臂"
  loading="eager"
  fetchpriority="high"
>

在 392 CSS 像素的视口下，这个布局给出 360 像素显示宽度；DPR 为 3 时，1200 宽候选可覆盖约 1080 像素的需求。浏览器实际选哪一张仍应通过 currentSrc 和网络请求确认，不能把算例写成所有环境的固定下载结果。

若真实页面是双栏布局，就不能继续照抄这份 sizes。错误地把小卡片声明成接近整屏宽，可能让浏览器选择比实际需要更大的图片。

不同画幅的构图调整则是另一件事，不能把横图简单当作竖图的低清晰度候选；可先参考多比例裁剪与扩图。

首屏主图和屏外详情图不要使用同一加载策略

web.dev 的 LCP 指南明确建议不要懒加载 LCP 图片。LCP，即最大内容绘制，衡量视口内最大的图片或文本块何时完成呈现；实际元素需通过工具确认，不一定永远是商品主图。

上面的 eager 与高优先级示例，只适用于已经判断为重要首屏候选的场景。屏外详情图通常可以延后加载。不要把所有图都标成 fetchpriority="high"，否则优先级失去区分，也可能挤占其他关键资源。

同样，不应为“加速”给所有图片预加载。如果资源已经能被初始 HTML 尽早发现，额外预加载未必必要；配置不一致还可能产生多余下载。修改后要核对实际请求，而不是只看属性有没有加上。

沿着四段时间找真正瓶颈

对于以图片为 LCP 元素的页面，可以将过程拆为：

时间段	在等什么	更有针对性的检查
首字节时间	收到 HTML 的第一个字节	服务器响应、重定向、网络与缓存
资源加载延迟	浏览器发现并开始请求图片	初始 HTML、脚本插入、CSS引用和优先级
资源加载时长	图片传输完成	实际下载尺寸、格式、编码和缓存
元素渲染延迟	下载后真正显示出来	解码、主线程、样式及脚本控制的显示状态

例如，一张图下载已经很快，却被脚本隐藏到页面初始化完成，继续压缩可能只会损失细节，而不会让它更早出现。

截至 2026-09 可读的官方指南将良好 LCP 目标描述为至少 75% 的页面访问达到 2.5 秒或以内。这是用户体验指标，不是每一张图片的下载时限，也不是保证排名的条件。

测量时不要把实验室结果当成全部用户

本地性能面板或 Lighthouse 适合定位原因；真实用户数据更接近不同设备和网络下的整体体验。比较前后时，应记录测试页面、设备、网络设置、缓存状态和是否经过相同重定向。

PageSpeed Insights 可能展示页面级数据，也可能在页面样本不足时显示整个来源的数据。两者不能直接混比；没有足够数据也不代表指标为零或所有用户都很快。

本文没有对图叮网站执行性能实测，代码也只是接入示例，不是已验证的优化补丁。上线项目应实际检查首屏、滚动后的详情图、不同视口与缓存条件。

交付给开发的不是一堆随意压缩的文件

设计侧可以按真实页面需求准备候选宽度，保留同一构图与比例，说明哪些细字必须读清、哪些版本支持透明。开发侧根据实际容器写 sizes，核对候选实际宽度、请求结果和预留空间。

图叮图片改尺寸与格式转换可以参与文件准备；公开页面说明为本机处理，处理或导出需登录。它们不等于自动完成页面 HTML、CDN 或 LCP 优化。

将候选对应关系纳入交付清单，内容描述与抓取问题另按图片 SEO核对。先找出浏览器真正花时间的环节，再决定要不要继续牺牲画质。

参考来源

• web.dev：Optimize Largest Contentful Paint
• web.dev：Responsive images
• 图叮：图片改尺寸
• 图叮：格式转换与压缩