页面速度优化:完整指南
· 16分钟阅读
页面速度不再是可有可无的 — 它是谷歌算法中的直接排名因素,也是您可以为SEO和用户体验拉动的最具影响力的杠杆之一。根据Akamai和谷歌的研究,页面加载时间延迟一秒可能会使转化率降低7%,跳出率增加11%,页面浏览量减少11%。到2026年,随着核心网页指标牢固地嵌入谷歌的排名系统,优化页面速度对于任何想要在自然搜索中竞争的网站都是必不可少的。
本指南涵盖了您需要了解的关于页面速度优化的所有内容 — 从理解谷歌关心的指标到实施能够带来可衡量改进的具体技术修复。无论您是在处理小型博客还是大型电子商务平台,这些技术都将帮助您构建更快、性能更好的网站。在深入研究之前,使用我们的页面速度检查器来基准测试您当前的性能。
1. 为什么页面速度对SEO很重要
自2010年以来,谷歌一直将页面速度作为桌面端的排名信号,自2018年以来用于移动端("速度更新")。2021年,页面体验更新使核心网页指标成为官方排名因素。到2026年,页面体验信号 — 包括速度 — 已深度整合到谷歌评估和排名页面的方式中。
数据很清楚。谷歌自己的研究表明,当页面加载时间从1秒增加到3秒时,跳出的概率增加32%。当加载时间从1秒增加到5秒时,跳出概率增加90%。对于电子商务网站,亚马逊发现每100毫秒的延迟会使他们损失1%的销售额。沃尔玛报告称,页面加载时间每提高1秒,转化率就会增加2%。
除了排名之外,页面速度还会影响抓取预算。谷歌机器人在您的网站上花费的时间是有限的。更快的页面意味着谷歌可以在相同的时间窗口内抓取更多内容,这对于拥有数千个页面的大型网站至关重要。您可以使用我们的页面体验检查器检查您的整体页面体验。
速度还直接影响核心网页指标分数,这些分数显示在谷歌搜索控制台中,并影响您获得丰富结果和热门故事位置的资格。通过所有三个核心网页指标阈值的网站会获得排名提升 — 虽然很小但真实存在,在竞争激烈的领域,每一个优势都很重要。
2. 理解核心网页指标
核心网页指标是谷歌用来测量页面上真实用户体验的三个特定指标。截至2024年,谷歌用交互到下次绘制(INP)取代了首次输入延迟(FID),使当前的核心网页指标集为:LCP、INP和CLS。使用我们的核心网页指标检查器测试您的指标。
最大内容绘制(LCP)
LCP测量最大可见内容元素在屏幕上渲染所需的时间。这通常是主图、大文本块或视频海报。LCP反映了用户对页面主要内容何时加载完成的感知。
- 良好: ≤ 2.5秒
- 需要改进: 2.5 – 4.0秒
- 差: > 4.0秒
LCP差的常见原因包括服务器响应时间慢、阻塞渲染的CSS和JavaScript、图片或字体的资源加载时间慢,以及延迟内容可见性的客户端渲染。
交互到下次绘制(INP)
INP于2024年3月取代了FID,测量页面在整个生命周期内对用户交互的整体响应性 — 而不仅仅是第一次交互。INP观察所有点击、轻触和键盘交互的延迟,并报告几乎所有交互都低于的值。
- 良好: ≤ 200毫秒
- 需要改进: 200 – 500毫秒
- 差: > 500毫秒
INP差通常是由阻塞主线程的长JavaScript任务、过大的DOM大小、繁重的事件处理程序以及循环读写DOM属性的JavaScript导致的布局抖动引起的。
累积布局偏移(CLS)
CLS测量视觉稳定性 — 页面在加载期间意外移动布局的程度。每当可见元素在没有用户交互的情况下改变位置时,都算作布局偏移。CLS汇总最大的布局偏移分数突发。
- 良好: ≤ 0.1
- 需要改进: 0.1 – 0.25
- 差: > 0.25
布局偏移通常由没有尺寸的图片、动态注入的内容(广告、嵌入)、导致FOIT/FOUT的网络字体以及重新定位元素的延迟加载CSS引起。
3. 如何测量页面速度
在优化之前,您需要准确的测量。性能数据有两类:实验室数据(在受控环境中运行的合成测试)和现场数据(从实际访问者收集的真实用户测量)。两者都很有价值,但谷歌使用Chrome用户体验报告(CrUX)中的现场数据进行排名。使用我们的页面加载计时器测量您的加载时间。
PageSpeed Insights
谷歌的PageSpeed Insights(PSI)是大多数开发人员的首选工具。它提供实验室数据(由Lighthouse提供支持)和现场数据(来自CrUX)。PSI为您提供0到100的分数以及具体的改进建议。现场数据部分显示了过去28天内真实Chrome用户体验的实际核心网页指标。
Lighthouse
Lighthouse在Chrome DevTools(审计选项卡)、CLI工具或Node模块中运行。它模拟在受限4G连接上的中端移动设备,并提供详细的性能审计。从命令行运行它以进行CI集成:
npx lighthouse https://example.com --output=json --output-path=./report.json --chrome-flags="--headless"
WebPageTest
WebPageTest提供最详细的瀑布分析。您可以从全球多个位置、在真实设备上、以各种连接速度进行测试。胶片视图显示用户在页面加载期间每个时间点看到的确切内容。"机会与实验"功能甚至可以在您实施之前测试优化。
Chrome DevTools性能面板
对于深度调试,Chrome DevTools中的性能面板记录页面加载期间发生的所有事情的时间线。您可以准确看到哪些脚本阻塞渲染、哪些布局偏移发生以及长任务在哪里消耗主线程。使用覆盖率选项卡查找未使用的CSS和JavaScript。
现场数据与实验室数据
实验室数据是可重现的,非常适合调试,但它不能捕获全部真实世界条件。现场数据反映了不同设备、网络和地理位置的实际用户体验。始终优先考虑现场数据以了解您的真实性能,并使用实验室数据诊断特定问题。使用我们的页面大小分析器检查您的页面大小和资源分解。
4. 图片优化
图片通常占页面总重量的40-60%。优化图片通常是您可以为页面速度做出的影响最大的单一更改。使用我们的图片SEO检查器审核您的图片优化。
现代图片格式:WebP和AVIF
WebP在同等质量下提供比JPEG小25-35%的文件大小。AVIF更进一步,在许多情况下比JPEG节省50%。两种格式都支持透明度(替代PNG)和动画(替代GIF)。使用<picture>元素进行格式回退:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="主图描述"
width="1200" height="600" loading="eager"
fetchpriority="high">
</picture>
使用srcset的响应式图片
向375px宽的移动屏幕提供2000px宽的图片会浪费带宽。使用srcset和sizes让浏览器选择正确的图片大小:
<img src="product-800.webp"
srcset="product-400.webp 400w,
product-800.webp 800w,
product-1200.webp 1200w,
product-1600.webp 1600w"
sizes="(max-width: 600px) 100vw,
(max-width: 1200px) 50vw,
800px"
alt="产品照片"
width="800" height="600"
loading="lazy">
延迟加载
使用loading="lazy"的原生延迟加载会推迟屏幕外图片的加载,直到用户滚动到附近。这在所有现代浏览器中都受支持,不需要JavaScript。关键的首屏图片应使用loading="eager"(默认值)和fetchpriority="high"以确保它们尽快加载。
图片压缩
在提供图片之前始终压缩它们。Sharp(Node.js)、Squoosh或ImageMagick等工具可以在构建管道中自动执行此操作。一个实用的构建脚本:
# 使用Sharp CLI转换和压缩图片
npx sharp-cli --input ./src/images/*.{jpg,png} \
--output ./dist/images/ \
--format webp \
--quality 80 \
--resize 1600
特别是对于LCP图片,始终设置明确的width和height属性以防止布局偏移,使用fetchpriority="high",并考虑在完整图片加载时内联低质量占位符(LQIP)作为base64数据URI。
5. CSS和JavaScript优化
阻塞渲染的资源是页面加载缓慢的最常见原因之一。浏览器在解析完<head>中的所有阻塞CSS并执行完所有阻塞JavaScript之前无法渲染内容。
关键CSS
提取渲染首屏内容所需的CSS并直接内联到<head>中。异步加载其余CSS。这消除了初始绘制的阻塞渲染CSS请求:
<head>
<!-- 内联关键CSS -->
<style>
/* 仅首屏内容所需的样式 */
body { margin: 0; font-family: system-ui, sans-serif; }
.header { background: #1a1a2e; color: #fff; padding: 1rem; }
.hero { padding: 4rem 2rem; text-align: center; }
.hero h1 { font-size: 2.5rem; margin: 0 0 1rem; }
</style>
<!-- 异步加载完整CSS -->
<link rel="preload" href="/css/style.css" as="style"
onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/style.css"></noscript>
</head>
critical(npm包)或PurgeCSS等工具可以自动提取关键CSS和删除未使用的CSS。
JavaScript:defer、async和代码拆分
<head>中没有defer或async的脚本会阻塞HTML解析。对需要DOM的脚本使用defer(它们在解析后按顺序执行)。对独立脚本(如分析)使用async(它们在下载完成后立即执行,顺序不定):
<!-- 阻塞解析 - 避免这样做 -->
<script src="/js/app.js"></script>
<!-- 延迟 - HTML解析后按顺序执行 -->
<script defer src="/js/app.js"></script>
<!-- 异步 - 准备好时执行,不保证顺序 -->
<script async src="/js/analytics.js"></script>
树摇和压缩
Webpack、Rollup和esbuild等现代打包工具可以消除未使用的代码(树摇)并压缩输出。典型的esbuild生产配置:
// esbuild.config.js
import { build } from 'esbuild';
await build({
entryPoints: ['src/index.js'],
bundle: true,
minify: true,
treeShaking: true,
splitting: true,
format: 'esm',
outdir: 'dist',
target: ['es2020'],
sourcemap: true,
});
代码拆分将您的JavaScript分解为按需加载的较小块。基于路由的拆分是最常见的方法 — 每个页面只加载它需要的JavaScript。这可以将大型应用程序的初始包大小减少60-80%。
6. 服务器端优化
您的服务器响应时间(首字节时间,或TTFB)为所有其他性能指标设定了底线。如果您的服务器需要2秒才能响应,您的LCP不可能低于2.5秒。使用我们的HTTP标头检查器检查您的服务器标头。
降低TTFB
良好的TTFB对于缓存内容应低于200毫秒,对于动态内容应低于600毫秒。TTFB高的常见原因包括数据库查询慢、应用程序代码未优化