「ムラサキスポーツ」トップページの表示速度ボトルネック研究

サーフィン・スノーボード・スケートボードの専門店として知られるムラサキスポーツの公式オンラインストアです。ボードスポーツのギアから、アパレル・シューズまでを幅広く取り扱い、スクールやイベント、ライダー、店舗の最新情報も発信しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は4.2秒から0.1秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は3.2秒から0.1秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は8.2秒から0.6秒へと、いずれも大きく変化するシミュレーション結果が得られました。

数値を読むうえで、計測条件について2点補足します。1点目は、この研究の Lighthouse は CPU の減速をかけずに計測しているため、TBT（Total Blocking Time = メインスレッドのブロック時間）が観測時点からほぼ0msになっていることです。メインスレッドの負荷は、CPU を4倍に減速した別の計測で評価しています（ボトルネック2で扱います）。2点目は、Lighthouse の推定値には HTML の応答時間（約660ms）がほとんど反映されないことです。実際のブラウザで計測した解消シミュレーション後の表示開始（FCP = LCP）は0.75秒で、その約9割をこの応答時間が占めていました。

また、観測時点の CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）0.020の大半は、記録したページを再生する環境の不具合で、本番のサイトには存在しないずれでした。研究の途中でこの不具合を修正し、以降は本番どおりの表示で計測しています。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画は、通信速度約10Mbps・CPU 4倍減速というモバイル相当の条件で録画しています。

観測時点のページは、サードパーティタグと大きな画像の読み込みが続き、30秒たっても読み込みが完了しませんでした。

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

詳細レポート

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

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

オリジナルページの全454リソースのうち、サイト固有のリソースは314件（約7割）、サードパーティタグ由来のリソースは140件（約3割）を占めていました。13種類のタグの中には、DMP の AudienceSearch が別の Google Tag Manager コンテナを読み込み、そこから広告タグが連鎖的に発火する構造や、Meta Pixel と Google Analytics 4 が HTML への直書きと Google Tag Manager の両方から重複して読み込まれる構造がありました。

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

タグやCDNを経由して読み込まれているタグ ​

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

このフェーズでは、同じ状態でも 総合スコア や LCP・SI が大きく揺れていたため、個々の段階の差よりも、タグ全体の除去による累積の変化が主な評価の対象です。head 内で同期読み込みされていた Evergage と A8.net は、それぞれ400ms以上のレンダリングブロックと推定されていました。サードパーティータグを全て除去した状態では、総合スコア は72から96へ、LCP は4.2秒から2.6秒へ、SI は8.2秒から2.7秒へと変化する結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: スライダーのSwiperを公開CDNから読み込んでいる ​

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

観察された状況 ​

このページは、ファーストビューのメインビジュアルをはじめ、多数のスライダーに Swiper を使っています。その CSS と JavaScript を、head から公開 CDN の cdn.jsdelivr.net で読み込んでいました。CSS はレンダリングをブロックし、JavaScript は同期読み込みのため HTML の解析を止めます。どちらも描画の前に必要なリソースでありながら、別ドメインへの新しい接続（DNS・TCP・TLS）の確立に約400msを要していました。Lighthouse は Swiper の CSS によるレンダリングブロックを418msと推定していました。

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

同じバージョンの Swiper の CSS と JavaScript を、自社ドメイン（www.murasaki.jp）から配信した状態を計測しました。ファイルの中身は変えておらず、すでに確立済みの HTTP/2 接続をそのまま使えるようになります。

シミュレーション結果 ​

FCP は1.4秒から0.9秒へと約35%短縮され、Lighthouse のレンダリングブロックの指摘からも Swiper の CSS が消えました。ファイルの中身を一切変えずに配信元のドメインを変えただけのシミュレーションでこれだけの変化が生じたことから、描画の前に別ドメインへの接続を必要とする構造が、表示開始を大きく遅らせていたことが読み取れます。

ボトルネック2: Tailwind CSS Play CDNがブラウザ上でCSSを生成している ​

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

観察された状況 ​

head では、cdn.tailwindcss.com から Tailwind CSS Play CDN のスクリプトを同期読み込みしていました。これはページ内のクラス名をブラウザ上で調べ、その場で CSS を生成する開発用のスクリプトで、Tailwind の公式も本番環境での利用を想定していません。このスクリプトは次の3つの処理でメインスレッドを使っていました。

• スクリプト自体の評価（約32ms）
• HTML の解析中に、読み込まれた要素のクラスから CSS を生成する処理
• DOM の変化を MutationObserver で監視し、スライダーの自動再生などでクラスが変わるたびにページを再走査する処理

CPU を4倍に減速した計測では、解析中の CSS 生成が約121msのロングタスクになっていました。先に行った初期化処理の分割の後に残る、最大のタスクでした。

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

