Core Web Vitals是什么?让PageSpeed 90+(无需懂开发)
2026年,Google把Core Web Vitals作为Ranking factor——在同等竞争市场,3项指标都达标的网站排名高于不达标的网站。
此外,Core Web Vitals直接影响转化:LCP减少1秒,转化率提升8-12%。
Core Web Vitals是3个指标
1. LCP(Largest Contentful Paint)
衡量主要图片或文字何时加载完成。
| 分数 | 状态 |
|---|---|
| < 2.5秒 | ✅ Good |
| 2.5-4.0秒 | ⚠️ Needs Improvement |
| > 4.0秒 | ❌ Poor |
LCP慢的原因:
- 图片过大(5MB hero)
- Server响应慢(TTFB > 600ms)
- Render-blocking JS/CSS
- Web Font加载慢
2. CLS(Cumulative Layout Shift)
衡量加载后页面”自动位移”的程度。
| 分数 | 状态 |
|---|---|
| < 0.1 | ✅ Good |
| 0.1-0.25 | ⚠️ Needs Improvement |
| > 0.25 | ❌ Poor |
CLS高的原因:
- 图片未指定width/height
- Ads/Embed后加载
- Web Font Swap后layout变化
- 动态内容Inject
3. INP(Interaction to Next Paint) —— 2024年起替代FID
衡量点击/触摸后页面响应速度。
| 分数 | 状态 |
|---|---|
| < 200ms | ✅ Good |
| 200-500ms | ⚠️ Needs Improvement |
| > 500ms | ❌ Poor |
INP高的原因:
- 重JavaScript阻塞Main thread
- 太多event listeners
- 慢的Third-party scripts(Analytics、Chat widget)
测试Core Web Vitals——免费工具
- PageSpeed Insights —— 单页快速测试
- Web.dev Measure —— 网页版Lighthouse
- Chrome DevTools Lighthouse —— Local测试
- CrUX Report —— Chrome真实用户数据
- Google Search Console → Core Web Vitals tab —— 您网站的真实Performance
以GSC真实数据为主,因为这是Google用于排名的数据。
修复Core Web Vitals——按优先级
优先级1:图片优化(修LCP)
这是最易做且影响最大的。
用WebP/AVIF:
- JPEG 2MB → WebP 200KB(减少90%)
- AVIF 100KB(减少95%)
指定width/height:
<img src="hero.webp" width="1200" height="630" alt="...">非Hero图片懒加载:
<img src="..." loading="lazy" alt="...">通过CDN使用现代图片格式:
- Cloudflare Image/Imgix/Cloudinary
优先级2:减少JavaScript(修LCP+INP)
减少Third-party scripts:
- 每个工具(Hotjar、Intercom、Chat widget)都是Performance的”税”
- 只用真正必要的
Defer非关键JS:
<script src="..." defer></script>Code Splitting(现代Stack):
- Next.js/Astro自动做
- WordPress需要装Plugin
优先级3:Server响应(修LCP)
目标TTFB < 600ms:
- 升级Hosting(Shared → VPS/Cloud)
- 用CDN(Cloudflare、CloudFront、Fastly)
- 启用Caching(Page cache+Object cache)
WordPress:
- 用Cloudflare APO+WP Rocket
- 服务器级cache(Nginx FastCGI)
现代Stack(Astro/Next.js):
- Static-generated或ISR
- 部署在Edge(Cloudflare Workers、Vercel Edge)
优先级4:预留空间(修CLS)
所有Image/Video/iframe都指定width/height
为Ads预留空间:
.ad-slot {
min-height: 250px; /* 提前知道ads尺寸 */
}避免Web Font Layout Shift:
- 用
font-display: optional或swap - 预加载关键字体
优先级5:优化Third-party(修INP)
把重Script移到Web Worker:
- Partytown library(Astro有集成)
替换重型widget:
- Disqus → Giscus(更轻,基于GitHub)
- Intercom → 开源替代
哪种网站更难修
WordPress+Page Builder(最难)
- Elementor/Divi/WPBakery加载重JS
- Plugin Hell —— 每个plugin都加JS
- 通常只能做到PageSpeed Mobile 75-85
- 真正解决方案: 换Theme+减Plugin,或迁移到现代Stack
延伸阅读:WordPress速度优化
Custom WordPress Theme(中等)
- 看Theme+Cache plugin
- 能做到85-90+
- 需要Code级优化
现代Stack:Astro/Next.js(最简单)
- 首日PageSpeed 90+(默认)
- 无需装Plugin
- Static-first架构
延伸阅读:WordPress vs Astro
真实案例 普吉酒店
卡伦的一家酒店,2024:
- 优化前: Mobile 42、LCP 5.8s、CLS 0.34
- WordPress → Astro迁移: Mobile 96、LCP 1.4s、CLS 0.02(3周工作)
- 结果: 迁移后前60天,Direct Booking转化率提升28%
修复Core Web Vitals——30天路线图
第1周: Audit(用PageSpeed+GSC Core Web Vitals tab) 第2周: 图片优化(全部转WebP、加width/height) 第3周: JS优化(Defer非关键、移除未使用) 第4周: Hosting+Cache(必要时升级)
30天后,预期PageSpeed Mobile提升15-25分。
申请Performance Audit
如果您的网站PageSpeed Mobile < 60且排名差,申请Audit —— 我们做benchmark+Action Plan。
或如果决定要迁移到现代Stack,请看Web Development。