2017年，我们研究过网页臃肿如何影响网速较慢的用户。即便在美国，许多用户也达不到宽带速率，导致大量网页难以使用。如今，无论在美国境内还是境外，依然有许多用户没有宽带速度，许多现代网页对网络较慢的人来说根本无法使用。不过，带宽呈指数级增长（尼尔森认为高端连接的增速为每年50%），增速已经超过了普通网站的臃肿化速度，因此这个问题相比2017年已有所缓解，但对网络条件差的人而言，依然是个严重问题。

网页应用的 CPU 性能增长远不及带宽。因此，虽然越来越多的网页对低网速用户变得可访问，却有越来越多的网页对使用低端设备的人变得不可访问，即便他们拥有高速网络。例如，如果我在一台Tecno Spark 8C上尝试浏览一个“现代”的 Discourse 论坛，有时浏览器会直接崩溃。即便没有崩溃，实测的响应速度也远比用一台8 MHz 286搭配1200 baud调制解调器浏览 BBS 还要差。在我家1Gbps的网络下，加载帖子标题所“必需”的2.6 MB压缩传输体积还算轻量。实际传输体积“仅仅”增长了1000x，与网速的提升相比不值一提。但在 CPU 速度方面情况恰恰相反——就网页浏览和论坛加载性能而言，那颗8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55)的 CPU 竟然带不动 Discourse。这颗 CPU 的速度大约是那台286的100000x。也许需要一台快1000000x的设备才够用。

对于不熟悉Tecno Spark 8C的人来说，简单搜索就会发现，如今一台全新的Tecno Spark 8C在尼日利亚大约售价USD 50-60，在印度大约是USD 100-110。按家庭收入中位数占比来算，这比今天在美国买一台最新款 iPhone 要贵得多。

按全球标准来看，Tecno Spark 8C甚至还算不上低端设备，因此我们还会测试一台更低端的设备Itel P32（虽然它也远非如今人们在用的最低端设备）。此外，我们还会测试M3 Max Macbook (14-core)、M1 Pro Macbook (8-core)以及在 Chrome 开发者工具中设置为10x限速的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）。谷歌文档对LCP的解释是

最大内容绘制（LCP）衡量的是用户感知到页面最大内容可见的时刻。LCP 的指标值代表用户发起页面加载到页面渲染出主要内容之间的时长

LCP是一个常见的优化目标，因为它是 Google PageSpeed Insights 中展示的主要指标之一，属于“核心网页指标”。本文中LCP旁标注了星号（LCP*），是因为 Chrome 所测量的LCP实际上是屏幕上大面积绘制的时刻，而非上述定义中“内容”可见的时刻。随着网站纷纷针对LCP做优化，出现大面积绘制却对用户毫无用处、而页面真正内容在LCP之后很久才出现的情况已屡见不鲜。遇到这种情况时，我采用的是有用内容出现的时间戳，而不是那个大而无用的更新所对应的LCP。测试的全部细节以及选择这些指标的原因在附录中讨论。

虽然 CPU 时间并非“核心网页指标”，但这里仍将其列出，因为它是一个简单且与我和其他用户在慢速设备上对可用性的感知高度相关的指标。详见附录中的讨论。CPU 时间之所以有效，一是因为即便页面在其他所有指标上表现优异，只要占用大量 CPU 时间，在慢速设备上就依然不可用。如果页面需要 100% 的 CPU 持续 30 秒，那么这 30 秒内页面将完全无法使用；如果需要 50% 的 CPU 持续 60 秒，页面在这 60 秒内也几乎无法使用，依此类推。二是因为相较于常用指标，CPU 时间很难作弊——很难在不影响用户体验的情况下对这个数字做大幅优化。

下表的配色方案是，对于体积指标，越绿表示越小/越快，越红表示越大/越慢。极端值以黑色显示。

乍一看，表格的结果基本符合直觉：那些在没有超高速设备时就感觉很慢的网站，在表格中也显示为慢速（即在低端设备上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的帧率。

