2017年，我们曾探讨过网页臃肿对慢速连接用户的影响。即便在美国，许多用户也并未拥有宽带速度，导致大量网页难以使用。如今，无论美国内外，仍有众多用户缺乏宽带速度，且现代网页的许多内容对网速慢的人群而言依然不可用。不过，带宽的指数级增长（尼尔森指出高端连接每年增长50%）已超过典型网站的臃肿程度，使得这一问题相比2017年有所缓解——尽管对网络条件差的用户而言，这仍是一个严峻挑战。

Web应用的CPU性能提升远不及带宽增速。因此，虽然更多网页对低端连接用户变得可访问，但更多网页却对低端设备用户（即便拥有高端连接）变得不可访问。例如，若尝试用Tecno Spark 8C浏览基于“现代”Discourse的论坛，浏览器有时会崩溃。在崩溃间隙测量性能时，其响应速度甚至不如用8 MHz 286处理器和1200 baud调制解调器浏览BBS。在我1Gbps的家庭网络下，加载帖子标题“必需”的2.6 MB压缩数据量相对较轻。网络传输数据量“仅”增加了1000倍，这远不及网速的提升幅度。但CPU性能的情况恰恰相反——对于网页浏览和论坛加载性能，8核（2个1.6 GHz Cortex-A75 / 6个1.6 GHz Cortex-A55）CPU无法处理Discourse。该CPU比我们的286快约100000倍。或许需要快1000000倍的设备才够用。

对于不熟悉Tecno Spark 8C的人而言，如今一台全新的Tecno Spark 8C，快速搜索显示在尼日利亚约需50-60美元，在印度约需100-110美元。占家庭收入中位数的比例，这远超美国当前一代iPhone的价格。

以全球标准衡量，Tecno Spark 8C甚至算不上低端设备，因此我们还将考察Itel P32的性能——这是一款更低端的设备（尽管仍远非当今用户使用的最低端设备）。此外，我们还将测试M3 Max Macbook（14核）、M1 Pro Macbook（8核）以及Chrome开发者工具中设置为10倍节流的M3 Max的性能。为充分发挥这些设备的优势，我们将使用相当高速的网络（1Gbps，搭配负载下延迟低于同类产品的WiFi路由器）。我们将考察一些博客和微博平台（本博客、Substack、Medium、Ghost、Hugo、Tumblr、Mastodon、Twitter、Threads、Bluesky、Patreon）、论坛平台（Discourse、Reddit、Quora、vBulletin、XenForo、phpBB、myBB）以及中小企业常用平台（Wix、Squarespace、Shopify，以及再次提及的WordPress）。

在下表中，每一行代表一个网站，每一列（除标签列外）代表一项指标。在网站名称列之后，我们列出了通过网络传输的压缩后大小（wire）以及未压缩的原始大小（raw）。接着，针对每种设备，我们列出了最大内容绘制*（LCP*）和主线程的CPU使用率（CPU）。Google的文档将LCP解释为：

最大内容绘制（LCP）衡量用户感知到页面最大内容可见的时间。LCP的指标值表示从用户启动页面加载到页面渲染其主要内容之间的时间间隔。

LCP是一个常见的优化目标，因为它被列为Google PageSpeed Insights中的主要指标之一，属于“核心网页指标”。本文档中使用的LCP带有一个星号，因为Chrome测量的LCP关注的是绘制屏幕的大部分区域，而非上述定义中关于内容的部分。随着网站针对LCP进行优化，经常会出现对用户完全无用的较大绘制（更新），而页面的实际内容在LCP之后很久才出现。在这种情况下，我使用了有用内容出现的时间戳，而非根据定义中发生较大但无用更新时的LCP。测试的完整细节以及选择这些指标的原因将在附录中讨论。

尽管CPU时间并非“核心网页指标”，但在此列出是因为它是一个简单的指标，与我和其他用户在慢速设备上对可用性的感知高度相关。关于此点的更详细讨论请参见附录。CPU时间作为指标有效的一个原因是，如果某个页面在所有其他指标上表现优异，但消耗了大量CPU时间，那么该页面在慢速设备上就无法使用。如果CPU占用100%持续30秒，页面将在30秒内完全无法使用；如果CPU占用50%持续60秒，页面将在60秒内几乎无法使用，依此类推。另一个有效原因是，相对于常用指标，CPU时间难以通过优化作弊，在不影响用户体验的情况下显著改变数值。

下表的配色方案为：对于大小，绿色越多表示越小/越快，红色越多表示越大/越慢。极端值以黑色显示。

table {border-collapse:collapse;margin:0px auto;}table,th,td {border: 1px solid black;}td {text-align:center;}td.l {text-align:left;}

站点 大小 M3 Max M1 Pro M3/10 Tecno S8C Itel P32
线路 原始 LCP* CPU LCP* CPU LCP*
danluu.com 6kB 18kB 50ms 20ms 50ms 30ms
HN 11kB 50kB 0.1s 30ms 0.1s 30ms
MyBB 0.1MB 0.3MB 0.3s 0.1s 0.3s 0.1s
phpBB 0.4MB 0.9MB 0.3s 0.1s 0.4s 0.1s
WordPress 1.4MB 1.7MB 0.2s 60ms 0.2s 80ms
WordPress (旧版) 0.3MB 1.0MB 80ms 70ms 90ms 90ms
XenForo 0.3MB 1.0MB 0.4s 0.1s 0.6s 0.2s
Ghost 0.7MB 2.4MB 0.1s 0.2s 0.2s 0.2s
vBulletin 1.2MB 3.4MB 0.5s 0.2s 0.6s 0.3s
Squarespace 1.9MB 7.1MB 0.1s 0.4s 0.2s 0.4s
Mastodon 3.8MB 5.3MB 0.2s 0.3s 0.2s 0.4s
Tumblr 3.5MB 7.1MB 0.7s 0.6s 1.1s 0.7s
Quora 0.6MB 4.9MB 0.7s 1.2s 0.8s 1.3s
Bluesky 4.8MB 10MB 1.0s 0.4s 1.0s 0.5s
Wix 7.0MB 21MB 2.4s 1.1s 2.5s 1.2s
Substack 1.3MB 4.3MB 0.4s 0.5s 0.4s 0.5s
Threads 9.3MB 13MB 1.5s 0.5s 1.6s 0.7s
Twitter 4.7MB 11MB 2.6s 0.9s 2.7s 1.1s
Shopify 3.0MB 5.5MB 0.4s 0.2s 0.4s 0.3s
Discourse 2.6MB 10MB 1.1s 0.5s 1.5s 0.6s
Patreon 4.0MB 13MB 0.6s 1.0s 1.2s 1.2s
Medium 1.2MB 3.3MB 1.4s 0.7s 1.4s 1s
Reddit 1.7MB 5.4MB 0.9s 0.7s 0.9s 0.9s

乍一看，这张表似乎还算合理：那些除非使用超快设备否则会感觉缓慢的网站，在表中确实显示为慢速（即低端设备上 max(LCP*,CPU) 值较高）。当我向人们询问他们认为哪些平台在我们慢速设备上最快和最慢时（Mastodon、Twitter、Threads），他们通常正确预测出 Wordpress 和 Ghost 会比 Substack 和 Medium 更快，而 Discourse 会比 phpBB、XenForo 和 vBulletin 等旧式 PHP 论坛慢得多。我还为这些页面提取了 Google PageSpeed Insights (PSI) 分数（未展示），但这些数字与实际情况的关联性并不强，因为少数网站设法优化了 PSI 分数，却并未真正加快用户访问页面的速度。

