平均ファイル容量は３MB。これをどう考えるべき？

目的：ページサイズは肥大化しています。しかし、パフォーマンス指標としては適していません。

Tammy Everts　2017年8月9日

数か月前、誰かに「最近、ページの肥大化ついて書きましたか？」と尋ねられました。答えは「いいえ」でした。

平均ページが1MBだった2012年以来、ページの肥大化に関する記事を多く書きました。私にとっては、話題は十分にカバーしていました。しかし、トレンドとして、ページは、さらに安定して肥大化を続けていました。

Ilya Grigorikが、投稿の中でページ肥大化の話題に向け、なぜ「平均ページは神話」なのかを説明しました。IlyaがPCサイトのHTTPアーカイブデータを分析した結果、中には30MB以上のページもありした。しかし、各ページの90％以上が5MB以下のため、平均ページサイズは2227KBだったのです。

なぜ？　平均的なページは3MBになりました。本当ですか？これは立ち止まるには、いいタイミングです。自らにに尋ねます：

パフォーマンス指標として、ページサイズに気を使う理由がありますか？また、ページサイズを有意義な指標と考えないなら、何を気にする必要がありますか？

トピックに戻る前に（もう一度）、重要な注意点

こららの平均値は「HTTPアーカイブ」から得たもので、これは大規模なデータ平均です。平均値は、”典型的な”ウェブサイトを代表しません。というのは、典型的なウェブサイトというものが存在しないからです。

これらの数値は、歴史的な文脈をみると関連はします。トレンドを表しています – それだけ。

これらの数字は、自社サイトのベンチマークとして取得されるべきではありません。これより小さくても、素晴らしいわけではないし、ページが大きくても失敗したわけではありません。

すべてのページが大きくなっているわけではありません。多くは毎年小さくなっています。あなたのページもその一つです！

グラフに起こっていない？本当か？

2011年から今までのページの肥大化をコンテンツの種類別に見ることができます：

大きな話題としては、多くのページ資産（容量）にはビデオが入っていることです。ビデオ人気を考えれば、当たり前ですが、最近の成長の多く部分を占めています。

カスタムフォントが増え続けています:上位50万のサイトうち69％がカスタムフォントを使用しています。興味深いのは、2016年の総KBに関するディップ（へこみ）が気になります。

最近のHTTPアーカイブデータ（下記）の一部をグラフ化し、どのメトリックがページサイズに対してフラットで、どのメトリックではそうでないかを確認しました。

上記では、ページサイズに関係なく、Start renderが一定していることがわかります。これは注目すべき点で、ユーザーがコンテンツを見れるようになるのは、容量の大きさとは関連してません。

また、ページサイズと強く相関するため、パフォーマンス・メトリックとしてonloadによって誤解されやすいこともわかります。

このグラフでは、500KBコホートのページの2393（〜2.4秒）から20MBのコホートのページの10266（〜10.3秒）まで、SpeedIndexはかなり上向きになっています。これがオンロードの急激な上昇によって、少し隠されています。これは、SpeedIndexが一般的にユーザーエクスペリエンスのためのシンセティック（合成）メトリックだというこということを再認識させます。

予測：2019年までに4MBのページ？

興味深い論点として、ページサイズが前年比約16％増加すると仮定すると、平均ページは2年後には4MBを超える可能性があります。

しかし、もう一度、Ilyaの論点に戻れば、平均的な数値です。 4MBのページはすでに存在しています。 HTTPアーカイブによれば、最近のページの約16％（6ページ中約1ページ）は、4MB以上のサイズです。 私はいつも10MB以上のページを見つけています。私がマークとスティーブとこの問題について話していたときことです。Markは30MBのページを構築しましたが、それでも高いパフォーマンスを出していました。

ユーザーエクスペリエンスにおいて、ページサイズは適切な追跡指標ではありません

ページサイズや読み込み時間は、ユーザーが知覚するパフォーマンスとしてよい指標ではありません。

例えば、「Amazonはパフォーマンスリーダーだ」と広く認識されていますが、比較的重い（3MB以上と定義）と、読み込み時間の遅い（5秒以上と定義）ページがあります。しかし、Amazonで見たところ、ページサイズとload timeは間違ったメトリックです。

たとえば、このAmazonのホームページのテスト結果ページ（5MBを少し上回る）を見ると、開始レンダリング時間は1.4秒、十分に読み込まれたビューポートは2.5秒になります。しかし、ページは18.8秒まで完全にロードされません。

持ち帰りましょう！

1. ページサイズは重要ですが、思うほどではない

速く感じられる、大きく丈夫なページを作成することはできます。しかし、ページの肥大化は、モバイルユーザー、特に帯域幅の制約やデータ制限を扱うモバイルオンリーユーザーにどのように影響するかを気にする必要があります。ティム・ケダック氏は2017年6月、Fluentでこの問題についての基調講演を行いました。また、世界中の国々のページコストをドルで計算するティムのonline calculatorもチェックしてください。

できること：パフォーマンスパジェットを積極的に使用して、page size, start render, a Speed Indexなどの指標に対して目標値を設定していない場合は、始めてみましょう。パフォーマンスパジェットの仕組みを説明する短い解説ビデオみましょう。

2. イメージは心配するほど多くはありません。

はい、イメージ画像は平均的なページの大半を占めています。ユーザーに最適化されていない巨大な画像を提供していないことを確認しましょう。これは、比較的簡単に扱うことができる対策の１つです。

できること：ページ上の問題のある画像を見つけて修正します。

3. CSSとJavaScriptについて

スタイルシートとスクリプトが非同期である場合、これらのページはページ全体をブロックする可能性があることを知る必要があります。これらはCPU負荷が高いからです。

あなたができること：非同期スクリプトは同期よりも優れていますが、スクリプトを延期するための引数があります。 CPU使用率をまだ測定していない場合は、今すぐ始めてみましょう。

4. ユーザーエクスペリエンスを気にするなら、カスタムメトリックを使用します

ページサイズとユーザーエクスペリエンスとを関連付けることは、ビュッフェ全体のディナーを見せて、実際に何を食べたかを表すと、仮定しているようなものです。ユーザーエクスペリエンスを適切に測定するには、ユーザーが実際に消費したいコンテンツ（ナビゲーションバーやメイン商品イメージなど）に焦点を当てる必要があります。ユーザーエクスペリエンスを測定するためのベストなパフォーマンスメトリックは、重要なコンテンツを見るまでに、どれくらいユーザーは待たないといけないのかを計測ことです。

あなたができること：これは、W3Cのユーザータイミング仕様を使用してカスタムタイマーが入る場所です。カスタムタイマーを実装するには、ページの重要な内容を特定し、いつレンダリングするかを追跡するマークと測定値を追加する必要があります。スティーブは、カスタムタイマーの詳細なブログ記事を書いただけでなく、始めるためのサンプルメトリックを提供しています。あなたがユーザーエキスペリエンスを測定するなら、ぜひ読んでみてください。

総括として

SpeedCurveでは、多くのパフォーマンスデータより 正しいパフォーマンスデータのほうが重要と考えています。そのため、どのようにユーザーがサイトを利用するかを把握できる指標作成に努めています。これらのメトリックで、パフォーマンスバジェットとアラートを設定することは重要です。

優れたユーザーエクスペリエンスの鍵は、重要なコンテンツをすばやく配信することです。これは簡単に言うことができますが、過去を振り返るとやりにくいものです。 カスタムメトリックは進化の大きな一歩です。 カスタムメトリックを使用している場合は、そのメトリックがどのように機能しているのか、またどのようなメリットから学習しているのか、ぜひ聞きたいと思います。