网站速度和核心网页指标：完整指南

核心网页指标的简单解释

让我们从基本要素开始。核心网页指标是谷歌用来衡量页面在真实用户（而非机器人）眼中实际加载情况的三个指标。它们回答三个简单的问题：主要内容是否快速出现，网站对您的操作反应是否迅速，以及布局在您的手指下是否保持不变。

LCP — 主要内容显示的速度

LCP（最大内容绘制）是最大可见元素完成渲染的时刻：通常是一个主图像、一个标题或一个大型横幅。当该块出现时，访客认为页面已加载，而不是最后一个页脚脚本到达时。到2026年，一个合理的目标是在典型的移动连接上大约为2.5秒。

INP — 网站响应的速度

INP（交互到下一个绘制）替换了旧的 FID 并测量响应速度：你点击一个按钮，打开一个菜单，开始输入——在界面明显反应之前经过多少毫秒。如果点击后半秒内没有任何反应，大脑会认为网站卡住了。一个舒适的范围是200毫秒以内。

CLS — 布局的稳定性

CLS（累积布局偏移）捕捉到最烦人的错误：你瞄准一个按钮，一个图像或横幅在其上方加载，所有内容都向下跳动，你点击了错误的东西。这是布局的累积偏移，越接近零，网站感觉越整洁。一个健康的值是0.1以下。

记住一个简单的公式：LCP 是关于可见，INP 是关于点击，CLS 是关于不跳动。谷歌从真实的 Chrome 用户那里收集这三项数据，并将其视为页面质量信号的一部分，用于排名。

为什么速度影响SEO和转化率

让我们直言不讳：一个慢的网站在门口就失去了金钱，在访客阅读任何单词之前。每多等一秒，关闭标签页并转向瞬间打开的竞争对手的人数就会增加。

速度和搜索排名

核心网页指标是一个官方排名因素。这并不意味着一个快速但空白的页面会胜过一个缓慢但专业的页面：内容仍然是第一位的。但是当两个页面的质量接近时，速度就成为决定胜负的因素，使你更高。一个快速的网站也会被更彻底地抓取——在相同的抓取预算下，机器人能访问到更多的页面。

速度和金钱

在商业项目中，链接之间的关系网站速度和收入显而易见。加快首屏加载速度明显提升了结账和表单转化率，降低了你的获取成本（你不再在加载屏幕上失去一半的付费流量），并增加了用户的浏览深度。我们在我们的开发和优化工作中反复看到这一点：技术性能的回报比另一场广告活动更快。

还有一个声誉层面。一个反应迟钝的网站在潜意识中被解读为不可靠：如果这里的一切都卡顿，我能信任它处理我的支付吗？速度是你品牌的第一次握手，它应该给人以信心。

如何测量速度：实验室与现场

在你修复任何问题之前，诚实地进行测量。在这里，区分两种根本不同的数据是至关重要的，因为人们常常混淆它们。

实验室数据

实验室测量是在受控条件下由工具进行的：固定连接、定义的设备、干净的环境。这是Lighthouse（内置于 Chrome DevTools 中）和PageSpeed Insights的实验室部分。好处是可重复性：你更改代码后可以立即看到是否有所改善。缺点是这是一种模拟，而不是生活中的人。

现场数据

现场数据是从真实的 Chrome 用户（CrUX 数据集）收集的指标。这些正是 Google 用于排名的依据。它们显示了网站在真实设备、真实网络和真实地理位置上的表现。现场数据是在第 75 个百分位数测量的：目标是网站在速度上不仅仅是平均水平，而是要满足四分之三的受众。

一个实用的测量顺序

1. 通过 PageSpeed Insights 分别对移动端和桌面端运行您的关键模板（主页、类别、产品、表单）。
2. 如果存在，首先查看核心网页指标；使用实验室分数作为调试工具。
3. 在 DevTools 中打开性能选项卡，找出哪个元素驱动 LCP，以及哪些脚本阻塞主线程。

黄金法则：按字段优化，按实验室调试。追求 Lighthouse 中的漂亮分数而不考虑真实用户的体验，是为了截图而做的工作，而不是为了业务。

LCP：它涵盖的内容及如何改善

LCP通常是人们所说的网站加载时间很长的意思。改善它意味着更早地显示主要的首屏元素。让我们将其分解为几个部分。

LCP由什么组成

LCP有四个成分：服务器响应时间（TTFB）、资源开始加载前的延迟、资源本身的加载时间和渲染时间。它们中的任何一个都可能成为瓶颈，因此处理应从诊断开始，而不是猜测。

实际上加速LCP的因素

• 快速的服务器响应。保持TTFB低：服务器端缓存、适当的托管和生成第一个屏幕时尽量少进行重的数据库查询。
• 主要资源的优先级。LCP图像或标题字体应以高优先级加载（预加载），而不是在一般队列中。
• 第一个屏幕不使用懒加载。一个经典的错误是在顶部横幅上使用懒加载。将懒加载留给折叠以下的内容。
• 一个轻量、适当压缩的LCP元素。一个巨大的 2 MB PNG 英雄即使在快速服务器上也会破坏指标。