如果你从未使用过这样的低端设备，那么总体体验是：许多网站在该设备上无法使用，加载任何资源密集型内容（一个应用或一个大型网站）都可能导致崩溃。在资源密集型应用中执行过于繁重的操作也可能引发崩溃。尽管评测指出，在 Tecno Spark 8C 上可以以不错的性能运行 PUBG 和其他 3D 游戏，但这并不意味着该设备足以流畅阅读现代以文本为中心的社交媒体平台或现代以文本为中心的网页论坛。虽然 PUBG 中能达到 40fps，但在这些网站上滚动时，我们很容易看到低于 0.4fps 的情况。

从表中可以看出，如果你使用慢速设备，有多少网站是无法使用的。所有 10s+ CPU 的页面即使在加载完成后，体验也相当糟糕。滚动非常卡顿，经常掉到每秒几帧，有时甚至远低于此。当我们点击任何链接时，延迟如此之长，以至于我们无法确定点击是否生效。如果再次点击，可能会陷入可怕的情况：第一次点击被注册，导致第二次点击执行了错误操作；但如果等待，又往往等得太久，因为最初的点击实际上并未被注册（或者注册了，但位置并非我们以为的那样）。尽管 MyBB 不提供移动端网站，并且因没有移动友好页面而受到谷歌惩罚，但在这些慢速移动设备上，它实际上比除了最快网站之外的所有网站都更可用，因为滚动和点击确实能正常工作。

我们还能看到不同设备在相对性能上存在巨大差异。例如，对比 M3/10 和 Tecno Spark 8C，在 danluu.com 和 Ghost 上，M3/10 能大致模拟出 Tecno Spark 8C 的表现（尽管 danluu.com 加载速度过快），但在 Medium、Substack 和 Twitter 上，Tecno Spark 8C 的 CPU 性能慢了约三倍，在 Reddit 和 Discourse 上慢了约四倍，而在 Shopify 上则快了超过一个数量级。对于 Wix，CPU 的模拟大致准确，但我们的 Tecno Spark 8C 在 LCP* 上慢了超过三倍。Chrome 能让你方便地在自己的电脑上模拟较慢的设备，这固然很好，但仅启用 Chrome 的 CPU 节流（或使用任何现成的选项组合）所得到的结果，与我们实际在许多真实设备上测得的结果差异相当大。造成这种差异的完整原因超出了本文的讨论范围；就本文而言，只需注意一点：随着设备变慢，慢页面往往以超线性速度变得更慢，而且一个页面的慢速并不能强有力地预测另一个页面的慢速。

如果从以网站为中心而非以设备为中心的角度来看，另一种观察方式是：像 Discourse、Medium 和 Reddit 这样的网站，在我们快速的 M3 和 M1 电脑上并不占用太多 CPU，但它们在我们的 Tecno Spark 8C 上却是最慢的之一（Reddit 的 CPU 显示为 ∞，因为无论我们等待多久且不进行任何交互，Reddit 都占用 约 90% CPU）。Discourse 在稍作交互或仅仅等待一段时间后，有时还会导致浏览器崩溃。例如，有一次，在加载 Discourse、滚动两次，然后让设备静止一两分钟后，浏览器就崩溃了。为了保持一致性，这种情况在表格中并未标记为 FAIL，因为页面确实加载了，但实际上，一个资源消耗如此之大以至于浏览器崩溃的页面，其用户体验远比表格中的任何 FAIL 情况都要糟糕。当我们研究 网络膨胀如何影响慢速连接用户 时，我们发现许多网页对于慢速连接的用户来说根本无法使用，而慢速设备的情况也并无不同。

我们还能看到的另一个模式是，较老的网站总体上比新网站更快，那些（视觉上）看起来十多年未更新的网站往往是最快的。例如，MyBB，这个最不现代化、看起来最古老的论坛，在 M3 上比 Discourse 快 3.6 倍 / 5 倍（LCP* / CPU），但在 Tecno Spark 8C 上，差异达到了 19 倍 / 33 倍，而且考虑到整体的缩放趋势，可以安全地推测，如果 Discourse 能在 Itel P32 这样廉价的设备上运行，这种差异会更大。

另一个例子是WordPress（旧版）与Medium、Substack等更新潮的博客平台。在我们的M3 Max上，WordPress（旧版）比Medium快17.5倍 / 10倍（LCP* / CPU），比Substack快5倍 / 7倍（LCP* / CPU）；而在我们的Tecno Spark 8C上，分别快4倍 / 19倍和20倍 / 8倍。Ghost是个明显的例外，作为现代平台（比Medium晚一年推出），其性能可与旧平台媲美（现代WordPress或许也算例外，但很多人可能仍认为它是旧平台）。在论坛中，NodeBB似乎也稍显例外（详见附录）。

采用部分加载页面再动态加载剩余内容等现代技术的网站（如Discourse、Reddit和Substack），其实际可用性往往低于表格中的评分。虽然原则上可以用简单方式构建此类网站，使其在廉价设备上表现良好，但实践中采用动态加载的网站通常过于复杂，导致低端设备上极其卡顿。通常很难或无法预测滚动距离，这意味着用户有时会因滚动过远而意外触发更多加载，导致页面卡死。许多页面甚至会在滚动时移除已滚过的部分——这类页面基本无法使用。页面搜索等其他基础网页功能也普遍失效。这种动态加载的页面无法依赖简单快速的ctrl/command+F搜索，必须自行构建搜索功能。其效果参差不齐（Google Docs曾表现良好，但过去几个月甚至一年来，加载耗时过长，我不得不刻意等待文档打开后再操作，以免触发浏览器无用的内置搜索；Discourse的搜索在慢速设备上从未真正好用，甚至在不算慢的设备上也是如此）。

理论上，这些加载时消耗大量CPU的现代页面，可能通过预加载使后续交互更快、更省资源（这是支持此类页面的常见论点），但测试结果并非如此——这些页面初始加载更慢，后续加载更慢，加载完成后依然更慢。

要理解为何“预先完成所有工作通常不会带来更快的后续体验”这一理论设想难以实现，谷歌一位杰出工程师与Discourse创始人（时任CEO）之间的这段对话颇具启发性，在讨论中Discourse创始人表示，应在带宽受限但CPU不受限的笔记本上测试移动网站。

  • Google：你也没有慢速3G网络。这两个设置是配套的。同理心不能只局限于隧道里的iPhone XS用户。
  • Discourse：实际上，任何iPhone 6或更新型号的手机，速度基本和“普通”笔记本电脑一样快。你得明白高通的工作有多糟糕。不信的话自己去查。
  • Google：我不需要相信你。我知道。关心这事的人都清楚。我的意思是，就像不是每个人都有高速网络一样，也不是每个人都有快手机。当然，iPhone 6在真实网站上经常受CPU限制。但这并不是重点。
  • Discourse：几十年来我们一直在朝着无限CPU速度发展（在桌面上大约5年前就已经接近极限了），但我们永远不会朝着无限带宽发展。优化那些真正重要的东西。我对@qualcomm毫无同情心。去他妈的Qualcomm，他们工作做得太烂了。我希望他们倒闭，他们公司所在的地面被撒上盐，寸草不生。
  • Google：移动设备在大多数情况下并不受带宽限制，而是受延迟限制。即使是最新的iPhone，在带宽受限之前也是受CPU限制。如果在MBP上以4倍慢速运行效果不错，那情况就还算可以。
  • …
  • Google：100%的用户都在iOS上吗？
  • Discourse：那些花钱的有影响力的用户往往是iOS用户，我告诉你……担心CPU毫无意义，在iOS上它实际上已经是无限的了，即使以高通的无能程度，再过4年他们那令人尴尬的SoC也能达到这个水平。

