読み込み速度は重要だが、最優先事項ではない

写真：Jonathan Chng (Unsplash)

この数年、Indeed がユーザー向けWebアプリケーションの読み込み速度が低下していました。私たちは、パフォーマンスを改善するためにさまざまな方法を検証しました。その中には大幅な改善につながる方法もあれば、そうでないものもありました。

読み込み速度は40％向上しましたが、ユーザーエクスペリエンスの観点では、この読み込み速度が必ずしも重要な要因ではないことも学びました。

パフォーマンス指標

次の主な2つの指標を使用して、読み込み速度を測定しました。

• FirstContentfulPaint – ユーザーがそのページの最初のコンテンツを表示したとき。DomContentLoadedEventEnd – – ページがインタラクティブになったとき。クリティカルCSSとJavaScriptがすべて解析され、実行された瞬間に測定されます。

Indeed は、単一の指標ではなく、加重平均指標を採用しました。その結果、感知された読み込み時間を正確に測定することができ、次の重要な2つの疑問の解消につながりました。

• ユーザーにページが表示されるまで、どのくらいの時間がかかったか。
• ユーザーがページを操作できるようになるまで、どのくらいの時間がかかったか。

GoogleのWeb Vitalsではなく上記の指標を採用した理由は、トレードオフが伴うものの、幅広いユーザー層に対応しているためです。この2つの指標を使用したところ、何百ものアプリケーションやさまざまなWebブラウザから、分かりやすく観測可能で、報告価値のあるデータが得られました。

読み込み速度が向上した成功例

さまざまな方法を試しましたが、その中でもパフォーマンスが最も向上したのは次のような方法でした。

早めに <Head/> をフラッシュする

ブラウザのページ読み込み時には、JS、CSS、HTMLファイルといった静的リソースをダウンロードして解析する際に、通常、最も多くのリソースを使用します。この消費リソースを抑えるために、静的コンテンツを早期に送信して、ファイルが必要になる前にブラウザでファイルのダウンロードと解析が開始されるようにしました。その結果、このようなリソースによってレンダリングを妨げる時間を大幅に短縮することができます。

複数のアプリケーションでHTMLのheadタグを早期にフラッシュすることで、読み込み時間が5～10％向上しました。

ただし、この実装にはいくつかのトレードオフが伴います。HTMLドキュメントを複数のチャンクに分けてフラッシュすると、紛らわしいエラーにつながるためです。レスポンスの最初の部分をフラッシュすると、ステータスコードやCookieなどのレスポンスの一部を変更できなくなります。レスポンスの最後の部分よりも前にエラーが発生した場合でも、このヘッダーを変更することはできません。Indeed では、このような複雑な問題を解決するために、一般的なライブラリをいくつか実装しました。

クリティカルパス上のファイルを減らす

合計バイト数とは別に、ページの読み込み時間を短縮する上で重要なのが、クリティカルレンダリングパス上で必要になる合計リソース（特にレンダリングを妨げるリソース）の数があります。一般的に、読み込むファイルの数が増えるほど、ページの読み込み速度は遅くなります。たとえば、10のファイルで100KBのページを表示するよりも、5つのファイルで100KBのページを表示する方が速度は大幅に向上します。

A/Bテストでは、レンダリングを妨げるファイルの数を60％（30から12）削減しました。なお、ページ読み込み時の合計バイト数はほぼ変わりませんでした。このテストでは、デスクトップとモバイルの検索ページにおいて、95パーセンタイルのdomContentLoadedEventEndで2秒以上改善されました。また、largestContentfulPaintでも大幅な改善が見られました。

さらに深く掘り下げるために、CSSファイルを1つ増やした場合の消費リソースを調査しました。トラフィックが最も多いページを対象に、CSSファイルの数を1つ減らすテストを実施したところ、ページの読み込み時間は統計的に有意に短縮され、95パーセンタイルで約15ms（ミリ秒）になりました。

CSS-in-JSのランタイム負荷を抑える

Emotion library上に構築された、最新のコンポーネントライブラリを使用するアプリケーションが増えたことで、ページの読み込み速度が40％低下していることが分かりました。

Emotion libraryは、業界でも話題のCSS-in-JSをサポートしていますが、CSS-in-JSコンポーネントをレンダリングすると、JavaScriptバンドルに余分なバイトが追加されることが分かりました。この新しいレンダリング戦略のランタイム負荷とバイト数の増加が、読み込み速度が低下する原因となっていました。そこで、よく使用されるコンポーネントの多くを事前コンパイルするwebpackプラグインを使用することで、レンダリングによる負荷を削減して、この問題を解決することができました。

この方法によって大幅に改善し、95パーセントタイルで全体で40％だった速度低下が約5％にまで抑えられました。ただし、CSS-in-JSを使用した方法は、従来のレンダリング手法よりもランタイム負荷が高くなりました。

