「ポリピュアEX」トップページの表示速度ボトルネック研究

シーエスシー株式会社が運営する、薬用育毛剤「ポリピュアEX」の公式通販サイトです。独自成分のバイオポリリン酸を配合した育毛剤を中心に、シャンプーとのセットやまとめ買い、定期お届けコースを扱っており、ショップシステムにはMakeShopが使われています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

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

なお、本研究の計測はCPUスロットリングなしの条件で行っているため、PageSpeed Insightsの数値とは一致しません。

このサイトでは、研究の後半で Lighthouse のシミュレーション値が下限に張り付き、それ以上の差が数値に表れなくなりました。そこで、同じ計測のトレースに記録されたブラウザ上の実際の描画タイミング（以下、実測値）もあわせて記録しています。サードパーティータグとレイアウトのずれを解消した後の時点を起点にすると、実測値は次のように変化しました。

実際の描画は1.4秒台から0.2秒弱まで短縮しており、シミュレーション値だけでは見えないボトルネックの影響が、実測値に表れています。

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

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

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

詳細レポート

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

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

オリジナルページの全225リソースのうち、サイト固有のリソースは42件（約2割）、サードパーティタグ由来のリソースは183件（約8割）を占めていました。転送量で見るとページ全体の約89%（約4.1MB）、メインスレッドの処理時間で見ると約78%（約831ms）がサードパーティータグによるものでした。

HTMLには次の10件のタグ（単体のタグ5件とGTMコンテナ5件）が直接記述されていました。

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

Google Tag Managerのコンテナ ​

1ページに Google Tag Manager のコンテナが5つ設置されており、そのうち2つは計測を終了した（標準版）ユニバーサル アナリティクスの読み込みだけ、1つは404を返すコンテナでした。

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

途中の段階で 総合スコア が66まで下がっていますが、同じ計測の実測 LCP は1.43秒でほぼ変わっておらず、実際の読み込みが悪化したわけではありません。タグを除去して残ったリクエストの大半がショップシステムのアセット配信ドメインに集中し、Lighthouse の推定が大きく揺らいだものです。この揺らぎ自体が、後述するサイト固有のボトルネックの存在を示していました。

サードパーティータグを全て除去した状態では、総合スコア は90から91への変化にとどまったものの、LCP は2.1秒から1.0秒へ短縮され、ネットワークリクエストは200件以上から41件に減る結果が得られました。スコアへの影響が小さかったのは、CPUスロットリングなしの計測ではタグの処理が長いタスクにならなかったこと、そして観測時点の主な減点要因であった CLS がサイト自体の画像に起因していたためです。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、約4.1MBの通信と約0.8秒のメインスレッド処理を占めるサードパーティータグの最適化には、無視できない改善ポテンシャルがあることが読み取れます。

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

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

ボトルネック1: 画像・CSS・JavaScriptをHTTP/1.1の別ドメインから配信 ​

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

観察された状況 ​

HTMLは HTTP/2 に対応した 529270.com から配信されている一方、画像・CSS・JavaScript はショップシステムのアセット配信ドメイン gigaplus.makeshop.jp から配信されていました。このドメインは HTTP/1.1 にしか対応しておらず、ブラウザは同じホストに同時に6本までしか接続しません。HTMLから一斉に要求された約30件が待ち行列になり、応答まで約600msかかっていました。

同じサーバーの画像でも、少し遅れて要求されたものは15〜17msで応答しており、ファイルごとの処理が遅いわけではなく、同時に要求したことによる待ち行列が遅延の正体でした。その間、CSS と同期スクリプトの到着待ちでHTMLの解析が約620ms止まり、初回描画が遅れていました。

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

同期読み込みされていた JavaScript 4件（スライダー、イージング、アコーディオンメニュー、ページ内スクロール）を、HTMLと同じ 529270.com から配信する状態を作りました。移したリソースの応答時間は、529270.com から配信されていた静的ファイルの応答時間の最大値（53ms）を想定しています。直前には CSS 2件も同様に移していますが、CSS 単独では同期スクリプトの到着待ちが残り、実測の FCP は変わりませんでした。

シミュレーション結果 ​

レンダリングをブロックする CSS・JavaScript 計10件が0.75秒までに揃うようになり、HTMLの解析停止がほぼ解消しました。CSS と JavaScript の両方の待ちが解けて初めて描画が早まる、という結果です。

