MetricFireのLCPを35%改善した方法と、その効果を計測する方法

Great systems are not just built. They are monitored.

MetricFire runs Graphite and Grafana as a fully managed service for growing engineering teams, taking care of storage, scaling, and version updates so your team doesn't have to. Plans start at $19/month, billed per metric namespace rather than per host, and include engineer-staffed support. Integrations work natively with Heroku, AWS, Azure, and GCP, and data is stored with 3× redundancy in SOC2- and ISO:27001-certified data centres.

はじめに 

WebサイトのSEOでは、コンテンツだけでなくサイトのパフォーマンスも重要な要素です。

GoogleがWebサイトのユーザー体験を評価する際には、Core Web Vitals（コアウェブバイタル）が重要な指標として使われています。その中でも、LCP（Largest Contentful Paint）は、ページの主要なコンテンツが表示されるまでの時間を測定する重要な指標です。

近年、GoogleはWebサイトのパフォーマンスに対する評価基準を継続的に更新しています。開発チームにとって、パフォーマンス最適化は一度対応して終わるものではなく、継続的に測定・改善していくことが重要になっています。

MetricFireでも、こうした変化に対応するため、Webサイト全体のLCP改善に取り組みました。今回の目標は、既存のUIやデザインを大きく変更することなく、レンダリングを妨げるリソースを削減し、重要なコンテンツがより速く読み込まれるようにすることでした。

いくつかの改善を実施した結果、MetricFire.comのLCPは約35%改善しました。さらに、その他の主要なパフォーマンス指標にも改善が見られました。この記事では、実際にどのような変更を行ったのか、どのように効果を測定したのか、そして今回の取り組みから得られた知見について解説します。

1. クリティカルレンダリングパスを最適化

今回、SEOチームから求められていたのは非常にシンプルでした。

GoogleのCore Web Vitals、特にLCPを改善すること。

ただし、単一のバグや障害に対応するのではなく、大規模なコードのリファクタリングを行わずに、今後のパフォーマンス基準にも対応できるようにすることが目的でした。

そこで、考えられるすべての最適化を行うのではなく、主要なコンテンツが表示されるまでの時間に直接影響する部分に絞って改善しました。

ページを調査したところ、LCPには主に以下の2つが影響していることが分かりました。

• レンダリングをブロックするCSS
• ヒーロー画像などの主要アセットの読み込み方法

つまり、ブラウザがメインコンテンツを表示する前に、多くの処理を行っていました。そこで、クリティカルレンダリングパスを可能な限りシンプルにすることにしました。

主な変更内容

• 1. レンダリングをブロックするCSSを削減
  Integrationページでは、実際には必要のないグローバルなhomepage.cssファイルを読み込んでいました。
  このファイルを削除することで、ブラウザがコンテンツを表示する前に処理するCSSの量を削減しました。
  その結果、一部のスタイルが表示されなくなるケースがあったため、必要なスタイルだけを読み込むようにインポートルールも調整しました。
• 2. LCP画像の読み込みを最適化
  LCPの対象となる画像を、ブラウザがより優先的かつ高速に読み込めるようにしました。
  具体的には、<picture>要素を利用し、以下のような変更を行いました。
  • AVIF / WebPなどのモダンな画像形式を使用
  • フォールバック画像を設定
  • 画像のwidthとheightを明示
  • fetchpriority="high"を設定
  • decoding="async"を設定

  これにより、ブラウザがLCP対象の画像をより早く処理できるようにしました。

• 3. LCP対象アセットをプリロード
  LCP画像をできるだけ早い段階で取得できるよう、プリロードも追加しました。
  具体的には、以下のような設定です。
  • <link rel="preload" as="image" fetchpriority="high">

  これにより、ブラウザが重要な画像を早い段階で取得できるようになります。

• 4. 重要ではないアセットの読み込みを遅延
  初期表示に必要のない処理を、ページの初期レンダリングから外しました。
  具体的には、
  • JavaScriptの実行を遅延
  • 重要ではない画像をLazy Load
  • 動画の読み込み方法を調整

  といった対応を行いました。

これらの変更は、それぞれ単独では大規模なものではありません。しかし、ページの主要コンテンツが表示されるタイミングに直接影響する部分に集中して改善したことが、大きな効果につながりました。

2. Hosted GraphiteとSitespeedで改善効果を測定

MetricFireのWebサイトに変更を反映した後、次に行ったのは、「本当にパフォーマンスが改善したのか？」を検証することでした。

単発のテスト結果だけを見るのではなく、継続的にパフォーマンスを測定するため、今回はオープンソースのツールであるSitespeedを使用しました。

構成は非常にシンプルです。

• ローカル環境にDockerをインストール
• Hosted Graphiteのアカウントを用意

Sitespeedは、Webサイトに対して定期的なパフォーマンステストを実行し、その結果を指定したバックエンドへ送信できます。

今回はDockerからSitespeedを実行し、パフォーマンスメトリクスをHosted Graphiteへ直接送信しました。

docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:39.5.0 <FULL-SITE-URL> \
  -n 1 \
  --graphite.host carbon.hostedgraphite.com \
  --graphite.port 2003 \
  --graphite.namespace <HG-API-KEY>.sitespeed_io.default.hg

