「ライフハッカー日本版」トップページの表示速度ボトルネック研究

ライフハッカー日本版は、仕事術・ガジェット・ライフスタイルなど「Do everything better. 全部うまくやる」ための実践的なアイディアとヒントを発信する総合情報メディアです。Next.jsで構築されたSSR型のサイトで、本記事ではモバイル環境でのトップページ表示速度に関するボトルネック研究の観測結果を記録します。

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

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

本サイトは観測時点で 総合スコア 92と高い水準にありますが、LCP（Largest Contentful Paint = ページの主要コンテンツが表示されるまでの時間）は2.0秒、CLS（Cumulative Layout Shift = レイアウトのずれ）は0.159という値が観測されました。CLS は「Good」の基準（0.1以下）を超えており、ここにボトルネックが存在していることが読み取れます。本研究ではこれらのボトルネックを解消した場合の影響を計測することを目的としており、各種シミュレーションの結果として 総合スコア が99、LCP が0.6秒まで変化するという観測が得られました。

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

観測時点と解消シミュレーション後のページ読み込みを動画で比較できます。左が観測時点、右が解消シミュレーション後です。全体的にワンテンポ早く表示されるようになった様子が確認できます。

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

詳細レポート

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

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

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

ライフハッカー日本版で確認されたサードパーティータグは42件で、それらが参照するドメインを含めて合計217件のリソースがページ読み込み時に取得されていました。主なものは以下の通りです。

すべてのサードパーティータグを除去した場合の変化は以下の通りです。

サードパーティータグ全体として LCP で-0.5秒、リソース数で-217件という大きな変化が観測されました。ページを構成するリソースの大部分がサードパーティータグ由来であったことが、この数値から読み取れます。

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

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

1. Next.jsハイドレーションスクリプトによるレイアウトシフト — CLSが50%、総合スコアが+6の変化 ​

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

観察された状況 ​

トップページにはNext.jsが生成した16個のdeferredスクリプト（polyfills、webpack、framework、main、pages/_app などのチャンクファイル）が読み込まれていました。これらのスクリプトはページ読み込み時にハイドレーション（クライアントサイドでのDOM再構築）を実行しますが、その過程で記事一覧アイテムが97px上方にシフトするレイアウトシフトが2回発生し、CLS が0.159という値を引き起こしている状況が観測されました。

本サイトはNext.jsのSSRにより完全なHTMLが生成されており、初期表示に必要な情報はすべてHTMLに含まれています。つまり、初期描画という観点においてはハイドレーションスクリプトの読み込みと実行がボトルネックとして機能している状態でした。

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

index.htmlから16個のNext.js deferredスクリプト要素を削除しました。

<!-- 削除したスクリプト要素（例） -->
<script src="/_next/static/chunks/polyfills-xxx.js" defer></script>
<script src="/_next/static/chunks/webpack-xxx.js" defer></script>
<script src="/_next/static/chunks/framework-xxx.js" defer></script>
<script src="/_next/static/chunks/main-xxx.js" defer></script>
<script src="/_next/static/chunks/pages/_app-xxx.js" defer></script>
<!-- 他11個のチャンクファイル、ビルドマニフェスト -->

なお、実サイトにおいてハイドレーションを完全に外すとクライアントサイドのインタラクティブ機能（ルーティング、状態管理等）が動作しなくなります。本研究は「このスクリプト群がどの程度ボトルネックとして機能しているか」を観測するためのシミュレーションであり、実装上の対応策を示すものではありません。

シミュレーション結果 ​

ハイドレーションスクリプトの除去により、CLS が半減し、総合スコア が93から99へ+6ポイント変化するという観測結果が得られました。ハイドレーション時のDOM再構築がレイアウトシフトを引き起こしていたこと、さらにスクリプト読み込みによるリソース競合が LCP にも影響していたことが、この数値から立証されます。本研究で扱った全ボトルネックの中で、総合スコアに対する変化量が最大のボトルネックです。

2. Google Fontsによる欧文Webフォント読み込み — LCPが50%の変化 ​

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

観察された状況 ​

サイトでは Google Fonts から2つの欧文Webフォント（Overpass 39KB、Share Tech 167KB、合計206KB）を読み込んでいました。fonts.gstatic.com への接続にはDNSルックアップとTLSハンドシェイクが必要であり、フォントファイルのダウンロードを含めてページ描画を遅延させている状況が観測されました。

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

Google Fontsへのpreconnect、@font-face 定義、CSS の font-family から Overpass と Share Tech の参照を削除し、システムフォントスタックにフォールバックさせました。

<!-- 削除: Google Fontsへのpreconnect -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<!-- 削除: @font-face定義 -->
<style>
  @font-face {
    font-family: 'Overpass';
    src: url(https://fonts.gstatic.com/s/overpass/...) format('woff2');
  }
  @font-face {
    font-family: 'Share Tech';
    src: url(https://fonts.gstatic.com/s/sharetech/...) format('woff');
  }
</style>

シミュレーション結果 ​

206KBのフォントファイル読み込みと fonts.gstatic.com への接続がなくなることで、LCP が50%変化するという観測結果が得られました。欧文のWebフォント2書体の読み込みだけで LCP に0.6秒規模の影響が生じていたことが、この数値から立証されます。日本語Webフォントではデータ量が桁違いに大きくなるため、より大きな影響が生じることも予想されます。

3. 別ドメインから配信されていた CSS — FCPが71%の変化 ​

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

観察された状況 ​

ページのレンダリングブロック CSS である full.css が、本体ドメイン www.lifehacker.jp とは別の araklet.mediagene.co.jp から配信されていました。別ドメインからの取得には追加のDNSルックアップとTLS接続が必要となり、このリソースの TTFB（Time to First Byte = サーバーからの最初のバイトが返ってくるまでの時間）に469msを要している状況が観測されました。

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

CSS の配信元を本体ドメインと同じ www.lifehacker.jp に変更しました。preconnectタグも不要となるため削除しています。

<!-- 変更前 -->
<link rel="preconnect" href="https://araklet.mediagene.co.jp" crossorigin>
<link rel="stylesheet" href="https://araklet.mediagene.co.jp/full.css">

<!-- 変更後 -->
<link rel="stylesheet" href="https://www.lifehacker.jp/css/araklet-full.css">

シミュレーション結果 ​

配信元ドメインを変更しただけで、FCP が71%変化するという観測結果が得られました。同一ドメインからの取得では TTFB が20ms程度で済むのに対し、別ドメインでは469msを要していたことからも、レンダリングブロックリソースの配信元ドメインが FCP に与える影響の大きさが読み取れます。

まとめ ​

ライフハッカー日本版（lifehacker.jp）トップページの表示速度ボトルネックの実例研究では、Lighthouse スコアで92から99、LCP で2.0秒から0.6秒、FCP で0.4秒から0.1秒、CLS で0.159から0.079という変化が観測されました。

観測時点で既に 総合スコア 92と高い水準にあったサイトにおいても、Next.jsハイドレーションスクリプトによるレイアウトシフト・Google Fontsによる欧文Webフォントの読み込み・別ドメインから配信されていた CSS という3種類のボトルネックが存在していたことが、解消シミュレーションの数値として立証されました。特にNext.jsハイドレーションスクリプトは CLS に対するボトルネックであると同時に、LCP と 総合スコア にも大きな影響を及ぼしていたことが、複数の指標の変化から読み取れます。

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