Performance
改善 Core Web Vitals：真正有效的步骤顺序
启用缓存插件是第一步，而且往往是唯一做了的一步。之后指标停在“需要改进”，再也不动。原因在于：这三项指标测量的是三种不同的东西，而缓存只对其中一项真正有帮助。
三项指标，各用一句话说明
| 指标 | 测量什么 | 典型成因 |
|---|---|---|
| LCP | 最大的可见元素何时呈现完毕 | Hero 图片过大、服务器响应慢 |
| INP | 页面对点击的响应有多快 | JavaScript 过多，阻塞了浏览器 |
| CLS | 内容在加载时是否跳动 | 图片未设尺寸、后加载的横幅和字体 |
由此得出顺序：先图片，再脚本，最后布局。缓存主要作用于服务器时间——也就是 LCP 的一部分，对 INP 则几乎毫无作用。
第 1 步：最大的图片
在大多数页面上，Hero 图片就是 LCP 候选元素。有三件事能立竿见影，按以下顺序进行：
- 缩小到实际需要的尺寸——在 1200 像素宽的区域里放一张 4000 像素宽的照片，是最常见的单一成因。
- 转换为现代格式（WebP 或 AVIF），并为旧版浏览器提供回退方案。
- “不要”对它使用延迟加载。页面最上方的图片应当立即加载——在这里用 Lazy-Load 只会让指标变差，而不是变好。
检查一下格式转换在哪里进行。有些插件会为此把你的图片发送到厂商的服务上。不想这样的人，需要一个在本地转换的工具——这样第一次处理会花更长时间，但数据不出门。
第 2 步：JavaScript
INP 是缓存帮不上忙的指标。它测量浏览器需要多长时间才能对一次点击作出响应——而阻塞它的，正是恰好在那一刻运行的脚本。
最有效的手段是删减：一个没人操作的轮播图；每个页面上都有的聊天窗口；三种字体家族，其中两种根本没人注意到。在此之后，defer、合并以及延迟到首次交互时再执行才值得去做。
第 3 步：消除跳动
- 每张图片的标记中都需要 width 和 height——这样浏览器就会预留出位置
- 把嵌入内容放进一个固定高度的容器中
- 在本地提供字体并用 font-display 加以控制，而不是从外部后加载
- 以覆盖内容而非推挤内容的方式嵌入 Cookie 横幅和提示栏
然后才是：缓存、Minify、预加载
页面缓存省去的是生成页面的工作——服务器慢时这很可观，服务器快时则收效甚微。Minify 能节省字节，也是优化后页面出错最常见的原因。预加载是一道指令，而不是一个请求：用得太多，反而会把最先需要的资源挤到后面。
逐项启用 Minify，每次都检查一个表单页面、购物车和一个带视频的页面。一次全部打开的人，出错时就得在十个开关里逐个排查。
正确测量
有两种测量需要区分开来。实验室测试在固定条件下测量，适合比较优化前后的变化。实测数据来自真实访客的真实设备和网络连接——它们决定了 Google 如何评估这个页面。
因此：始终在相同条件下测量，测三次而不是一次；而实测数据需要几周时间才能体现出改动。一小时后去看却没发现变化的人，并不是优化得不够，而是看得太早了。
何时插件不再管用
存在一道任何缓存插件都跨不过去的界限：一个塞了三十个脚本的臃肿页面构建器、一个基础负载很高的主机商、一个在每个页面上都加载全部内容的主题。如果服务器即便不带内容时响应就已经很慢，问题就不在插件身上。
常见问题
我需要 CDN 吗？
如果你的访客离得很远，就需要。对于面向本地区的受众，与设置得当的缓存相比，CDN 带来的提升很小。
为什么启用了缓存，我的网站还是很慢？
最常见的原因：顶部的图片过大、JavaScript 过多、主机商速度慢。缓存加快的是页面分发，而不是生成过多内容的过程。
Lazy-Load 总是有用吗？
不是。对页面下方的图片有用，对最上方的图片则没用——在那里它会让 LCP 变差。
相比 WebP，AVIF 有什么优势？
文件通常还能再明显小一些，但生成速度更慢，而且并非所有地方都支持。同时提供两种格式、让浏览器自行选择，是通常的做法。
加载时间会影响排名吗？
它是众多因素之一，最可能在内容其他方面不相上下时发挥作用。而对访客来说，无论如何它都很重要。