続けて、LCP 要素であるトップバナー画像も同じように 529270.com から配信する状態を作ると、次のような変化が観測されました（詳細レポート）。

さらに残りの画像28件も移すと、LCP のシミュレーション値は0.64秒から0.07秒へ下がりました。FCP でも LCP でも、アセット配信ドメインでの約600msの応答待ちがそのまま描画の遅れになっていたことが、このシミュレーション結果から読み取れます。本研究で観測されたボトルネックの中でも、特に影響の大きかった要因の一つです。

ボトルネック2: 画像にwidth/height属性がないことによるレイアウトのずれ ​

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

観察された状況 ​

サードパーティータグを除去した後も CLS は0.190のままで、総合スコア を押し下げている唯一の指標でした。トレースに記録されたレイアウトシフトを調べると、3件のシフトすべてが、width / height 属性のない画像によるものでした。

画像が初回描画より先に届いた回だけシフトが起きないため、同じ状態で計測を繰り返すと CLS が0.051〜0.190の間で揺らいでいました。1回の計測では見逃されることもあるボトルネックです。

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

かつてスライダーがあった位置に表示されているトップバナー画像の <img> に、画像の実寸（width="640" height="290"）を属性として追加し、表示幅はコンテナに合わせて縦横比を維持する状態を作りました。続けて、商品導線バナー2件にも同様に実寸を指定しています。

シミュレーション結果 ​

トップバナー画像1枚に実寸を指定しただけで、最大のシフトが消え、総合スコア が91から100へ変化する結果が得られました。続く商品導線バナー2件への指定で、CLS は0.000になっています。観測時点から最終結果までの 総合スコア の変化（+10）の大部分は、このボトルネックの解消によるものでした。寸法の指定がない画像という小さな要因が、スコアに与えていた影響の大きさが読み取れます。

ボトルネック3: トップページの302リダイレクト ​

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

観察された状況 ​

https://529270.com/ にアクセスすると、スマートフォン判定によって https://529270.com/smartphone/ へ302リダイレクトされていました。リダイレクトの応答に約0.5秒かかり、その分だけHTMLの受信開始が遅れていました。

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

トップURLがスマートフォン版のHTMLを直接返す状態を作りました。URLが変わっても参照先が変わらないよう、HTML内の相対パスはルート相対パスに書き換えています。このシミュレーションは、サーバー側の端末判定の仕組みが変わることを前提に行いました。

シミュレーション結果 ​

リダイレクトにかかっていた約0.5秒が、そのまま実際の描画開始の短縮として表れる結果が得られました。一方、FCP のシミュレーション値はほぼ変化していません。Lighthouse のシミュレーションはリダイレクトの時間を FCP の推定にほとんど反映しないためで、シミュレーション値だけを見ていると見落とされるボトルネックであったことが、実測値との比較から読み取れます。

まとめ ​

ポリピュアEX（529270.com）のトップページの表示速度を観測したところ、総合スコア 90、LCP 2.1秒、CLS 0.190という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（10件、183リソース）: 転送量の約89%とメインスレッド処理時間の約78%を占めていました。除去によって LCP は2.1秒から1.0秒へ短縮した一方、今回の計測条件では 総合スコア の変化は+1にとどまりました。
• 画像・CSS・JavaScriptのHTTP/1.1別ドメイン配信: 約30件の同時要求による待ち行列で、応答まで約600msかかっていました。同一ドメインからの配信を想定したシミュレーションで、実測の FCP と LCP がそれぞれ約0.6秒短縮しました。
• 画像のwidth/height属性の欠如: CLS 0.190のすべてがこの要因によるもので、トップバナー画像への実寸指定だけで 総合スコア が91から100へ変化しました。
• トップページの302リダイレクト: HTMLの受信開始を約0.5秒遅らせていました。シミュレーション値にはほとんど表れないものの、実測の FCP と LCP は約0.5秒短縮しました。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は90から100へ、実測の FCP は1.42秒から0.18秒へと変化しました。最終状態で残っていたのは、HTMLを生成するサーバーの処理時間（約0.14秒）とブラウザのレイアウト・描画（約0.04秒）だけです。配信ドメインの通信方式やリダイレクトといった、ページの見た目には表れない配信経路の要因が表示速度に与えていた影響の大きさが、この一連のシミュレーションによって確認できた形です。