网站速度，老生常谈的话题。
但2026年了，很多人还在用2018年的方法优化。Google的算法早就变了，Core Web Vitals的指标也换了一轮。FID没了，INP来了。你还在死磕首屏加载时间，Google已经开始看交互响应速度了。
这篇文章不讲虚的。从原理到实操，从诊断到修复，一步步来。
为什么网站速度还重要？
先说结论：速度是排名因素，但不是最重要的那个。
根据Google官方博客，2010年Google就把网站速度纳入了桌面端排名因素。2018年，移动端也跟上了。
但Google也说得很清楚：内容相关性永远排第一。一个慢但内容好的页面，排名照样能干掉快但内容差的页面。
那为什么还要优化速度？
三个原因：
1. 用户体验
Google的研究显示，页面加载时间从1秒增加到3秒，跳出率增加32%。从1秒到5秒，跳出率增加90%。
用户没耐心。3秒不出内容，直接关掉换下一个。
2. 转化率
Portent的研究发现，页面加载时间每增加1秒，转化率下降4.42%。电商网站尤其明显。
3. 爬虫效率
Google给每个网站分配的爬取预算有限。页面加载慢，爬虫能抓的页面就少。大型网站这个问题更突出。
Core Web Vitals：2026年的三大指标
Google在2020年推出Core Web Vitals，2021年正式纳入排名因素。2024年，INP取代了FID，成为新的交互指标。
现在的三大指标：
LCP（Largest Contentful Paint）
最大内容绘制。简单说，就是页面主要内容加载完成的时间。
| 评级 | 时间 |
|---|---|
| 好 | ≤2.5秒 |
| 需改进 | 2.5-4秒 |
| 差 | >4秒 |
LCP测量的是视口内最大的图片或文本块的渲染时间。通常是首屏的主图或标题。
常见问题：
– 服务器响应慢
– 渲染阻塞的CSS/JS
– 资源加载慢
– 客户端渲染
INP（Interaction to Next Paint）
交互到下一次绘制。这是2024年新加的指标，取代了FID。
| 评级 | 时间 |
|---|---|
| 好 | ≤200毫秒 |
| 需改进 | 200-500毫秒 |
| 差 | >500毫秒 |
INP比FID更全面。FID只测量第一次交互的延迟，INP测量整个页面生命周期内所有交互的响应速度，取最差的那个。
常见问题：
– JavaScript执行时间长
– 主线程阻塞
– 第三方脚本拖累
CLS（Cumulative Layout Shift）
累积布局偏移。页面加载过程中，元素意外移动的程度。
| 评级 | 分数 |
|---|---|
| 好 | ≤0.1 |
| 需改进 | 0.1-0.25 |
| 差 | >0.25 |
你肯定遇到过这种情况：正要点一个按钮，突然页面跳了一下，点到了广告。这就是CLS问题。
常见问题：
– 图片没设置尺寸
– 广告/嵌入内容动态加载
– 字体加载导致文字跳动
– 动态插入的内容
诊断工具：先测再改
优化之前，先搞清楚问题在哪。
PageSpeed Insights
PageSpeed Insights是Google官方工具，免费。
输入URL，几秒钟出结果。会显示：
– Core Web Vitals三项指标
– 性能评分（0-100）
– 具体的优化建议
注意：它有两组数据。”实际用户体验数据”来自Chrome用户的真实访问，”诊断”是实验室模拟。两个都要看。
Lighthouse
Chrome浏览器自带。按F12打开开发者工具，找到Lighthouse标签。
比PageSpeed Insights更详细，能看到每个资源的加载时间、阻塞情况。
WebPageTest
WebPageTest是老牌工具，功能强大。
可以选择不同地区、不同网络条件测试。还能生成瀑布图，直观看到每个资源的加载顺序和时间。
Chrome DevTools
最强大的调试工具。
Performance面板可以录制页面加载过程，精确到毫秒级。Network面板能看到每个请求的详情。
服务器优化：从根源解决问题
页面速度慢，很多时候不是前端的锅，是服务器太慢。
TTFB（Time to First Byte）
首字节时间。从浏览器发出请求，到收到第一个字节的时间。
理想情况下，TTFB应该在200毫秒以内。超过600毫秒就有问题了。
优化方法：
1. 升级服务器配置
共享主机便宜，但性能差。流量稍微大点就扛不住。
VPS或云服务器是更好的选择。Cloudways、DigitalOcean、Vultr都是不错的选择。
2. 使用CDN
CDN（内容分发网络）把你的内容缓存到全球各地的节点。用户访问时，从最近的节点获取内容。
Cloudflare有免费套餐，对大多数网站够用了。Fastly和Akamai是企业级选择。
3. 启用缓存
服务器端缓存能大幅减少数据库查询和PHP执行时间。
WordPress用户可以用WP Rocket或W3 Total Cache。
4. 数据库优化
定期清理过期数据、优化表结构。WordPress的wp_options表经常是性能瓶颈。
HTTP/2和HTTP/3
还在用HTTP/1.1？该升级了。
HTTP/2支持多路复用，一个连接可以同时传输多个资源。HTTP/3更进一步，基于QUIC协议，连接建立更快。
大多数现代服务器和CDN都支持HTTP/2。Cloudflare已经默认启用HTTP/3。
图片优化：最容易见效的优化
图片通常占页面总大小的50%以上。优化图片，效果立竿见影。
选择正确的格式
| 格式 | 适用场景 | 特点 |
|---|---|---|
| WebP | 通用 | 比JPEG小25-35%，支持透明 |
| AVIF | 现代浏览器 | 比WebP还小20%，但兼容性差 |
| JPEG | 照片 | 兼容性最好 |
| PNG | 需要透明的图片 | 文件较大 |
| SVG | 图标、Logo | 矢量格式，无限缩放 |
2026年了，WebP应该是默认选择。所有主流浏览器都支持。
AVIF更先进，但Safari直到2023年才支持。如果你的用户主要用Chrome，可以考虑AVIF。
压缩图片
上传前先压缩。
在线工具：
– Squoosh（Google出品，免费）
– TinyPNG（支持PNG和JPEG）
– ImageOptim（Mac应用）
WordPress插件：
– ShortPixel
– Imagify
– EWWW Image Optimizer
压缩率设置在70-80%，肉眼几乎看不出区别，但文件大小能减少60%以上。
响应式图片
不同设备用不同尺寸的图片。手机屏幕就那么大，没必要加载4K图片。
HTML的srcset属性：
<img src="image-800.jpg"
srcset="image-400.jpg 400w,
image-800.jpg 800w,
image-1200.jpg 1200w"
sizes="(max-width: 600px) 400px,
(max-width: 1200px) 800px,
1200px"
alt="描述">
WordPress 4.4以后自动支持响应式图片，但你需要上传足够大的原图。
懒加载
首屏以外的图片，等用户滚动到附近再加载。
现代浏览器原生支持：
<img src="image.jpg" loading="lazy" alt="描述">
就这么简单。加一个loading=”lazy”属性就行。
但首屏的图片不要懒加载，会影响LCP。
设置图片尺寸
这是CLS问题的主要来源。
图片加载前，浏览器不知道它多大，就先按0处理。图片加载完，突然撑开空间，页面就跳了。
解决方法：在HTML里写死宽高。
<img src="image.jpg" width="800" height="600" alt="描述">
或者用CSS的aspect-ratio：
img {
aspect-ratio: 4 / 3;
width: 100%;
height: auto;
}
CSS优化：别让样式拖后腿
CSS是渲染阻塞资源。浏览器必须等CSS加载完才能渲染页面。
关键CSS内联
把首屏需要的CSS直接写在HTML的