当有人问Discourse的创始人“只是好奇你为什么恨他们”时，他回复了一个链接，引用了Anandtech评测中的Kraken和Octane基准测试，结果显示高通芯片的性能分别是当时苹果芯片的74%和85%。

Discourse的创始人兼时任CEO认为高通的移动性能令人尴尬，并且对此感到非常愤怒，以至于他认为高通工程师都应该因为只达到苹果性能的74%到85%而丢掉工作。苹果拥有我认为史上最出色的性能团队。理性的人可能对此有不同看法，但至少得把他们视为世界级团队。因此，生产出只有世界级团队性能74%到85%的产品，被认为是令人尴尬的，足以让人丢掉工作。

这里呈现出两种态度，我在许多软件从业者身上都见过。第一种是认为CPU速度无限，无需担心CPU优化；第二种是认为硬件理应带来巨大加速，如果硬件工程师做不到，那纯粹是因为他们极其无能，因此软件运行缓慢应该归咎于硬件工程师，而非软件工程师。唐纳德·克努特曾表达过类似观点：

我不妨也发点牢骚，谈谈我对当前多核架构趋势的个人不满。在我看来，这或多或少像是硬件设计师已经黔驴技穷，试图把摩尔定律未来失效的责任推给软件编写者——他们给我们造出的机器，只在少数关键基准测试上跑得更快！如果整个多线程构想最终沦为一场失败，我一点也不会惊讶，甚至比当年号称无比出色的“安腾”方案还要糟糕——直到人们发现，理想中的编译器根本写不出来。这么说吧：过去50年里，我写过一千多个程序，其中不少规模庞大。但我能想到的、能通过并行或多线程显著提升性能的程序，连五个都不到。例如，多个处理器对TeX毫无帮助……我知道并行计算有重要应用——渲染图形、破解密码、扫描图像、模拟物理和生物过程等等。但这些应用都需要专用代码和特殊技术，而且每隔几年就得大幅修改。即使我足够了解这些方法，能在《计算机程序设计艺术》中写出来，我的时间也多半是浪费，因为很快就没有人需要读那些部分了……我现在用的机器是双处理器。只有当同时运行两个独立任务时，我才能同时用到它们；这固然不错，但每周也就那么几分钟。

在Discourse的例子中，如果硬件工程师无法达到一支顶级性能团队90%的表现，那他们就是耻辱、不配拥有工作；但作为软件工程师，交付一个性能只有MyBB这类未经高度优化应用3%的系统，却毫无问题。在克努特的例子中，硬件工程师几十年来每十年就给程序员带来100倍的性能提升，而程序员几乎无需付出任何努力。一旦这种提升放缓，程序员需要适应新硬件时，硬件工程师就“黔驴技穷”了；但学习一些“新”的（其实是1970年代和1980年代）想法来利用当前硬件，却又成了浪费时间。而且我们之前讨论过艾伦·凯的说法，他认为硬件工程师“不成熟”、“没受过教育”，没有在做“真正的工程”，并声称如果听从艾伦·凯的“成熟”想法，就能获得1000倍的性能提升。

程序员常常期望硬件能解决所有问题，而当这未能实现时，他们便将责任推给用户，解释为何自己无需采取任何措施来帮助用户。一个值得思考的问题是：程序员究竟为我们带来了多少性能提升？确实存在通过算法改进实现大幅提速的案例，但正如我们之前提到的，如今增长最快的论坛软件 Discourse，其性能却大约下降了 1000000x 倍。

上述现象中另一个常见态度是：不富裕的用户无关紧要。当被问及是否 100% 的用户都在使用 iOS 时，Discourse 的创始人表示：“那些愿意花钱的有影响力的用户，我可以告诉你，他们确实如此。”我们在 Tonsky 的《JavaScript 臃肿》一文的评论中也看到了同样的态度，人们表达着类似鸡尾酒会式的观点：“手机应用动辄几百兆，为什么我们要纠结于几兆的网页应用？非洲的饥饿儿童能下载安卓应用，却不能下载网页应用？拜托”，以及“GitLab 的用户肯定不至于穷到用慢速设备吧，别开玩笑了”（为简洁起见，此处已做意译）。

但当我们审视非洲下载的应用大小时，会发现那些不使用高端设备的用户使用的应用，如 Facebook Lite（几兆大小），通常只有个位数到十几兆字节。应用开发者关注应用体积有多重原因。其一是手机总存储空间有限；如果你观察真实用户安装应用的过程，他们常常需要删除或卸载其他内容才能安装新应用，因此更小的体积不仅更容易安装，而且在用户寻找更多空间时被卸载的可能性也更低。其二是，如果你查看应用体积与使用数据之间的关系（我未发现任何公开数据；如果你有可引用的公开资料，请分享），当大型应用增加体积和内存占用时，崩溃率会上升，从而导致用户留存率、增长率和参与度下降；反之，当它们优化体积和内存占用时，崩溃率会降低，用户留存率、增长率和参与度也会提升。

Alex Russell 指出，iOS 在印度（14亿人口市场）的市场份额为 7%，在拉丁美洲（6亿人口市场）为 6%。尽管 Discourse 的创始人认为这些并非“有影响力的用户”，但他们仍然是真实的人。Alex 进一步指出，根据覆盖绝大多数桌面用户的 Windows 遥测数据，大多数笔记本电脑/台式机用户使用的是低端设备，其速度可能比现代 iPhone 还要慢。

关于“没有程序员使用慢速设备”的说法，我认识很多人都在用老旧缓慢的二手设备。其中许多人甚至并不贫穷，只是不明白为什么（比如）他们的孩子需要一台超快设备，也不理解现代网页在慢速设备上运行有多糟糕。毕竟，“慢速”设备能玩3D游戏，还能（在合适的操作系统下）编译像Linux或Chromium这样的代码库，那为什么就不能正常访问像Gitlab这样的网站呢？

与Discourse创始人声称“几年内每个安卓用户都会用上某种超快安卓设备”相反，从他发表评论至今已过去六年，而要让全球几乎所有手机用户都用上高速设备，至少还需要十年，甚至可能轻易拖到二十年或更久。如果你查看Discourse的市场份额数据，会发现它极其成功——似乎是全球增长最快的论坛软件，且遥遥领先。但问题在于：全球增长最快的论坛软件由一家组织开发，而其时任领导人曾公开表示“不太关心那些不是‘花钱的有影响力用户’、没有‘无限CPU速度’的人”——这导致许多论坛对买不起“无限CPU”设备的人关闭了大门。

如果Discourse创始人只是个例，问题还不算太严重，但他只是说出了许多程序员默认的假设。正因如此，我们看到大量现代网站在低收入国家中，用收入调整后相当于新款iPhone的设备访问时，根本无法使用。

感谢Yossi Kreinen、Fabian Giesen、John O’Nolan、Joseph Scott、Loren McIntyre、Daniel Filan、@acidshill、Alex Russell、Chris Adams、Tobias Marschner、Matt Stuchlik、@gekitsu@toot.cat、Justin Blank、Andy Kelley、Julian Lam、Matthew Thomas、avarcat、@eamon@social.coop、William Ehlhardt、Philip R. Boulain和David Turner的评论/更正/讨论。

附录：游戏化LCP

