👃🏾 😅 🛂 Webは時間の経過とともに遅くなっていますか？ 🏂🏻 🤚🏽 🚶🏿

Hacker Newsの最近の記事では、インターネットの速度が上がってもWebページの速度は向上しないと主張されました。

私の記事では、なぜそのような結論を初期データから引き出すことができないのかを説明します。

また、過去10年間にデバイスとウェブに発生した変化と、これらの測定値がウェブの速度にどのように影響したかについても見ていきます。

HTTPアーカイブデータの解釈

Nielsen Norman Groupの記事からのこのグラフは、モバイルネットワークの帯域幅の増加がページの読み込み時間の短縮につながっていないことを明確に示しています。

ただし、この間、HTTPアーカイブで使用される接続速度は向上しませんでした。

代わりに、2013年に廃止され、WiFiからエミュレートされた3G接続に切り替わりました。

2013年以降、onLoadメトリックは12.7秒から19.7秒に55％増加しました。2013年に電話を購入し、それ以降3G経由でインターネットに接続している場合、Webの速度は低下しています。

過去10年間でデバイスとウェブがどのように変化したかについて話す前に、このデータを解釈する方法についていくつか注意します。

なぜonLoadを見るのですか？

loadスクリプトや画像などのすべてのページリソースがダウンロードされると、イベントはページによってディスパッチされます。

ページヘッダーがすばやくレンダリングされたが、ページがさらに20個の画像を下にロードする場合、onLoadメトリックは、ページが遅いことを通知します。

別のページでは、最初は何も役に立たない場合がありますが、onLoadイベントの後で、追加のリソースのロードを開始し、コンテンツをすでに強力にレンダリングするだけです。ただし、そのようなページは速く表示されます。

したがって、onLoadは、ユーザーがページを高速に認識しているかどうかを測定するのにはあまり適していません。

なぜこのメトリックをわざわざ見るのですか？それは長い間使用されており、HTTPアーカイブは2010年から追跡しているためです。などの新しいメトリック最初のContentfulPaint、またはTime to Interactiveは、2017年にのみHTTPアーカイブに追加されました。

帯域幅を増やすと、ページの読み込みが速くなると予想する必要がありますか？

帯域幅を増やすと、ある時点で帯域幅がボトルネックになっている場合にのみ、ページの読み込みが高速化されます。ギガビット接続を使用していて、ネットワークを介した両方向の信号送信時間は1秒に等しい場合は役に立ちません。

ただし、1.6MbpsでエミュレートされたHTTPArchive 3G接続は非常に遅いため、帯域幅を増やすと大幅な速度の向上が期待できます。平均的なWebサイトは2020年に1.7MBのデータをダウンロードします。これは、HTTPアーカイブ接続速度では、ダウンロードに少なくとも9秒かかることを意味します。

HTTPアーカイブの他の微妙な点

この記事では、「平均的なWebサイト」について詳しく説明します。HTTPアーカイブは、サイト階層のより深いページではなく、マスターページでのみデータを収集することに注意してください。テストされたドメインのコーパスも時間の経過とともに成長しました。

テストは常に同じデバイスで実行されたわけではありません。元々は物理的なiPhone4が使用されていましたが、現在はエミュレートされたAndroidデバイスでテストが実行されています。

この記事では、メトリック値の中央値について説明します。ほとんどのWebサイトは高速ですが、5つのWebサイトのうち1つが20秒間電話の速度を低下させる場合、このメトリックを改善することはできません。

デスクトップでの速度

この記事では、米国のモバイルデバイスでの速度を見ていきます。ただし、元の記事のデスクトップデータを見ると、2013年にテストスループットが増加し、待ち時間が減少したことは注目に値します。

過去10年間で、モバイルネットワークとデバイスはどのように変化しましたか？

4つの要因を見てみましょう。

ネットワーク帯域幅
ネットワーク遅延
プロセッサ速度
ブラウザの速度

米国のモバイル帯域幅

このグラフは、さまざまなソースに基づいた、長年にわたる米国の平均モバイルネットワーク帯域幅を示しています。1Mbpsから約30Mbpsに増加しました。

