「スワロースポーツ」トップページの表示速度ボトルネック研究

野球グローブ、スパイク、バットをはじめとする野球用品を幅広く扱う専門通販サイトです。グローブの湯もみ型付けやオーダー用品にも対応し、実店舗も構えています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

観測されたボトルネックを仮に解消した場合、Lighthouse スコアは以下のような変化を示しました。

観測時点	解消シミュレーション後

総合スコア が64から100へと36ポイント変化するシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が5.2秒から0.1秒へ、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）が0.337から0.001へと大きく変化しています。SI（Speed Index = ビューの視覚的な表示進捗の速さ）も2.5秒から1.2秒へ短縮されました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）と TBT（Total Blocking Time = メインスレッドのブロック時間）は観測時点から良好な値でした。

あわせて、ページの総転送量は15.34MBから3.25MBへ、約79%少なくなる結果が得られています。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べた動画です。左が観測時点、右が解消シミュレーション後です。

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

詳細レポート

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

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

オリジナルページの全308リソースのうち、サイト固有のリソースは266件（約86%）、サードパーティタグ由来のリソースは42件（約14%）でした。件数としては少数ですが、このページで読み込まれる JavaScript の転送量のうち約96%がサードパーティタグ由来でした。なお、このサイトはjQueryやslickといったライブラリを自社ドメインから配信しており、Google Fontsも使用していません。42件はすべてタグマネージャー・計測・広告・ウィジェット系のリソースです。

HTMLから直接読み込み:

Google Tag Manager経由で読み込み:

段階的に除去した際の指標変化は次のとおりです。

サードパーティータグを全て除去した状態では、総合スコア は64から93へ、LCP は5.2秒から0.1秒へと変化する結果が得られました。Google Tag Manager の除去では、LCP 要素に関わる画像を一切変更していないにもかかわらず LCP が大きく短縮されています。アクセス解析3系統を含む約900KBのスクリプト群は、通信帯域と接続を占有して画像の取得を待たせていたと読み取れます。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルが存在することを示しています。

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

サードパーティータグの影響を切り離した状態を起点として、サイト固有のボトルネックを調査しました。本研究では全46件のボトルネック仮説を検証しました。その中から、特に影響の大きかった3件を紹介します。

ボトルネック1: メーカーロゴ25枚の寸法未指定 ​

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

観察された状況 ​

サードパーティータグを除去した時点で、LCP・FCP・TBT・SI は良好な値に達していましたが、CLS は0.162のまま残っていました。

ヘッダーに並ぶメーカーロゴ画像25枚は、width="100%" だけが指定され、height を持っていませんでした。img 要素の width 属性はピクセル数しか受け付けないため、パーセント指定はブラウザに無視されます。画像が届くまで表示領域の高さを計算できず、各行は16pxで描画されたあと、画像の到着とともに33pxへ伸びていました。3行分で合計51pxの伸びが、真下にあるカテゴリ一覧を押し下げていました。

このずれは、その時点の CLS の約66%を占めていました。ずれとして記録されていたのはカテゴリ一覧ですが、カテゴリ一覧自体の高さは変わっておらず、原因はその上にあるメーカーロゴでした。

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

25枚のロゴ画像の width="100%" を実寸に基づく数値（24枚は width="70" height="50"、1枚は width="210" height="50"）へ置き換えた状態を作り、その影響を計測しました。

シミュレーション結果 ​

HTMLに25箇所の属性を加えただけで、CLS は0.162から0.073へ半分以下になり、総合スコア は6ポイント変化しました。一見すると寸法を指定済みに見える width="100%" という記述が、実際にはブラウザにとって未指定と同じであり、ページ全体のレイアウトのずれの主要因となっていたことがこのシミュレーション結果から読み取れます。

なお、残る CLS についても、お知らせ表示用 iframe の高さ未指定、ヘッダー上部バナーのアスペクト比未確定などを順に解消するシミュレーションを行い、この節の範囲では0.000まで変化する結果が得られています（ほかのボトルネックもすべて解消した最終状態では0.001）。

ボトルネック2: WebP化されていない画像187枚 ​

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

観察された状況 ​

WebP 変換の直前の時点で、ページ転送量12.63MBのうち、12.51MB（約99%）が画像でした。その大半にあたる161枚が従来形式の JPEG（合計12.32MB）で配信されていました。一部には WebP 画像が12枚使われており、サイト側に WebP を扱う仕組み自体は存在していました。

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

JPEG と PNG の画像187枚を WebP に変換し、レスポンスの Content-Type を image/webp に更新した状態を計測しました。JPEG は画質指標（SSIM）を基準とした非可逆変換、PNG は可逆変換です。