从表格可以看出，如果你使用的是慢速设备，有多少网站是无法使用的。所有CPU超过10s的页面，即使在加载完成后体验也相当糟糕。滚动非常卡顿，经常掉到每秒几帧，有时甚至更低。当我们点击任何链接时，延迟之长让我们无法确定点击是否生效。如果再点一次，就会出现那种令人头疼的情况：第一次点击其实已生效，却导致第二次点击触发了错误操作；但如果一直等，又常常等得太久，因为最初的点击可能根本没生效（或者生效了，却点错了位置）。虽然 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，Tecno Spark 8C反而快了一个数量级以上。对于 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.6x / 5x (LCP* / CPU)，但在Tecno Spark 8C上，这一差距变为19x / 33x，而且按整体的扩展趋势来看，可以合理推测，如果 Discourse 能在 Itel P32 这种更便宜的设备上运行，差距还会更大。

另一个例子是 Wordpress（旧版）与 Medium 和 Substack 等更新、更时髦的博客平台相比。Wordpress（旧版）在M3 Max上比 Medium 快17.5x / 10x (LCP* / CPU)，比 Substack 快5x / 7x (LCP* / CPU)，而在Tecno Spark 8C上，则分别快4x / 19x和20x / 8x。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 速度的方向发展（在桌面端，我们大约五年前就已渐近地达到了这一点），而我们从未也永远不会朝着无限带宽的方向发展。要为重要的事情做优化。我对 @qualcomm 毫无同情。去他妈的高通，他们的工作烂透了。我希望他们倒闭，他们公司所在的那块地被撒上盐，永无再生。
• Google：移动设备在大多数情况下根本不受带宽限制，而是受延迟限制。即便是最新款 iPhone，也是在受带宽限制之前就先受 CPU 限制。如果你在 MBP 上 4 倍降速的情况下表现良好，那基本就没问题了
• ...
• Google：100% 的用户都在用 iOS 吗？
• Discourse：那些会花钱的有影响力的用户确实是，我告诉你……担心 CPU 是毫无意义的，在 iOS 上它实际上已经是无限的了，即便高通如此无能，再过四年，他们那些丢人的 SoC 也会达到这一点

当有人问 Discourse 的创始人“只是好奇你为什么讨厌他们”时，他的回应是附上一个链接，该链接引用了来自这篇 Anandtech 评测中的 Kraken 和 Octane 跑分，其中高通芯片的性能分别为当时苹果芯片的 74% 和 85%。

Discourse 的创始人兼时任 CEO 认为高通的移动端性能令人难堪，并对此感到极度反感，以至于他认为高通的工程师都应该为交付了相当于苹果 74% 至 85% 的性能而丢掉工作。苹果拥有一支我认为是史上最强的性能团队。人们对此当然可以有不同看法，但至少得承认他们是一支世界级的团队。那么，做出一款达到一支史上最强团队74% 至 85% 性能的产品，竟被视为丢人到应该失业。

这里展现了两种态度，我在许多软件从业者身上都看到过。第一种是认为 CPU 速度是无限的，无需担心 CPU 优化。第二种是认为硬件应该带来巨大的速度提升，而硬件工程师之所以未能实现这一点，唯一原因就是极其无能，因此缓慢的软件应该归咎于硬件工程师，而非软件工程师。Donald Knuth 在以下这段话中也表达了类似的情绪：

我不妨也发点牢骚，谈谈我个人对当前多核架构趋势的不满。在我看来，硬件设计师们或多或少已经黔驴技穷，他们正试图通过给我们提供只在少数关键基准测试上更快的机器，来把摩尔定律未来终结的责任推给软件开发者！如果整个多线程的想法最终被证明是一场失败，甚至比那个本该无比出色——直到人们发现所期望的编译器根本不可能写出来——的“Itanium”方案还要糟糕，我一点也不会感到惊讶。换句话说：在过去 50 年里，我写过一千多个程序，其中许多规模相当可观。我想不出其中有哪怕五个程序能通过并行或多线程得到显著提升。当然，例如，多处理器对 TeX 就毫无帮助……我知道并行确实存在重要的应用——渲染图形、破解密码、扫描图像、模拟物理和生物过程等。但所有这些应用都需要专门的代码和特殊的技术，并且每隔几年就需要大幅改动。即便我对这些方法足够了解，能在《计算机程序设计艺术》中撰写相关内容，我的时间也很大程度上会被浪费，因为很快就没什么人会去读那些部分了……我今天使用的机器有双处理器。只有当我同时运行两个独立任务时，才能同时用到它们；这很好，但每周也只有几分钟会这样。

