速度与 Core Web Vitals
我修复网站变慢的原因，而不是症状。
大多数提速工作就是装一个缓存插件、一个压缩工具，然后满怀希望地再测一次。这能让实验室分数动一动，真正的问题却原封不动。我会分析时间究竟花在了哪里，修复这些地方，并给您一份可以在自己电脑上复现的前后对比。
01现场演示来自您浏览器的实时数据
此刻您正在读的这个页面，实时测量。
任何卖提速服务的人都能给您看一张跑分漂亮的截图。这些则是您自己的浏览器加载本页时记录下的数字，并对照 Google 使用的阈值。打开开发者工具的网络面板，自己核对一下。
标记、样式、脚本和三种字体——呈现您正在阅读的内容所需的全部。
HTTP Archive 统计的网页体积中位数。
02诊断时间究竟花在哪里
慢只是症状，这些才是原因。
送到我这里的慢网站，几乎都慢在下面其中两三个原因上。诊断的意义就是找出是哪几个，因为每种原因的解决方法完全不同——买错了方案，就是很多人最后为提速付了两次钱的原因。
服务器想得太久
Time to First Byte 偏高，意味着在第一个字节到达浏览器之前就已经在做大量工作。在 WordPress 上，常见原因是模板循环里未缓存的查询、autoload 的选项表膨胀到好几 MB，或者某个插件在渲染页面时调用外部 API。这些都是前端优化碰不到的。
屏幕上最大的元素太大了
一张导出为 4000 像素宽、以 PNG 格式提供的首屏大图，单凭它就能让 Largest Contentful Paint 不达标。解决办法毫不花哨：正确的尺寸、现代图片格式、用 srcset 让手机不下载桌面版、明确的宽高，以及给唯一重要的那张图加上 fetchpriority。
脚本阻塞了渲染
head 里的每一个同步脚本，都是浏览器开始绘制前的一个停车标志。标签管理器、在线客服插件、A/B 测试工具和字体加载器是常见嫌疑，而且它们常常为了一个只在某页用到的功能而加载在每个页面上。
页面在加载时跳动
Cumulative Layout Shift 源于那些没有预留空间、姗姗来迟的元素——没有尺寸的图片、换成不同大小的网页字体、插在现有内容上方的 Cookie 横幅和广告。它通常是三项里修复成本最低、体验上最恼人的一项。
交互感觉发黏
Interaction to Next Paint 在 2024 年 3 月取代了 First Input Delay，是一项严格得多的指标。它衡量的是整个访问过程中，一次交互需要多久才能产生可见的反馈——而不只是第一次交互。网站不达标，是因为太多 JavaScript 在争抢主线程。
03流程确实有先后顺序
工作如何推进。
- 01
先诊断，再报价
- 我会分析网站，并书面列出时间花在哪里，按对您的影响程度和修复难度排序。无论您是否雇用我，这份文档都归您所有。
- 02
以真实用户数据为基准
- 实验室分数每次测都不一样。我会先记录 Chrome UX Report 的真实用户数据，这样最后比较的是真实访客的实际体验，而不是两个不同下午跑出的实验室分数。
- 03
从最大的原因开始修
- 所有工作都在测试环境进行，一次只改一处，每处单独测量。十项改动一起上，什么也说明不了——既不知道哪项起了作用，也没法撤回帮倒忙的那项。
- 04
验证，再把方法交给您
- 您会拿到前后对比、复现两者的步骤，以及一份说明什么会慢慢抵消这些成果的备注——通常是下一个被人装上的插件。
04常见问题常被问到，坦率回答
大家在雇用我之前常问的问题。
装个缓存插件能解决我的 Core Web Vitals 吗？
最多只能解决一部分。缓存能改善服务器响应时间，这对 Time to First Byte 有帮助。但对于首屏大图过大导致的 Largest Contentful Paint 问题帮助甚微，对没设尺寸的元素引起的布局偏移毫无作用，对繁重 JavaScript 造成的 Interaction to Next Paint 问题也毫无作用。找到我的大多数网站都已经装了缓存插件，却依然不达标。
为什么我的 PageSpeed Insights 分数总在变？
顶部那个大数字是在模拟慢速设备上的实验室测试，每次运行都会波动。下方的部分——来自 Chrome UX Report 的真实用户数据——才是 Google 实际使用的，它是真实访客 28 天的滚动平均值。盯紧真实用户数据，忽略实验室分数的小幅波动。
优化效果多久会在 Google 上体现？
因为真实用户数据是 28 天的滚动窗口，改动要完全体现大约需要四周——流量较低的网站需要更久才能攒够样本。任何承诺排名立刻变化的人，说的都是实验室分数，而不是真正算数的那个。
您能保证多大的提升？
在看过之前，无法保证——这就是为什么先诊断、后报价。一个插件堆积、首屏大图未优化的网站，有很大的轻松提升空间。一个前端已经很精简、却慢在数据库的网站，则是另一种工作、另一个价格。我宁愿在分析一小时后给您一个真实的数字，也不愿现在给一个好看的数字。
我需要重做网站吗？
通常不需要。大多数速度问题是少数几个具体原因，而不是根本性缺陷，修复它们远比重建便宜。如果我认为您已经触到了现有实现的天花板，我会直说——但那是例外，一上来就推荐重建也不符合您的利益。
INP 是什么？它取代了 FID 吗？
2024 年 3 月，Interaction to Next Paint 取代 First Input Delay 成为 Core Web Vital。FID 只衡量浏览器开始处理您第一次交互之前的延迟。INP 衡量的是在整个访问过程中，整次交互需要多久才能产生可见反馈。它难达标得多，而不达标通常只有一个原因：主线程上的 JavaScript 太多。
我的网站以前很快，后来变慢了。是什么变了？
根据我的经验，几乎总是这三者之一：后来新增的插件或跟踪脚本、内容团队直接上传相机拍出的全分辨率图片，或者数据库在悄悄膨胀——文章修订版、过期的 transient、autoload 的选项表。三者一旦找到，修复成本都很低。