我们之前提到使用的是LCP*而非LCP。这是因为LCP本质上测量的是最大变化发生的时刻。当这个指标未被刻意以不利于用户的方式操纵时，它是个很好的指标；但随着越来越多人对其进行游戏化，这个指标已无法准确反映实际用户体验。在不太露骨的案例中，人们会做小幅优化来提升LCP，但对实际用户体验几乎没有改善或毫无改善。

在更露骨的案例中，开发者会刻意尽快在页面上刷出一个巨大的变化，通常是一个对用户毫无价值的加载画面（实际上有负面价值，因为这样做增加了总工作量，也延长了页面加载总时间），然后他们小心翼翼地避免做出任何足够大的变化，以免后续变化被标记为 LCP。

出于与大众汽车未公开讨论其如何操纵排放数据相同的原因，开发者往往不愿公开讨论这类 LCP 优化。一个例外是 Discourse，他们公开宣布了这种 LCP 优化，并附有开发者及时任 CTO（现任 CEO）的评论，指出其新推出的“Discourse Splash”功能在部署后大幅降低了网站的 LCP。当开发者询问为何自己的 LCP 偏高时，Discourse 开发者的标准建议是：让元素保持小于“Discourse Splash”，这样 LCP 时间戳就会基于这个为优化 LCP 而抛出的无用元素来计算，而非基于任何与用户相关的实际元素。以下是 Discourse 的典型官方评论：

如果你的横幅比我们用于“Introducing Discourse Splash - A visual preloader displayed while site assets load”的元素还大，那你的 LCP 就会很糟糕。

Discourse 的官方回应是：你应该确保自己的内容不会触发 LCP 测量，而是让我们的加载动画时间戳用于计算 LCP。

在有用内容的 LCP 与 Chrome 测量的 LCP 之间比值最极端的网站包括：

  • Wix
    • M3：6
    • M1：12
    • Tecno Spark 8C：3
    • Itel P32：N/A （失败）
  • Discourse：
    • M3：10
    • M1：12
    • Tecno Spark 8C：4
    • Itel P32：N/A （失败）

虽然我们尚未讨论对其他指标的操纵，但似乎有些网站也在操纵其他指标并“优化”它们，即使这对用户毫无益处。

附录：优化网站的自私理由

这取决于网站的规模及其性能，但当我审视我曾任职大公司的数据时，提升网站和应用的性能所带来的价值高得惊人。这在 A/B 测试中可量化，并且在长期留存实验中，它也是对增长和留存影响相对较大的干预措施之一（许多干预措施测试效果不错，但长期表现不佳，而性能改进往往长期表现更佳）。

当然，你可以直接从数字中看出这一点，但在审视数据时，也能通过许多方式间接观察到。一个角度是（仅举例而言），在Twitter上，用户观察到的p99延迟在印度以及许多非洲国家（甚至排除埃及和南非等相对富裕的国家）约为60s，在美国也约为60s。当然，从整体人口来看，美国用户拥有更快的设备和连接，但在每个国家，都有足够多的用户使用慢速设备或连接，以至于限制因素实际上是用户的耐心，而非底层人口层面的设备和连接分布。即使你不关心尼日利亚或印度的用户，只关注美国广告收入，为低端设备和连接优化性能也能产生足够大的影响，以至于我们可以在全球以及美国收入的A/B测试中轻易看到效果，尤其是在长期留存实验中。此外，在拥有快速设备的用户中也能看到影响，因为一项将“低端”设备用户延迟从60s改善到50s的改动，可能也会将高端设备用户的延迟从5s改善到4.5s，这同样对收入、增长和留存数据产生影响。

由于超出本文档范围的多种原因，这种枯燥、可量化、推动增长和收入的工作，在我工作过的大多数大公司中，往往难以获得资金支持，相比之下，那些最终在长期留存实验中几乎无影响的炫酷产品工作却更容易获批。

附录：为低性能设备设计

在使用慢速设备或任何带宽低、连接差的设备时，迄今为止最好的体验通常是那些一次性将大量内容加载到静态页面中的设计。如果图片具有合适的宽度和高度属性以及替代文本，那会非常有帮助。渐进式图片（如渐进式JPEG）并没有特别大的作用。

在带宽高但设备慢的情况下，任何轻量级的静态页面都能良好运行，而轻量级的动态页面如果针对性能设计也能表现不错。重量级的动态页面则注定失败，除非页面重量不会导致页面变得复杂。

在带宽低和/或连接差的情况下，轻量级页面没有问题。对于重量级页面，我最好的体验是：触发页面加载后，去做别的事情，等加载完成（至少HTML和CSS加载完毕）后再回来。然后，我可以将每个想阅读的链接在新标签页中打开，再去做别的事情，等待这些页面加载。

现代网站的许多优化手段，比如滚动页面时触发更多内容的局部加载，以及随之而来的搜索功能劫持（因为浏览器自带的搜索在页面未完全加载时毫无用处），导致原本有效的交互模式失效，让页面使用起来非常痛苦。

举个例子，不少人反映Substack因采用局部页面加载而表现不佳。这是@acidshill录制的视频，展示在iPhone 8上加载Substack文章后滚动时的效果。虽然文章的LCP（最大内容绘制）速度较快，但如果你想滚动越过页头，必须等待6秒才能加载下一页内容，而再次滚动时，可能又需要等待1到2秒：

作为对比，我尝试加载了一些较大的纯HTML页面，例如https://danluu.com/diseconomies-scale/（0.1 MB 传输量 / 0.4 MB 原始大小）和https://danluu.com/threads-faq/（0.4 MB 传输量 / 1.1 MB 原始大小）。即使在慢速设备上，这些页面依然相当可用。1.1 MB似乎偏大，在低端设备上拆分成几个页面会更优，但包含1.1 MB文本的单个页面，在慢速设备上的表现仍优于大多数现代网站。虽然HTML页面过大可能导致浏览器无法处理，但对于内容量正常的页面，通常只有在引入复杂的CSS负载或JavaScript时，才会在慢速设备上引发问题。下文我们测试了一些相对简单的页面（其中某些包含大量媒体资源，例如一个页面有14 MB），发现只要保持简洁，这些页面运行良好。

Chris Adams也指出，使用屏幕阅读器的盲人用户常反馈动态加载让他们的体验更糟。就像为了提升性能而采用动态加载一样，虽然可以做得很好，但往往要么实现糟糕，要么捆绑了过多复杂性，最终效果反而不如简单页面。

@Qingcharles提到了另一个可访问性问题——他接触的（监狱）假释人员会获得“生命线”手机，这些通常是极低端的设备。快速搜索发现，2024年有些人会拿到iPhone 6或iPhone 8，但还有大量设备比Itel P32更低端，更不用说Tecno Spark 8C了。他们获得的套餐流量也极其有限，流量用完后，有些人“无法填写任何求职、福利表格，也无法用地图导航”。

对于那些提前做好准备工作、在低端设备上也能提供良好体验的网站，Andy Kelley 举了一个例子：一个提前完成前期工作、在慢速设备上似乎运行良好的网站（尽管在极慢的网络连接下可能会吃力）——Zig 标准库文档：

我做了一个有争议的决定：提前获取所有源代码，然后在本地完成所有内容渲染。理论上，这很消耗 CPU，但实际上……即使是那些旧手机，CPU 也快得惊人！

在 Tecno Spark 8C 上，这占用了 4.7s 的 CPU 时间，之后响应相当迅速（相对于设备而言——当然 iPhone 的响应速度要快得多）。点击链接后加载速度较快，滚动也正常（虽然有点卡顿，但在这台设备上几乎没有什么操作是真正流畅的）。这似乎就是人们所说的“通过发送大量负载可以获得更好性能”的那种情况，但真正能在低端设备上提升性能的例子并不多见。

