「タカムラ プラス」トップページの表示速度ボトルネック研究

ワインショップ「タカムラ」が運営するワイン通販サイト「タカムラ プラス（TAKAMURA Plus）」です。ボルドー、ブルゴーニュ、シャンパーニュをはじめ、ソムリエが厳選したワインを幅広く扱っています。スマートフォン向けのトップページには、キャンペーンを切り替えて見せるメインスライダー、送料無料などのバナー、「NEW ITEM」の商品カルーセル8本が並びます。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

観測時点の 総合スコア は68でした。LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は4.3秒、CLS（Cumulative Layout Shift = ページ読み込み中のレイアウトのずれ）は0.255で、どちらも「低速」の範囲に入っていました。FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）は1.4秒、SI（Speed Index = ビューの視覚的な表示進捗の速さ）は5.1秒、TBT（Total Blocking Time = メインスレッドのブロック時間）は0msです。解消シミュレーション後は 総合スコア が100に達し、LCP は0.1秒、CLS は0.000まで変化しました。ページ全体の転送量も10.92MBから約1.41MBへ減っています。

なお、本研究の Lighthouse は、記録した通信を再生する環境で、CPUの速度制限をかけない条件で計測しています。TBT が観測時点から0msなのはこのためです。また、対処が進んだ後の FCP・LCP の推定値（0.04秒、0.14秒）は、HTMLの応答時間（約0.45秒）より短く、実際の描画時刻とはずれています。そこで本研究では、ブラウザで実際に計測した値（実測値）もあわせて記録しました。

実測値の起点は、サードパーティータグ、CLS、TBT に関するシミュレーションを終え、FCP に関するシミュレーションに入る直前の時点です。

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

観測時点とボトルネック解消シミュレーション後のページ読み込みを並べると、体感的にも明確な違いが見て取れます。動画は左が観測時点、右が解消シミュレーション後です。

観測時点ではファーストビューが描画されるまでしばらく画面が空白のままですが、解消シミュレーション後はほぼ即座にファーストビューが描画されています。

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

詳細レポート

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

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

観測時点のページの全271リソースのうち、サードパーティータグ由来のリソースは27件（約1割）でした。jQueryなどのライブラリは自社ドメインから配信されており、Google Fontsも使われていません。件数としては少なめですが、スクリプト19件のうち9件がタグ側で、展開後のサイズは合計約6.8MBありました。

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

Google Tag Manager経由で読み込まれているタグ ​

WorldShoppingは6種類の中で唯一、async と defer のどちらも付かない同期スクリプトとして読み込まれていました。また Google Analytics 4 の gtag.js（展開後約1.9MB）は、HTMLへの直接設置と Google Tag Manager 経由の2系統で、2回取得されていました。

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

この段階では、LCP が約3.0秒か約4.2秒のどちらかになる二峰性の揺らぎがあり、WorldShopping除去後の 総合スコア 79と LCP 2.9秒にはこの揺らぎが含まれます。揺らぎの原因は、後述するメインスライダーの描画タイミングでした。一方、FCP はWorldShoppingの除去で1.3秒から0.9秒へと変化しており、同期スクリプトのタグが最初の描画を待たせていたことが分かります。

サードパーティータグを全て除去した状態では、総合スコア は68から70へ、FCP は1.4秒から1.0秒へ変化する結果が得られました。タグの多くが非同期で読み込まれていたため、このページでは描画指標への影響は限られていました。ただし、今回の計測はCPUの速度制限をかけない条件であり、約6.8MBのスクリプトの処理負担は数値に表れにくくなっています。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: メインスライダーの画像に寸法がない ​

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

観察された状況 ​

Lighthouse のレイアウトシフトの監査は、送料無料バナーの画像をずれの原因として指摘していました。ところが、バナー画像に寸法を指定しても CLS は0.255のまま変わりませんでした。

そこで、読み込みの記録（トレース）にあるレイアウトシフトのイベントを調べたところ、読み込み開始から約6.5秒の時点で、送料無料バナーが257px押し下げられていました。257pxは画面幅412pxの10/16で、メインスライダーの画像（16:10）の高さと一致します。監査が指摘したバナーはずれた側の要素で、ずれを生んでいたのはメインスライダーでした。

メインスライダーは、JavaScript が組み立てたHTMLを document.write で出力し、jQueryのスライダープラグイン（slick）で初期化する作りです。スライド画像には width と height の属性がなく、画像が届くまで高さ0で描画されていました。また初期化前は、6枚のスライドがすべて縦に並んで描画されていました。

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

スライド画像に全スライド共通の縦横比（16:10）で width と height の属性を付け、CSS で height: auto を指定しました。あわせて、スライダーの初期化前は1枚目だけを表示する CSS を加えています。スライダーの見た目と動作は変えていません。

シミュレーション結果 ​

CLS は0.255から0.000へ変化し、総合スコア は70から84へ上がりました。この対処の直後の計測では 総合スコア が94になりましたが、これには LCP の二峰性の揺らぎが含まれるため、表には揺らぎの影響を受けにくい区切りの時点の値を示しています。このシミュレーション結果から、寸法を持たないスライダー画像が、このページの CLS のほぼ全量を生んでいたボトルネックであったことが読み取れます。

ボトルネック2: 別ドメインのCSSが初回描画を約1秒保留させる ​

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

観察された状況 ​