就 Discourse 而言，如果硬件工程师无法达到史上最强性能团队 90% 的水平，就是令人难堪、不配拥有这份工作；但作为软件工程师，交付出只有未经高度优化的应用如 MyBB 3% 性能的产品，却毫无问题。就 Knuth 而言，硬件工程师几十年来每十年就给程序员带来了 100 倍的性能提升，而程序员几乎无需付出任何努力。一旦这种提升放缓，程序员需要做出调整以利用新硬件，硬件工程师就成了“黔驴技穷”，而学习一些“新”（上世纪七八十年代的）思想以利用现有硬件则成了浪费时间。以及我们之前讨论过的 Alan Kay 宣称硬件工程师“不老练”、“没受过教育”、“不是在做真正的工程”，如果听从 Alan Kay 那些“老练”想法，我们就能获得 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、@[email protected]、Justin Blank、Andy Kelley、Julian Lam、Matthew Thomas、avarcat、@[email protected]、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 的一条典型的官方评论

如果你的横幅比我们用于“推出 Discourse Splash——在网站资源加载时显示的视觉预加载器”的元素更大，你的 LCP 就会很糟糕。

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

有用内容的LCP与 Chrome 所测LCP之比最为极端的网站是：

• Wix
  • M3: 6
  • M1: 12
  • Tecno Spark 8C: 3
  • Itel P32: N/A (FAIL)
• Discourse:
  • M3: 10
  • M1: 12
  • Tecno Spark 8C: 4
  • Itel P32: N/A (FAIL)

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

附录：为网站优化的自利论据

这将取决于网站的规模及其性能，但在我曾任职的大型公司中查看这类数据时，提升网站和应用性能所带来的收益高得惊人。这在 A/B 测试中是可衡量的，而且在长期对照中，它也是对增长和留存影响相对较大的干预措施之一（许多干预措施在短期测试中表现不错，但长期来看却不那么好，而性能提升往往在长期来看表现更好）。

当然，你可以从直接数据中看到这一点，但从数据的许多侧面也能隐约看出。例如，仅以 Twitter 为例，用户可感知的 p99 延迟在印度以及若干非洲国家（即便排除埃及和南非等相对富裕的国家）约为60s，在美国也约为60s。当然，就整体人群而言，美国用户拥有更快的设备和网络，但在每个国家，都有足够多拥有慢速设备或慢速网络的用户，使得真正的限制因素其实是用户的耐心，而非人群层面设备和网络的底层分布。即便你不关心尼日利亚或印度的用户，只关心美国的广告收入，为低端设备和网络提升性能也足以在全球乃至美国收入的 A/B 测试中，尤其是在长期对照中，产生清晰可见的影响。而且，你也能在拥有高速设备的用户身上看到影响——一项将“低端”设备用户的延迟从60s降至50s的改动，可能会将高端设备用户的延迟从5s降至4.5s，这同样会对收入、增长和留存数据产生影响。

出于超出本文范围的种种原因，这类枯燥但可量化、能驱动增长和收入的工作，在我曾任职的大多数大公司中，相较于那些最终在长期对照中几乎看不到影响的花哨产品工作，一直难以获得资金支持。

附录：为低性能设备设计

在使用慢速设备或任何带宽低、连接差的设备时，迄今为止体验最好的，往往是一次性加载大量内容到静态页面中的方式。如果图片设置了正确的宽高属性和 alt 文本，会非常有帮助。渐进式图片（如渐进式 jpeg）则没什么帮助。

在带宽高但设备慢的情况下，任何轻量的静态页面都能很好地工作，轻量的动态页面如果为性能而设计也能表现不错。笨重的动态页面则注定会失败，除非其页面重量不会导致页面变得复杂。

在带宽低或连接差的情况下，轻量页面没有问题。对于笨重的页面，我体验最好的方式是触发一次页面加载，然后去做别的事，等加载完成（或至少 HTML 和 CSS 加载完成）后再回来。之后我可以把每个想看的链接都在新标签页中打开，然后再去做别的事，等待它们加载。