附录：关于 Web 性能问题的文章

  • 2015：Maciej Cegłowski：《网站肥胖危机》
    • 大小：1.0 MB / 1.1 MB
    • Tecno Spark 8C：0.9秒 / 1.4秒
      • 滚动略显卡顿，快速滚动时（从顶部跳至页面一半位置）图片需要稍长时间才出现，但延迟低于绝大多数用户在正常距离滚动时的感知阈值。
  • 2015：Nate Berkopec：《页面重量无关紧要》
    • 大小：80 kB / 0.2 MB
    • Tecno Spark 8C：0.8秒 / 0.7秒
      • 采用懒加载，若滚动浏览整个页面，下载量达 650 kB / 1.8 MB，但滚动仅轻微卡顿，且懒加载未造成延迟。这可能是唯一一个以提升而非降低慢速设备体验的方式实现懒加载的页面；我未在慢速网络下测试，但在此条件下体验仍会变差。
    • Itel P32：1.1秒 / 1秒
      • 滚动基本不可用；滚动极其卡顿且移动距离随机，滚动到新文本时文字渲染常需 1秒 以上；懒加载图片时情况更糟。尽管这是我见过的最佳懒加载实现，Itel P32 仍无法应对。
  • 2017：Dan Luu：《网页臃肿如何影响慢速连接用户》
    • 大小：14 kB / 57 kB
    • Tecno Spark 8C：0.5秒 / 0.3秒
      • 滚动和交互正常。
    • Itel P32：0.7秒 / 0.5秒
  • 2017-2024+：Alex Russell：《性能不平等鸿沟（系列）》
    • 大小：82 kB / 0.1 MB
    • Tecno Spark 8C：0.5秒 / 0.4秒
      • 滚动和交互正常。
    • Itel P32：0.7秒 / 0.4秒
      • 滚动和交互正常。
  • 2024：Nikita Prokopov (Tonsky)：《2024年的JavaScript臃肿》
    • 大小：14 MB / 14 MB
    • Tecno Spark 8C：0.8秒 / 1.9秒
      • 滚动时图片显示需较长时间（约500毫秒），滚动不流畅，但未卡顿到难以定位正确位置。
    • Itel P32：2.5秒 / 3秒
      • 滚动不流畅。精确定位稍显困难，但若非常小心，通常能滚动到目标位置。滚动较大距离时，新内容出现通常需 1秒 以上。
  • 2024：Dan Luu：《本文》
    • 大小：25 kB / 74 kB
    • Tecno Spark 8C：0.6秒 / 0.5秒
      • 滚动和交互正常。
    • Itel P32：1.3秒 / 1.1秒
      • 滚动和交互正常，尽管我为此做了调整——本文原嵌入视频，Itel P32 无法处理。
        • 注意：虽然这些数值比《页面重量无关紧要》更差，但本页面加载后可用，而另一页面因执行某种复杂懒加载（该手机无法在合理时间内处理）而不可用。

附录：对非富裕用户的同理心

随着编程行业日益声名显赫且利润丰厚，我长期观察到的一个现象是，从业者往往来自更富裕的家庭背景，对不同收入水平人群的接触也更少。我们之前讨论过一个例子：在一家知名且声望颇高的初创公司（员工政治立场普遍偏左），所有员工都变得富有了。在一次关于新冠刺激支票的Slack讨论中，一位善意的进步派员工表示，刺激支票毫无意义，因为人们只会用它来买股票。显然，这个人从未与任何中产阶级（更不用说穷人）聊过他们的钱花在了哪里，也从未查看过关于谁持有股票的数据。而这还只是针对美国财富的观察。放眼全球财富，人们的普遍理解水平则低得多。人们似乎严重低估了全球财富和收入的动态范围。在与不少人讨论过这个问题后，我发现许多人脑海中存在两类标签：一类是“按美国标准算穷人”（会用刺激支票买股票），另一类是“按全球标准算穷人”（可能连股票都不买）。但世界范围内的贫困程度远超美国，其差距之大，似乎许多富裕的程序员并未意识到。

例如，在关于我父母带我来到美国是多么幸运（尤其是在经济机遇方面）的讨论中，有人提到这其实没什么大不了的，因为他们在波兰也有极好的经济机遇。首先，就讨论的主题而言——一个人最终获得高薪编程工作（比如高薪科技公司的高级工程师）或同等职位的概率——我怀疑，在我出生时，出生在美国的贫困家庭比出生在波兰的富裕家庭胜算更大，但如果有数据支持，我也能相信相反的情况。然而，如果我们比较波兰与美国、越南与美国，只需花15秒查一下我出生那年这些国家的大致财富数据，就会发现美国与波兰的人均GDP之比约为8:1，而波兰与越南之比约为50:1。波兰与越南之间的财富差距，大致相当于美国与波兰之间差距的平方，因此波兰与越南的对比，就相当于波兰与某个假设中比美国更富裕（富裕程度相当于美国比波兰富裕的程度）的国家相比。这两者根本不可同日而语，但很多人似乎有一种思维模式，认为世界上只有“富裕国家”和“非富裕国家”，而“非富裕国家”都大致处于同一水平。人均GDP并非理想指标，但比百分位收入统计更容易找到；我快速搜索了一下，还发现当时越南的年收入大约在200到300美元之间。越南当时还处于一场饥荒的尾声，其影响难以准确判断，因为相关统计数据似乎被人为操纵，但如果你相信死亡率数据，这场饥荒导致总死亡率飙升至正常基线的两倍1。

当然，在当时，低收入国家的普通人根本不会拥有电脑，更不用说互联网接入。但如今，低收入国家的人们拥有设备已相当普遍。许多人似乎要么没有意识到这一点，要么不了解这些人使用的设备类型。

附录：Fabian Giesen的评论

关于Discourse创始人对iOS与Android市场份额的评论，Fabian指出：

在美国，根据我能找到的最新数据（2023年），iPhone 的市场份额约为 60%。在欧盟，这一比例约为 33%。这带来了连锁反应。iOS 用户不仅偏向富裕阶层，也更倾向于美国用户。

这还产生了一些次要影响。例如，在美国，iMessage 在群聊等场景中非常流行，并且因与安卓设备互通性极差而臭名昭著——这种糟糕体验几乎可以肯定是苹果有意为之，让安卓用户感到非常恼火。

在欧盟，由于安卓占据更主导地位，iMessage 远没有那么流行。据我所知，甚至我认识的 iPhone 用户——如果在美国可能会用 iMessage——也更倾向于使用 WhatsApp。

关键在于，从全球范围来看，最新 iOS 设备搭配高速互联网的组合，其用户群体比许多美国应用开发者意识到的更加偏向特定人群。

关于移动应用与网页应用大小的评论，Fabian 补充道：

再补充一点经验之谈：安装应用时是一次性下载，通常你可以在慢速或计量网络下（甚至完全无数据时）推迟更新。

当初我刚拿到美国手机时，因为没有美国信用记录，只能使用预付费套餐。我现在仍用预付费，因为它能满足我大部分日常需求。但这意味着每年回德国时，我完全没有数据漫游功能。（此外，在德国打电话每分钟要花 1.5 美元——尽管 T-Mobile 是德国最大的移动运营商，但当然不是美国 T-Mobile。）

关键在于，我确实能在 T-Mobile 热点（如主要火车站、机场等）和提供 Wi-Fi 的城际列车上使用免费高速网络，但在德国期间实际上没有任何数据套餐。