シミュレーション結果 ​

総転送量が8.91MB少なくなる結果が得られました。本研究で検証した46件のうち、単独のシミュレーションとしては最大の削減量です。

一方で、LCP などの速度指標はほとんど変化していません。理由は2つあります。この計測環境はネットワークの往復遅延をほぼ0として扱うため、転送量の削減が時間に表れにくいこと。そして、この時点の LCP 要素は画像ではなくヘッダーのテキストであり、画像の到着を待たずに描画されていたことです。ただし8.91MBという量は、たとえば実効5Mbpsのモバイル回線であれば約14秒分のダウンロード時間に相当します。指標には表れにくいものの、ユーザーの通信量と配信帯域の両面で、画像形式が非常に大きなボトルネックとなっていたことがこの結果から読み取れます。

ボトルネック3: 入口URLの多段リダイレクト ​

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

観察された状況 ​

https://www.4860.jp/ にアクセスすると、スマートフォン向けページ /sp/ へリダイレクトされます。その転送先は平文の http://www.4860.jp/sp/ で、そこから再び https://www.4860.jp/sp/ へ転送される3段構成になっていました。HTTPSで始まったアクセスがいったんHTTPへ降格するため、TLS接続の確立もやり直しになります。

検索結果・広告・ブックマークなど、トップページへの流入はすべてこの経路を通ります。Lighthouse のスコア計算に使われる推定値とは別に、ブラウザが実際に記録した時刻を分析すると、最初の描画までの1.3秒のうち約0.6秒（46%）をリダイレクトが占めていました。

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

まずリダイレクト先を https:// に揃えて平文HTTPの経由をなくし、次に入口URLがリダイレクトを返さず、スマートフォン向けページの内容を直接返す状態を作りました。このシミュレーションは、スマートフォン向けページを別URLで運用しているサイトの構成が変わることを前提として行いました。計測値のばらつきが大きかったため、前後それぞれ3回ずつ計測した中央値で比較しています。

シミュレーション結果 ​

下の表は、平文HTTPの経由をなくした状態を起点に、入口URLのリダイレクトを全廃した前後の比較です。平文HTTPの経由をなくす段階だけでは、ブラウザ実測の FCP はほとんど変わりませんでした（1,292msから1,289ms）。

ブラウザ実測の FCP が1.3秒から0.7秒へ、ほぼ半分になる結果が得られました。Lighthouse の監査がリダイレクトの無駄時間として指摘していたのは55.5msでしたが、シミュレーションで観測された差はその10倍以上です。監査が計上するのはリダイレクト応答そのものの時間だけで、接続の再確立や後続リソースの取得遅延までは含まれないためです。ページの取得が始まる前の段階に置かれた遠回りが、表示全体を後ろにずらしていたことがこの結果から読み取れます。

まとめ ​

スワロースポーツ（4860.jp）の表示速度を観測したところ、総合スコア 64、LCP 5.2秒、CLS 0.337という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

観測されたボトルネックとその影響は次のように整理できます。

• サードパーティータグ（42リソース）: 除去によって 総合スコア が64から93へ、LCP が5.2秒から0.1秒へ変化。ページの JavaScript の約96%がサードパーティタグ由来で、アクセス解析が3系統同時に動いていました。
• メーカーロゴ25枚の寸法未指定: 実寸の width と height を指定することで CLS が0.162から0.073へ、総合スコア が93から99へ変化。パーセント指定の width 属性がレイアウトのずれの主要因でした。
• WebP化されていない画像187枚: WebP への変換で総転送量が8.91MB（約71%）少なくなりました。速度指標への影響は小さい一方、転送量としては本研究で最大のボトルネックでした。
• 入口URLの多段リダイレクト: 平文HTTPを経由するホップを除いたうえで、入口URLのリダイレクトを全廃することで、ブラウザ実測の FCP が1.3秒から0.7秒へ短縮。スコアに表れにくい一方、実際の表示には大きく影響していました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は64から100へ、LCP は5.2秒から0.1秒へ、CLS は0.337から0.001へと変化しました。

なお、フロントエンド側のボトルネックを解消しきった後に残ったのは、サーバーが最初の1バイトを返すまでの応答時間（TTFB、約0.5秒）でした。最終的なブラウザ実測の LCP 約0.6秒のうち、約0.5秒を TTFB が占めています。参考として TTFB を約0.5秒から0.1秒に短縮したシミュレーションでは、LCP の対処を始めた時点のブラウザ実測 LCP（約0.7秒）が約0.3秒へ変化する結果が得られました。スコアが100に達した後にも、サーバー応答という別の層にボトルネックが残っていたことが、この一連のシミュレーションによって確認できた形です。