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

Pierrot（ピエロ）は、大人の女性向けにトレンドファッションをリーズナブルな価格で提供するレディースファッション通販サイトです。トップス、パンツ、ワンピースなど幅広いアイテムを展開しています。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が47から93へと46ポイント変化するシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が16.8秒から0.9秒へ、SI（Speed Index = ビューの視覚的な表示進捗の速さ）が13.1秒から2.2秒へと大きな変化が観測されており、表示速度に強く影響するボトルネックが複数存在していたことが読み取れます。

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

本サイトでは、解消シミュレーション後も依然として画像の読み込みやレイアウトの確定にもたつきが見られ、読み込みプロセス動画上では劇的・大幅な体感速度の改善という結果までは得られませんでした。

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

詳細レポート

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

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

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

pierrotshop.jpでは合計136件のサードパーティーリソースが確認されました。HTMLから直接読み込まれているものと Google Tag Manager 経由で配信されているものがあります。

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

GTM経由で配信されているタグ ​

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

サードパーティータグを全て除去した状態では、総合スコア は47から73へ変化し、LCP は16.8秒から2.3秒へ、SI は13.1秒から3.3秒へという値が得られました。特に Channel.io と広告・トラッキングタグ19種の除去段階で大きな変化が集中しています。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。

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

サードパーティータグの影響を除いた上で、サイト自体の構成に起因するボトルネックを観察しました。全16件のボトルネック仮説を検証した中から、特に影響の大きかった3件を紹介します。

ボトルネック: バナースライダーの高さ未固定 ​

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

観察された状況 ​

トップページのメインバナースライダー（div.bannerSlider）で、slick-carousel の JavaScript 初期化前に全スライド画像が縦に並んで表示され、初期化後に1枚表示に切り替わることで非常に大きなレイアウトシフトが発生していました。CLS の値は0.882に達し、そのうち98%がこのバナースライダーに起因するものでした。

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

CSS の :not(.slick-initialized) セレクタを使い、slick-carousel 初期化前の状態で2枚目以降のスライドを画面外に配置することで、表示高さを1枚分に固定しました。初期化後はこのセレクタが外れるため、カルーセルの動作には影響しません。

シミュレーション結果 ​

解消前	解消後

CLS が0.882から0.128へ、総合スコア が73から94へと大きく変化しました。バナースライダーの初期化前の高さが固定されていないことが、CLS を悪化させる最大のボトルネックであったことがこの結果から読み取れます。

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

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

観察された状況 ​

jQuery、slick-carousel（CSS + JS）、picturefill の4リソースが、code.jquery.com、cdn.jsdelivr.net、cdnjs.cloudflare.com の3つの外部CDNドメインから配信されていました。各ドメインへのDNSルックアップ、TCP接続、TLSハンドシェイクが個別に発生するため、クリティカルパス上のリソース取得に遅延が生じていました。

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

3つの外部CDNドメインから配信されていた4リソースを、pierrotshop.jp ドメインに移管するシミュレーションを行いました。これにより、外部ドメインへの個別の接続コストが不要になります。

シミュレーション結果 ​

解消前	解消後

FCP が1.2秒から0.8秒へ34%短縮、LCP が2.4秒から1.0秒へ58%短縮という結果が得られました。パブリックCDNは手軽に利用できる一方で、外部ドメインへの接続コストがクリティカルパスに乗ることで表示速度のボトルネックとなっていたことが、この結果から読み取れます。

ボトルネック: TypeKitフォントの@importチェーン ​

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

観察された状況 ​

Adobe TypeKitのCSS（riz6zog.css）が p.typekit.net/p.css を @import で読み込んでおり、HTML → CSS → @import CSS → フォントファイルという連鎖的な読み込みが発生していました。この @import チェーンにより、合計700ms以上のレンダリングブロックが生じていました。このシミュレーションは、TypeKitフォントを廃止しシステムフォントに代替するため、サイトのデザイン（フォントの見た目）が変わることを前提として行いました。

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

TypeKit CSS の読み込みを削除し、font-family をシステムフォント（Georgia、Helvetica Neue 等）にフォールバックさせました。これにより @import チェーン自体が解消されます。

シミュレーション結果 ​

解消前	解消後

FCP が47%、LCP が41%短縮されるという結果が得られました。TypeKitの @import チェーンは、CSSの読み込みが完了するまでページのレンダリングを止めてしまうため、表示速度に対して極めて大きなボトルネックとなっていたことがこの結果から読み取れます。

まとめ ​

本研究では、Pierrotのトップページにおける表示速度のボトルネックを観察しました。

サードパーティータグとして合計136件のリソースが確認され、これらを除去するシミュレーションでは 総合スコア が47から73へ変化する結果が得られました。特に Channel.io と広告・トラッキングタグ19種の影響が大きく、サードパーティータグ全体が表示速度に与えていた影響の大きさが数値として示されました。

サイト固有のボトルネックとしては、バナースライダーの高さ未固定が CLS を0.882まで悪化させていたこと、パブリックCDNの外部ドメイン配信が FCP ・ LCP を遅延させていたこと、TypeKitフォントの @import チェーンが700ms以上のレンダリングブロックを生じさせていたことが、それぞれのシミュレーション結果から確認されました。これらのボトルネックが複合的に作用した結果、観測時点で 総合スコア 47、LCP 16.8秒という状態になっていたことが、本研究を通じて明らかになりました。