Tailwind CLI で、このページと自社の JavaScript が使うクラスだけを含む CSS（17,206バイト）を事前にビルドし、Play CDN が実行時にスタイルを挿入していたのと同じ位置（head の末尾）に置いた状態を計測しました。body 内の全要素（2,561件）の計算済みスタイルを、読み込み後・スクロール後・メニュー表示・検索表示の4つの状態で比較し、見た目の差が0件であることを確認しています。

シミュレーション結果 ​

CPU 4倍減速で計測した TBT 相当値は約6割減り、同時にレンダリングをブロックするスクリプトが1つ減ったことで、FCP と LCP もそれぞれ0.4秒短縮される結果が得られました。スタイルをブラウザ上で組み立てる仕組みが、メインスレッドの負荷と表示開始の遅れの両方を生んでいたことが読み取れます。

なお、このスクリプトは記録したページを再生する環境でも壊れやすく、観測時点の計測では Tailwind のスタイルが1つも生成されていませんでした。冒頭で触れた CLS の不具合はこれが原因で、研究の途中で修正しています。

ボトルネック3: head内の同期スクリプトが最初の描画を止めている ​

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

観察された状況 ​

このページの LCP 要素は、ファーストビューのキャッチコピー「RIDE LIFE」のテキストです。メインビジュアルの画像は画面全体を覆う背景のため LCP の候補にならず、LCP は最初の描画のタイミングで決まっていました。

head には同期読み込みの JavaScript が置かれていました。HTML の到着後、特に Swiper の JavaScript の到着を待つ間の約330ms、ブラウザは HTML の解析と最初の描画を止めていました。ページ内の <script> 要素は54件（外部26件・インライン28件）ありました。

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

54件の <script> 要素を、出現順を保ったまま </body> の直前へ移動した状態を計測しました。移動後も、17か所のスライダーの初期化、メニュー、検索が動作し、ページエラーがないことを確認しています。このシミュレーションはスクリプトの実行タイミングが変わることを前提に行いました。

シミュレーション結果 ​

この時点で 総合スコア はすでに100で、Lighthouse の推定値の変化は小さくなっています。一方、実際のブラウザで計測した LCP は1.2秒から0.8秒へと約32%短縮されました。CSS が届いた直後に最初の描画が行われるようになり、スクリプトの到着を待たなくなったためです。

このシミュレーションは、画面外の画像の遅延読み込みを整える前にも試しています。そのときは、HTML の解析が早く body に進むことで画面外の画像（約20MB）の要求が前倒しされ、SI の推定値がかえって悪化しました。スクリプトの配置と画像の読み込みが互いに影響し合い、1つのボトルネックが別のボトルネックの影響を隠していたことが読み取れます。

まとめ ​

ムラサキスポーツのトップページでは、観測時点で 総合スコア が72でした。スコアの内側を観察すると、次のようなボトルネックが表示速度に影響していました。

• サードパーティータグ（13種類・140リソース）: 除去によって 総合スコア が72から96へ、SI が8.2秒から2.7秒へ変化。DMP が別の Google Tag Manager コンテナを読み込む連鎖や、計測タグの重複設置も見られました。
• 公開CDNから読み込むSwiper: 自社ドメインからの配信に置き換えることで FCP が約35%短縮。別ドメインへの接続が描画の前提になっていました。
• Tailwind CSS Play CDN: ビルド済みの CSS に置き換えることで、CPU 4倍減速での TBT 相当値が136msから53msへ、FCP が0.4秒短縮。ブラウザ上でのスタイル生成が、メインスレッドと描画開始の両方を圧迫していました。
• head内の同期スクリプト: body 末尾へ移すことで実測の LCP が約32%短縮。スクリプトの到着待ちが最初の描画を止めていました。

この他にも、Webフォントの CSS がレンダリングをブロックしていたボトルネックでは、Google Fonts の CSS を非同期にすると FCP が0.6秒から0.2秒へ、Adobe Fonts の CSS を非同期にすると LCP が2.0秒から0.8秒へ変化する結果が得られています。表示サイズよりはるかに大きな画像（幅2,000〜3,000pxの写真を247px幅で表示するなど）を縮小するシミュレーションでは、ページ全体の転送量が約3分の1になりました。

なお、全ボトルネックの解消シミュレーション後も、実際のブラウザで計測した表示開始0.75秒のうち約0.66秒（約89%）は、HTML のサーバー応答時間でした。CDN で HTML がキャッシュされず、ASP.NET がリクエストごとに HTML を生成しているため、フロントエンドの変更では短縮できない部分として、今回のシミュレーションには含めていません。実際のユーザーの体感速度を左右する要因として残っていることが観測されました。