Indeed 側で解消できない要因

改善テストと並行して、ページの読み込み速度に影響を及ぼしているユーザーのターゲット層やロケール、使用デバイスを分析しました。

デバイスの種類やオペレーティングシステム

一般的にiOSよりも消費電力が低いAndroid端末では、firstContentfulPaintの読み込み時間が63％、domContentLoadedEventEndの読み込み時間が107％低下しました。

Windowsユーザーは、iOSユーザーと比較して、domContentLoadedEventEndの読み込み速度が26％低下しました。Windowsデバイスには古いものが多いことから、これはある程度予想通りの結果となりました。

このデータからは、重要な学びがありました。

• 機能とコード追加によるパフォーマンスへの影響は比例していません。新型の安定したデバイスでは、100KBのコードを追加してもパフォーマンスに影響がないのに対し、旧型のデバイスでは読み込み速度が大幅に低下することが分かります。
• パフォーマンスはデバイスやOSの性能によって大きく異なるため、パフォーマンスを理解するには、RUM（リアルユーザーメトリクス）を使用してアプリケーションをテストすることが重要です。

通信方式とネットワーク遅延

私たちは、Network Information APIを使用して、さまざまな接続方式に関する情報を収集しました。このAPIはすべてのブラウザでサポートされているわけではないため、不完全なデータではありますが、注目すべき調査結果が得られました。

• 4Gの接続タイプと比較した場合、読み込み速度は3Gの4倍、2Gの10倍、2G未満の場合は20倍に向上しました。つまり、ネットワーク遅延が全体の遅延に占める割合は非常に大きいと考えられます。
• 通信方式の情報が送信されるブラウザでは、4Gがトラフィック全体の95％を占めています。すべてのタイプのブラウザでは、この割合は50％以下にまで減ります。

ネットワーク速度は国によって大きな差があり、一部の国では、ページの読み込みに20秒以上かかることもあります。地域によっては、サイズの大きい画像や動画などを減らして負荷を軽減することにより、低速なネットワークでも、シンプルかつ高速なユーザーエクスペリエンスを実現できます。

このようにすることでパフォーマンスを簡単に高めることはできますが、複雑さは解消されません。

読み込み速度などの要因によって生じる結果

パフォーマンスがWebに与える影響はさまざまです。Amazonなどの企業の報告によると、わずか1秒の読み込み速度低下が16億ドルの売上損失につながると言われています。一方で、パフォーマンスの影響に対する解釈は曖昧であるといった報告事例もあります。

今回のテストにおいては、パフォーマンスの向上に伴って、エンゲージメントも向上するという結果が出ました。ただし、それがパフォーマンスの向上だけに強く相関しているかどうかは分かりません。

信頼性と読み込み速度

現時点では、このようなエンゲージメントの向上は、読み込み速度の向上ではなく、信頼性の向上に基づくものであると考えています。

静的資産をコンテンツデリバリーネットワーク（CDN）に移行したテストでは、エンゲージメントの向上が見られましたが、同時に信頼性と可用性も向上しました。パフォーマンスは向上しても、信頼性が向上しないテストでは、エンゲージメントにも大幅な向上は見られませんでした。

一度の大幅な向上がもたらす影響

パフォーマンスが1秒以上向上した（信頼性は向上しない）テストでは、主要なパフォーマンス指標（KPI）に大きな変化は見られませんでした。

Indeed のデータによると、商用でないアプリケーションの場合、パフォーマンスが多少変化してもエンゲージメントの大幅な向上にはつながらないことが分かっています。

エンゲージメントとパフォーマンス

今回の調査結果では、指標を分析する際に、パフォーマンスとエンゲージメントを同一視してはならないことが分かりました。明確な例として、モバイルiOSユーザーとモバイルAndroidユーザーのパフォーマンス指標の違いが挙げられます。

Androidユーザーはレンダリング速度がiOSユーザーの半分程度でしたが、iOSユーザーと比較してエンゲージメントの低下は見られませんでした。

読み込み速度が重要な場合

1年間にわたって読み込み速度を改善するための方法を検証した結果、パフォーマンス向上につながる方法がいくつか見つかりました。このような改善は測定可能でしたが、主要なパフォーマンス指標（KPI）に変化をもたらすほどの重要性はありませんでした。

ある程度の読み込み速度は必要ですが、重要な要因はそれだけではありません。ユーザーのデバイスや接続タイプは、ユーザーエクスペリエンス全体において大きな役割を担います。これらすべての要因を完全に制御することはできませんが、読み込み速度の向上を目的として特別に設計されていないアーキテクチャ戦略でも受け入れることができるというメリットもあります。読み込み速度を多少妥協して他の部分を改善することで、ユーザーエクスペリエンス全体の向上につながります。