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）がある。その次に、デバイスごとにLargest Contentful Paint*（LCP*）とメインスレッドのCPU使用量（CPU）がある。GoogleのドキュメントではLCPを次のように説明している。

Largest Contentful Paint（LCP）は、ユーザーがページの最大のコンテンツが表示されたと知覚するタイミングを測るものです。LCPの値は、ユーザーがページ読み込みを開始してから、ページが主要なコンテンツを描画するまでの時間です

LCPはGoogle PageSpeed Insightsで主要な指標の一つ、「Core Web Vital」として提示されているため、最適化のターゲットとしてよく使われる。ここでLCPにアスタリスクを付けているのは、Chromeで計測されるLCPが上記の定義のような「コンテンツ」ではなく、画面の大きな領域が描画されたタイミングを測っているためだ。サイトがLCPに最適化するにつれ、ユーザーにとってまったく無意味な大きな描画がLCPとして記録され、実際のコンテンツはそのずっと後に表示される、ということが珍しくなくなっている。そうしたケースでは、無意味な大きな更新がLCPとして記録された時点ではなく、有用なコンテンツが表示された時点のタイムスタンプを用いている。テストの詳細やなぜこれらの指標を選んだかは付録で述べる。

CPU時間は「Core Web Vital」ではないが、ここで示しているのは、低速端末での体感的な使いやすさと非常に強く相関する、シンプルな指標だからだ。詳しくは付録を参照。CPU時間が指標として機能する理由の一つは、他のすべての指標が優れていてもCPU時間を大量に使っていれば、そのページは低速端末では使い物にならないからだ。CPUを100%で30秒使い続ければ30秒間まったく使えず、50%で60秒なら60秒間かろうじてしか使えない、といった具合だ。もう一つの理由は、よく使われる指標と比べて、CPU時間はごまかしが難しく、ユーザー体験に影響を与えずに数値だけを大きく動かすような最適化がしにくいことだ。

下の表の配色は、サイズについては緑が濃いほど小さい／速く、赤が濃いほど大きい／遅いことを示す。極端な値は黒で示している。

表を一見すると、超高速なデバイスを持っていないと遅く感じるサイトが、表でもきちんと遅い（つまり低スペック端末でmax(LCP*,CPU)が高い）ものとして現れていて、概ね妥当だ。低速端末ではどのプラットフォームが最も速く、どれが最も遅いと思うかアンケートを取ったところ（Mastodon、Twitter、Threads）、回答者は概ね正しく、WordpressやGhostはSubstackやMediumより速く、DiscourseはphpBBやXenForo、vBulletinといった古いPHPフォーラムよりずっと遅いと予想した。Google PageSpeed Insights（PSI）のスコアも取得したが（表には非表示）、そちらの数値との相関はそこまで強くない。なぜなら、一部のサイトはページを実際には速くしていないのにPSIスコアだけを最適化することに成功しているからだ。

こうした低スペック端末を使ったことがない人のために説明すると、一般的な体験として、多くのサイトはその端末では使い物にならず、リソースを大量に食うもの（アプリや巨大なウェブサイト）を読み込むとクラッシュすることがある。リソースを食うアプリの中でさらに重い操作をしてもクラッシュする。レビューではPUBGのような3Dゲームもまずまずの性能で動くと指摘されている Tecno Spark 8Cでさえ、現代のテキスト中心のSNSやテキスト中心のウェブフォーラムで投稿を読むには性能が足りない。PUBGでは40fpsが出せる一方で、これらのサイトをスクロールすると0.4fpsを下回ることすら容易にある。

表から、低速端末を持っているとどれだけ多くのサイトが使い物にならないかがわかる。10s+ CPUのページはすべて、読み込み後でさえかなりひどい体験だ。スクロールは非常にカクつき、しばしば数fpsまで落ち、時にはそれ以下になる。リンクをタップしても遅延が長すぎて、タップが本当に効いたのかどうかわからない。もう一度タップすると、一回目のタップが登録され、それによって二回目のタップが誤った動作を引き起こすという、あの恐ろしい事態になる。かといって待っていると、元のタップがそもそも登録されていなかった（あるいは登録されたが思った位置ではなかった）ために、待ちすぎることも多い。MyBBはモバイル向けサイトを提供しておらず、モバイルフレンドリーでないとしてGoogleからペナルティを受けているが、スクロールやタップが実際に機能するため、こうした低速モバイルでは最も高速なサイトを除くすべてのサイトよりずっと使いやすい。

また、異なるデバイス間での相対的な性能のばらつきがどれだけ大きいかもわかる。例えばM3/10とTecno Spark 8Cを比べると、danluu.comやGhostではM3/10がTecno Spark 8Cのそこそこまともな近似になっているが（danluu.comは読み込みが速すぎるものの）、Medium、Substack、TwitterではTecno Spark 8Cの方がCPUで約3倍遅く、RedditやDiscourseではざっと4倍遅く、Shopifyでは逆に一桁以上速い。WixではCPUの近似はだいたい合っているが、LCP*ではTecno Spark 8Cの方が3倍以上遅い。Chromeを使えば手元のPCから手軽に低速デバイスをシミュレートできるのは素晴らしいが、ChromeのCPUスロットリングを有効にするだけ（あるいはすぐに使えるオプションをどんな組み合わせで使っても）では、実際のデバイスで得られる結果とはかなり異なる。詳しい理由は本稿の範囲を超えるが、ここで言えるのは、遅いページはデバイスが遅くなるほど超線形に遅くなり、あるページでの遅さが別のページでの遅さを強く予測するわけではない、ということだ。

