工具站速度慢？别先怪服务器，先过这张 Core Web Vitals 清单 · Day 63

排名和转化不听口号。它们听 LCP、INP、CLS 三个数。

昨天 Day 62 讲边缘：门口该干啥、工厂该干啥。

今天把镜头拧回来——用户真正感知到的，是三个更硬的字：

快、跟手、不抖。

Google 把它们正式叫做 Core Web Vitals（核心网页指标）：

✅ 门槛来自 Google Search 文档与 web.dev Web Vitals 说明（LCP / INP / CLS），并要求看 真实用户 75 分位（p75），移动端与桌面端分开看。 ⚠️ 「过了一定涨排名」「实验室分=现场分」不做保证——搜索是多信号，CWV 是体验信号之一，不是唯一开关。

冰山线：

你以为在优化性能，其实在决定：用户有没有耐心把工具用完。

先说结论（忙的人只看这表）

Day 63 北极星：

工具站性能优化不是「把分数刷绿」，是：让 75% 的真实用户，在三个门槛内把活干完。

一、为什么工具站特别要懂 CWV

出海工具站、游戏攻略站，有三个共性：

1. 1. 用户目标极明确——来就为办一件事：查词条、转格式、对比参数
2. 2. 页面模板化——同一套壳 + 大量变体页（pSEO / 词库页）
3. 3. 流量来自搜索——Google 明确把页面体验（含 Core Web Vitals）纳入理解页面质量的参考

✅ Search 文档写明：Core Web Vitals 是页面体验相关信号的一部分；具体是否「通过」，看 URL 级现场数据不足时，可能回退到分组或源站级数据。

对一人团队更狠的是：

• • 你没有客服去解释「再等两秒」
• • 跳出 = 零转化
• • 模板一错，成千页一起慢

所以 Day 63 不写玄学「性能文化」，只写 清单：测什么、怎么读数、先改哪三刀。

二、三个指标，拆成人话

1）LCP：主内容什么时候「看见了」

LCP = Largest Contentful Paint。 通常是：首屏大标题区、英雄图、工具结果区上方的主视觉、文章首图。

Good：p75 ≤ 2.5s\ Needs improvement：2.5s–4.0s\ Poor：> 4.0s

✅ 与 PageSpeed Insights / web.dev 公开阈值一致。

工具站上 LCP 常见「最大元素」：

• • 首页 Hero 大图
• • 攻略页顶部封面
• • 对比表上方的产品图
• • 有时是一整块带背景的标题容器

你真正要问的不是「首页总分多少」，而是：

用户来办正事的那一页，主内容多久出来？

2）INP：点了之后，页面跟不跟手

INP = Interaction to Next Paint。 测的是：点击、敲键、点触之后，到下一次绘制之间有多慢。

Good：p75 ≤ 200ms\ Needs improvement：200–500ms\ Poor：> 500ms

✅ 同上，官方 Web Vitals 阈值。

对工具站，INP 往往比 LCP 更要命：

• • 点「Convert」卡住 800ms
• • 输入关键词，建议列表半天才弹
• • 切换 Tab，整页假死

用户可以原谅首屏慢半拍；\ 点了没反应，会直接骂「这站坏了」。

3）CLS：布局会不会突然「抖一下」

CLS = Cumulative Layout Shift。 广告弹出、字体替换、图片晚加载、Cookie 条顶下来——都会加分（坏方向）。

Good：p75 ≤ 0.1\ Needs improvement：0.1–0.25\ Poor：> 0.25

工具站高频场景：

• • 图片没写宽高，加载完把正文顶下去
• • 顶部通知条晚到，把工具区整体下推
• • Web 字体闪一下，标题行高跳变
• • 结果区异步插入，按钮位置漂移——用户点空

三、实验室 vs 现场：别被「绿分」骗了

很多人的日常是：

1. 1. 打开 PageSpeed Insights
2. 2. 看实验室分
3. 3. 绿了就收工

这只做对了一半。

✅ Google 用 CrUX 等现场数据评估体验；工具链包括 Search Console 的 Core Web Vitals 报告、PageSpeed Insights 的现场部分、web-vitals 库等。

一人站建议顺序：

1. 1. Search Console → Core Web Vitals 报告：哪些 URL 组「差 / 需改进」
2. 2. 挑 3 个代表页：首页、一个高流量着陆页、一个核心工具页
3. 3. PSI 看现场 + 实验室，对照
4. 4. Chrome DevTools Performance / 性能面板，抓一次真实交互
5. 5. 改完等现场窗口滚动（现场数据有时间窗，不是改完立刻满分）