许多现代网站所做的优化，例如滚动到底部时部分加载并触发更多加载，以及随之而来的对搜索功能的劫持（因为如果页面未完全加载，浏览器自带的搜索就毫无用处），会让这种原本可行的交互模式失效，使页面变得极难使用。

仅举一例，不少人提到 Substack 对他们来说表现很差，因为它采用了部分加载。这是 @acidshill 录制的在 iPhone 8 上加载一篇 Substack 文章并滚动的视频，其中帖子的LCP相当快，但如果你想滚过头部，就必须等待6s让下一页加载，再次滚动时，又得再等大约1s到2s：

作为相反做法的例子，我尝试加载了一些相当大的纯 HTML 页面，例如https://danluu.com/diseconomies-scale/（0.1 MB wire / 0.4 MB raw）和https://danluu.com/threads-faq/（0.4 MB wire / 1.1 MB raw），即便在慢速设备上它们依然相当可用。1.1 MB似乎已大于最优值，将其拆分成几个页面在低端设备上会更好，但一个包含1.1 MB文本的单页，仍比大多数现代网站在慢速设备上的表现好得多。虽然当 HTML 页面大到浏览器难以处理时也会出问题，但对于内容量正常的页面，通常要到出现复杂的 CSS 负载或 JS 时，页面才开始给慢速设备带来麻烦。下面我们测试了一些相对简单的页面，其中一些包含不少媒体（有1个案例达14 MB），发现只要保持简单，这些页面都能正常工作。

Chris Adams 也提到，使用读屏软件的盲人用户经常反映，动态加载让他们的体验变得更糟。与为提升性能而做的动态加载类似，虽然这可以做得很好，但往往要么做得很糟，要么与过多其他复杂性捆绑在一起，导致结果比简单页面更差。

@Qingcharles 还提到了另一个无障碍问题——他所服务的（监狱）假释人员会获发“lifeline”手机，这些手机往往是非常低端的设备。粗略搜索可知，2024年有些人会拿到 iPhone 6 或 iPhone 8，但也有不少设备的档次比 Itel P32 更低，更不用说 Tecno Spark 8C 了。他们获得的套餐流量也极其有限，用完后，有些人“无法填写任何求职、福利申请表格，也无法用地图导航”。

对于那些做了前期工作且在低端设备上确实能提供不错体验的网站，Andy Kelley 举了一个在慢速设备上似乎表现尚可的前期工作示例（虽然在网速很慢的连接下会很吃力），即Zig 标准库文档：

我做了一个有争议的决定，让它预先获取所有源代码，然后在本地完成所有内容渲染。理论上，这是 CPU 密集型的，但在实践中……即便是那些旧手机也有非常快的 CPU！

在Tecno Spark 8C上，这需要4.7s的 CPU，之后响应就相当流畅了（相对于该设备而言——当然 iPhone 的响应要快得多）。点击链接能较快加载，滚动也基本正常（有点卡顿，但在该设备上几乎没有什么是真正流畅的）。这似乎就是人们所说的那种通过发送较重负载来获得更好性能的例子，但在低端设备上真正能提升性能的例子并不多见。

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

• 2015: Maciej Cegłowski: The Website Obesity Crisis
  • 体积：1.0 MB / 1.1 MB
  • Tecno Spark 8C：0.9s / 1.4s
    • 滚动略有卡顿，如果非常快速地滚动（从顶部一下跳到页面中部），图片需要一点时间才出现，但以正常距离滚动时，延迟低于几乎所有用户可感知的阈值。
• 2015: Nate Berkopec: Page Weight Doesn't Matter
  • 体积：80 kB / 0.2 MB
  • Tecno Spark 8C：0.8s / 0.7s
    • 做了懒加载，如果你滚完全页，页面会下载650 kB / 1.8 MB，但滚动只是略微卡顿，懒加载并未造成延迟。这可能是我在真实环境中见过的唯一一个以让慢速设备体验变好而非变差的方式实现懒加载的页面；我未在慢速网络下测试，在那种情况下这仍会让体验变差。
  • Itel P32：1.1s / 1s
    • 滚动基本不可用；滚动极其卡顿且移动距离随机，滚动到新文本时经常需要超过1s文本才渲染出来；对于懒加载的图片会更糟。即便这是我在野外见过的懒加载的最佳实现，Itel P32依然无法承受。
