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

GIGAZINE（ギガジン）は、日々のあらゆるシーンで役立つ情報を毎日更新するIT系ニュースサイトです。ガジェット、サイエンス、ソフトウェア、ネットカルチャーなど幅広いジャンルの記事を配信する日本の老舗メディアのひとつとして知られています。本記事では、モバイル環境におけるトップページの表示速度に関するボトルネック研究の観測結果を記録します。

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

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

本サイトは観測時点で 総合スコア 86、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）4.2秒という観測値が記録されており、メディアサイトとしてはやや重い数値が観測されていました。一方、CLS（Cumulative Layout Shift = レイアウトのずれ）は0.004、TBT（Total Blocking Time = メインスレッドのブロック時間）は15msといずれも小さく、レイアウト安定性とメインスレッド負荷にはほぼボトルネックが存在しない状態でした。本研究ではボトルネックを段階的に解消した場合の影響を計測することを目的としており、各種シミュレーションの結果として LCP が0.3秒まで変化するという観測が得られました。

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

本サイトでは、解消シミュレーション後に画像の表示タイミングが早くなった様子が見て取れます。

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

詳細レポート

本研究ではまず、サードパーティータグ（広告・アクセス解析・プッシュ通知など外部サービスのスクリプト）を除去したシミュレーションを行い、タグ全体が表示速度に与える最大改善ポテンシャルを観測します。同時に、以降のサイト本体のボトルネック観察におけるノイズ除去も兼ねています。なお、サイト運営上必要なタグも含まれるため、すべてを除去することは現実的ではありません。

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

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

GIGAZINEで確認されたサードパーティータグは以下の通りです。広告配信、アナリティクス、プッシュ通知、スクリプト管理の4カテゴリにわたる10件のタグが読み込まれていました。

これら10件のサードパーティータグを除去した場合の変化は以下の通りです。

サードパーティータグのみの除去で 総合スコア が86から100へ、LCP が4.2秒から0.9秒へ変化し、リソース数の83%・転送サイズの69%がサードパーティータグ由来であったことが観測されました。以降の観察では、この状態を起点としてサイト本体の実装に由来するボトルネックを順次解消しながら数値の変化を記録します。

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

サードパーティータグの影響を切り分けた上で、サイト本来の実装に起因するボトルネックを順次解消しながら観測を進めます。本研究では全6件の解消シミュレーションを実施しました。その中から、特に影響が大きかった3つのボトルネックを紹介します。

1. パブリックCDNリソースが別ドメイン経由 — FCPが46%の変化 ​

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

観察された状況 ​

ページでは jQuery 1.12.4 が ajax.googleapis.com から、pubcid.min.js が cdn.jsdelivr.net から配信されており、HTMLとは異なるドメイン経由で読み込まれていました。外部ドメインへの初回接続には DNS 解決とTLSハンドシェイクが必要であり、この接続確立コストが描画開始のタイミングを遅延させているという状況が観測されました。

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

外部CDNから配信されていた jquery.min.js と pubcid.min.js を、HTMLと同一ドメイン（gigazine.net）から配信するように変更しました。リソースの中身は変更せず、配信元のドメインのみを切り替えています。

シミュレーション結果 ​

配信ドメインを揃えるだけで FCP が46%変化するという観測結果が得られました。外部ドメインへの DNS 解決とTLSハンドシェイクが、このサイトにおける描画開始の主要ボトルネックのひとつとして機能していたことが数値的に立証されます。「CDN経由のほうが速い」という一般的なイメージとは逆の結果が観測される事例として記録します。

2. 画像が未最適化（JPEG/PNG） — LCPが43%の変化 ​

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

観察された状況 ​

ページ内で使用されていた画像はすべてJPEGおよびPNG形式で配信されていました。特に LCP 対象画像（ビューポート内で最大のコンテンツ要素）は144.8KBのJPEGであり、このダウンロード時間が LCP 値に直接的に寄与しているという状況が観測されました。ページ全体の画像サイズ合計は約2.37MBに達していました。

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

ページ内の全画像45枚を WebP 形式に変換しました。cwebp コマンドによる単純な形式変換であり、視覚的な品質はおおむね維持されています。

cwebp -q 80 input.jpg -o output.webp

シミュレーション結果 ​

LCP 対象画像単体が82%サイズ削減されたことで、LCP が43%変化するという観測結果が得られました。画像形式の変更のみで、HTML構造やレイアウト、画像の見た目を変えずにこの変化量が得られた点は、画像形式が LCP に及ぼす影響のスケールを示すデータとして記録に値します。

3. 非表示要素内の画像が即時ダウンロード — LCPが20%の変化 ​

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

観察された状況 ​

display: none で非表示にされている donation_wrapper 要素内に、決済アイコン画像5枚（visa.png、master.png、amex.png、apple-pay.svg、g-pay.png）が配置されていました。これらの画像は画面に表示されていないにもかかわらず、ブラウザによって即座にダウンロードが開始されており、LCP 画像のダウンロード帯域と競合しているという状況が観測されました。

display: none で非表示の要素内にある画像であっても、loading 属性が未指定の場合、ブラウザはリソースを即時取得します。これは多くのサイトで見逃されやすいボトルネックパターンのひとつです。

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

対象の5枚の img 要素に loading="lazy" 属性を付与しました。HTMLの1属性追加のみの変更です。

<!-- 変更前 -->
<img src="https://i.gzn.jp/img/gsc/payment/visa.png" alt="VISA">

<!-- 変更後 -->
<img src="https://i.gzn.jp/img/gsc/payment/visa.png" alt="VISA" loading="lazy">

シミュレーション結果 ​

loading="lazy" 属性の追加のみで LCP が20%変化するという観測結果が得られました。非表示要素内の画像が LCP 画像のダウンロード帯域を圧迫していたことが、この数値から読み取れます。属性追加という最小の変更で観測された変化量としては大きな部類に入り、loading 属性が表示速度に与える影響の大きさを示す事例として記録します。

まとめ ​

GIGAZINE（gigazine.net）の表示速度ボトルネックの実例研究では、Lighthouse の 総合スコア で86から100、LCP で4.2秒から0.3秒という変化が観測されました。

観測時点ではサードパーティータグが LCP および転送サイズの大部分を占めており、10件のタグ除去だけで 総合スコア が14ポイント変化するという状況が確認されました。その上でサイト本体の実装を順次観察したところ、パブリックCDN経由のリソース配信・未最適化の画像形式・非表示要素内画像の即時ダウンロードという3種類のボトルネックが存在していたことが、解消シミュレーションの数値として立証されました。いずれも実装レベルでの変更は小規模ながら、観測される変化量は無視できない規模であり、サイト本体側のボトルネックパターンの典型例として記録に値します。

本研究の目的はボトルネックの存在とその影響量を可視化することにあり、観測された数値はサイトに実際どのような改変を行うべきかを示すものではありません。研究結果として残すデータが、Web表示速度におけるボトルネックの性質の理解の一助となれば幸いです。