对于支持离线工作、有网络时同步数据的手机应用来说，这完全没问题。但网页应用在我远离公共 Wi-Fi 时就无法使用。

同样，我可以通过 Gmail 应用在慢速计量网络下发送邮件，但绝不会使用任何需要下载几 MB 压缩 JS 才能操作的网页邮件客户端——尤其是在计量网络下。

至少对于原生应用下载，我可以提前准备，在有良好网络的地方提前下载好！

Fabian 的另一个评论（这次是转述，因为来自对话）是，人们常常会以“存在某种定性原因导致某件事本该慢”为由，来证明数量级上的极度缓慢是合理的。他举的一个例子是，屏幕同步连接通常需要很长时间，而人们认为这是合理的，因为有些操作必须执行，需要时间。长期以来，这些操作往往需要几秒钟。最近，许多显示器同步速度大幅提升，因为 Nvidia 对“G-Sync”认证规定了这一过程的时间上限，所以显示器制造商现在能在合理时间内完成。虽然确实有些操作必须执行且需要时间，但并没有根本性原因让它们必须像过去那样耗时。他举的另一个例子是，有人为读取数千个文件耗时过长辩护，理由是这一操作需要大量系统调用，而“系统调用很慢”——这在定性上是正确的，但如果看看系统调用的实际成本，在讨论的案例中，系统调用的成本距离足以合理解释读取数千个文件为何耗时如此之久，还差着好几个数量级。

关于这个话题，当有人指出现代网站速度慢时，通常会有回应者给出定性辩护：现代网站拥有旧网站所缺乏的诸多优秀功能。虽然（例如）Discourse 确实有 MyBB 没有的功能，但很难说它的功能集足以证明其速度慢 33 倍 是合理的。

附录：实验细节

除了danluu.com和（可以说）HN之外，对于每个网站，我都尽量寻找“最默认”的体验。例如，对于WordPress，这意味着使用当前默认主题twentytwentyfour的演示博客。在某些情况下，这可能不是如今人们最常用的配置，比如对于Shopify，我查看了他们浏览主题时首先展示的主题，但我没有尝试查找主题数据来了解最常用的主题是什么。对于这篇文章，我希望将所有数据收集和分析作为一个短项目来完成，耗时不超过一天，因此采取了类似上述的许多简化措施，下文会详细说明。我认为使用Shopify首先展示的主题并没有错，因为相当一部分用户可能会使用这个主题，但这当然不如获取最常用主题、然后测试多个使用该主题的网站、观察用户修改主题后实际性能变化来得有代表性。如果我受雇于Shopify或想为竞争对手做竞争分析，我会那样做，但对于一个关于大型网站如何影响低端设备用户的一日项目而言，这里展示的Shopify性能似乎还可以。实际上，我早在二月份进行这些投票时就开始了初步工作；只是花了一个月时间才真正把这些内容写出来。

对于笔记本电脑的测试，我尽量让电池电量保持在约60%，不插电，并在20°C的室温下让笔记本闲置足够长时间以恢复热平衡，这样页面就不会受到之前页面加载或机器上其他先前工作的影响。

在移动端测试中，手机电量均保持在约100%并连接电源，且此前已充满电，因此手机不会出现快速充电可能导致的发热效应。如上所述，这些测试均在1Gbps的WiFi环境下进行。设备上未运行其他应用，浏览器未打开其他标签页，且仅安装了测试所需的应用程序，因此除设备默认对用户施加的后台任务外，不应有其他额外后台进程运行。在几乎所有情况下，使用相同设备的真实用户将观察到比我们此处测量的更差的性能，除非在手机上运行Chrome Dev Tools会显著降低性能。我注意到，在Itel P32上，运行Dev Tools时滚动操作比正常运行时略显卡顿，但由于这是一个为期一天的项目，我并未尝试量化这一影响，也未评估其对不同网站的影响程度差异。从绝对值来看，开销不可能太大，因为运行Dev Tools时最快的网站仍然相当快，但如果存在某种与网站工作量呈超线性关系的开销（可能间接导致资源耗尽），那么在某些网站的测量中可能会成为问题。

所有尺寸均在移动端测量，因此当移动端与桌面端加载不同资源时，我们测量的是移动端资源的大小。CPU以主线程上的CPU时间进行测量（我也记录了使用其他线程的网站的其他线程时间，但未使用该数值；如果CPU成为人们想要操控的指标，则必须考虑其他线程的时间，以防止网站试图将尽可能多的工作卸载到其他线程，但目前这不是问题，且主线程时间与可用性的相关性比所有线程时间总和更直接，而适合操控的指标目前尚无优势，因此暂不采用）。

WiFi速度测试结果如下：

  • M3 Max
    • Netflix（fast.com）
      • 下载：850 Mbps
      • 上传：840 Mbps
      • 延迟（空闲/负载）：3ms / 8ms
    • Ookla
      • 下载：900 Mbps
      • 上传：840 Mbps
      • 延迟（空闲/下载/上传）：3ms / 8ms / 13ms
  • Tecno Spark 8C
    • Netflix（fast.com）
      • 下载：390 Mbps
      • 上传：210 Mbps
      • 延迟（空闲/负载）：2ms / 30ms
    • Ookla
      • Ookla网页应用失败，无法查看结果
  • Itel P32
    • Netflix
      • 下载：44 Mbps
      • 上传：测试失败（发送一个数据块后挂起，不再发送数据）
      • 延迟（空闲/负载）：4ms / 400ms
    • Ookla
      • 下载：45 Mbps
      • 上传：测试失败
      • 延迟：测试无法显示延迟

需要注意的一点是，Itel P32 实际上无法使用其标称的带宽。查看谷歌上的热门评论，没有一条提到这一点。第一条评论写道

性能方面，这款手机不会卡顿。它搭载了最新的Android 8.1（Go版）……我们拥有8GB存储+1GB运存，由1.3GHz四核处理器驱动，便于轻松多任务处理……我对P32的功能印象深刻，尤其是考虑到它的价格。我会推荐给那些经常外出的人。对于那些将智能手机电池续航作为首要考虑的人来说，P32是您的最佳选择。

第二条评论写道

Itel手机是非洲领先的经销商之一，在非洲大陆排名第三……轻量级操作系统表现符合我们的预期，在1GB RAM设备上运行流畅，没有卡顿……处理速度相当快……Itel P32智能手机在其能力范围内提供了最佳性能……以高达33万乌干达先令的价格，Itel P32是那些令人惊叹的低端智能手机之一，凭借其单一包装中嵌入的丰富功能，值得获得中端手机的赞誉。

第三条评论写道

“远不止是一款入门级预算智能手机……我们使用两周后的完整评测……在切换应用和浏览繁重网页时，性能表现最佳。当多个应用在后台运行或玩游戏时，偶尔会出现卡顿。然而，对于大多数手机用户来说，整体性能属于平均水平，最适合普通用户使用。[游戏截图] 尽管游戏会跳过一些帧，并自动降低图形细节，但如果手机上没有其他应用在运行，速度会快得多。