• 2017: Dan Luu: How web bloat impacts users with slow connections
  • 体积：14 kB / 57 kB
  • Tecno Spark 8C：0.5s / 0.3s
    • 滚动和交互正常。
  • Itel P32：0.7s / 0.5 s
• 2017-2024+: Alex Russell: The Performance Inequality Gap (series)
  • 体积：82 kB / 0.1 MB
  • Tecno Spark 8C：0.5s / 0.4s
    • 滚动和交互正常。
  • Itel P32：0.7s / 0.4s
    • 滚动和交互正常。
• 2024: Nikita Prokopov (Tonsky): JavaScript Bloat in 2024
  • 体积：14 MB / 14 MB
  • Tecno Spark 8C：0.8s / 1.9s
    • 滚动时，图片需要一段时间（约500ms）才显示，滚动也不流畅，但卡顿不至于让人难以滚到正确位置。
  • Itel P32：2.5s / 3s
    • 滚动不流畅。精准滚动有点困难，但如果非常小心，一般仍能滚到想去的位置。滚动较大距离时，通常需要略多于1s新内容才会出现。
• 2024: Dan Luu: This post
  • 体积：25 kB / 74 kB
  • Tecno Spark 8C：0.6s / 0.5s
    • 滚动和交互正常。
  • Itel P32：1.3s / 1.1s
    • 滚动和交互正常，不过我为此做了一处改动——本文原本嵌入了一个视频，Itel P32基本无法处理。
      • 注意，虽然这些数字比“Page Weight Doesn't Matter”更差，但该页面在加载后是可用的，而另一页面则不可用，因为它执行了某种对这部手机来说过于复杂的懒加载，无法在合理时间内完成。
        

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

随着编程变得越来越体面、越来越赚钱，我观察到的一件事是，从业者越来越倾向于来自富裕家庭，与不同收入水平人群的接触也越来越少。我们之前讨论过的一个例子是，在一家知名且备受推崇、员工整体极度倾向自由派的初创公司，每个人都赚得盆满钵满，在一次关于新冠刺激支票的讨论中，在 Slack 讨论里，一位善意的进步派员工说这毫无意义，因为人们只会拿刺激支票去买股票。这个人显然从未与任何中产（更不用说贫困）人群谈论过他们的钱花在了哪里，也没有看过关于谁拥有股权的数据。而这还仅仅是审视美国的财富状况。当我们放眼全球财富时，人们的整体认知水平要低得多。人们似乎真的低估了世界范围内财富和收入的动态范围。据我与不少人的交谈，许多人脑中似乎只有“按美国标准算穷”（拿刺激支票买股票）和“按全球标准算穷”（也许甚至不买股票）这两个筐，但世界范围内的贫困差距之大，远超美国国内的贫困差距，其程度是许多富裕程序员所未意识到的。

仅举一例，在这场关于我父母来到美国我在经济机会上有多幸运的讨论中，有人提到这没什么大不了，因为他们在波兰也有很好的经济机会。首先，就讨论的主题——某人最终获得高薪编程工作（在高薪科技公司担任资深员工工程师）或同等机会的概率而言，我怀疑，当我出生时，在美国出生于贫困家庭的几率要好于在波兰出生于相当富裕家庭的几率，但如果有人拿出数据证明相反情况，我也可以接受。但如果我们比较的是波兰与美国 vs 越南与美国，如果我花15秒粗略查找这些国家在我出生那年的大致财富数据，美国与波兰的人均 GDP 之比约为 8:1，而波兰与越南之比则约为 50:1。波兰与越南之间的财富差距大约是美国与波兰差距的平方，因此波兰 vs 越南大致相当于波兰 vs 某个比美国富裕程度超过美国之于波兰的假想国家。这两者完全不可同日而语，但许多人脑中的模型似乎是只有“富国”和“不富的国家”，而“不富的国家”都大致在同一个筐里。人均 GDP 并非理想指标，但它比按分位数的收入统计更容易找到；我快速搜索还发现，当时越南的年收入大约是每年200-300美元。越南当时还正经历一场饥荒的尾声，其影响有点难以确定，因为这里的统计数据似乎被操纵过，但如果你相信死亡率统计，这场饥荒导致总体死亡率飙升至正常基线的两倍¹。