何を計測したのか？

今回の分析では、Sitespeedから取得したGraphiteメトリクスのうち、ユーザーが実際に体感するWebパフォーマンスに関係する指標に絞って確認しました。

• LCP
  今回の主要な指標です。Largest Contentful Paintを計測し、主要なコンテンツが表示されるまでの時間を確認しました。
  • sitespeed_io.default.hg.pageSummary.<site_url>._.chrome.native.browsertime.statistics.timings.largestContentfulPaint.median
• FCP
  First Contentful Paintを確認し、ページ上に最初のコンテンツが表示されるまでの時間を測定しました。
  • ...timings.firstContentfulPaint.median
• TBT
  Total Blocking Timeを確認し、JavaScriptなどによってメインスレッドがブロックされていないかを確認しました。
  • ...timings.totalBlockingTime.median
• CLS
  Cumulative Layout Shiftを確認し、ページのレイアウトが安定しているかを確認しました。
  • ...pageinfo.cumulativeLayoutShift.median
• Speed Index
  ページのコンテンツが視覚的にどの程度速く表示されるかを確認するために使用しました。
  • ...visualMetrics.SpeedIndex.median

このように、ユーザーが実際に体験するパフォーマンスに焦点を当てて分析しました。

改善前と改善後を比較

メトリクスを継続的に収集することで、単一のテスト結果ではなく、デプロイ前後のパフォーマンスの変化を比較できました。

さらに、Hosted Graphiteのダッシュボードにデプロイ時点を示すアノテーションを追加しました。これにより、「コードを変更したタイミング」と「パフォーマンスが変化したタイミング」を同じグラフ上で確認できます。

デプロイ前後のデータを見ると、改善は明確でした。

• LCP：約2.3〜2.4秒 → デプロイ後に約1.3秒まで低下
• FCP：約2.3秒 → 約1.2〜1.6秒へ改善
• TBT：約60ms → ほぼ0msまで改善
• CLS：ほぼ安定し、レイアウトへの悪影響がないことを確認
• Speed Index：低下し、ページ全体の視覚的な表示速度も改善

特に重要なのは、単に一度だけ数値が改善したのではなく、デプロイ後も低い水準で安定していることです。

変更前はメトリクスの値が高く、変動も大きくなっていました。一方、変更後はより低い水準で安定しています。

これにより、今回の改善が一時的なテスト結果ではなく、クリティカルレンダリングパスの変更による効果であることを確認できました。

3. SitespeedとHosted Graphiteを自分のWebサイトでも試してみる

Webサイトのパフォーマンス改善に取り組んでいるのであれば、最も確実な方法は、改善前後の変化を実際に計測することです。

Sitespeedは無料で利用できるオープンソースのツールで、Webサイトに対して繰り返しパフォーマンステストを実行できます。必要なのは基本的にDockerだけです。

さらにGraphiteのようなメトリクス保存基盤と組み合わせることで、パフォーマンスの変化を長期間にわたって記録し、デプロイ後の推移を可視化できます。

MetricFireでは、Hosted GraphiteとGrafanaを無料で試せる14日間のトライアルを提供しています。クレジットカードの登録も必要ありません。

メトリクスを収集し始めたら、カスタムダッシュボードやアラートを作成し、パフォーマンスの推移を追跡できます。また、デプロイ時点にアノテーションを追加することで、「このコード変更によってパフォーマンスがどう変化したのか」を簡単に確認できます。

Hosted Graphiteには、Sitespeedから収集したメトリクスをすぐに可視化できるワンクリックのオートダッシュボードも用意されています。

パフォーマンス改善の効果を推測するのではなく、LCPなどのメトリクスが実際にどのように変化したのかをリアルタイムで確認できます。

以下のコマンドを実行するだけで、Sitespeedのテスト結果をHosted Graphiteへ送信できます。

docker run --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:39.5.0 <FULL-SITE-URL> \
  -n 1 \
  --graphite.host carbon.hostedgraphite.com \
  --graphite.port 2003 \
  --graphite.namespace <HG-API-KEY>.sitespeed_io.default.hg

まとめ

LCPを改善するために、必ずしもフロントエンド全体を書き直したり、大規模なリファクタリングを行ったりする必要はありません。

今回のMetricFire.comでは、クリティカルレンダリングパスに注目し、いくつかのボトルネックを取り除くことで大きな改善を実現しました。

具体的には、

• レンダリングをブロックするCSSを削減
• LCP画像の読み込みを最適化
• 重要な画像をプリロード
• 重要ではない処理を遅延

といった比較的小さな変更を、パフォーマンスに大きく影響する部分に集中して適用しました。

そして、最適化そのものと同じくらい重要なのが、その効果を継続的に測定することです。

SitespeedとHosted Graphiteを利用することで、コードを変更する前後のパフォーマンスを継続的に比較できました。

一度だけテストを行って「改善したはず」と判断するのではなく、

測定 → 改善 → デプロイ → 再測定

というサイクルを繰り返すことで、Webサイトのパフォーマンスを継続的に改善できます。

Core Web Vitalsなどの評価基準が今後も変化していく中で、このように継続的にパフォーマンスを測定・改善できる仕組みを作ることがますます重要になっています。