网站备注：

  • Wix
  • Patreon
    • www.patreon.com/danluu：尽可能使用我的个人主页
    • 在 Patreon 上滚动并查找旧帖子的体验非常痛苦，以至于我维护了自己的 Patreon 帖子索引，以便无需使用 Patreon 就能找到旧帖子。尽管在快速笔记本电脑上，表格中的 Patreon 数据看起来并不差，但这仅针对初始加载。滚动时的性能糟糕到我认为，如今不存在一台电脑和网络连接能以体面的性能浏览 Patreon。
  • Threads
    • threads.net/danluu.danluu：尽可能使用我的个人主页
    • 在 Itel P32 上，严格来说页面加载不正确，可标记为 FAIL，但因为它足够接近，我将其计入了。不正确之处在于个人资料照片周围有一个方形边框
      • 然而，与其他重型页面一样，与页面交互实际上无法正常工作，页面不可用，但这似乎是出于标准的性能原因，而非页面渲染失败
  • Twitter
    • twitter.com/danluu：尽可能使用我的个人主页
  • Discourse
    • meta.discourse.org：这是我搜索官方论坛时出现的结果。
    • 如上所述，LCP 被高度操纵，基本毫无意义。我们链接到了一篇帖子，其中 Discourse 团队指出，在加载缓慢时，他们会在 2s 时放置一个巨大的启动画面，以将 LCP 限制在 2s。同样值得注意的是，在加载速度快于 2s 的情况下，LCP 也被高度操纵。例如，在配备低延迟 1Gbps 网络的 M3 Max 上，LCP 报告为 115ms，但页面实际内容在 1.1s 时加载。这似乎使用了与“Discourse Splash”相同的基本技巧，即先绘制一个巨大的变化到屏幕上，然后小心地加载较小的元素，以避免实际页面内容被检测为 LCP。
    • 在 Tecno Spark 8C 上，滚动不可预测，可能跳得太远，触发无限滚动加载，导致页面挂起 3s-10s。此外，如果让浏览器在此页面上停留一段时间，整个浏览器有时会崩溃。
    • 在 Itel P32 上，7.5s 后显示一条错误消息
  • Bluesky
    • bsky.app/profile/danluu.com
    • 在 Itel P32 上显示空白屏幕
  • Squarespace
    • cedar-fluid-demo.squarespace.com：这是我点击主题获取主题时出现的第二个主题；第一个是名为“Bogart”的主题，但那基本上是一个“即将推出”的单页屏幕，没有内容，因此我使用了第二个主题。
    • 在 Itel P32 上，控制台出现大量错误和警告，但页面似乎加载并正常工作，尽管与之交互相当缓慢且痛苦
    • Tecno Spark 8C 上的 LCP 明显早于页面内容实际加载的时间
  • Tumblr
    • www.tumblr.com/slatestarscratchpad：使用此链接是因为我知道这个 tumblr 存在。我不怎么阅读 tumblr（大概三四个），而这个似乎是我在 tumblr 上所知的最接近我博客的页面。
    • 此页面在 Itel P32 上加载失败，但未 FAIL。控制台显示 JavaScript 出错，但页面仍然正常工作（我尝试了滚动、点击链接等操作，均正常），因此你实际上可以访问并阅读你想要的帖子。JS 错误似乎使此页面加载速度比正常情况下快得多，并且使页面加载后的交互相当流畅。
  • Shopify
    • themes.shopify.com/themes/motion/styles/classic/preview?surface_detail=listing&surface_inter_position=1&surface_intra_position=1&surface_type=all：这是我查找主题时出现的第一个主题
    • 在首次 M3/10 运行时，Chrome 开发者工具报告了荒谬的 697s CPU 时间（运行在正常时间内完成，远低于 697s 甚至 697/10s。此运行在计算结果时被忽略。
    • 在 Itel P32 上，页面加载从未完成，仅显示一个闪烁的光标状图像，这是主题故意加载的。在正常加载的设备上，闪烁的光标图像会立即被另一图像覆盖，但这里从未发生。
    • 我怀疑使用此示例主题是否公平，因为页面上有一些内容允许切换主题样式，因此我检查了该主题的实际使用情况（宣传该主题的页面列出了该主题的用户）。我尝试了列出的前两个真实示例，它们都比此演示页面慢得多。
  • Reddit
    • reddit.com
    • 与页面变得可用所需的时间相比，LCP* 异常低。尽管未在此测试中测量，但我通常发现该页面在 Intel Macbook 上缓慢且几乎不可用，而按历史标准，这些是极快的计算机（除非我使用 old.reddit.com）
  • Mastodon
    • mastodon.social/@danluu：尽可能使用我的个人主页
    • 在 Itel P32 上加载失败，仅显示空白屏幕。由于 Itel P32 上通常需要很长时间，因此在一段时间内无法判断页面是加载失败还是只是缓慢
  • Quora
    • www.quora.com/Ever-felt-like-giving-up-on-your-dreams-How-did-you-come-out-of-it：我尝试搜索 quora 加上一位 metafilter 用户的用户名，我听说该用户现在在 Quora 上非常活跃。Google 没有返回该用户的个人主页，而是返回了此页面，该页面似乎与我搜索的用户无关。因此，这与社交媒体个人主页不可比，但从 Google 获得一个随机的无关 Quora 结果是我与 Quora 互动的方式，所以我想这代表了我的 Quora 使用情况。
    • 在 Itel P32 上，页面在某个时刻停止执行脚本，并未完全加载。这导致页面无法正确显示。与页面交互实际上也无法正常工作。
  • Substack
    • 使用 thezvi.substack.com，因为我知道 Zvi 有一个 substack，并且撰写类似主题。
  • vBulletin：
    • forum.vbulletin.com：这是我搜索官方论坛时出现的结果。
  • Medium
    • medium.com/swlh：我不在 Medium 上阅读任何内容，因此我搜索了 Medium 上的编程博客，这是最热门的结果。从主题来看，它似乎并不特别重，也不是为 Medium 博客特别定制的。由于它似乎被广泛阅读且受欢迎，因此更有可能从 CDN 提供服务，并且比此处的一些其他博客更快。
    • 在一次非基准参考运行中，在 Itel P32 上，我尝试在加载页面 35 秒后开始滚动。滚动的延迟为 5s-8s，并且滚动移动了不可预测的量，使页面完全无法使用。这在表格中未被标记为 FAIL，但有人可能会认为这应该是一个 FAIL，因为页面不可用。
  • Ghost
    • source.ghost.io，因为这是当前默认的 Ghost 主题，也是我找到的第一个示例
  • Wordpress
    • 2024.wordpress.net，因为这是当前默认的 Wordpress 主题，也是我找到的第一个示例
  • XenForo
    • xenforo.com/community/：这是我搜索官方论坛时出现的结果
    • 在 Itel P32 上，布局严重错误，页面内容重叠。因此无法以合理方式与所需元素交互，阅读文本需要阅读多次重叠打印的文本。
  • Wordpress（旧版）
    • 使用 thezvi.wordpress.com，因为它与 Zvi 的 substack 内容相同，并且恰好使用了一个曾经非常常见的旧 Wordpress 主题
  • phpBB
  • MyBB
    • community.mybb.com：这是我搜索官方论坛时出现的结果。
    • 网站不提供移动版本。总的来说，我发现使用慢速设备时，网站的桌面版明显优于移动版，因此这效果很好，尽管他们可能会因此受到 Google 的惩罚。
  • HN
    • news.ycombinator.com
    • 原则上，HN 应该是最慢的社交媒体网站或链接聚合器，因为它是用一种未高度优化的自定义 Lisp 编写的，并且代码最初以简洁和巧妙为目标，这通常会导致性能相当差。然而，这只是相对于编写高性能代码所能获得的结果而言的，而这不是此处相关的比较点。
  • danluu.com
    • 不言自明
    • 目前，这使用的 CPU 比 HN 略少，但我预计随着主页不断增长，最终会使用更多 CPU。目前，此页面有 176 个链接指向 168 篇文章，而 HN 有 199 个链接指向 30 篇文章，但除非意外消亡，此页面最终应该会有比 HN 更多的链接。
      • 如上所述，我发现对于如此小的页面进行分页，在慢速设备或连接不良的情况下会使浏览体验更差，因此我不想通过分页或更糟糕的是在滚动时进行某种动态内容加载来“优化”它。
  • Woo Commerce
    • 我最初也测量了 Woo Commerce，但与上面测试的页面和平台不同，我发现初始加载的快慢不一定代表后续其他操作的性能，因此未将其包含在表格中，因为将其放入表格中有点要求与 Shopify 进行比较。特别是，虽然我能找到的“最默认”的 Woo 主题在慢速设备上的初始加载速度明显快于“最默认”的 Shopify 主题，但性能是多维的，很容易找到现实场景中 Shopify 比 Woo 快，反之亦然，这与我在较新的博客平台（如 Substack 和 Medium）与较旧平台（如 Wordpress）或现代论坛（如 Discourse）与较旧的基于 PHP 的论坛上看到的情况截然不同。对具有购物车、结账流程等的购物网站进行真正的比较，需要对这些网站的实际使用情况有比我一天之内能获得的更深入的了解。
  • NodeBB
    • community.nodebb.org
    • 这不在我最初的测试中，我之所以尝试它，是因为 NodeBB 的一位创始人建议，他说：“我有兴趣看看 @nodebb@fosstodon.org 在你的测试中是否表现更好。多年来，我们花了很多时间让它变得非常快，我个人认为它比 Discourse 更能代表现代论坛软件，至少在速度和初始负载方面。”
    • 我没有进行全套测试，因为我没有给 Itel P32 充电（电池状况不佳，拔掉电源后放电很快，所以我需要等很长时间才能将其充电）
    • 在我进行的测试中，它在 M1 上获得了 0.3s/0.4s，在 Tecno Spark 8C 上获得了 3.4s/7.2s。这比 vBulletin 稍慢，比更快的 PHP 论坛慢得多，但比 Discourse 快得多。如果你出于某种原因需要一个“现代”论坛，并希望你的论坛能被那些按全球标准并不富裕的人使用，这似乎可行。
    • 另一个值得注意的事情是，鉴于它是一个“现代”网站，初始加载后的交互工作正常；你可以滚动和点击，这些基本都能正常工作，没有崩溃等。
    • 大小分别为 0.9 MB / 2.2 MB，因此对于一个“现代”网站来说也相当轻量，可能在慢速连接上可用，尽管此处未测试慢速连接。