（私はこのデータをあまり注意深く収集しませんでした。たとえば、データ収集日が公開日と同じであるかどうかを常に把握しているわけではありませんでした。私の情報源はここにあります。）

米国のモバイルネットワークでの遅延

このパラメータのデータを見つけるのは困難でしたが、結果は、待ち時間が約200ミリ秒（2011年）から50ミリ秒（2020年）に減少したことを示しています。

モバイルプロセッサの速度

米国の平均移動速度に関するデータを見つけることができませんでした。しかし、アレックス・ラッセルとSurmaは、公開スケジュール年間の様々な携帯電話のリリースと一緒に評価GeekBench 4。

手頃な価格の電話でさえ4倍高速で、iPhoneは20倍強力です。

ブラウザはどのように変更されましたか？

過去10年間、ブラウザを改善するために多くの作業が行われてきました。JavaScriptはWebのさらに重要な部分になっているため、この領域には多くの改善が集中しています。V8ブログのこのグラフに

基づいて、ページあたりのCPU消費量は4分の1に削減されました。

ネットワーキング

ネットワークを使用したブラウザの動作も改善されました。たとえば、2015年にHTTP / 2が導入されて以来、リクエストの64％はHTTP / 2を介して処理されます。

ウェブサイトはどのように変わりましたか？

HTTPアーカイブのデータを見て、Webサイトがどのように変更されたかを理解しましょう。

ページの重み

2013年から2020年にかけて、モバイルページの重みは337％増加しました。これは主に、画像とJavaScriptコードの数の増加によるものです。

他のリソースの量も大幅に増加しています-それは主にビデオだと思います。

2012年10月にHTTPアーカイブが測定方法を変更したため、グラフは2013年に始まります。それ以前は、ページ読み込みイベントがトリガーされた後に他のデータが読み込まれた場合でもテストが停止したため、ページの重みが過小評価されていました。

JavaScriptランタイム

モバイルネットワークが加速しているにもかかわらず、ページの速度が低下している場合は、JavaScriptが原因である可能性が最も高くなります。残念ながら、HTTPアーカイブは2017年の終わりにこのデータの収集を開始しただけであり、それ以降は安定しているようです。

2018年半ばの減少は、テストされたURLのコーパスの変更が原因である可能性があります。

パフォーマンスの絶対持続時間（0.5秒）は、Lighthouseなどの機器で通常見られるものよりも短いことに注意してください。このようなツールは通常、モバイルデバイスをエミュレートするためにJavaScriptの実行を遅くしますが、HTTPアーカイブテストでは、このシステムは壊れていました。したがって、この数値はミッドレンジの電話では現実的かもしれませんが、一般的に、低価格の電話は約4倍遅いと考えられています。

ウェブが遅くなった場合の質問への回答

ウェブが遅くなりましたか？一般に、デバイス、ネットワーク接続、および最も頻繁にアクセスするWebサイトによって異なります。

さまざまなユーザーがWebの認識を時間の経過とともにどのように変化させるかを示す分布を取得するには、実際の速度データを測定する必要があります。また、1日に数千ページを開く人の経験は、週に1回だけFacebookにアクセスする人の経験と同じようにカウントする必要があるのでしょうか。

個々のユーザーの詳細なデータはありませんが、この問題をいくつかの異なる角度から見ることができます。

Chrome UXレポート（CrUX）の実際のユーザーデータ
ウェブサイトとデバイスの変更に基づく素朴なモデリング

また、archive.orgから古いバージョンのページをダウンロードしてLighthouseでテストしようとしましたが、妥当な時間枠内に意味のあるデータを取得できませんでした。たとえば、ページアーカイブから画像が欠落している場合があります。

Chromeユーザーエクスペリエンスレポートのデータ

CrUXデータの大きな制限は、2017年末から収集を開始したことです。ただし、これらを使用して、過去2年半でWebの速度が低下したかどうかを確認できます。

HTTPアーカイブとは異なり、CrUXはメインページだけでなくドメイン全体を検査することに注意してください。