当然，当时，低收入国家的中位人群不会拥有电脑，更不用说互联网接入。但今天，低收入国家的人们拥有设备已相当普遍。许多人似乎要么没有意识到这一点，要么不理解这些人中的许多人使用的是何种设备。

附录：来自 Fabian Giesen 的评论

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

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

这还有一些次生影响。例如，在美国，iMessage 在群聊等方面非常流行，并且以与安卓设备互操作性极差、让安卓用户体验非常糟糕而臭名昭著（几乎可以肯定是故意的）。

在欧盟，至少因为安卓更为普及，iMessage 没那么流行，据我所知，即便是我认识的 iPhone 用户中那些在美国可能会使用 iMessage 的人，也更倾向于使用 WhatsApp。

关键在于，从全球来看，近期 iOS 加上高速网络的组合，比许多美国应用开发者所意识到的更偏向某一特定人群。

而关于移动应用与网页应用体积的评论，Fabian 说：

再补充一个来自经验的说明：你在安装时安装应用，并且通常有机会在网络缓慢或按流量计费时（或根本没有流量时）暂缓更新。

当初我刚拿到美国手机时，由于没有美国信用记录，不得不使用预付费套餐。我至今仍在使用，因为它对我大多数时候实际使用手机的方式来说已经足够，但这确实意味着当我一年一度前往德国时，我根本无法获得数据漫游。（而且，在德国打电话每个要花我1.50美元，即便 T-Mobile 是德国最大的移动运营商——当然，不是 T-Mobile US。）

关键在于，我在 T-Mobile 热点（如主要火车站、机场等）以及有热点覆盖的城际列车上确实能接入免费高速 Wi-Fi，但在德国期间我实际上没有任何数据套餐。

对于那些可离线工作并在有连接时同步数据的手机原生应用来说，这完全没问题。但网页应用在我不在公共 Wi-Fi 附近时就无法使用。

同样，我完全可以通过 Gmail 应用在缓慢的按流量计费的连接上发送邮件，但在按流量计费的连接上，我绝不会使用任何需要下载几 MB 压缩 JS 才能做任何事的网页邮件客户端。

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

Fabian 的另一条评论（此次为转述，因为这来自一次对话）是，人们常常会因为某个东西本该很慢的定性原因，而为其在定量上慢得离谱辩护。他举的一个例子是，屏幕同步连接往往需要很长时间，这被解释为因为有必须完成的操作需要时间。很长一段时间里，这些操作往往需要数秒。最近，许多显示器同步得快多了，因为英伟达对“G-Sync”认证规定了这一过程所需的时间上限，因此显示器制造商现在确实能在合理时间内完成。虽然确实存在必须完成且需要时间的操作，但并没有根本原因导致它们需要像过去那样花那么多时间。他举的另一个例子是，有人解释读取数千个文件为何耗时很长，理由是该操作需要大量系统调用而“系统调用很慢”，这在定性上是正确的，但如果你查看系统调用的实际开销，在所讨论的案例中，系统调用的开销与解释读取数千个文件为何耗时如此之长所需的开销相差了好几个数量级。

就此话题而言，当有人指出某个现代网站很慢时，总会有人以定性的辩护回应，称该现代网站拥有旧网站所缺乏的那些出色功能。虽然（例如）Discourse 确实拥有 MyBB 所没有的功能，但很难说其功能集足以证明慢33x是合理的。

附录：实验细节

