针对低端设备优化 Core Web Vitals

为什么在低端硬件上构建快速网站需要比大多数团队承认的更尖锐的权衡

Arjen Karel - linkedin

Last update: 2026-02-07

针对低端设备优化 Core Web Vitals

Core Web Vitals 应该是衡量网站质量的客观基准的一部分。但实际上并非如此！这些指标与用户使用的设备紧密相关。如果一个企业销售高端产品或服务，其客户往往拥有快速的手机、台式机和可靠的网络连接。
与之形成对比的是面向注重成本的消费者或新兴市场的企业。他们的受众依赖老旧的手机、性能较弱的处理器或较差的网络条件。
同一个网站在旗舰 iPhone 上轻松通过测试，却在中端 Android 设备或低带宽连接的国家难以正常加载。本文探讨如何针对低端设备优化 Core Web Vitals。

第一步：生成客户端能力评分

为了评估访问者使用的是高端还是低端设备，可以直接在浏览器中计算客户端能力评分。该评分范围从 0（极度受限）到 100（顶级硬件）。在实际应用中，任何评分低于 40 的设备应被归类为较差。

client capability score coredash lcp

下面的函数使用与真实 RUM 和 Google Core Web Vitals 数据高度相关的硬件和网络指标来计算客户端能力评分。更高的分数表明设备更有能力以更少的资源限制提供快速的页面性能，并能处理更流畅的交互。

function getClientCapabilityScore() {
  const mem = navigator.deviceMemory || 4;
  let cpu = navigator.hardwareConcurrency || 4;
  cpu = Math.min(cpu, 8);

  let net = 4;
  if (navigator.connection) {
    const { effectiveType, rtt = 300 } = navigator.connection;
    const map = { 'slow-2g': 1, '2g': 2, '3g': 3, '4g': 4, '5g': 5 };
    net = map[effectiveType] || 4;
    if (rtt > 500) net = Math.max(net - 3, 1);
    else if (rtt > 300) net = Math.max(net - 2, 1);
    else if (rtt < 150) net = Math.min(net + 1, 5);
  }

  const score = mem + cpu * 0.5 + net * 2;
  return Math.min(100, Math.round(score * 5));
}

getClientCapabilityScore();

Core Web Vitals 提示： 这些优化对所有人都有帮助。但如果有人使用慢速连接或内存有限的设备，它们的作用就更加重要。跳过这些优化的负面影响会更快显现。
以图片下载为例。在正常连接下，它们通常占 Largest Contentful Paint 时间的约 10%。在慢速连接下，这个比例很容易翻倍。这就是为什么我们不会将图片优化放在大多数用户优先列表的首位，但在面对低带宽或内存受限的访问者时，它很快成为优先事项。

启用 HTTP/3、QUIC 和 0-RTT

距离服务器较远或处于慢速网络的访问者面临较高的往返时间（RTT）。HTTP/3 与 QUIC 和 0-RTT 直接提升了初始连接速度。这对所有访问者都是重要的优化，但对低带宽访问者尤为关键。

更快的连接建立：QUIC 将传输和加密握手合并为一步。0-RTT 更进一步：回访者可以立即发送数据，完全绕过握手过程。
回访用户更低的延迟：0-RTT 允许客户端恢复会话并即时发送请求。节省数百毫秒——对远距离或移动用户尤其有价值。
长距离传输的弹性：HTTP/3（基于 UDP）避开了 TCP 的队头阻塞。QUIC 更优雅地处理丢包和不稳定网络——非常适合跨大陆或不稳定的移动连接。

比设计师期望的更激进地压缩图片

高分辨率图片会拖慢 LCP（Largest Contentful Paint），尤其是在 GPU 解压能力有限的设备上。与其迁就美学，不如追求更小但视觉上可接受的图片。WebP 和 AVIF 有所帮助，但懒加载和提供响应式尺寸更为重要。

一个简单的规则：低端设备上的首屏大图应控制在 100KB 以下。如果设计师反对，让他们先在一台 100 欧元的 Android 手机上测试同一网站再争论。

将 CSS 精简到最低必要限度

在样式方面只有一条规则：大扫除。移除未使用的选择器，降低特异性，合并冗余规则。

专注于可预测、一致的布局，尽量减少覆盖。使用少量工具类而非复杂的组件专用样式。这既有助于浏览器的 CSSOM 构建，也有利于开发者维护。

对于首屏内容，仅内联绝对必要的样式。其余部分懒加载，但保持拆分最小化且清晰。避免使用猜测 "critical CSS" 的工具，手动精确定义。

对脚本要毫不留情

任何脚本都不应阻塞渲染：确保所有非必要脚本都是非阻塞的。在 <script> 标签上使用 async 或 defer 属性。如果脚本对初始页面加载或用户交互不是必需的，就不能是同步的。否则，你只是在浪费宝贵的毫秒。
调度非关键脚本 不需要立即执行的脚本应该被调度。但不要随意加载。使用 requestIdleCallback 函数在浏览器空闲时触发脚本。这样可以卸载繁重任务而不干扰关键渲染路径。
使用客户端能力评分有选择地加载锦上添花的脚本：客户端能力评分不仅是一个指标，更是优化 user experience 的工具。在低端设备上，减少加载的脚本数量并选择更轻量的替代方案。如果用户内存有限或 CPU 较旧，不要浪费资源加载重量级脚本。优先考虑性能，而非那些在高端设备上可能令人印象深刻但在低端设备上令人沮丧的花哨功能。