⚠️ 「改完第二天排名起飞」——不写。现场分位更新需要时间，且排名因素不止 CWV。

四、工具站 LCP 清单（先把主内容送出来）

4.1 先找到「谁是 LCP 元素」

Chrome 里可以看 LCP 候选；PSI 诊断也会点名。

找到以后只问一句：

这个元素，是不是用户来办正事必须看见的东西？

如果 LCP 是一张装饰大图——考虑砍掉或换成 CSS/小图。 如果 LCP 是工具标题+输入框区域——优先保它。

4.2 图片与媒体

清单：

• • [ ] 首屏图用现代格式（按你栈选 WebP/AVIF），别无脑塞 2MB PNG
• • [ ] 给 width / height 或固定 aspect-ratio（顺带帮 CLS）
• • [ ] 真正的 LCP 图：考虑 fetchpriority="high" + 合适预加载
• • [ ] 非首屏图：懒加载；LCP 图不要懒加载
• • [ ] CDN 就近；别让首图绕远路

游戏攻略站、工具着陆页模板化时，封面字段一旦允许运营传超大原图，整站 LCP 会一起烂。 模板层要卡：最大边长、自动压缩、默认占位。

4.3 字体

• • [ ] 控制 Web 字体数量（能系统字体就系统字体）
• • [ ] font-display: swap 或可选策略，避免长时间空白
• • [ ] 子集化（只含用到的字符）——多语言站尤其疼
• • [ ] 预加载 真正首屏用到的 那一个字重，不要预加载全家桶

4.4 JS / CSS 阻塞

• • [ ] 首屏关键 CSS 内联或优先加载；其余延后
• • [ ] 第三方脚本（统计、聊天、A/B）能晚则晚
• • [ ] 框架水合（Hydration）体积：工具页只加载工具需要的 chunk
• • [ ] 广告脚本永远别放进「主内容必经路径」的同步位

Day 61 的 ISR、Day 62 的边缘分流，本质都在帮 LCP：\ 少回源、少算、先出壳。 但壳出来之后，如果主图还在慢速域名上爬，LCP 照样炸。

五、工具站 INP 清单（点了就要有反馈）

5.1 先分清：重活 vs 反馈

用户点「开始处理」时，他需要的第一帧往往不是「结果算完」，而是：

• • 按钮进入 loading
• • 进度条动一下
• • 输入框禁用，防止连点

先给反馈，再算重活。 这是 INP 最便宜的一刀。

5.2 主线程别当矿机

清单：

• • [ ] 大 JSON 解析、大表格排序、图片像素处理 → Web Worker 或分段 requestIdleCallback / 分片
• • [ ] 输入建议、搜索过滤 → 防抖（debounce），别每个字母全量扫 1 万行
• • [ ] 长列表虚拟滚动，别一次渲染 5000 行 DOM
• • [ ] 避免在 input 事件里同步写超级复杂布局
• • [ ] 第三方脚本的长任务：能砍则砍，不能砍就延后到交互后

在线转换类工具（压缩、格式转换、计数）尤其容易：\ 算法写在主线程 + UI 更新绑在一起 → INP 直接 Poor。

5.3 交互路径要短

• • 关键菜单、多级弹窗、重动画——都会拉长「到下一次绘制」
• • 工具主路径：输入 → 一键执行 → 结果，中间别塞三层引导
• • 移动端点击热区够大，减少误触导致的无效交互统计噪声

六、工具站 CLS 清单（别让页面自己打架）

6.1 尺寸预留

• • [ ] 所有图片/视频/iframe 明确尺寸
• • [ ] 广告位、嵌入组件用 固定最小高度 的容器
• • [ ] 骨架屏高度尽量贴近真实内容，别 40px 骨架突然变 400px 正文

6.2 晚到的 UI

• • [ ] Cookie / 订阅条：优先占文档流固定位，或确认不影响主按钮
• • [ ] 字体：减少 fallback 与最终字体的行高差
• • [ ] 动态插入的「相关推荐」放在结果区下方，别插在标题和按钮之间

6.3 工具结果区

结果区异步返回时：

• • 先渲染固定高度的结果容器
• • 用「计算中」占位，而不是结果出来后把分享按钮顶飞
• • 错误态与成功态同一容器高度策略，减少二次跳动

七、一套「两人下午能跑完」的执行顺序

你不是大厂性能组。要的是 可重复的作战顺序。

Step 1：定代表页（30 分钟）

至少三类：

1. 1. 流量最大的内容/着陆页
2. 2. 核心工具交互页
3. 3. 模板页里「最肥」的那类（图多、脚本多、第三方多）

Step 2：拉出现场名单（30 分钟）

