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

Hamee株式会社が運営するスマートフォンケース・アクセサリーの公式オンラインストアです。人気ブランドiFaceをはじめ、耐衝撃ケースやキャラクターコラボ商品を多数取り扱っています。Shopifyをプラットフォームとして運用されており、モバイル環境での表示速度にどのようなボトルネックが存在するかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が63から100へと37ポイント変化するというシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が20.9秒から1.0秒へと約19.9秒短縮される変化が観測されており、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）も2.6秒から0.4秒へと大きく変化しています。これらの指標に強く影響するボトルネックが存在していたことが読み取れます。

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

本サイトでは、動画撮影ツールの仕様上メイン画像がうまく撮影されていませんが、それ以外の要素については解消シミュレーション後のほうが若干早く表示されるようになった様子が見て取れます。

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

詳細レポート

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

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

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

本サイトでは計22種のサードパーティータグが確認されました。さらに Google Tag Manager 経由で間接的に読み込まれるリソースを含めると、合計73ドメインからリソースが読み込まれていました。

HTMLに直接埋め込まれたタグ（13種） ​

Shopify Web Pixels Manager経由のタグ（9種） ​

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

サードパーティータグを全て除去した状態では、総合スコア が63から100へ変化し、LCP は20.9秒から1.6秒、FCP は2.6秒から1.0秒まで短縮される結果が得られました。特に第1段階の Criteo 除去だけで LCP が約16.5秒短縮されており、Cookie同期先17ドメインへの大量リクエストが LCP の支配的な要因であったことが読み取れます。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが分かります。

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

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

ボトルネック1: CDNリソースが外部ドメインから配信されている ​

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

観察された状況 ​

アイコンフォント用の CSS が外部CDN（code.ionicframework.com、maxcdn.bootstrapcdn.com）から配信されている状態が観測されました。外部ドメインへのリクエストではDNS解決やTLSハンドシェイクが新たに発生するため、レンダリングブロックリソースである CSS の取得完了が遅延し、FCP に影響を与えていました。

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

外部CDNから読み込んでいたIonicons CSSとフォントファイル、Font Awesome CSSを、同一ドメイン（www.strapya.com）からの配信に変更しました。

シミュレーション結果 ​

同一ドメインへの移行によって既存のHTTP接続が再利用可能となり、FCP が0.4秒短縮される結果が得られました。外部ドメインからのレンダリングブロックリソース配信が FCP に対して無視できないボトルネックとなっていたことが読み取れます。

ボトルネック2: 巨大インラインスクリプトによるHTMLの肥大化 ​

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

観察された状況 ​

HTMLに埋め込まれたインラインスクリプトとして、サイト内検索用の全商品データJSON（約703KB）とフォームビルダー定義データJSON（約303KB）が存在していました。これらは初期表示には不要なデータですが、HTMLの一部として転送されるため、HTMLサイズが約1.94MBに達し、ドキュメントのダウンロードとパースに余分な時間がかかっている状態でした。

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

初期表示に不要な2つの巨大インラインスクリプト（合計約1MB）をHTMLから削除し、HTMLサイズを1.94MBから1.00MBへ約50%削減した状態を作りました。

シミュレーション結果 ​

LCP が0.2秒短縮される結果が得られました。HTMLドキュメントの転送量が401KBから204KBに削減されたことで、ドキュメントのダウンロード完了が早まり、後続リソースの取得開始も前倒しされたことが影響しています。初期表示に不要なデータがHTMLに含まれていることが、ドキュメント転送のボトルネックとなっていたことが読み取れます。

ボトルネック3: 未使用の日本語Webフォント（Noto Sans JP） ​

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

観察された状況 ​

Google Fontsから日本語フォント Noto Sans JP（ウェイト400/700）が読み込まれていましたが、CSS内にNoto Sans JPの font-family 参照が一切存在しませんでした。つまり、229KBのCSSが読み込まれ、外部ドメイン（fonts.googleapis.com）へのリクエストも発生していたにもかかわらず、実際のレンダリングには使用されていない状態でした。

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

使用されていないGoogle Fontsの <link> 要素を削除しました。CSSで参照されていないフォントであるため、ページの見た目に変化はありません。

シミュレーション結果 ​

未使用にもかかわらず読み込まれていた229KBのCSSを削除したことで、FCP が0.4秒短縮される結果が得られました。このCSSはレンダリングブロックリソースとして検出されていたため、削除によってレンダリング開始が前倒しされたことが影響しています。日本語Webフォントのリソースサイズの大きさと、未使用のまま残存していたことが FCP に対する明確なボトルネックであったことが読み取れます。

まとめ ​

Hamee本店（strapya.com）の表示速度を観測したところ、総合スコア 63、LCP 20.9秒、FCP 2.6秒という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（22種・73ドメイン）: 除去によって 総合スコア が +37、LCP が 19.3秒短縮。特に Criteo のCookie同期17ドメインが LCP の支配的な要因でした。
• 外部ドメインからのCDNリソース配信: 同一ドメイン化で FCP が 0.4秒短縮、LCP が 0.6秒短縮。
• 巨大インラインスクリプト: HTML軽量化で LCP が 0.2秒短縮。HTMLサイズが約50%削減されました。
• 未使用の日本語Webフォント: 削除で FCP が 0.4秒短縮。CSSで参照されていないフォントがレンダリングブロックを引き起こしていました。

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