「じゃらんニュース」トップページの表示速度ボトルネック研究

リクルートが運営する旅行・おでかけ情報メディアです。全国の観光スポット、宿泊施設、ご当地グルメ、季節のイベントなど、旅行の計画に役立つ記事を毎日配信しています。このトップページの表示速度について、どのようなボトルネックが存在するのかを調査しました。

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

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

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

総合スコア が84から100へ変化するというシミュレーション結果が得られました。特に LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）が3.5秒から0.1秒へ、FCP（First Contentful Paint = 最初のコンテンツが表示されるまでの時間）が3.3秒から0.1秒へと大きな変化が観測されています。一方、TBT（Total Blocking Time）と CLS（Cumulative Layout Shift）には変化がなく、このサイトではJavaScriptの実行負荷やレイアウトシフトはボトルネックになっていなかったことが分かります。

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

本サイトでは、解消シミュレーション後のほうが観測時点よりワンテンポ早く表示されるようになった様子が見て取れます。

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

詳細レポート

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

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

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

じゃらんニュースのトップページでは、以下の12件のサードパーティータグが確認されました。

HTMLに直接記述されたタグ ​

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

これらのサードパーティータグを段階的に除去した際の指標変化は次のとおりです。

サードパーティータグを全て除去した状態では、総合スコア が84から97へ変化し、LCP は3.5秒から2.2秒、FCP は3.3秒から2.0秒まで短縮される結果が得られました。これはあくまで上限値であり、実際にはこの一部しか実現できないとしても、サードパーティータグの最適化には無視できない改善ポテンシャルがあることが読み取れます。以降のセクションでは、この状態を起点としてサイト固有のボトルネックを観察していきます。

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

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

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

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

観察された状況 ​

head 内の最初の <script> タグで、ajax.googleapis.com から jQuery 1.8.3 が同期読み込みされていました。同期スクリプトはHTMLパーサーを完全にブロックするため、外部ドメインへの DNS 解決 + TLS 接続確立にかかる約300～500msの間、後続のCSS・JSの読み込みが一切開始できない状態が観測されました。同様に、maxcdn.bootstrapcdn.com からも Font Awesome CSS がレンダリングブロックリソースとして読み込まれていました。

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

外部CDNから読み込んでいた jQuery と Font Awesome を、同一ドメイン（www.jalan.net）からの配信に切り替えました。

シミュレーション結果 ​

外部ドメインへの接続コストが排除されたことで、FCP が2.0秒から0.7秒へ、LCP が2.2秒から0.9秒へと大きく変化しました。特に jQuery がクリティカルパス上の最初のブロッキングリソースであったため、この接続遅延がページ全体の描画開始を押し下げていた影響の大きさが読み取れます。

ボトルネック2: head内に同期スクリプトが集中している ​

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

観察された状況 ​

head 要素内に async / defer 属性のない同期 <script> タグが15個存在していました。同期スクリプトはそれぞれHTMLパーサーをブロックするため、15個のスクリプトが順番にダウンロード・実行されるまで、HTML解析が中断し続ける状態でした。

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

head 内の15個の同期 <script> タグを </body> 直前に移動し、HTML解析とCSSの読み込みが先行する構成にしました。

シミュレーション結果 ​

FCP が0.8秒から0.7秒へ短縮される結果が得られました。先行するCDN同一ドメイン化やCSS結合によってクリティカルパスが改善された状態からの追加効果であるため変化幅は限定的ですが、パーサーブロッキングの排除によってHTML解析が先行できるようになった影響が観測されています。

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

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

観察された状況 ​

サイトでは Google Fonts を通じて日本語Webフォント（Noto Sans JP）と欧文フォント（Oswald）が使用されていました。日本語Webフォントは文字数の多さから40個のサブセットファイル（合計約440KB）に分割されて配信されるため、英語フォントとは桁違いのデータ量になります。さらに、5つのCSSファイル内でそれぞれ同じ @import が記述されており、Google Fonts CSS への多重リクエストが発生している状態が観測されました。このシミュレーションはフォントの見た目が変わることを前提に行いました。

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

Google Fonts の読み込みを削除し、CSS の font-family 指定をシステムフォント（ヒラギノ角ゴ、游ゴシック、メイリオ等）にフォールバックする変更を加えました。

シミュレーション結果 ​

LCP が1.0秒から0.1秒へ、FCP が0.7秒から0.1秒へと変化する結果が得られました。Google Fonts CSS の読み込み（TTFB 約494ms）と40個の WOFF2 フォントファイル（合計440KB）のダウンロードがレンダリングブロッキングとなっていたことが、この数値から読み取れます。日本語Webフォントは文字数の多さからデータ量が英語フォントとは桁違いに大きく、表示速度への影響もそれに比例して大きくなるという事実がここに表れています。

まとめ ​

じゃらんニュース（www.jalan.net/news/）のトップページを観測したところ、総合スコア 84、LCP 3.5秒、FCP 3.3秒という値が計測されました。本研究では、この計測値の背後にあるボトルネックを切り分けて観測するため、順に解消シミュレーションを実施しました。

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

• サードパーティータグ（12件）の集合体: 除去によって 総合スコア が +13、LCP が 1.3秒短縮、FCP が 1.3秒短縮。特に Google Maps API を含む4タグの除去で 総合スコア が84から97へと変化する大きな影響が観測されました。
• パブリックCDNリソースの外部ドメイン配信: 同一ドメイン化で FCP が 1.3秒短縮、LCP が 1.3秒短縮。クリティカルパス上のブロッキングリソースが外部ドメインにあったことの影響が顕著でした。
• head内の同期スクリプト集中: </body> 直前への移動で FCP が 0.1秒短縮。
• 日本語Webフォント（Google Fonts）: 読み込み停止で LCP が 0.9秒、FCP が 0.6秒短縮。40個のサブセットファイル（約440KB）がレンダリングブロッキングとなっていた影響の大きさが確認されました。

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