• • Search Console → Core Web Vitals
• • 记下「差」的 URL 模式（是 /tools/* 还是全站）
• • 若数据不足：先看源站级，同时用 PSI 实验室 + 自己真机点一点

Step 3：一页一刀（半天）

每页只改 一类主因：

忌讳： 一次改缓存、改 CDN、改框架、改字体全家桶——你不知道是哪刀生效。

Step 4：回归（第二天起）

• • 同一 URL 再跑 PSI
• • 真机弱网点主路径三遍
• • 记一笔：改了什么、预期动哪个指标
• • 现场分位变化交给时间窗，不天天截图自嗨

八、和 Day 61 / 62 怎么拼在一起

三天其实是同一条链：

错误拼法：

• • 边缘上了一堆，首屏仍是 3MB 英雄图 → LCP 依旧
• • ISR 再生很勤，但每次带着重 JS 水合 → INP 依旧
• • 分数刷绿，工具点下去主线程卡死 → 转化依旧

正确拼法：

1. 1. 内容正确、可索引（前几模块）
2. 2. 缓存与再生正确（61）
3. 3. 入口轻逻辑正确（62）
4. 4. 代表页 CWV 过线（63）
5. 5. 再谈极限炫技

九、一人站「不要做」的五件事

1. 1. 不要只优化首页，不管赚钱页/工具页
2. 2. 不要把实验室 100 分当现场已通过
3. 3. 不要为了 CLS 把所有动画删光——先修无尺寸和插入顺序
4. 4. 不要在没测 INP 前先上重型前端特效
5. 5. 不要把性能当成「上线前刷一次」——模板站是 持续回归，新第三方一加就会倒退

十、回扣：三个数，一句话

回到开头那句：

排名和转化不听口号。它们听 LCP、INP、CLS 三个数。

对出海工具站，更直白的版本是：

• • LCP：用户有没有看见你的价值
• • INP：用户敢不敢继续点
• • CLS：用户点的时候手会不会点歪

你不需要先成为性能专家。 你需要一张清单，每周挑一个代表页，砍一刀最大的真凶。

Day 61 让内容「改完还能被看见」。 Day 62 让请求「进门先分拣」。 Day 63 让用户「留下来把工具用完」。

三件事做完，你的站才像一个 能收钱的产品，而不只是一堆能打开的 URL。

今日可执行清单

1. 1. 打开 Search Console 的 Core Web Vitals 报告，截一张「差 / 需改进」列表
2. 2. 选出 3 个代表 URL（内容页 / 工具页 / 最肥模板页）
3. 3. 对每个 URL 用 PageSpeed Insights 看现场 + 实验室，记下 LCP 元素是谁
4. 4. 只改一刀：本周只修一个指标的一个主因（图 / JS / 尺寸 / Worker）
5. 5. 写回模板规范：图片必有尺寸、LCP 图不懒加载、工具按钮必有即时 loading
6. 6. 把第三方脚本列清单：哪些同步挡首屏——能晚加载就晚加载

做完这六步，你才算「管过性能」，而不是「听说过 Core Web Vitals」。

十一、模板站特别条款（游戏攻略 / pSEO 页）

做游戏攻略站、以及常见出海工具着陆页时，结构往往一样：

一套模板 × 成百上千 URL。

性能问题一旦写进模板，就是批量事故。所以除了「代表页」，还要加三条模板纪律：

1. 1. 封面与插图入口统一压测 编辑后台若允许上传原图，模板层必须二次压缩。别指望每个作者自觉。
2. 2. 第三方脚本分环境 统计、热图、客服挂件：开发环境可以全开，生产环境默认延后到 load 之后。工具主按钮路径上，禁止同步塞聊天 SDK。
3. 3. 「肥页」回归名单 每月抽 10 个：含表格最多的、含嵌入最多的、含对比组件最多的。 普通词条页绿了不算完，肥页才是 INP/CLS 的隐藏 Boss。

这三条不炫技。它们只解决一件事：

你改对了一页，别在第二周被模板复制打回原形。

和 Day 52/53 的 pSEO 同一逻辑——规模化之前，先把错误成本按住。

Day系列完整索引

出海工具站 90 天路径持续更新中。模块一（Day 1-15）启动 → 模块二（16-30）流量 → 模块三（31-45）变现 → 模块四（46-60）规模化 → 模块五进阶技术（61 ISR · 62 Edge · 63 Core Web Vitals …）。

完整索引入口文章规划中；单篇可在公众号内搜「Day」+ 编号回看。

袁锐钦 · AI产品实操 & 出海工具站日更中。做产品、测工具、跑变现，把试过的路摊开给你看。