关于渲染阻塞的一点说明。如果浏览器必须在显示第一个屏幕之前下载并运行大量的 CSS 和 JavaScript，LCP 就会被延迟正好那么长的时间。这就是为什么关键 CSS 是内联的，而次要脚本被推迟和延后的原因。

INP 和 CLS：响应性和稳定性

如果 LCP 是关于可见性的，那么 INP 和 CLS 则是关于加载后的质量感知。它们常常被低估，这是一个错误：它们正是让网站感觉精心构建的原因。

如何改善 INP

糟糕的 INP 几乎总是意味着浏览器的主线程正忙于处理大量的 JavaScript。用户点击——但此时线程正在处理分析、驱动滑块或渲染小部件，反应被延迟。有什么帮助：

• 将长任务拆分为短任务，给浏览器暂停的机会来处理点击。
• 移除或延迟在后台运行的第三方脚本。
• 避免在每次移动和击键时使用重型处理程序。
• 将可选计算移出交互时刻。

如何消除布局偏移 (CLS)

CLS 通过标记纪律来解决。主要规则：

1. 始终为图像和视频设置宽度和高度（或纵横比），以便提前保留空间。
2. 为横幅、组件和广告位保留空间，而不是让它们在出现时推挤内容。
3. 加载字体，以便将系统字体替换为自定义字体时不会移动文本（正确的字体显示和后备度量）。
4. 绝不要在用户已经看到的内容上方插入内容 — 只能在其下方插入。

支付和表单是一个特殊的痛点。在我们的Payora 支付服务项目中，我们特别关注首屏稳定性：当涉及到金钱时，跳动的布局和缓慢的按钮响应会直接降低信任度和完成交易的数量。

网站速度慢的主要原因

好消息：缓慢的网站有很少的原因，而且它们出奇地典型。在十个案例中，有九个是这个列表上的某个原因造成的。

重型图像

页面大小的绝对重型。全分辨率照片，多兆字节的PNG截图，浏览器缩小到小尺寸但下载完整的图像。通常图像也是LCP元素，因此这是双重打击。

字体

几种重型格式的不同字重，从外部域加载，没有预加载——文本要么闪烁，要么出现得很晚，导致布局错位。

阻塞的CSS和JavaScript

必须在首次绘制之前下载和执行的巨大包。重型框架尤其浪费，而几行代码就能解决的问题。

第三方脚本

聊天、像素、十几个分析标签、社交小部件、A/B测试。每个单独来看都很轻，但加在一起会占用主线程并破坏INP。这是最被低估的类别。

慢速托管和高TTFB

如果服务器在回答之前思考了一秒钟，那么前端的魔法也无法完全掩盖这一点。廉价的过载主机、没有服务器缓存、繁重的数据库查询——所有这些都是LCP的根本原因。

实际的收获是：不要急于一次性修复所有问题。先进行测量，找出主要的损失来源——然后集中解决。

图像优化：格式和延迟加载

由于图像是重量级的，速度优化几乎总是从这里开始。这是风险最低、最明显的快速胜利。

现代格式

转向WebP，并在可能的情况下转向AVIF。在相同质量下，它们的体积明显小于经典的JPEG和PNG。对于图标和简单图形，使用SVG它是矢量的，无重量的，并且在任何屏幕上都非常清晰。

正确的尺寸和响应性

永远不要提供比实际显示更宽的图像。准备几种尺寸并通过 srcset 进行连接，以便手机获取紧凑版本，桌面获取大版本。在 800 像素的容器中放置 4000 像素的主图像是浪费的兆字节和时间。

懒加载——但要明智

• 添加loading="lazy"对第一屏幕以下的图像进行懒加载，以便它们不会干扰初始绘制。
• 但要立即并优先加载第一屏幕的 LCP 图像——懒加载在这里只会造成伤害。
• 始终设置尺寸，以便懒加载不会导致布局偏移（同样的 CLS）。

不要忘记压缩。通过合适的优化器处理资产通常可以减少 40-70% 的重量，而不会造成明显的质量损失。对于内容网站来说，这些实际上是免费的秒数。

字体、关键 CSS 和多余的 JavaScript

在图像之后，第二重要的区域是浏览器在显示页面之前必须处理的代码。大多数阻塞渲染的问题都隐藏在这里。

字体

• 保持最小的权重数量——两个通常就足够了。
• 使用 woff2 并从您自己的域名提供字体。
• 预加载关键的首屏字体。
• 设置 font-display: swap，这样文本可以立即可读，而不是等待字体加载。

关键 CSS

这个想法很简单：首屏所需的样式直接内联到 HTML 中，其余的 CSS 后续加载。这样浏览器可以在不等待整个样式表的情况下绘制页面顶部。同时剔除无效规则——多年来，网站会积累很多这样的规则。

减少 JavaScript

最诚实的优化是不加载你可以不使用的内容。检查您是否为几个效果引入了一个庞大的框架。延迟加载次要脚本延迟 和 异步，拆分包，并按需加载代码。单独审核第三方小部件：每个聊天、像素和标签都必须证明其在性能预算中的位置。我们在关于多语言网站和SEO.