另一种测试方式是尝试将页面配置得尽可能相似。如果有人做这个测试，我很想看看结果，但这种测试会耗费更多时间。首先，它需要为每个网站进行定制；其次，还需要决定网站应该呈现什么样子。如果你测试一个类似 danluu.com 的网站，那么任何能让你直接从 CDN 提供轻量内容的平台（如 WordPress 和 Ghost）得分应该相近，分数取决于 CDN 和 CDN 缓存命中率。而像 Medium 和 Substack 这类可定制性较低的网站，得分基本会和现在一样。实际上，从现有网站来看，大多数用户创建的网站会比 WordPress 和 Ghost 的“最默认”主题更慢，不过这个博客的读者平均而言可能会相反，所以你可能需要测试多种不同的网站风格。

附录：本网站 vs. 在慢速设备或慢速连接上无法运行的网站

顺便提一句，有一件事我很久以来都觉得很有趣：我收到了不少关于本页面风格的仇恨邮件（以及数量相当的赞赏邮件）。我说的仇恨邮件，不是指礼貌的修改建议，而是相当于路怒症的网络版——网络暴怒。我认识一些运营复杂网站的人，这些网站复杂到世界上相当一部分人无法使用。为什么人们对这个网站的风格如此愤怒，而按比例来说，却基本不关心网络对这么多人来说无法使用呢？

另一个有趣的地方是，欣赏这种风格的人通常喜欢网站不覆盖任何默认样式，让你可以自由设置宽度（通过调整窗口大小），也不会覆盖你应用到网站上的任何默认样式。而那些对此非常坚持的人希望每个人都使用他们偏好的宽度限制、字体等，但总是以一种“这不是为了我自己，而是为了大众利益”的方式表达，尽管迎合网络暴怒者的偏好会直接违背那些（举例来说）喜欢通过调整窗口宽度来调整文本宽度的人。

在我指出这一点几十次之前，这种讨论通常始于网络喷子告诉我“研究表明”更窄的文字宽度客观上更好，但在我阅读了能找到的所有关于这个话题的研究后，我发现事实并非如此。此外，当我要求他们提供引用时，很明显说这话的人通常根本没有读过任何相关研究，有时他们会匆忙发给我一篇他们似乎也没读过的研究。当我指出这一点时，人们就会改变论点，说研究其实无法真正描述这个问题（奇怪的是他们一开始却引用研究），尽管有一个人引用了一本书给我（我读了，而他们显然没读，因为那本书也不支持他们的论点），然后转而说这是每个人都想要的，尽管从我所收到的评论以及我做出改变后获得的数据来看，显然并非如此。

持这种论点的网络喷子通常似乎无法接受他们的偏好并非普遍适用这一信息，并且会坚持认为无论人们怎么说自己喜欢什么，他们的偏好才是正确的，我觉得这相当有趣。从数据来看，当我从Octopress样式（当时编程博主最流行的样式）切换到当前样式时，我获得了看似因果性的流量和参与度增长，所以不仅那些给我写感谢信的人喜欢这种样式，那些不给我写信的人的整体感受似乎也是这个网站不错，而且比标准的程序员博客样式更有吸引力。当我指出这一点时，人们往往会更加坚信他们的偏好是普遍的，认为那些有其他偏好的人是错的，并用完全荒谬的话来回应。

对我而言，有两个问题让我感到好奇：一是为什么人们会觉得有必要在这个话题上捏造证据（比如引用自己根本没读过的研究，或者谷歌搜索后链接到一篇与自己声称内容相反的论文——大概是因为他们根本没认真读），以此来宣称自己的偏好具有“客观”正确性或普适性；二是为什么人们对这件事的愤怒程度，远高于对典型网页设计造成的全球可访问性问题？关于后者，我猜想如果用抽象问卷进行调查，人们会认为全球可访问性是更大的问题。但根据人们的实际行为——无论是他们创作的内容，还是足以激怒他们到发送仇恨邮件的因素——可以看出，拥有完全可调节的行宽、不将行宽限制在他们偏好的长度，这件事值得采取行动，而全球可访问性却不然。如上所述，那些因性能问题导致网站不可访问的运营者，通常几乎不会因此收到仇恨邮件。而当我使用默认的Octopress安装时，我也从未因此收到过仇恨邮件。当时阅读我网站的人更少，但此后我的流量并未大幅增长，而关于我网站设计的仇恨邮件却从零增加到了相当数量——与流量增长相比，这个比例高得离谱。

需要明确的是，我当然不会声称这个网站的设计是最优的。我当时只是移除了当时最受程序员欢迎的博客平台的CSS，因为那个CSS对低端网络连接的用户来说显然很糟糕，而作为副作用，我获得了更多的流量和整体参与度——不仅来自那些通常使用低端网络和设备的地区。毫无疑问，关心低端网络和设备用户的设计师可以做得更好，但关于此事的评论中，无论是虚假陈述还是尖刻言辞，都显得相当奇怪。

  1. 这个估算将回溯性预期寿命定在60岁出头；那篇论文还讨论了其他在65岁左右的估算，并探讨了估算中的偏差。[返回]