デバイス中心ではなくサイト中心に見ると、Discourse、Medium、Redditのようなサイトは、高速なM3やM1ではそれほどCPUを使わないのに、Tecno Spark 8Cでは最も遅い部類に入る（RedditのCPUは∞と表示している。何も操作せずいくら待っても~90% CPUを使い続けるためだ）。Discourseは、少し操作したり、ただ放置したりするだけでブラウザがクラッシュすることもある。例えば、一度はDiscourseを読み込み、2回スクロールしてから1〜2分放置しただけでブラウザがクラッシュした。一貫性のためにこれは表ではFAILとしていない。ページ自体は読み込まれたからだ。しかし現実には、ブラウザがクラッシュするほどリソースを食うページは、表のFAILのどのケースよりもはるかにひどいユーザー体験だ。ウェブの肥大化が低速回線のユーザーに与える影響を見たとき、ウェブの多くが低速回線の人にとって使い物にならないことがわかったが、低速端末でも同じだ。

見て取れるもう一つのパターンは、古いサイトの方が概して新しいサイトより速いということだ。視覚的に10年、20年アップデートされていないように見えるサイトほど、最も速い部類に入る傾向がある。例えばMyBBは、最もモダンでなく最も古臭く見えるフォーラムだが、M3ではDiscourseより3.6x / 5x 速い (LCP* / CPU)。しかしTecno Spark 8Cではその差は19x / 33xで、全体のスケーリングを考えると、もしDiscourseがこんな安い端末で動いたとすれば、Itel P32では差はさらに大きいと推測できる。

もう一つの例がWordpress（old）とMediumやSubstackのような新しい流行りのブログプラットフォームとの比較だ。Wordpress（old）はM3 MaxでMediumより17.5x / 10x 速く (LCP* / CPU)、Substackより5x / 7x 速い。そしてTecno Spark 8Cではそれぞれ4x / 19x、20x / 8x速い。Ghostはこの例外として目立つ存在で、モダンなプラットフォーム（Mediumの1年後にローンチ）でありながら古いプラットフォームに匹敵する（モダンなWordpressも一応例外と言えるが、多くの人はまだ古いプラットフォームと見なすだろう）。フォーラムの中ではNodeBBも少し例外のようだ（詳細は付録参照）。

Discourse、Reddit、Substackのように、ページを部分的に読み込んでから残りを動的に読み込むようなモダンな手法を使うサイトは、表のスコアが示す以上に使いづらい傾向がある。原理的には、そうしたサイトを安い端末でもうまく動くシンプルな作りにすることは可能だが、実際には動的読み込みを使うサイトは複雑すぎて、低スペック端末では極めてカクつく。予測可能な距離だけスクロールすることが概ね困難で、ユーザーが少しスクロールしすぎただけで追加の読み込みがトリガーされ、ページがロックする。多くのページはスクロールするにつれて過ぎ去った部分を実際に削除するが、そうしたページはすべて実質的に使い物にならない。ページ内検索のような基本的なウェブ機能も、概ね動かなくなる。こうした動的読み込みを行うページは、シンプルで高速なctrl/command+Fの検索に頼ることができず、自前の検索を実装しなければならない。これがどれだけうまく動くかはまちまちだ（これはGoogleドキュメントでは以前はかなりうまく動いていたが、ここ数ヶ月、あるいは1年ほどは読み込みに時間がかかりすぎて、ブラウザの使い物にならない組み込み検索をトリガーしないよう、ドキュメントを開いた後に意図的に待たなければならない。Discourseの検索は低速端末では、あるいは特に遅いわけでもないが超高速でもない端末でも、まともに動いたことがない）。

原理的には、読み込み時に大量のCPUを消費するこうしたモダンなページは、後の操作を、事前作業の少ないページよりも速く安くするための先行投資をしている可能性がある（こうしたページを支持する際によく出る主張だ）が、テストしたページではそうなっていない。初期読み込みも、後続の読み込みも、読み込み後の動作もすべて遅い。

なぜ事前にこれだけの作業をやっても後で速くならないのかを理解するために、Googleのディスティングイッシュド・エンジニアとDiscourseの創業者の一人（当時のCEO）との次のやり取りが象徴的だ。モバイルサイトは帯域を絞ったノートPCでテストすべきで、CPUは絞るべきではないとDiscourseの創業者が語る議論の中で：

• Google: 君だって低速な3Gを持っていない。この二つの設定はセットだ。共感はトンネル内のiPhone XSユーザーだけに留まるべきではない。
• Discourse: 文字通り、iPhone 6以降のどんな電話も基本的に「平均的な」ノートPCと同じくらい速い。Qualcommがどれだけ仕事ができないかを理解する必要がある。信じられないなら調べてみろ。
• Google: 信じる必要はない。知っている。これは気にかける人にはよく知られたことだ。言いたかったのは、誰もが高速な回線を持っているわけではないのと同じで、誰もが高速な電話を持っているわけではないということだ。確かにiPhone 6は現実のウェブサイトで頻繁にCPUバウンドになる。だがそれが要点ではない。
• Discourse: 僕らは何十年も無限のCPU速度に向かって進んできた（そしてデスクトップでは約5年前からほぼそこに到達している）。僕らが向かっておらず、決して向かわないのは無限の帯域幅だ。重要なことを最適化しろ。そしてQualcommにはまったく共感しない。クソくらえだ、あいつらは仕事がひどすぎる。潰れてしまえばいいし、会社があった土地は塩をまかれて二度と何も育たないようにしてほしい。
• Google: モバイルデバイスはほとんどの状況で帯域幅に制約されているわけではない。レイテンシに制約されているんだ。最新のiPhoneでさえ、帯域幅に制約される前にCPUに制約される。MBPで4倍のスローダウンでうまくいけば、かなり大丈夫だ
• ...
• Google: ユーザーの100%がiOSなのか？
• Discourse: 金を払う影響力のあるユーザーはそうなる傾向がある、と言っておこう……CPUを心配するのは無意味だ、iOSではすでに実質無限だし、Qualcommの無能さをもってしても、あと4年もすればあの恥ずかしいSoCでもそうなる

