网页发布链路中的 PSD 转 JPG：把 LCP、srcset 与 CDN 缓存策略提前写进交付说明，而不是上线当天临时改文件名
前端性能指标里 Largest Contentful Paint 往往被一张过大的首屏 JPG 拖垮，而设计侧如果只按「好看」导出、不考虑真实布局宽度与 DPR，就会把优化压力全部推给工程。`web-psd-jpg` 适合在已冻结的视觉稿上按内容团队给定的长边与质量预算输出主档，再由图片服务或构建脚本衍生多档位。与此同时，缓存键设计错误会导致用户长期看到旧图，因此文件名或路径必须能随内容变更。把这三件事写进同一份 brief，可以减少设计、前端与运维之间的往返邮件。
如何使用
- 从设计标注或 Storybook 里读取组件实际展示宽度，乘以主要受众设备的 DPR 得到像素上限，再决定 PSD 是否需要先裁安全区；上传时同步提供「首屏/懒加载」两档参数给工具或后续流水线。
- 在本地用 Lighthouse 或 WebPageTest 对试跑页面采样，看首图体积与 LCP 元素是否匹配预期；若仍偏大，优先减像素而不是无限提高质量因子，因为 JPEG 在过高分辨率下收益递减。
- 发布到 CDN 时使用内容哈希或版本查询串，并在缓存规则里禁止对无版本路径设置过长 max-age；在变更记录里登记旧 URL 失效时间，避免运营误以为「我换了图但用户看不见」。
PSD 转 JPG（web）问答
网页首图要兼顾 LCP，JPG 长边与质量怎么定？
按真实展示宽度 × DPR 设上限，质量以视觉门禁为准；用性能预算表固定「首屏/非首屏」两档参数。
响应式站点要 srcset，PSD 一次导出够吗？
响应式站点通常需要 2x、3x 或连续 w 描述符的多档资源，单张 PSD 往往只作为视觉母版；常见做法是导出一份高质主档后由图片 CDN 或构建时脚本自动切出多宽，再在组件里用 srcset 与 sizes 告诉浏览器该选哪一档。在线工具适合产出这份主档并冻结色彩与锐化策略，具体切分规则应写在代码仓库而不是散落在设计师笔记本里。
Progressive JPEG 是否一定更好？
弱网下渐进展示体验更好，但编码略慢、体积略变；按监控数据在模板里开关，不要拍脑袋全局开。
CSS 里还要叠加滤镜，导出 JPG 时要注意什么？
预留对比与锐化余量，避免双重增强发假；最好在设计稿标注「仅前端滤镜」区域。
CDN 缓存旧版 JPG，发版后用户仍看到糊图？
文件名或路径带内容哈希；禁止长期缓存无版本号的同名 URL。