75パーセンタイルをデータと見なします。つまり、75％のユーザーの場合、ページはこの速度以上で読み込まれます。

（私は複数のWebサイトの中央値ではなく平均をとっていますが、これは完全には正しくありません。）

米国でのページの読み込み時間

米国のCrUXデータは、ページ速度の低下を示していません。

onLoadメトリックは、おそらくスループットの増加が原因で、わずかな改善を示しています。または、最初のページの読み込み後に、さらに多くのアクションが発生する可能性があります。

ペイントメトリックはかなり安定しているようです。最大のコンテンツフルペイント（メインコンテンツの読み込み時間）は、2019年半ば以降にのみ収集された新しいメトリックです。

世界の残りの部分

米国のonLoadメトリックの減少傾向は、グローバルデータと一致しています。ただし、国によってページの読み込み時間には大きな違いがあります。たとえば、インドのonLoad時間は韓国のほぼ2倍です。

CrUXデータを使用して、HTTPアーカイブデータをよりよく理解できます。2020年1月、HTTPアーカイブは、18.7秒の合成データに基づいて、ロード時間の中央値（50パーセンタイル）を報告しました。

対照的に、CrUXは、ロード時間をわずか5.8秒と見積もっており、これは75パーセンタイルです。

（グローバル値（グローバル）は単に平均として取得され、人口によって重み付けされていないことに注意してください）

ページの読み込み時間のモデリング

デバイス、ネットワーク、およびWebサイトへの変更が全体的な速度にどのように影響するかについての理論モデルを作成できます。

モデルは完璧ではありませんが、うまくいけば、それは私たちにいくつかの洞察を与えるでしょう。

理論上のページダウンロード時間

ページの重みは時間の経過とともに増加しましたが、帯域幅も増加しました。信号の往復時間も減少しました。

2013年にモバイルWebサイトの中央値のサイズのファイルをダウンロードするには1.7秒かかります。それ以来接続速度が変わらなければ、今日は4.4秒かかります。しかし、今日の平均接続速度では、わずか0.9秒しかかかりません。

実際には、Webサイトは単一の要求で構成されておらず、処理速度やサーバーの待ち時間などの他の要因がページの読み込み速度に影響します。HTTPアーカイブによるonLoad時間は、この下限の2〜3倍です。

ただし、これは、一般的にレイテンシーの低下と帯域幅の増加がWebサイトの読み込みを高速化したことを示す指標として使用できます。

（HTTPアーカイブページの重みメトリックはその時点から一貫して測定され始めたため、2011年ではなく2013年から開始しています。）

CPU

このパラメータにアプローチする方法はよくわかりませんが、いくつかの仮定をします。

2013年にGalaxyS4を使用し、現在Galaxy S10を使用している人は、プロセッサの5倍の処理能力を持っています。それ以来、ブラウザの効率が4倍になったとしましょう。これら2つの数値を直接乗算すると、20倍の改善が得られます。

2013年以降、ページ上のJavaScriptの重みは、107KBから392KBに3.7倍に増加しました。それ以来、最小化と圧縮はおそらく改善されたため、同じ量のJavaScriptコードがより少ないバイト数に収まるようになりました。この係数を6に切り上げましょう。ページ上のJavaScriptの重みがJavaScriptの実行時間に比例すると想像してください。

その結果、3.3倍の速度向上が得られます。

結論

今日のWebサイトはより多くのコードを実行し、10年前のWebサイトよりも何倍も大きくなっています。ただし、モバイルウェブがユーザーにとって全体的に遅くなっているとは思いません。

同時に、より多くの人々がモバイルWebを使用しています。これにより、知覚されるWeb全体の速度が低下します。

モバイルデバイスのコンピューティング能力はデスクトップデバイスの能力に追いついており、ネットワークの帯域幅も追いついています。同時に、新しい安価な予算レベルのデバイスが登場しています。

このデータは2つの角度から見ることができます。一方では、ウェブは徐々に速くなっています。一方、ネットワークとデバイスの進歩は、生産性を向上させる機会を逃したことを表しています。

Webは時間の経過とともに遅くなっていますか？