誰かがDiscourseの創業者に「なぜそんなに嫌っているのか」と尋ねると、彼はこのAnandtechレビューのKrakenとOctaneベンチマークを引用したリンクで答える。そこではQualcommチップが当時のAppleチップのそれぞれ74%、85%の性能となっている。

Discourseの創業者にして当時のCEOは、Qualcommのモバイル性能を恥ずべきものと考え、それがあまりに許しがたいので、当時のAppleチップの74%から85%の性能しか出せないことでQualcommのエンジニア全員が職を失うべきだと考えている。Appleには私は史上最高クラスの性能チームがいると考えている。これについては異論もあり得るが、少なくとも世界クラスのチームと見なさなければならない。だから、史上最高のチームの74%から85%の製品を出したことが、職を失うに値する恥とされる。

ここには、私が多くのソフトウェア関係者に見てきた二つの態度が表れている。一つ目は、CPU速度は無限であり、CPUの最適化を心配すべきではないという考え方だ。二つ目は、ハードウェアによる巨大な高速化は当然期待されるもので、ハードウェアエンジニアがそれを達成できないのは驚くべき無能のせいでしかなく、だから遅いソフトウェアはソフトウェアエンジニアではなくハードウェアエンジニアのせいにすべきだという考え方だ。ドナルド・クヌースも次のように似た感情を表明している。

現在のマルチコアアーキテクチャへの流れについて、個人的な不満を少しぶちまけておこう。私には、ハードウェア設計者がアイデアを使い果たし、ムーアの法則の将来の終焉の責任をソフトウェア書きに押し付けようとしているように見える。いくつかの主要なベンチマークでだけ速く動くマシンを与えることでね！マルチスレッドというアイデア全体が、「Itanium」アプローチよりもひどい失敗に終わっても、私はまったく驚かないだろう。あれは素晴らしいはずだったのに——望まれたコンパイラを書くのが基本的に不可能だとわかるまでは。こう言わせてほしい。過去50年間、私は大小含めて1000本以上のプログラムを書いてきたが、そのうち並列性やマルチスレッドによって noticeably 強化されたであろうと思えるものは5本すら思いつかない。確かに、例えばマルチプロセッサはTeXの助けにはならない……並列性が重要なアプリケーションが存在することは知っている——グラフィックスのレンダリング、暗号解読、画像スキャン、物理・生物プロセスのシミュレーションなどだ。しかしこれらのアプリケーションはすべて専用のコードと特殊な手法を必要とし、それらは数年ごとに大幅に変更される必要がある。たとえ私がそうした手法についてTAOCPで書けるほど十分に知っていたとしても、私の時間は largely 無駄になるだろう。なぜなら、すぐにそれらの部分を読む理由が誰にもなくなるからだ……私が今日使っているマシンはデュアルプロセッサだ。両方を使えるのは、2つの独立したジョブを同時に走らせるときだけだ。それはいいことだが、週に数分しか起こらない。

Discourseの場合、ハードウェアエンジニアは史上最高クラスの性能チームの90%に達しなければ恥ずかしくて職に値しないとされる一方で、ソフトウェアエンジニアとしては、特に高度に最適化されているわけでもないMyBBのようなアプリケーションの3%の性能しか出せなくても何の問題もない。クヌースの場合、ハードウェアエンジニアは、プログラマ側がほとんど何もしなくても、数十年にわたって10年ごとに100倍の性能向上を与えてきた。そのペースが落ち、プログラマが新しいハードウェアを活かすために適応しなければならなくなった途端、ハードウェアエンジニアは「アイデアが尽きた」ことになり、一方で現在のハードウェアを活かすためのいくつかの「新しい」（1970年代や80年代の）アイデアを学ぶことは時間の無駄になる。そして以前に議論したように、アラン・ケイはハードウェアエンジニアは「洗練されておらず」「教育が足りず」「本当のエンジニアリング」をしていないと主張し、アラン・ケイの「洗練された」アイデアに耳を傾ければ1000倍高速化できるとしている。

プログラマがハードウェアがすべての問題を解決してくれると期待し、それが起こらないと問題をユーザーに押し付け、なぜプログラマがユーザーを助けるために何もする必要がないのかを説明するのは、かなりよくあることだ。そこで問うべきは、プログラマがどれだけの性能向上を私たちにもたらしてきたかということだ。大幅な高速化をもたらすアルゴリズムの改善の事例はあるが、上で述べたように、今日最も急速に成長しているフォーラムソフトウェアであるDiscourseは、おおよそ1000000xの性能低下をもたらしたように見える。

