一个站点的性能，多数人只看首字节时间。但首字节只是第一段——用户看到完整首屏，还要等 HTML 解析、CSS 下载、JS 执行、图片加载。这段体验由另外三项指标决定：LCP（最大内容绘制）、CLS（累积布局偏移）、INP（交互到下一次绘制）。
这篇记录我在一个 3000 多页面的模板站上做客户端性能治理的过程。核心结论是：对于内容型站点，客户端的瓶颈通常在图片上，而不在代码上。
一、先把数据摆出来，才知道该优化什么
优化之前必须有一张真实的资源账单。我们这个站的情况是：
资源
数量
单体体积
首屏占比
CSS
1 个
40 KB
阻塞渲染
JS
1 个
18 KB
延后执行（defer）
预览图
单页最多 15 张
每张 36-63 KB，均值 42 KB
合计 630 KB
字体
0 个
—
—
HTML 平均 34 KB（402 个静态页合计 13.5 MB），边缘渲染的区县页在 25 KB 到 48 KB 之间。
这个账单立刻给出了两个结论：
第一，代码不是瓶颈。 CSS 40 KB 加 JS 18 KB，合计 57 KB。这个体量在移动端 4G 上传输时间约 200 毫秒，且 HTTP/2 下两个请求并行，几乎不构成延迟。
第二，图片占了首屏字节的九成以上。 15 张图 630 KB，是代码的 11 倍。如果只盯着 JS 优化，收益接近于零。
二、LCP 优化：让首屏主图先到
LCP 元素在内容型站点里几乎总是首屏的主预览图。它是最先被浏览器发现并下载的，也是用户判断"这页有没有东西"的第一依据。
这一项的核心是优先级排序，而不是压缩。
浏览器的图片加载默认按 DOM 顺序排队。如果首屏主图排在第 8 位，它就要等前 7 张图下载完才开始——即便它体积最大、位置最关键。所以做法很简单：给主图一个明确的优先级声明，让浏览器把它插到队列最前面。
这一个属性解决的是优先级问题，它不减少任何字节，但能让 LCP 更早开始。成本几乎为零。
其余图片全部标记为懒加载。这条的意义同样不在速度，而在首屏带宽不被稀释：15 张图如果同时竞争，首屏主图实际拿到的带宽只有 1/15。
图片尺寸：统一分辨率比"响应式"更重要
我们的预览图统一输出为 1024 × 576。这个选择看起来很朴素，但它解决了两个问题：
一是布局稳定性。 固定宽高比意味着容器可以提前占位（见下一节的 CLS 部分）。
二是避免多套资源带来的复杂度。 响应式图片（多套尺寸 + srcset）本身是好事，但它要求每张图产出 2 到 3 个文件。对于 3000 多张图的规模，这意味着产物数量和维护成本成倍上升。而我们的场景是图片尺寸需求高度一致——都是同一版式的预览图，用户在同一块区域内查看。这种情况下统一尺寸是更合适的选择。
格式选择：JPEG 与 WebP
我们的预览图输出 JPEG，单张 36 KB 到 63 KB。这个体量已经足够小，但也还有优化空间——如果换成 WebP，同样画质下通常能再降 25% 到 35%。
我没有换，原因是一个具体的约束：这批图片要作为社交分享卡片使用（og:image）。主流平台的分享卡片渲染对 JPEG 的兼容性支持比较完整。为一个不影响到站用户的场景引入兼容性风险，不划算。
判断依据：格式选择要看兼容性要求最严的那个消费方，而不是你自己的浏览器。你能打开不代表爬虫能打开、代表分享卡片能渲染。
三、CLS 优化：布局偏移与排序的关系
CLS 衡量的是页面内容在加载过程中发生位移的总量。
它的重要性在于：Google 的页面体验体系把 LCP、INP、CLS 三项一起作为搜索排序的参考维度。也就是说，这三项不是"加分项"而是"底线项"——内容质量相近的两页之间，这三项的表现会直接影响先后顺序。
需要说明的是，页面体验类信号在整体排序里属于权重有限的一类。内容本身的相关性、权威性和新鲜度始终是更靠前的因素。所以下面这类优化的定位应该是"消除明显的短板"，而不是"靠性能把内容质量补上来"。
CLS 最大的来源是：图片没有预留空间。浏览器在图片下载完成前不知道它有多高，下载完成后把下方内容整体下推，这个位移就被记为 CLS。
解法是给每个 img 写死 width 和 height 属性：
浏览器读这两个数字就能在下载前算出占位尺寸，图片到位时布局不动。这两个属性是纯 HTML 层的，零成本。
我们的做法是把它做成构建期的断言，而不是靠人自觉：
// 概念示例：构建时扫描产物 HTML
每张 必须同时具备：
width="..." ← 数字，且与 height 一起存在
height="..."
loading="lazy" 或 fetchpriority="high"（首屏主图）
alt="..."
任何一条不满足，构建直接失败。靠人记的规范容易漏，靠断言的规范不会。
CLS 的第二个来源：广告位和异步内容
如果你在页面里嵌了第三方脚本或广告容器，脚本加载完成时会撑开空间。处理方式是预留容器：容器写死尺寸，异步内容加载失败时只是留白，而不是把布局顶下去。
四、INP 与 JS：我们的结论是"少写一点"
INP 衡量用户交互到页面响应的延迟。它由事件处理函数本身、渲染阻塞和主线程排队三者决定。
我们的 JS 只有 18 KB，全部交互逻辑集中在一个弹窗组件里。这个体量的脚本几乎不会造成 INP 问题。
但有三个通用做法值得说：
一是 defer 与 async 的正确使用。 非关键脚本不应阻塞解析。页面底部或 head 里加 defer，让浏览器在解析完 HTML 后再下载执行。
二是长任务切分。 超过 50 毫秒的任务会阻塞输入响应。大型数据处理应该拆成小段，或放进 Web Worker。这类场景需要处理的数据量通常比较大，本站不涉及，但原则是通用的。
三是避免在交互处理器里做同步布局读取。 例如在点击事件里直接读 getBoundingClientRect()，会强制浏览器立即重排。改成缓存值或用 requestAnimationFrame 延后读取。
五、静态资源缓存：先有指纹，再谈长缓存
这里有一个容易被忽略的顺序问题，值得单独讲。
边缘平台上的资源通常分两类来源：静态托管目录（构建产物直接托管）和函数响应（边缘运行时生成或代理）。两者的缓存头由不同环节负责，行为并不一致。
一个典型的对照是这样：
资源来源
Cache-Control
协商缓存
对象存储 / 图片代理
public, max-age=31536000, s-maxage=31536000, immutable
有 ETag
静态托管目录
视平台配置，可能不返回
有 ETag + Last-Modified
如果静态托管目录返回的资源没有带 Cache-Control，靠 ETag 做协商缓存，后果是：每次访问都要发一次条件请求，哪怕资源从未被修改，也得走一次完整的请求-响应往返才能拿到 304。
理想状态是给静态资源也加上长缓存。但这里有个前提不能跳过：如果文件名不带内容指纹，加长缓存会导致用户长期读到旧版本——代码明明改了，线上行为却不变。
所以正确的顺序是：
- 文件名带内容指纹（内容变，文件名变）
- 带上长缓存 + immutable（内容不变，缓存永不失效）
第 1 步不做，第 2 步就是个坑。这也是为什么静态资源要用构建期生成的内容哈希命名，而不能图省事写死文件名。
顺序不可颠倒的原因：缓存策略的"有效期"和资源标识的"唯一性"必须配套。长缓存的语义是"在这个 URL 对应的有效期内，内容不会变"——只有当 URL 自带内容指纹时，这句话才成立。
六、怎么让客户端性能可回归
客户端性能最容易退化的原因是没有断言。 服务端性能坏了会报错，图片体积、缺尺寸、脚本阻塞这些事情不会——它只是慢慢变慢，等到流量掉下去再查，已经过去几周了。
我在构建链里加了三类检查：
一、静态体积阈值。 CSS、JS 单个文件超过设定值就告警；单页 HTML 超过阈值也告警。这能拦住"顺手加了个库"导致的体积膨胀。
二、HTML 资源断言。 扫描产物 HTML，检查每张图片的必备属性（尺寸、加载策略、alt），检查有没有同步加载的非必要脚本。
三、体积增长趋势记录。 每次构建记录资源体积，纳入版本记录。单项不超阈值不代表没膨胀——所有资源各涨 20%，总流量会涨 20%，而单项都不越线。
一个必须用真实浏览器的理由
图片体积、布局偏移、加载顺序这三类问题，命令行工具测不出来。
curl 能告诉你图片多大，但不知道它出现在首屏第几位、是不是懒加载、有没有占位。断言"每张图都有 width/height"是静态可查的；断言"首屏没有布局跳动"必须真的在浏览器里渲染一遍。
经验：凡是涉及"用户看到的过程"的性能指标（LCP/CLS/INP），都必须用真实浏览器度量。用命令行工具验证这些，等于没验证。
七、几条能迁移到任何站的结论
一、先出账单再动手。 很多站点的性能问题排序和直觉相反。先统计首屏资源的构成占比，避免把力气花在占比 5% 的地方。
二、代码靠压缩，图片靠治理。 内容型站点的首屏字节里，图片通常占九成以上。图片的手段是优先级、尺寸、格式、懒加载——不是压缩算法。
三、width/height 是性价比很高的两行代码。 零字节成本，直接改善 CLS 这个排名信号。应该是构建期的硬断言，而不是最佳实践建议。
四、长缓存的前提是内容指纹。 顺序不能反：先有内容指纹，再谈 immutable 缓存。
五、用户可见的性能指标必须用浏览器测。 命令行能测的只是"文件多大"，测不了"看起来多快"。
八、这套优化的实际结果
优化后这个站的首屏形态是：
- 首屏只有 2 个阻塞资源（1 CSS + 1 JS），合计 57 KB
- 零字体请求——中文站点直接用系统字体栈，省掉了整个字体下载与字体切换的过程
- 首屏主图 fetchpriority="high"，其余 14 张懒加载
- 全部图片带固定宽高，CLS 来源被构建期断言堵住
- 静态资源带内容指纹，图片一年强缓存
区县页的边缘渲染 TTFB 实测在 0.24 到 0.46 秒之间，单页 25 KB 到 48 KB。
小结
服务端性能决定"能不能访问到"，客户端性能决定"访问到了愿不愿意留下"。
对内容型站点来说，客户端性能的杠杆点非常集中：图片是九成以上的字节，LCP/CLS/INP 三项指标都能靠具体的工程手段改善，而且大部分是零成本或极低成本。
如果只能先做一件事，我会选：把图片的必备属性写成构建期断言。 这条规则不需要任何性能知识，但能同时改善 LCP、CLS 两个核心指标，而且是永久生效的。
附：可复核的实测入口
文中的资源体积、缓存响应头、TTFB 都可以自己验证。相关的公开入口有三个： - 站点首页 —— 直接看首屏请求列表和资源体积
- 健康检查端点 —— 返回环境自检状态，可用来测边缘函数响应时间
- 站点事实语料 —— 站点对外声明的事实与数据口径
利益关系说明：本文涉及的实测数据全部来自上述站点，作者是该站点的运营者。文中所有结论、参数取值和判断依据均可按上述入口自行复核。
