目录站的性能预算：把「页面别太重」写成一条能执行的红线

我见过太多这样的站：某个月集中优化了一次，Lighthouse 分数从 40 多提到 90 多，大家很高兴；半年后再看，又回到 60 分。中间没人做错什么，只是每次上线加一点东西，加着加着就回去了。性能预算就是用来对抗这种缓慢劣化的，它不解决问题，它只是让问题在发生的那一刻就被发现。

图片来源：网络，版权归原作者所有，侵权请联系删除

预算要分四类写

类别	建议值（目录站首屏）	说明
体积预算	总传输 ≤ 800KB，其中图片 ≤ 400KB	压缩后实际传输量，不是源文件大小
数量预算	请求数 ≤ 50，第三方域名 ≤ 6	第三方域名比请求数更值得盯
指标预算	LCP ≤ 2.5s，INP ≤ 200ms，CLS ≤ 0.1	看 28 天 p75 的真实用户数据
时间预算	TTFB ≤ 800ms	后端和网络的份额，前端优化救不了这个

这四类里，最容易被忽略的是数量预算里的「第三方域名数」。每多一个第三方域名，就多一次 DNS 解析、一次 TCP 和 TLS 握手，而且这个开销是你控制不了的。目录站常见的第三方来源是统计、广告、客服、搜索建议、CDN 上的字体库，很容易就堆到十几个。

目录站的特殊性：一页几百个条目

文章站的预算比较好定，因为页面结构相对固定。目录站难在列表页条目数量可变，一页 20 条还是 200 条，体积差好几倍。所以需要单独给「单条目」定预算：每个条目的缩略图不超过 8KB，HTML 片段不超过 500 字节。这样不管一页放多少条，总量都能算出来。

缩略图这块，统一尺寸是最有效的一招。目录站的缩略图显示尺寸通常就 96×96 到 160×160，但很多人直接引用对方站点原图，一张一两百 KB，一页 50 张就是好几 MB。自己抓下来重采样到统一尺寸再存，这一步的收益比其他所有图片优化加起来都大。图标用 SVG sprite 或者 iconfont，别每张都是独立请求。列表太长就分页，一页塞几百条会带来 DOM 节点数暴涨，顺带把渲染和交互都拖慢。

三个卡点，缺一个就会漏

第一个卡点放在 CI 里。Lighthouse CI 支持 budgets 配置，可以写 resourceSizes 和 resourceCounts 两类断言，超了就让构建失败，或者至少给出警告。举例来说，可以规定 script 总量不超过 300KB、image 不超过 400KB、third-party 请求不超过 15 个。这一关能拦住大部分「顺手加了个 SDK」的情况。

第二个卡点在发布前的人肉检查。听起来不高级，但很管用：上线前打开浏览器网络面板，看一眼首屏总传输量和请求数。数字对不上预算，就别发。CI 只能跑固定几个 URL，人的眼睛能看到任意页面。

第三个卡点是线上监控。Search Console 的核心网页指标报告和 CrUX 数据看的是真实用户，28 天滚动的 p75，这个数据不会骗人，也不会因为你在本地跑了一次高分就变好。每月看一次，按 URL 分组（目录站的分组通常是首页、分类页、条目页三类）分别看。

超了先砍谁

预算超了要有明确的砍伐顺序，否则每次都是一场争论。我的顺序是：第三方脚本 → 图片 → 字体 → 自有 JS → CSS。理由是第三方脚本的收益最难证明、成本最高，砍掉的风险最小；图片靠压缩和尺寸控制能立竿见影；字体往往是全量加载的中文字体，一个文件几百 KB；自有 JS 和 CSS 通常已经优化过一轮，能挤的水分不多。

最后一句

预算一定要写进需求文档或者上线清单里，写在脑子里等于没有。最好还能指定一个人负责看，否则所有人都会默认「别人在看」。这件事技术难度不高，难的是它永远不紧急，所以永远被排在后面，直到某天发现页面已经重得救不回来。