上記で示されているもう一つのよくある態度は、裕福でないユーザーは重要ではないという考えだ。ユーザーの100%がiOSかと問われて、Discourseの創業者は「金を払う影響力のあるユーザーはそうなる傾向がある、と言っておこう」と言う。同じ態度はTonskyのJavaScript Bloat投稿のコメントの至る所にも見られ、「電話アプリは何百メガもあるのに、なぜ数メガのウェブアプリにこだわるのか？アフリカの飢えた子供たちはAndroidアプリはダウンロードできるのにウェブアプリはできないとでも？冗談でしょう」や「まあ、gitlabのユーザーが低速デバイスしか持てないほど貧しいなんてことはないでしょう、真面目に」といったカクテルパーティー的な感想が並んでいる。

しかしアフリカでダウンロードされているアプリのサイズを見ると、ハイエンド端末を持っていない人々はFacebook Lite（数メガ）のようなアプリを使い、一般的に一桁から十数メガのアプリをよく使っている。アプリメーカーがアプリサイズを気にする理由は複数ある。一つは単純に電話のストレージ容量だ。実際のユーザーがアプリをインストールするのを見ていると、新しいアプリを入れるために何かを削除したりアンインストールしたりすることがよくあり、サイズが小さいほどインストールしやすく、アンインストールされる可能性も低くなる。もう一つは、アプリのサイズと使用状況に関するデータを見ると（これについて公的なデータは知らない。もし参照できるものがあれば教えてほしい）、大きなアプリがサイズとメモリ使用量を増やすとクラッシュが増え、それがユーザーの維持、成長、エンゲージメントを押し下げ、逆にサイズとメモリ使用量を最適化するとクラッシュが減り、維持、成長、エンゲージメントが改善することだ。

Alex Russellは、iOSはインド（14億人市場）で7%、ラテンアメリカ（6億人市場）で6%のシェアしかないと指摘している。Discourseの創業者はこれらは「影響力のあるユーザー」ではないと言うが、それでも彼らは生身の人間だ。Alexはさらに、Windowsのテレメトリによれば、それは大多数のデスクトップユーザーをカバーしているが、ほとんどのノートPC／デスクトップユーザーは現代のiPhoneより遅い可能性が高いローエンドマシンを使っているとも指摘している。

「プログラマで低速デバイスを持っている人なんていない」という話については、私はお下がりの古くて遅いデバイスを使っている人をたくさん知っている。彼らの多くは貧しいわけですらない。ただ、例えば子供に超高速なデバイスが必要だとは思っておらず、現代のウェブのどれだけが低速端末でまともに動かないかを理解していないのだ。結局、「遅い」デバイスでも3Dゲームはプレイできるし、（適切なOSなら）LinuxやChromiumのようなコードベースをコンパイルすることさえできるのだから、なぜgitlabのようなサイトとやり取りできないのか、というわけだ。

Discourseの創業者が、数年以内にすべてのAndroidユーザーが何らかの超高速Androidデバイスを使うようになると主張したのとは反対に、その発言から6年が経った今、世界中の電話ユーザーのほぼ全員が高性能デバイスを持つようになるまでには少なくともあと10年はかかり、20年以上かかる可能性も十分にある。Discourseの市場シェアを調べてみると、非常に成功している。世界で圧倒的に最も急速に成長しているフォーラムソフトウェアのようだ。世界で最も急速に成長しているフォーラムソフトウェアが、当時のリーダーが「金を払う影響力のあるユーザー」ではなく「無限のCPU速度」を持たないユーザーのことなどあまり気にしないと明言する組織によって作られたことの影響は、多くのフォーラムが、世界的な基準で見て新品の現行iPhoneに相当するものを買うだけの富を持たない人々にとってアクセス不能になっているということだ。

もし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としてマークされないよう、慎重にそれより大きな変化が起きないようにする。