除了 danluu.com 和勉强可算的 HN 之外，对于每个网站，我都尝试寻找“最默认”的体验。例如，对于 WordPress，这意味着使用当前默认主题 twentytwentyfour 的演示博客。在某些情况下，这可能不是当今人们最可能使用的东西，例如对于 Shopify，我查看的是在浏览其主题时他们给你的第一个主题，但我并未尝试查找主题数据以确定最常用的主题是什么。对于本文，我希望将所有数据收集和分析作为一个短期项目，在一天内完成，因此有许多像这样的捷径，下文将有所描述。我认为使用 Shopify 展示的第一个主题并无不妥——相当一部分用户可能会使用第一个展示的主题——但这当然不如抓取最常见的主题，然后再测试许多使用该主题的不同真实网站，以观察人们为自用而修改主题时真实性能如何变化那样具有代表性。如果我在 Shopify 工作或想代表其竞争对手做竞品分析，我会那样做，但对于一个关于大型网站如何影响低端设备用户的一天项目而言，此处展示的 Shopify 性能似乎已经足够。我实际上在二月份进行这些投票时就已完成了这项初步工作，只是直到一个月后才有时间真正整理成文。

对于笔记本电脑上的测试，我尽量让笔记本电量保持在约60%，不插电，并且让笔记本空闲足够长时间以在20°C的房间内恢复到热平衡状态，因此页面不应受到此前页面加载或其他此前在机器上发生的任务的影响。

对于手机测试，手机电量约为100%并保持插电，且此前也保持在100%电量，因此手机不会出现快速充电可能带来的发热效应。如上所述，这些测试在1Gbps WiFi 下进行。没有其他应用在运行，浏览器没有其他标签页，设备上也只安装了必要的应用，因此除了设备默认会运行的任务外，不应有额外的后台任务在运行。拥有相同设备的真实用户在几乎所有情况下都会看到比我们此处测得的更差的性能，除非在手机上运行 Chrome 开发者工具会显著降低性能。我注意到，在 Itel P32 上，运行开发者工具时的滚动比正常运行时要更卡顿一些，但由于这是一个一天的项目，我并未尝试量化这一点以及它是否对某些网站的影响远大于其他网站。就绝对值而言，开销不会太大，因为最快的网站在运行开发者工具时依然相当快，但如果存在某种与网站工作量呈超线性关系的开销（可能是间接的，如果它导致某种资源耗尽），那么这可能会对某些网站的测量造成问题。

体积均在移动端测量，因此在移动端与桌面端加载不同资源的情况下，我们测量的是移动端资源的体积。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
  • Oookla
    • Ookla 网页应用加载失败，无法查看结果
• Itel P32
  • Netflix
    • 下载：44 Mbps
    • 上传：测试无法工作（发送一块数据后就卡住，不再发送数据）
    • 延迟（空载 / 负载）：4ms / 400ms
  • Okta
    • 下载：45 Mbps
    • 上传：测试无法工作
    • 延迟：测试无法显示延迟

需要注意的一点是，Itel P32实际上并没有能力用满它名义上的带宽。查看排名靠前的谷歌评测，没有一篇提到这一点。第一篇评测写道

性能方面，手机不卡顿。它搭载最新的 Android 8.1（GO 版）……我们拥有 8GB+1GB 的 ROM 和 RAM，运行在 1.3GHz 四核处理器的强劲动力之上，可轻松多任务……我对 P32 的功能印象深刻，尤其是考虑到它的价格。我会向那些经常在外奔波的人推荐它。而对于那些将智能手机续航视为第一优先级的人来说，P32 是你的最佳选择。

第二篇评测写道

Itel mobile 是非洲排名前列的分销商之一，在大陆范围内排名第3……轻量操作系统达到了我们的预期，在 1GB RAM 的设备上没有出现迟缓……相当快的处理速度……Itel P32 智能手机的表现超出了其能力范围……以高达 UGX 330,000 的价格标签，Itel P32 是那些以惊人价格标签封装在单一套餐中的出色低端智能手机之一，值得被授予中端旗舰的称号。

第三篇评测写道

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

关于各网站的说明：

• Wix
  • www.wix.com/website-template/view/html/3173?originUrl=https%3A%2F%2Fwww.wix.com%2Fwebsite%2Ftemplates%2Fhtml%2Fmost-popular&tpClick=view_button&esi=a30e7086-28db-4e2e-ba22-9d1ecfbb1250：这是我点击获取主题时出现的第一个条目
  • LCP在所有设备上都具有误导性
  • 在Tecno Spark 8C上，滚动基本无法正常工作。非常卡顿且始终无法稳定下来
  • 在Itel P32上，页面会非确定性地失败（不同次加载出现不同错误）；可能需要相当长时间才会报错；第一次运行时为23s，CPU 占用峰值为28s
