「RUNWAY channel」トップページの表示速度ボトルネック研究

MERCURYDUO、MURUA、dazzlin、EMODA、Ungridなど多数のレディースファッションブランドを取り扱うファッションECサイトです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

Core Web Vitalsにつながる指標の改善ポテンシャル ​

観測時点	全ボトルネック解消シミュレーション後

総合スコア が66から100へと34ポイント変化するというシミュレーション結果を得ました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が13.6秒から0.5秒へと大幅に短縮されており、表示速度に強く影響するボトルネックが複数存在していたことが読み取れます。

読み込みプロセスの変化を動画で体験 ​

本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見られます。

サードパーティータグの影響 ​

詳細レポート

本研究ではまず、サードパーティータグを段階的に除去することで、タグ全体が表示速度に与えている影響を観測しました。あわせて、タグ由来のノイズを取り除くことで、サイト自体のボトルネックを観察しやすくする狙いもあります。タグを完全に除去することは現実的でないものの、最適化によってどこまでの改善ポテンシャルがあるかを把握する材料としてご覧ください。

本セクションは「サードパーティータグがページスピードに影響を与えている」という現実を数値で示すとともに、それらを最適化することでどれだけのスピード改善ポテンシャルがあるかを示唆するものです。

オリジナルページの全330リソースのうち、サイト固有のリソースは231件（約7割）、サードパーティタグ由来のリソースは99件（約3割）を占めていました。ページスピードのボトルネックを正確に把握するには、まずこの3割のタグを取り除いてサイト固有のパフォーマンスを分離する必要があります。

HTMLから直接読み込まれているタグ ​

GTM経由で読み込まれているタグ ​

本サイトでは Google Tag Manager が3コンテナ運用されており、それぞれが独立してサブタグ群を読み込んでいました。

段階的除去シミュレーションの結果 ​

サードパーティータグを全て除去した状態では、総合スコア は66から89へ+23ポイント変化し、LCP は13.6秒から3.4秒まで短縮される結果が得られました。リソース数は328件から231件に99件削減され、転送量ベースで約3.15MB（約50%）がサードパーティータグに起因していました。特に Google Optimize Next が <head> 先頭にブロッキングスクリプトとして配置されていた点、GTMが3コンテナ並行で運用されていた点は、大きなオーバーヘッドの要因として観測されました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルの存在が読み取れます。

サイト固有のボトルネック ​

サードパーティータグを除去した状態から、サイト自体に起因するボトルネックの検証を進めました。全12件のボトルネック仮説を検証し、その中から特に影響の大きかった3件を紹介します。

ボトルネック: テキストリソースの未圧縮配信 ​

詳細レポート 差分コミット

観察された状況 ​

runway-webstore.com ドメインから配信されているHTML・CSS・JavaScript・JSONなど44件のテキストリソースに対して、GZIP 圧縮が適用されていない状態が観測されました。テキストリソースは圧縮率が高く、未圧縮のまま配信されることで転送量が大幅に増加し、ページの初期表示を遅延させていました。

解消シミュレーションの方法 ​

44件のテキストリソース（HTML 1件、CSS 11件、JavaScript 20件、JSON 13件）に GZIP 圧縮を適用した状態でシミュレーションを実施しました。

シミュレーション結果 ​

このシミュレーション結果から、テキストリソースの未圧縮配信が FCP と LCP の両方に影響を与えていたボトルネックであったことが読み取れます。サーバー側の配信設定のみに起因する問題であり、サイトの機能や見た目には一切影響を与えないボトルネックです。

ボトルネック: パブリックCDNリソースの外部ドメイン配信 ​

詳細レポート 差分コミット

観察された状況 ​

jQuery 1.10.2、jQuery UI 1.10.3、Underscore.js、Backbone.js、Moment.jsなど9件のJavaScriptライブラリが、ajax.googleapis.com や cdnjs.cloudflare.com といった外部CDNドメインから読み込まれていました。これらの外部ドメインへの接続には、DNS解決やTLS接続の確立といったオーバーヘッドが発生し、自サイトのドメインで既に確立されているHTTP/2接続を再利用できない状態にありました。

解消シミュレーションの方法 ​

9件のJavaScriptライブラリを自サイトのドメイン（runway-webstore.com）から配信する構成に変更してシミュレーションを実施しました。

シミュレーション結果 ​

FCP が1.7秒から0.9秒へとほぼ半減しており、外部ドメインへの接続オーバーヘッドが FCP に与えていた影響の大きさを読み取れます。パブリックCDNの利用は広く行われている構成ですが、接続先ドメインの増加とともに初期表示への影響の蓄積が、このシミュレーション結果から確認されました。

ボトルネック: Google Fontsによる日本語Webフォントの読み込み ​

詳細レポート 差分コミット

観察された状況 ​

Google Fontsから Noto Sans JP（日本語フォント）、Poppins（欧文フォント）、Material Icons（アイコンフォント）が読み込まれていました。特に日本語フォントは文字数が多いためデータ量も非常に大きく、合計35件のリソースで読み込みが発生し、fonts.googleapis.com および fonts.gstatic.com への外部ドメイン接続を伴っていました。このシミュレーションはフォントの見た目が変わることを前提として行いました。

解消シミュレーションの方法 ​

Google Fontsの読み込みを全て除去し、システムフォントスタックにフォールバックする構成でシミュレーションを実施しました。

シミュレーション結果 ​

LCP が1.4秒から0.5秒へ0.9秒短縮されており、日本語Webフォントの読み込みが LCP に与えていた影響の大きさを読み取れます。デザインとしてWebフォントを使いたい理由は十分に理解できますが、日本語フォントは英語フォントと比べてデータ量が桁違いに大きく、表示速度への影響もそれに比例して大きくなることが、この結果から明確に示されました。

まとめ ​

RUNWAY channelのトップページでは、サードパーティータグの大量導入（GTM 3コンテナを含む計10種類以上）、テキストリソースの未圧縮配信、パブリックCDNの外部ドメイン依存、日本語Webフォントの読み込みなど、複数のボトルネックが表示速度に影響していました。

サードパーティータグだけで 総合スコア が23ポイント、LCP が10.2秒分の影響を与えており、表示速度への影響が最も大きい要因として観測されました。サイト固有のボトルネックとしては、GZIP 圧縮の未適用が FCP を0.6秒遅延させ、パブリックCDNの外部ドメイン配信が FCP をさらに0.8秒遅延させていました。Google Fontsの日本語Webフォントは LCP に0.9秒の影響を与えていました。

これらのボトルネックを全て解消したシミュレーションでは、総合スコア が66から100へ、LCP が13.6秒から0.5秒へと変化する結果が得られています。