你先记住一句话：技术 SEO 不是“做极致”，是“别拖后腿”
独立开发时间最值钱。你不需要把每一页都优化到 100 分，但你必须保证：
- 重要页面别慢到让用户烦
- 交互别卡到让人点两次
- 页面别乱跳让人找不到按钮
因为这些东西会同时影响两件事：
用户留不留得住，以及你在搜索里能不能拿到更高的上限。Google 也明确建议站长把 Core Web Vitals 做到“Good”，这对搜索和用户体验都有帮助。
Core Web Vitals 到底看什么：别背概念，先记阈值
你只需要把这三个指标当成“红绿灯”：
| 指标 | 它在测什么 | Good 阈值 | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | 首屏主要内容加载速度 | ≤ 2.5s | 2.5s–4s | > 4s |
| INP | 全程交互响应（点击/输入后多久有反馈） | < 200ms | 200ms–500ms | > 500ms |
| CLS | 页面布局抖动 | ≤ 0.1 | 0.1–0.25 | > 0.25 |
INP 已经替代 FID 成为 Core Web Vitals 的交互指标（从 2024 年开始生效）。
INP 的解释你也可以这样理解：用户点一下按钮，你别让他“等着反应”。web.dev 对 INP 的定义和计算方式也说得很清楚：它观察用户访问期间的交互延迟，最后取一个代表性的最差值（会忽略部分离群值）。
先别瞎改：你要用同一套方法定位问题
我建议你固定用三件工具，别今天 Lighthouse、明天随便测一个就开始改：
- GSC Core Web Vitals 报告：看真实用户数据分组（Good/NI/Poor），也能看到按 URL 分组的表现。
- PageSpeed Insights：把实验室数据 + 真实用户数据放一起看，还能给出可操作建议。
- Chrome DevTools Performance：定位卡顿、长任务、主线程被谁占了（INP 主要靠它抓元凶）
你的流程最好固定成这样：
- GSC 找出最差的 URL 组（通常是模板页或工具页）
- 选 3 个最重要的流量页（首页 + 2 个流量页）做 PSI
- 对 INP/LCP/CLS 里最差的那个先下手
最小动作清单：先把“最常见的坑”一次性扫掉
下面这张表是我自己常用的“先改这些，八成就见效”的清单。
| 优化点 | 主要影响指标 | 你会看到的典型问题 | 最小改法（独立开发版） |
|---|---|---|---|
| 图片没做尺寸与压缩 | LCP、CLS | 首屏大图加载慢、图片一加载页面抖 | 首屏图用现代格式、压缩；固定 width/height 或占位；首屏图别 lazy |
| 字体阻塞渲染 | LCP | 首屏文字很晚才出现 | 减少字体文件；用 font-display: swap；只加载需要的字重 |
| JS 太多、主线程太忙 | INP、LCP | 点击后没反应、输入卡顿 | 砍首屏 JS；拆包；延后非关键脚本；减少 hydration 压力 |
| 长任务（Long Task） | INP | 点击后要等很久才绘制 | 拆分计算；把重活放 Web Worker；分帧处理（requestIdleCallback 等） |
| 事件处理太重 | INP | 点击按钮触发一串同步逻辑 | 先给 UI 反馈（loading/optimistic）；重逻辑异步化 |
| 布局抖动 | CLS | 图片/广告/组件加载后整体跳 | 给元素预留空间；避免首屏插入未知高度内容 |
| 第三方脚本太多 | INP、LCP | analytics/ads/widget 拉低分数 | 只留必要的；延迟加载；能用 server-side 的别放前端 |
| 缓存与 CDN 没用好 | LCP | 静态资源每次都重新拉 | 静态资源强缓存；走 CDN；合理 cache-control |
你不用一次做完所有，先按页面的重要性从上往下扫。
INP 实战：我通常先抓 3 类“最常见元凶”
INP 是很多工具站、Next.js 站的第一杀手。你别一上来就“优化代码质量”，先抓最常见的三类元凶。
元凶 1：主线程被 JS 占满（尤其首屏 hydration）
典型表现：
- 页面看起来加载完了，但一点击就卡一下
- 输入框打字会丢字或者延迟
最小改法（思路）：
- 首屏减少需要 hydration 的组件
- 非关键组件延后渲染（比如折叠区、下方模块）
- 大计算不要放在点击事件里同步跑
元凶 2：点击事件里做了太多同步工作
典型表现：
- 点击按钮后，loading 迟迟不出现
- 直到逻辑跑完才更新 UI
最小改法（思路）：
- 先更新 UI 状态（让用户知道“我收到你的点击了”）
- 重逻辑异步化、分批处理、或丢给 Worker
- 网络请求要有超时与降级
元凶 3：第三方脚本抢资源
典型表现：
- 你自己代码没那么复杂，但分数就是上不去
- PSI/Performance 里第三方占了大量 main thread time
最小改法（思路）：
- 能延后就延后（用户滚动后再加载）
- 能少一个就少一个
- 广告/统计别在首屏堆一排
web.dev 的 INP 指南里也把“主线程工作、事件回调、渲染开销”等方向讲得很系统，你后面要深挖可以按那个体系逐项排。
Next.js 抓取与渲染：别赌 Googlebot“帮你跑完 JS”
我见过不少 Next.js 站做 SEO 的时候犯一个低级错误：把关键内容全放到客户端渲染，然后指望爬虫“反正能执行 JS”。
现实是：你可以让 Google 渲染 JS，但你不该把关键内容和关键 SEO 元素押在这上面。Vercel 也明确建议关键 SEO 内容和标签最好通过 SSR 或静态生成，保证初始 HTML 里就有。
渲染策略怎么选（按 SEO + 性能）
| 渲染方式 | SEO 友好度 | 性能上限 | 适合页面 | 独立开发建议 |
|---|---|---|---|---|
| SSG（静态生成） | 很高 | 很高 | 教程页、模板页、对比页 | 优先用 |
| ISR（增量静态） | 很高 | 高 | 内容多、需要定期刷新 | 内容站很香 |
| SSR（服务端渲染） | 高 | 中 | 需要实时数据的页面 | 控制好 TTFB |
| CSR（纯客户端渲染） | 不稳定 | 取决于 JS | 强交互应用 | SEO 页面尽量别用 |
Next.js 自己的 SEO 教程里也明确说：静态生成通常对 SEO 最友好，因为首屏就是预渲染 HTML，而且对性能也更有利。
再补一句很容易忽略的：别在 robots.txt 里把渲染需要的资源（JS/CSS/API）挡了，不然爬虫想渲染也渲染不出来。
重复与规范化：技术 SEO 里最“隐蔽”的掉坑点
这块很多人不重视，但它会悄悄稀释你站内权重。
你至少要盯住这三类重复
- 参数 URL：同内容带不同参数产生多个 URL
- 同内容多路径：比如 /tool/xxx 和 /tools/xxx 都能打开
- 分页/筛选页：列表页组合出一堆近似页面
最小动作：
- 关键页面保持规范 URL（canonical 自引用为主）
- 明确哪些参数页不需要索引（必要时 noindex）
- 统一重定向规则（带/不带斜杠、http→https、www→non-www）
作业：把 4 个页面优化到“能用且不卡”的水平
别贪多，这章的个页我建议你就盯 4 个页面：
- 首页
- 3 个核心流量页（通常是：一个工具页 + 一个内容页 + 一个对比/模板页）
你需要提交的结果（像做工程一样留记录）
- 每个页面优化前后的数据截图或记录（PSI/GSC 都行）
- 你做了哪些改动（用清单写出来）
- 你总结的一份“性能优化 SOP”（下个站直接照抄）
你可以用这张表当台账：
| 页面 | 优化前最差指标 | 主要问题 | 做了哪些改动 | 优化后结果 |
|---|---|---|---|---|
| 首页 | INP/LCP/CLS | 例如：JS 重、首屏图大 | 例如：拆包/压缩图/延后脚本 | 记录数值 |
| 工具页 | ||||
| 内容页 | ||||
| 对比/模板页 |