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

アーティストの新曲・動画・ライブ・コンサート情報を届ける音楽メディアサイトです。モバイル環境での表示速度について、どのような要素がボトルネックとなっているのかを研究するため、解消シミュレーションを実施しました。

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

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

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

総合スコア が90から100へと10ポイント変化するというシミュレーション結果が得られました。元々 TBT（Total Blocking Time = メインスレッドのブロッキング時間の合計）が0ms、CLS（Cumulative Layout Shift = レイアウトのずれ）が0.023と良好な状態にあり、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）と FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）にボトルネックが集中していたことが読み取れます。

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

本サイトでは、読み込みプロセス動画上では観測時点と解消シミュレーション後で表示スピードに大きな差は感じられませんでした。

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

詳細レポート

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

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

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

www.barks.jp で確認されたサードパーティータグは次のとおりです。

なお、Public CDN（jQuery、Swiper、yakuhanjp、lenis、Font Awesome、GSAP）および Google Fonts（Noto Sans JP、Questrial）はサードパーティータグとしては扱わず、後続のボトルネック検証で個別に分析しています。

段階的に除去した際の指標変化は次のとおりです。

全タグを除去した状態では 総合スコア が90から89へとわずかに低下し、LCP もやや悪化する結果が得られました。これは計測揺らぎの範囲内であり、barks.jp においてはサードパーティータグの表示速度への影響は限定的であることが読み取れます。サードパーティータグが全て非同期で読み込まれており、レンダリングをブロックしていない構成であったことが要因と考えられます。以降のセクションでは、サードパーティータグ除去後の状態を起点としてサイト固有のボトルネックを観察していきます。

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

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

ボトルネック1: Google Fonts CSSが外部ドメインから配信されている ​

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

観察された状況 ​

Google Fonts の CSS（Noto Sans JP、Questrial）が fonts.googleapis.com から配信されている状態でした。CSS はレンダリングブロックリソースであり、外部ドメインへの DNS 解決と TLS 接続が完了するまでページの描画が開始されないため、FCP に直接影響していることが観測されました。

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

Google Fonts の CSS を www.barks.jp ドメインから配信するように変更し、重複していた preconnect タグも整理しました。

シミュレーション結果 ​

解消前	解消後

Google Fonts の CSS を同一ドメインに移すだけで FCP が0.9秒から0.5秒へと約45%変化するという結果が得られました。CSS がレンダリングブロックリソースであるため、外部ドメインへの接続コストがそのまま FCP の遅延として表れていたことが読み取れます。このボトルネックは FCP フェーズで最も影響が大きかったものです。

ボトルネック2: LCP画像に loading="lazy" が設定されている ​

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

観察された状況 ​

ファーストビューのカルーセル画像（LCP 要素）に loading="lazy" が設定されている状態でした。loading="lazy" はビューポート外の画像を遅延読み込みするための属性ですが、ファーストビューの LCP 画像に設定されていると、ブラウザが画像のフェッチ開始を遅延させるため逆効果となります。

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

LCP 画像の loading 属性を eager に変更し、fetchpriority="high" を追加することで、ブラウザに優先的なダウンロードを指示しました。

シミュレーション結果 ​

解消前	解消後

HTML属性を変更するだけで LCP が0.8秒短縮され、総合スコア 100を達成するという結果が得られました。ファーストビューの LCP 画像に loading="lazy" が設定されていたことが、LCP における明確なボトルネックであったことが読み取れます。

ボトルネック3: CDN CSSが外部ドメインから配信されている ​

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

観察された状況 ​

yakuhanjp、Swiper、Font Awesome の3つの CSS ファイルが、cdn.jsdelivr.net や cdnjs.cloudflare.com といった外部CDNドメインから配信されている状態でした。Google Fonts CSS と同様に、外部ドメインへの接続コストが FCP に影響していることが観測されました。

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

3つの CDN CSS を www.barks.jp ドメインから配信するように変更しました。

シミュレーション結果 ​

解消前	解消後

CDN CSS を同一ドメインに移すことで FCP が1.5秒から1.0秒へと変化する結果が得られました。外部CDNからの CSS 配信が、DNS 解決と TLS 接続のコストを通じて FCP のボトルネックとなっていたことが読み取れます。

まとめ ​

BARKS（www.barks.jp）の表示速度を観測したところ、総合スコア 90、LCP 3.5秒、FCP 1.5秒という値が計測されました。TBT が0ms、CLS が0.023と既に良好であった一方、LCP と FCP にボトルネックが集中していました。

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

• Google Fonts CSSの外部ドメイン配信: 同一ドメインへの移管で FCP が約45%変化。レンダリングブロックリソースが外部ドメインにあることの影響の大きさが観測されました。
• LCP画像への loading="lazy" 設定: eager への変更と fetchpriority="high" の追加で LCP が0.8秒短縮、総合スコア 100を達成。
• CDN CSSの外部ドメイン配信: 同一ドメインへの移管で FCP が0.5秒短縮。Google Fonts CSS と合わせて、外部ドメインからの CSS 配信が FCP の主要なボトルネックとなっていたことが確認されました。
• サードパーティータグの影響: barks.jp では全て非同期読み込みとなっており、表示速度への影響は限定的でした。

全ボトルネックの解消シミュレーションを重ねた結果、総合スコア は90から100へ、LCP は3.5秒から1.4秒へ、FCP は1.5秒から0.5秒へと変化しました。barks.jp のボトルネックは主に外部ドメインからのレンダリングブロックリソース配信と LCP 画像の読み込み優先度に起因しており、サイト構成の技術的な要因が指標に与えていた影響の大きさが、この一連のシミュレーションによって確認できた形です。