新兴市场网站性能优化：超越灯塔评分的实战指南

新兴市场网站性能优化：超越灯塔评分的实战指南 | 前端进阶之旅

Full translation

完整中文译文

在办公室的光纤网络上测试网站，拿到 95+ 的 Lighthouse 分数，然后宣布性能优化“已经完成”，这很容易。可当某位身处二线城市的用户提到，网站在他的手机上感觉很慢时，测试性能与真实性能之间的差距就暴露无遗了。

理论上，这并不是一个只存在于巴基斯坦的问题，但在实际中，这种情况在这里尤为常见——很大一部分真实用户使用的是拥塞的 3G 网络或被限速的 4G 网络，设备通常是中端 Android 手机，而且往往身处主要大都市以外的地区，那里的基础设施并没有那么完善。如果你的产品面向巴基斯坦用户，或者更广泛地说，面向新兴市场用户，那么“在办公室里运行得很好”并不等于“对真实用户来说运行得很好”。

下面这些方法才是真正能带来显著改善的，而不仅仅是接入一个 CDN。

CDN 有帮助，但解决不了最后一公里问题

CDN 可以让资源在物理距离上更接近用户，这确实有所帮助。但如果用户手机与最近边缘节点之间的连接仍然是一条拥塞的 3G 链路，那么 CDN 的任务基本上已经完成了——真正的瓶颈在最后一公里，无论做多少边缘缓存都无法解决。真正有效的办法，是从一开始就减少需要通过最后一公里传输的数据量。

这也重新定义了整个问题：重点不再是“怎样更快地把字节传过去”，而是“怎样发送更少的字节”。

1. 图片体积通常是最大的罪魁祸首

图片通常是页面体积最大的单一组成部分，而解决办法并不复杂：

// Next.js example — explicit width/height prevents layout shift,
// and the Image component serves modern formats automatically
import Image from "next/image";

<Image
  src="/hero.jpg"
  alt="Product hero shot"
  width={1200}
  height={630}
  priority // only for above-the-fold images
/>

下面是一些具体且能积少成多的习惯：

在条件允许时使用 WebP/AVIF，而不是原始 JPEG/PNG——在视觉质量相当的情况下，体积通常可以减少 25%～50%。
始终设置明确的 width/height，或者使用能代你处理这些属性的框架组件。这样浏览器就不会在图片加载时移动页面布局——这也会直接影响 Cumulative Layout Shift 分数。
对首屏以下的所有图片进行懒加载。没必要浪费带宽去加载访客可能永远不会滚动到的图片。

在一次电商网站重构中，仅仅优化图片处理流程，包括格式、懒加载和明确尺寸，就让页面总体积减少了大约三分之一——完全没有改动设计。

2. 像审计成本一样审计每一个第三方脚本（因为它们确实在消耗成本）

每一个第三方脚本——聊天组件、分析工具、营销 pixel、嵌入式社交组件——都会增加客户端解析与执行所需的时间。相比开发者的笔记本电脑，这些开销在低端设备上会被显著放大。一个在光纤网络和 Chrome DevTools 中“感觉瞬间完成”的脚本，到了通过 3G 上网的入门级 Android 手机上，就可能明显阻塞页面交互。

一个简单的审计习惯是：打开 Network 面板，按 JS 过滤，再按文件大小排序。对于任何你无法立即说清用途的脚本，都应该问问它带来的价值是否真的配得上它的成本。能延迟加载的就延迟加载：

<!-- Bad: blocks parsing immediately -->
<script src="https://widget.example.com/embed.js"></script>

<!-- Better: doesn't block initial render -->
<script src="https://widget.example.com/embed.js" defer></script>

对于真正非关键的内容——大多数聊天组件和大多数营销 pixel 都属于这一类——等主要内容可以交互之后再加载，而不是把它们放进关键路径，通常是你能做出的、收益最高的单项 JS 优化。

3. 自托管字体

从第三方 CDN 加载字体——最常见的例子是 Google Fonts 的默认嵌入方式——意味着在任何一个字体文件开始下载之前，都要额外进行一次 DNS 查询和连接往返。自托管字体可以彻底省去这一跳：

// Example using @fontsource (self-hosted font packages)
import "@fontsource/inter/400.css";
import "@fontsource/inter/600.css";

再配合 font-display: swap，让文本立即使用后备字体渲染，而不是在自定义字体下载期间保持不可见，从而避免经典的“不可见文本闪烁”问题：

@font-face {
  font-family: "Inter";
  src: url("/fonts/inter.woff2") format("woff2");
  font-display: swap;
}

这是一个很小的改动，却能在慢速网络下持续带来可测量的 Largest Contentful Paint 改善。

4. 在限速网络上测量，而不只是在光纤网络上测试

Chrome DevTools 内置了网络限速选项——Network 面板中的 “Slow 3G” 和 “Fast 3G” 预设——但真正使用它的人少得出奇。与其相信基于高速网络生成的 Lighthouse 分数，不如在模拟 3G 环境下测试实际构建产物，这能暴露实验室分数可能掩盖的问题。

PageSpeed Insights 的 “Field Data” 部分在有数据可用时更加实用——它基于真实访客产生的 Chrome User Experience Report 数据，而不是一次合成的实验室测试。

这些方法一点也不新奇——重点恰恰在这里

上面的做法没有一个是什么巧妙的黑科技。归根结底，它们主要是在约束页面中添加了什么，以及这些内容何时加载。但正是这种自律，决定了一个网站究竟只是能在实验室测试中拿到高分，还是能让主要大都市以外、通过真实 3G 网络访问的用户也感到流畅——而对于许多在这里开发的产品来说，这些用户构成了真实受众中数量庞大、却很容易被遗忘的一部分。

我经营着 WebTech Solutions，这是一家位于巴基斯坦拉瓦尔品第的 Web 开发工作室——我们的客户遍布巴基斯坦、英国、美国、阿联酋和沙特阿拉伯。上面提到的许多实践，来自我们专门针对低带宽环境进行开发的经验，但它们放到任何地方都同样适用。这里有一个近期的 Next.js 项目案例，在这个项目中，性能从一开始就是刻意设定的优先事项，而不是事后才想起来补救的问题。

如果需要采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。