缓存、CDN、HTTP/2 和托管

的文章中讨论了这如何与多语言网站相适应，而不会使页面臃肿。前端优化如果基础——服务器和交付——速度慢，就会达到瓶颈。这些项目在每个页面上都会带来回报。

缓存

它在两个层面上工作。服务器缓存避免重复生成一个重的页面，并直接降低TTFB。浏览器缓存（静态资源的正确Cache-Control头）意味着在返回访问时，图像、字体和脚本不会再次下载。

CDN

内容分发网络从离用户地理位置最近的服务器提供静态资源。你的受众离源头越远，效果越明显：延迟降低，首字节到达更快。

HTTP/2、HTTP/3和压缩

• 启用现代协议（HTTP/2或HTTP/3）——它更有效地并行加载数十个小文件。
• 在服务器上启用文本资源的压缩（Brotli 或 gzip）。
• 压缩 HTML、CSS 和 JS，去除空格和注释。

托管和 TTFB

一个合适的服务器不是奢侈品，而是基本要求。在繁忙的 24freelance 市场项目中，我们正好遇到了服务器层面的问题：没有缓存和查询优化，首字节加载缓慢，直到我们整理好后端，图像工作才达到了目标数字。

移动设备上的速度

2026年的一个重要真相：谷歌主要通过你的网站移动版本来评估你的网站，大部分流量来自手机。而手机意味着处理器较弱、网络不稳定，以及用户的耐心更少。

为什么移动端更苛刻

在强大的笔记本电脑上瞬间运行的内容，在普通智能手机上需要花费几倍的时间。重型 JavaScript 在移动端对 INP 的影响尤其严重，正是因为处理器较弱，每个任务的处理时间更长。

该怎么办

• 在受限设备和慢速网络模拟下进行测试，而不仅仅是在你的旗舰设备上。
• 确保控件足够大，并提前预留空间，以避免意外点击和移动。
• 特别要削减第三方脚本——它们在移动设备上的成本高出几倍。
• 提供移动尺寸的图像，而不是被浏览器缩小的桌面图像。

好消息是：如果一个网站在普通手机上通过一般网络运行良好，它在桌面上几乎肯定会很快。因此，要针对最糟糕的现实场景进行优化，而不是针对你的工作显示器。

监控和持续控制

速度不是一次性的项目，而是一种卫生状态。一个网站是活的：内容不断添加，新小部件和横幅到来，代码被更新——而性能悄然下降。没有监控，你只能通过销售下降来发现问题，而不是通过报告。

如何保持对脉搏的关注

• 定期在Google Search Console中检查现场核心网络指标——它显示了你受众的真实趋势。
• 设置关键模板的自动检查，以便在发布后立即捕捉回归，而不是一个月后。
• 设定一个性能预算——页面重量和脚本数量的上限，团队不得超过。
• 将每个新的第三方脚本视为一个单独的决策：它为业务带来了什么，以及在速度上花费了多少。

谁来监督它

实际上，指定一个人负责速度是有帮助的——否则这个指标就会变成无人负责，首先下滑。如果团队中没有这样的人，可以将这个角色外包：例如，我们提供定期审计和性能支持，这最容易安排通过我们的联系表单.

核心思想：在每次重大变更前后进行测量。声称事情变得更快应该得到证明，而不仅仅是感觉。

实用的网站速度检查清单

让我们将所有内容汇集成一个应用列表。逐项处理——这些项目大致按效益与努力的比率排序。您不必一次性完成所有，但每一点都值得审查。

测量和优先排序

1. 在 PageSpeed Insights（移动和桌面）中测量您的关键模板，并记录当前的核心网页指标。
2. 找到每个重要模板的 LCP 元素及其主要瓶颈。

图片

1. 将图片转换为 WebP 或 AVIF，将图标转换为 SVG。
2. 通过 srcset 提供响应式尺寸，永远不要大于容器。
3. 在第一个屏幕下启用懒加载；优先加载 LCP 图片。
4. 设置图片尺寸，以避免布局偏移。

代码和字体

1. 内联关键 CSS，稍后加载其余部分。
2. 减少字体粗细，添加预加载和 font-display: swap。
3. 使用 defer/async 延迟脚本，并删除未使用的 CSS 和 JS。
4. 审核第三方小部件，删除任何多余的内容。

服务器和交付

1. 启用服务器缓存并降低 TTFB。
2. 设置静态资源的浏览器缓存和 Brotli/gzip 压缩。
3. 添加 CDN 和现代协议，HTTP/2 或 HTTP/3。
4. 压缩 HTML、CSS 和 JS。

控制

1. 在限制的移动设备仿真上验证结果。
2. 设置字段指标监控和性能预算。
3. 重新测量前后 — 用数字记录胜利。

诚实地完成这个检查清单，你将不仅获得一个漂亮的分数，还能拥有一个更快、更稳定和更有利可图的网站。最终，这才是关键。

常见问题