• 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。同样值得注意的是，在快于2秒的加载中，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 加上我听说现在在 Quora 上很活跃的一位 metafilter 用户的用户名。谷歌并未返回其个人主页，而是返回了这个页面，该页面似乎与我搜索的用户毫无关系。因此，这与社交媒体个人主页不可比，但从谷歌获得随机的、不相关的 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 (old)
  • 使用 thezvi.wordpress.com，因为它与 Zvi 的 substack 内容相同，且恰好使用某个曾是非常常见选择的旧 wordpress 主题
• phpBB
  • www.phpbb.com/community/index.php：这是搜索官方论坛时出现的结果。
• MyBB
  • community.mybb.com：这是搜索官方论坛时出现的结果。
  • 网站未提供移动版。一般来说，我发现在慢速设备上，网站的桌面版明显好于移动版，因此这表现得相当好，尽管他们可能因此被谷歌惩罚。
• 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 的一位创始人建议才尝试的，他说“我很想看看 @[email protected] 在你的测试中表现如何。多年来我们花了相当多时间让它变得极快，我个人认为，至少在速度和初始负载方面，它比 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 及其缓存命中率。像 Medium 和 Substack 这样可定制性相对较低的网站，得分将基本与此处相同。实际上，从观察现有网站来看，大多数用户创建的网站会比 Wordpress 和 Ghost 的“最默认”主题更慢，尽管对于本博客的读者而言，平均而言可能恰恰相反，因此你可能需要测试多种不同的网站风格。

附录：本站与在慢速设备或慢速网络下无法工作的网站

顺带一提，有一件我觉得很有趣很久的事是，我收到了大量关于本站样式的仇恨邮件（以及数量相当的感谢邮件）。所谓仇恨邮件，我指的不是客气地建议改动，而是相当于路怒，但在网页浏览中的发作；可称之为网页之怒。我认识一些人，他们运营的网站复杂到让世界上相当一部分人无法使用。为什么人们会对本站的样式如此愤怒，而按比例来说，却几乎完全不关心网络对如此多人的不可用性呢？

另一件有趣的事是，那些欣赏本站样式的人通常欣赏的是本站没有覆盖任何默认样式，让你可以通过设置窗口大小来将宽度调整为你想要的任何值，并且也不会覆盖你应用于网站的任何默认样式。那些对此非常坚持的人希望每个人都有他们偏好的某种宽度限制、某种字体等，但这总是以一种方式来表述，仿佛他们并非为自己争取，而是为了大众的利益，即便迎合网页愤怒者的偏好会直接违背那些（例如）偏好通过调整窗口宽度来调整文本宽度的人的偏好。

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

持有这种推理的网页愤怒者似乎无法吸收他们的偏好并非普遍这一信息，并会坚持认为无论人们说自己喜欢什么，都是错的，我觉得这相当有趣。从数据来看，当我从 Octopress 样式（当时，编程博主中最流行的样式）切换到当前样式时，我得到了看似因果性的流量和参与度增长，因此似乎不仅给我写感谢邮件赞赏样式的人喜欢这种样式，那些不给我写信的人的整体感受似乎也认为该网站尚可，并且显然比标准的程序员博客样式更具吸引力。当我指出这一点时，人们往往会更加坚信他们的偏好是普遍的，并认为那些自认为有其他偏好的人是错的，进而回复完全 nonsense 的内容。

需要明确的是，我绝不会声称本站的设计是最优的。我只是移除了当时程序员最流行的博客平台中的 CSS，因为那些 CSS 对低端网络用户来说客观上很糟糕，结果作为副作用，总体上获得了更多流量和参与度，而不仅仅来自那些倾向于拥有低端网络和设备的地区。毫无疑问，一个关心低端网络和设备用户的设计师可以做得更好，但关于此事的不诚实和激烈言辞，确实有些奇怪。