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

WEGOは日本のストリートファッションを中心に展開するアパレルブランドで、公式オンラインストアではレディース・メンズのウェア、シューズ、バッグ、アクセサリーなどを幅広く販売しています。Shopifyベースで構築されたトップページについて、モバイル環境での表示速度上のボトルネックを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が62から100へと38ポイント変化するというシミュレーション結果を得ました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が25.8秒から1.0秒へと大幅に短縮されており、表示速度に強く影響するボトルネックが複数存在していたことが読み取れます。

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

本サイトでは、解消シミュレーション後に大幅な表示速度の改善が見られます。

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

詳細レポート

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

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

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

WEGOオンラインストアで確認されたサードパーティータグは次のとおりです。

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

GTM 経由で読み込まれるタグ ​

合計32件のサードパーティータグが確認され、リクエスト数は483件、転送サイズは11.18MBに達していました。段階的に除去した際の指標変化は次のとおりです。

サードパーティータグを全て除去した状態では、総合スコア は62から100へ変化し、LCP は25.8秒から1.4秒まで短縮される結果が得られました。リクエスト数も483件から341件へ、転送サイズも11.18MBから5.16MBへと大幅に削減されています。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルの存在が読み取れます。

以降のセクションでは、この状態を起点としてサイト固有のボトルネックを観察していきます。

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

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

ボトルネック1: 独立スクリプトによるレンダリングブロック ​

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

観察された状況 ​

<body> 末尾に移動済みのスクリプト群の中に、他のスクリプトとの依存関係を持たない独立スクリプトが2つ（policy.js、zeta-voice-display.js）存在していました。これらは async・defer 属性なしで同期的に読み込まれており、ブラウザのHTMLパーシングをブロックしてレンダリングの進行を妨げている状況が観測されました。

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

依存関係のない2つのスクリプトに async 属性を付与し、HTMLパーシングと並行してダウンロード・実行される状態を作りました。

シミュレーション結果 ​

FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が1.0秒から0.6秒に短縮され、LCP と SI もそれぞれ0.3秒短縮される結果が得られました。たった2つのスクリプトに async 属性が付いていなかっただけで、これだけの影響を、このシミュレーション結果から読み取れます。

ボトルネック2: head内同期スクリプトによるHTMLパーシングブロック ​

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

観察された状況 ​

<head> 内に配置された vendor.toppage.js と toppage.js の2ファイルが、defer 属性なしで読み込まれていました。<head> 内の同期スクリプトはHTMLパーサーを停止させるため、スクリプトのダウンロードと実行が完了するまでページのレンダリングが開始されません。

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

2つのスクリプトに defer 属性を付与し、HTMLパーシングと並行してダウンロードが行われ、パーシング完了後に実行される状態を作りました。

シミュレーション結果 ​

FCP が0.2秒短縮される結果が得られました。<head> 内のスクリプトにHTML属性（defer）が1つ欠けているだけでレンダリング開始が遅延するという、HTML属性レベルのボトルネックがここに確認されました。

ボトルネック3: Google Fonts（日本語Webフォント）の読み込み ​

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

観察された状況 ​

サイトでは Google Fonts から3書体（Inter、Noto Sans JP、Oswald）が読み込まれていました。特に日本語Webフォントの Noto Sans JP は文字数が多いため複数のサブセットファイルに分割されており、外部ドメイン fonts.googleapis.com からCSSを取得した上でさらに fonts.gstatic.com からフォントファイルをダウンロードするという二段階のリソース取得が発生していました。

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

Google Fontsの読み込みを全て削除し、CSS の font-family 指定をシステムフォントにフォールバックさせました。このシミュレーションはサイトの見た目（フォントの表示）が変わることを前提として行いました。

シミュレーション結果 ​

FCP が0.6秒から0.1秒へと大幅に短縮され、SI（Speed Index = ビューの視覚的な表示進捗の速さ）も1.7秒から0.9秒へと変化する結果が得られました。Google Fonts が2つの外部ドメインにまたがるリソース取得を必要とし、特に日本語フォントの Noto Sans JP がデータ量の大きさから FCP に対して強い影響を与えていたことを、この数値から読み取れます。Webフォントをサイトで使いたいデザイン上の意図は理解できますが、日本語フォントの場合は文字数の多さから生じるリソースサイズが指標に対して明確に表れるという事実がここに観測されました。

まとめ ​

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

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

• サードパーティータグの集合体（32件、483リクエスト、11.18MB）: 除去によって 総合スコア が +38、LCP が24.4秒短縮。特に KARTE・StaffStart 等 マーケティング系5件の除去で一気に +29ポイントの影響が観測されました。
• 独立スクリプトのレンダリングブロック: async 属性付与によって FCP が0.4秒、LCP が0.3秒短縮。
• head内同期スクリプト: defer 属性付与によって FCP が0.2秒短縮。
• Google Fonts（日本語Webフォント Noto Sans JP）: 読み込み停止で FCP が0.5秒、SI が0.8秒短縮。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は62から100へ、LCP は25.8秒から1.0秒へと変化しました。観測された各要素がそれぞれ独立して指標に与えていた影響の大きさが、この一連のシミュレーションによって確認できた形です。