VWが排出ガスの数値をどうごまかしていたかを公に語らなかったのと同じ理由で、開発者はこうした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 (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に改善するかもしれず、それも収益、成長、維持の数字に影響するからだ。

このドキュメントの範囲を超える様々な理由で、この種の地味で定量的に成長や収益を押し上げる仕事は、私が勤めたほとんどの大企業で、長期ホールドバックでほとんど影響を示さない派手なプロダクト開発に比べて資金を得るのが難しかった。

付録: 低性能デバイス向けの設計

低速端末や帯域が低く／接続性が悪いデバイスを使うとき、圧倒的に最高の体験は、大量のコンテンツを一度に静的なページに読み込むものだ。画像に適切なwidthとheight属性や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が出てくるまでは低速端末で問題を起こし始めない。下では比較的シンプルなページをテストしており、その中にはかなりのメディア（あるケースでは14 MB）を含むものもあるが、シンプルさを保っている限りこれらのページは問題なく動くことがわかる。

Chris Adamsは、視覚障害者でスクリーンリーダーを使っている人々が、動的読み込みによって体験がはるかに悪化するとよく報告していることも指摘している。性能向上のための動的読み込みと同様、これはうまくやることもできるが、しばしば杜撰に実装されたり、他の複雑さと抱き合わせにされたりして、結果はシンプルなページより悪くなる。

@Qingcharlesは別のアクセシビリティの問題を指摘した——彼が支援している（刑務所の）仮釈放者たちは「lifeline」電話を支給されるが、それはしばしば非常に低スペックな端末だ。ちょっと検索しただけでも、2024年にはiPhone 6やiPhone 8を支給される人もいるが、Itel P32はおろかTecno Spark 8Cよりも低スペックな端末もたくさんある。彼らはデータ容量が非常に限られたプランも支給され、使い切ってしまうと「仕事や福祉の申請書を提出したり、Mapsで道案内したりすることがまったくできない」人もいる。

低スペック端末でもまともな体験を提供するために事前作業を行うサイトの例として、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以上かかる。遅延読み込みされる画像ではさらにひどくなる。これまで野放しで見た中で最高の遅延読み込み実装ではあるが、この電話にはまだ荷が重すぎる。
• 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での議論で、善意の進歩的な従業員が、それは株式を買うのに使われるだけだから無意味だと言った。この人物は、どうやら中流（ましてや貧困層）の人がお金をどこに使うのかについて誰とも話したことがなく、誰が株式を保有しているかというデータも見たことがなかったようだ。そしてそれはアメリカの富だけを見た話だ。世界の富を見ると、一般的な理解度はさらに低い。人々は世界の富や所得のダイナミックレンジを本当に過小評価しているように見える。かなり多くの人とこの話をしてきたが、多くの人は「アメリカの基準で貧しい」（給付金で株を買う）と「世界的な基準で貧しい」（株すら買わないかもしれない）という心のバケツを持っているように見えるが、世界の貧困の範囲は、アメリカの貧困の範囲をはるかに凌駕しており、裕福なプログラマの多くが気づいている以上に大きい。

例えば私の両親がアメリカに来られたことがどれだけ幸運だったか（金銭的機会という点で）という議論で、ポーランドでは素晴らしい金銭的機会があったから大したことではないと言う人がいた。一つには、議論のトピックである高収入のプログラミング職（高収入テック企業のシニアスタッフエンジニア）やそれに相当する職に就く確率に関して言えば、私が生まれた当時、米国で貧しく生まれる方が、ポーランドでかなり裕福に生まれるよりも確率が高いと思うが、データを示されれば逆のケースも信じるだろう。しかしポーランド対米国とベトナム対米国を比較するなら、15秒ほどかけて私が生まれた年のこれらの国のざっくりした富の数字を調べると、一人当たりGDPの比率は米国：ポーランドで約8:1だったのに対し、ポーランド：ベトナムでは約50:1だった。ポーランドとベトナムの富の差は、米国とポーランドの差のおよそ二乗であり、つまりポーランドからベトナムは、ポーランドから、米国がポーランドより豊かである分だけさらに米国より豊かな仮想の国へ行くのに相当する。これらはまったく比較にならないが、多くの人は「豊かな国」と「豊かでない国」があり、「豊かでない国」はみなだいたい同じバケツに入るというメンタルモデルを持っているように見える。一人当たりGDPは理想的ではないが、パーセンタイル所得統計より見つけやすい。ざっと検索したところ、当時のベトナムの年収は年200〜300ドル程度だった。ベトナムは当時、飢饉の末期でもあり、その影響は統計が操作されているように見えるため判断が難しいが、死亡率統計を信じるなら、飢饉によって全体の死亡率は通常のベースラインの2倍に跳ね上がった¹。

もちろん当時、低所得国の中央値の人がコンピュータを持っていることはおろか、インターネットアクセスを持っていることすらなかっただろう。しかし今日、低所得国の人々がデバイスを持っていることはかなり一般的だ。多くの人はこのことに気づいていないように見え、あるいはこうした人々の多くがどんなデバイスを使っているかを理解していない。

付録: Fabian Giesenからのコメント

Discourse創業者のiOS対Androidの市場シェアに関するコメントについて、Fabianは次のように指摘する。

米国では、私が見つけられた最新のデータ（2023年）によれば、iPhoneは約60%の市場シェアを持っている。EUでは約33%だ。これは波及効果を持つ。iOSユーザーは富裕層に偏るだけでなく、米国にも偏っている。

これには二次的な効果もある。例えば米国では、iMessageがグループチャットなどで非常に人気があり、Androidデバイスとの相互運用性が非常に悪く、Androidユーザーにとって非常に煩わしいものになっていることで悪名高い（ほぼ確実に意図的にそうなっている）。

EUでは、Androidがはるかに優勢であることもあって、iMessageははるかに人気がなく、私の知り合いの中でも、米国ならおそらくiMessageを使うであろうiPhoneユーザーでさえ、代わりにWhatsAppを使う傾向がある。

要するに、世界的に見れば、最近のiOS＋高速インターネットは、米国の多くのアプリ開発者が認識しているよりもさらに特定の人口層に偏っているということだ。

そしてモバイルアプリ対ウェブアプリのサイズに関するコメントについて、Fabianはこう言った。

経験からもう一点：アプリはインストールするときにインストールするもので、一般的には低速ないし従量制の回線にいるとき（あるいはまったくデータがないとき）にアップデートを保留にする機会がある。

私が最初に米国の電話を手に入れたとき、米国のクレジットヒストリーがなかったためプリペイドプランを使わなければならなかった。今でも、ほとんどの時間に電話を実際に使う用途には十分なのでプリペイドを使っているが、年に一度ドイツに旅行するときは、データローミングがまったくできないということでもある。（また、T-Mobileがドイツで最大のモバイルプロバイダであるにもかかわらず——もちろんT-Mobile USではないが——ドイツでの通話は1回1.50ドルかかる）。

要するに、T-Mobileのホットスポット（例えば主要な駅や空港など）やホットスポットのある都市間列車では無料で高速なWi-Fiを利用できるが、ドイツにいる間は事実上まったくデータプランがないということだ。

これはオフラインで動作し、接続があるときにデータを同期する携帯電話アプリではまったく問題ない。しかしウェブアプリは、公衆Wi-Fiの近くにいない間は使い物にならない。

同様に、低速な従量制回線でもGmailアプリ経由でメールを送るのは平気だが、従量制回線で何かするのに数メガの圧縮されたJSをダウンロードしなければならないウェブメールクライアントは絶対に使わないだろう。

少なくともネイティブアプリのダウンロードに関しては、事前に準備してインターネットが良好な場所にいる間にダウンロードできる！

Fabianからの別のコメント（これは会話からのものなので意訳）は、人々は定量的に極端に遅いことを、定性的に遅くなるべき理由があるからといって正当化することがよくある、というものだ。彼が挙げた一例は、画面が接続の同期に時間がかかることが多く、それは時間がかかる操作をしなければならないためだと正当化されることだ。長い間、これらの操作はしばしば数秒かかっていた。最近、多くのディスプレイはずっと速く同期するようになった。Nvidiaが「G-Sync」認証のためにこれにかけてよい時間を規定しているため、ディスプレイメーカーが実際に妥当な時間でこれを行うようになったからだ。時間がかかる操作をしなければならないのは事実だが、それが以前しばしばそうだったほど時間がかかる根本的な理由はない。彼が挙げたもう一つの例は、ある操作が大量のsyscallを必要とするため数千のファイルを読み込むのに時間がかかることを正当化していた人がいて、「syscallは遅い」というものだった。これは定性的には正しいが、実際にsyscallのコストを見てみると、議論されていたケースでは、syscallのコストは、なぜ数千のファイルを読み込むのにそんなに時間がかかったのかを合理的に説明できるほどコストが高いのとは桁違いにかけ離れていた。

このトピックに関して、現代のウェブサイトが遅いと誰かが指摘すると、誰かが一般的に、現代のウェブサイトには旧来のウェブサイトにない素晴らしい機能があるという定性的な擁護で応じる。そして（例えば）DiscourseにはMyBBにはない機能があるのは事実だが、その機能が33xも遅いことを正当化すると主張するのは難しい。

付録: 実験の詳細

danluu.comと、おそらくHNを除いて、各サイトについて「最もデフォルト」な体験を探そうとした。例えばWordPressなら、現在のデフォルトテーマであるtwentytwentyfourを使ったデモブログを意味する。場合によっては、これが今日誰かが使う最も可能性の高いものではないかもしれない。例えばShopifyでは、テーマを閲覧したときに最初に表示されるテーマを見たが、最もよく使われているテーマが何かというテーマデータを探そうとはしなかった。この投稿では、データ収集と分析のすべてを1日で終わる短期プロジェクトとして行いたかったので、このようなショートカットが多数あり、以下で説明する。Shopifyで最初に提示されたテーマを使うことが間違っているとは思わない。かなりの割合のユーザーはおそらく最初に提示されたテーマを使うだろうが、もちろん、最も一般的なテーマが何かを把握し、さらにそのテーマを使うさまざまなサイトを多数テストして、人々が自分の用途に合わせてテーマを修正したときに現実世界のパフォーマンスがどう変わるかを見る方がより代表的だ。もし私がShopifyで働いているか、競合のために競合分析をしたいのであればそうするだろうが、低スペック端末のユーザーに大規模ウェブサイトがどう影響するかという1日プロジェクトとしては、ここで示されたShopifyの性能で十分だと思う。実際、このための初期作業はアンケートを実施したのと同時期の2月に行った。ただ、これを書き上げる時間が1ヶ月ほどなかっただけだ。

ノートPCでのテストでは、バッテリー残量約60%、電源に繋がない状態で、室温20°Cで熱平衡に戻るのに十分な時間アイドル状態にしたため、ページが以前のページ読み込みやマシン上で行われていた他の作業の影響を受けることはないはずだ。

モバイルテストでは、電話は約100%充電され、電源に繋がれた状態で、以前も100%充電されていたため、急速充電による発熱の影響はない。上で述べたように、これらのテストは1GbpsのWiFiで行われた。他のアプリは動作しておらず、ブラウザには他のタブは開いておらず、デバイスにインストールされていたのはそれだけなので、デフォルトでユーザーが通常受けるもの以外に追加のバックグラウンドタスクが動いていたことはないはずだ。同じデバイスを持つ実際のユーザーは、電話上でChrome Dev Toolsを実行することが性能を著しく低下させる場合を除き、ほぼすべての状況でここで測定されたよりも悪い性能を目にすることになる。Itel P32では、Dev Toolsを動かしているときの方が通常時に動かすよりもスクロールがややカクつくことに気づいたが、これは1日プロジェクトだったため、これを定量化したり、一部のサイトに他よりはるかに大きく影響するかどうかを試そうとはしなかった。絶対的な意味では、オーバーヘッドはそれほど大きくはないはずだ。最も速いサイトは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
  • Oookla
    • Ooklaウェブアプリは失敗し、結果が見られない
• Itel P32
  • Netflix
    • ダウンロード: 44 Mbps
    • アップロード: テストが動作しない（1チャンクのデータを送信した後にハングし、それ以上データを送らない）
    • レイテンシ (無負荷 / 負荷時): 4ms / 400ms
  • Okta
    • ダウンロード: 45 Mbps
    • アップロード: テストが動作しない
    • レイテンシ: テストがレイテンシを表示できない

注意すべき点の一つは、Itel P32は名目上の帯域幅を実際には使いこなす能力がないということだ。上位のGoogleレビューを見ても、どれもこのことに触れていない。最初のレビューはこうだ。

性能に関しては、電話はラグらない。最新のAndroid 8.1（GO Edition）を搭載している……8GB+1GBのROMとRAMで、1.3GHzクアッドコアプロセッサのパワーホースで簡単にマルチタスクできる……P32の機能、特に価格を考えると感心している。常に移動している人にお勧めする。そしてスマートフォンでバッテリー持ちを最優先にする人にとって、P32は最良の選択だ。

2番目のレビューはこうだ。

Itel mobileはアフリカ大陸で3位にランクされる主要な流通業者の一つだ……軽量なOSは1GB RAMデバイスでももたつかない性能という期待に応えた……かなり速い処理速度……Itel P32スマートフォンはその能力を超えた最高の性能を発揮する……UGX 330,000という驚きの価格で、Itel P32は単一のパッケージに詰め込まれた素晴らしい機能でミドルレンジの旗を掲げるに値するローエンドのようなスマートフォンの一つだ。

3番目のレビューはこうだ。

「単なる予算重視のエントリー・スマートフォン以上のもの……2週間の使用後の完全レビュー……アプリの切り替えや重いウェブページの閲覧時も、性能は最適だった。複数のアプリがバックグラウンドで動いているときやゲームプレイ時にいくつかのラグがあった。しかし全体的な性能は大多数の電話ユーザーにとって平均的で、平均的なユーザーにとって最適だ［ゲームのスクリーンショット］いくつかのフレームをスキップし、自動的にグラフィックの詳細を落としたが、他にアプリが動いていなければはるかに速かった。

サイトに関する注意：

• 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の数値は高速なノートPCではそれほど悪く見えないが、それは初期読み込みだけの話だ。スクロール時の性能はひどすぎて、今日、まともな性能で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: テーマをクリックして表示された2番目のテーマ。最初は「Bogart」というものだったが、基本的にコンテンツのない「coming soon」的な1ページ画面だったので、1番目ではなく2番目のテーマを使った。
  • Itel P32ではコンソールに多くのエラーと警告が出るが、ページは読み込まれて動作するように見える。ただし操作はかなり遅く苦痛だ
  • Tecno Spark 8CでのLCPは、ページコンテンツが実際に読み込まれるかなり前だった
• Tumblr
  • www.tumblr.com/slatestarscratchpad: このtumblrが存在することを知っていたので使った。あまり多くのtumblrを読んでいるわけではない（3つか4つくらい）が、これが私のブログに最も近いものに思えた。
  • このページは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 Dev Toolsが697sというナンセンスなCPU時間を報告した（実行は通常の時間、697sや697/10sよりはるかに短く完了した）。この実行は結果の計算では無視した。
  • Itel P32ではページ読み込みが完了せず、テーマが意図的に読み込む点滅するカーソルのような画像だけが表示される。正しく読み込まれるデバイスでは、点滅するカーソル画像はすぐに別の画像で覆い隠されるが、ここではそれが起こらない。
  • このサンプルテーマを使うのは不公平ではないかと思った。ページにはテーマスタイルを切り替えるものがあるためだ。そこでテーマの実際の使用例（テーマを宣伝するページにそのテーマのユーザーがリストされている）を確認した。リストされていた実際の例の最初の2つを試したが、どちらもこのデモページよりはるかに遅かった。
• 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: metafilterのユーザーで今はQuoraで多作だと聞いた人のユーザー名で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 (old)
  • thezvi.wordpress.comを使った。Zviのsubstackと同じコンテンツで、たまたま以前非常によく選ばれていた古いwordpressテーマを使っているため
• phpBB
  • www.phpbb.com/community/index.php: 公式フォーラムを検索して出てきたもの
• MyBB
  • community.mybb.com: 公式フォーラムを検索して出てきたもの
  • サイトはモバイル版を提供していない。一般的に、低速端末ではサイトのデスクトップ版の方がモバイル版より著しく優れていると感じているので、これは非常によく機能する。Googleからはそのためにペナルティを受けていると思われるが。
• HN
  • news.ycombinator.com
  • 原理的には、HNは最も遅いソーシャルメディア／リンクアグリゲーターであるはずだ。高度に最適化されていないカスタムLispで書かれており、コードは元々簡潔さと clever さを念頭に書かれているため、一般的にかなり貧弱な性能になるからだ。しかしそれは、ハイパフォーマンスなコードを書いた場合と比べた場合に貧弱だというだけで、ここでの比較としては関係がない。
• danluu.com
  • 説明不要
  • 現在はHNより少しCPU使用量が少ないが、メインページが成長し続けるにつれ、いずれはより多く使うようになると予想している。現時点では、このページには168本の記事への176のリンクがあるのに対し、HNは30本の記事への199のリンクがあるが、早世しない限り、このページはいずれHNよりリンクが多くなるはずだ。
    • 上で述べたように、こうした小さなページでのページネーションは低速端末や接続が悪い場合にブラウジング体験をはるかに悪化させると感じているので、ページネーションしたり、さらに悪いことにスクロール時に動的コンテンツ読み込みをしたりしてこれを「最適化」したくはない。
• Woo Commerce
  • 元々Woo Commerceも測定したが、上でテストしたページやプラットフォームとは異なり、初期読み込みが速いか遅いかが必ずしも他の操作のその後の性能を代表するわけではないことがわかったため、Shopifyとの比較を求められることになるので表には含めなかった。特に、私が見つけられた「最もデフォルト」なWooテーマは、低速端末での初期読み込みでは「最もデフォルト」なShopifyテーマより著しく速かったが、性能は多次元的で、低速端末でShopifyの方がWooより速い現実的なシナリオもその逆も容易に見つかり、これはWordpressのような古いプラットフォームとSubstackやMediumのような新しいブログプラットフォーム、あるいはDiscourseのようなモダンなフォーラムと古いPHPベースのフォーラムを比較したときに見たものとはかなり異なる。カートやチェックアウトフローなどを持つショッピングサイトの本当の比較は、1日で得られる以上に現実世界でのこれらのサイトの使われ方をよく理解する必要があるだろう。
• NodeBB
  • community.nodebb.org
  • これは当初のテストには含まれておらず、NodeBBの創業者の一人が「私たちのNodeBBがテストでより良い結果を出すか見てみたい。長年高速化にかなり時間を費やしてきたし、少なくとも速度と初期ペイロードに関しては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のようなものをテストするなら、WordpressやGhostのようにCDNから直接軽量なものをそのまま提供できるプラットフォームはすべて同様のスコアになるはずで、スコアはCDNとCDNのキャッシュヒット率に依存する。MediumやSubstackのような、あまりカスタマイズできないサイトは、ここでのスコアとほぼ同じになるだろう。現実的に、どんなサイトが存在するかを見ると、ほとんどのユーザーはWordpressやGhostの「最もデフォルト」なテーマよりも遅いサイトを作るだろう。ただし、このブログの読者は平均すると逆になる可能性はある。だからさまざまなサイトスタイルをテストしたくなるだろう。

付録: 低速端末や低速回線で動かないサイト vs. このサイト

余談だが、ずっと面白いと思っていることがある。このページのスタイリングについて、かなりの量のヘイトメールをもらうことだ（同量の感謝メールももらうが）。ヘイトメールといっても、丁寧に変更を提案するようなものではなく、ウェブブラウジングにおけるロードレイジのようなものだ。ウェブレイジとでも言おうか。世界の相当な割合の人にとって使い物にならないほど複雑なサイトを運営している人を知っている。なぜ人々はこのサイトのスタイリングにそれほど激昂し、典型的なウェブデザインが引き起こす世界的なアクセシビリティの問題については、比例してまったく気にしないのだろうか？

ここで面白いのは、スタイリングを評価してくれる人々は、 generally このサイトがデフォルトのスタイリングを一切上書きせず、ウィンドウサイズを好きなように設定することで幅を正確に思い通りにでき、サイトに適用するデフォルトのスタイリングも上書きしないことを評価しているということだ。本当に主張が激しい人々は、皆にある幅の制限や好みのフォントなどを押し付けたいと思っているが、それは常に、自分が欲しいからではなく、大衆の利益のためであるかのように語られる。たとえウェブレイジの人々の好みに合わせることが、例えばウィンドウ幅を調整することでテキスト幅を調整できることを好む人々の好みに真っ向から反することになっても、だ。

私が何十回も指摘するまで、このやり取りは通常、ウェブレイジの人々が「研究によれば」狭いテキスト幅の方が客観的に優れていると私に言うことから始まった。しかし、このトピックについて存在するすべての研究を読んだ限り、私はそれが事実だとは思わなかった。さらに、引用を求めると、彼らは一般的にまったく研究を読んでおらず、時には読んでいないように見える研究を慌てて送ってくることが明らかだった。私がそれを指摘すると、彼らは主張を変え、研究ではこの問題を本当に説明できないのだと言い出す（そもそもなぜ研究を引用したのか不思議だが）。ある人は私に本を引用してきたが（私は読んだが、彼らはどうやら読んでいなかった。なぜならそれも彼らの主張を裏付けていなかったからだ）、そして、これが皆が望んでいることなのだという話に移る。コメントや、私が変更を行ったときのデータからも明らかなように、それが事実でないにもかかわらず、だ。

この推論をするウェブレイジの人々は、自分の好みが普遍的ではないという情報をどうやら吸収できないようで、人々が他の好みを持っていると言ってもなお、そうではないと主張し続ける。私はこれをかなり興味深く思う。データで見ると、Octopressのスタイリング（当時、プログラミングブロガーにとって最も人気のあるスタイリング）から現在のスタイリングに切り替えたとき、トラフィックとエンゲージメントに因果関係があるように見える増加があった。つまり、スタイリングについて感謝のメールをくれる人々がスタイリングを気に入っているだけでなく、私にメールをくれない人々の全体的な感想としても、サイトは問題なく、標準的なプログラマーブログのスタイリングよりも明らかに魅力的であるように見えるのだ。私がこのことを指摘すると、人々は自分の好みは普遍的であり、他の好みを持っていると思っている人々は間違っているという考えにさらに固執し、完全なナンセンスで返信してくる傾向がある。

はっきりさせておくと、このサイトのデザインが最適だとはまったく主張しない。当時プログラマーにとって最も人気のあったブログプラットフォームからCSSを単に取り除いただけだ。なぜならそのCSSは低速回線の人々にとって客観的に悪いと思えたからだ。そして副作用として、トラフィックとエンゲージメントが全体的に増加した。低所得国の人々だけでなく、全体でだ。低スペック端末や低速回線のユーザーのことを気にかけるデザイナーなら、間違いなくより良いものを作れるだろう。しかし、この件に関するコメントの不誠実さと激烈さの両方には、かなり奇妙なものがある。