HTMLは takamuraplus.jp から配信されていますが、CSS は別ドメインの takamuraplus.com から読み込まれていました。研究の途中で、6本に分かれていた CSS を1本にまとめたり、同期スクリプトを非同期にしたりするシミュレーションを重ねると、Lighthouse の FCP の推定値は大きく下がりました。ところが、ブラウザで実際に計測した FCP と LCP は、約1.55秒のままほとんど動きませんでした。

実測のタイムラインを調べると、HTMLの受信から初回描画まで約1,080msの空白があり、その間メインスレッドにはほとんど処理がありませんでした。検証用のコピーで条件を1つずつ変えて切り分けたところ、<body> を空にしても初回描画は約1.54秒のままでした。一方、別ドメインの CSS の応答時間を30msまで縮めると初回描画は約0.52秒に早まり、80msや150msではまた約1.54秒に戻りました。別ドメインのレンダリングブロック CSS の到着がわずかに遅れるだけで、初回描画が約1秒保留されていたことになります。

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

1本にまとめた takamuraplus.com の CSS（約20KB）を、HTML内の <style> に直接記述しました。CSS の内容は変えていません。

シミュレーション結果 ​

CSS を取得するリクエストがなくなり、初回描画の保留が解消されました。Lighthouse の LCP の推定値はすでに下限に張り付いていたため変わりませんでしたが、実測 LCP は約1.56秒から約0.64秒へ、実測値を記録した中で最も大きく変化しています。

この後、LCP 画像を preload するシミュレーションを行うと、実測 LCP はさらに約0.06秒短くなりました。同じシミュレーションは CSS を埋め込む前にも試していましたが、そのときはシミュレーション上の LCP がかえって悪化したため採用していませんでした。このシミュレーション結果から、別ドメインの CSS による初回描画の保留が、ほかの対処の効果をすべて覆い隠すほどの、実際の描画を律速するボトルネックであったことが読み取れます。

ボトルネック3: head内の楽天ドメインの同期スクリプト ​

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

観察された状況 ​

<head> 内で、楽天市場の店舗ドメイン（www.rakuten.ne.jp）に置かれた自社スクリプト2本が、同期で読み込まれていました。期間限定バナーの表示を切り替える display_switcher.js と、出荷日表示用の関数を定義する syukkabi.js です。サーバーの応答に約740msかかり、その間HTMLの解析が止まっていました（Lighthouse の推定でレンダリングブロック738ms）。

楽天市場の店舗と自社サイトでスクリプトを共有したいという運用上の事情は、十分に理解できます。ただし研究を進めると、display_switcher.js の処理は研究の途中でHTML内に追加した同じ判定で代替でき、syukkabi.js はHTMLコメント内からしか呼ばれていないことも分かりました。

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

jQueryに依存する display_switcher.js には実行順が保たれる defer を、どこからも依存されていない syukkabi.js には async を付け、HTMLの解析を止めないようにしました。

シミュレーション結果 ​

FCP は1.0秒から0.4秒へ、総合スコア は83から92へ変化しました。続いて、takamuraplus.com から同期で読み込まれていた自社スクリプト4本を非同期にすると、FCP は0.4秒から0.2秒へ、総合スコア は94へ変化しています。

なお、この時点の実測 FCP は、ボトルネック2の初回描画の保留に律速されて約1.55秒のままでした。表の変化は Lighthouse の推定値に表れたものです。それでも、応答の遅い別ドメインのスクリプトが <head> で解析を止めていた構造は、Lighthouse が評価する最初の描画を大きく遅らせていました。このシミュレーション結果から、楽天ドメインの同期スクリプトが FCP と 総合スコア に与えていた影響の大きさが読み取れます。

まとめ ​

タカムラ プラスのトップページの表示速度を観測したところ、総合スコア 68、LCP 4.3秒、CLS 0.255という値が計測されました。本研究では、これらの計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（27リソース）: 全て除去した状態では 総合スコア が68から70へ、FCP が1.4秒から1.0秒へ変化。同期読み込みのWorldShoppingが FCP の変化の主な要因でした。
• メインスライダーの画像に寸法がない: 表示領域を先に確保することで、CLS が0.255から0.000へ、総合スコア が70から84へ変化しました。
• 別ドメインのCSSによる初回描画の保留: CSS をHTMLに埋め込むことで、実測 LCP が1.6秒から0.6秒へ変化しました。
• head内の楽天ドメインの同期スクリプト: 非同期にすることで、FCP が1.0秒から0.4秒へ、総合スコア が83から92へ変化しました。

このほか、スマートフォンでのアクセス時にトップURLから /smartphone/ へ転送するリダイレクト（実測 LCP で約0.23秒）、ページ転送量の約98%を占めていたJPEG・PNGの画像と表示サイズより大きい画像（WebP化とリサイズで約9.2MBから約1.41MB）、応答に約4秒かかる外部の画像ホストなども観測されています。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は68から100へ、LCP は4.3秒から0.1秒へ、CLS は0.255から0.000へと変化しました。とりわけ、監査が指摘したバナーではなくメインスライダーがレイアウトのずれを生んでいたこと、別ドメインの CSS がほかの対処の効果を覆い隠すほどに実際の描画を止めていたことは、Lighthouse の指摘や推定値だけでは見えにくいボトルネックでした。これらの要素がこのページの表示速度に大きな影響を与えていたことが、この一連のシミュレーションによって読み取れます。