はじめに

「# New Relic 使ってみた情報をシェアしよう！ by New Relic Advent Calendar 2024」の24日目に寄稿させていただく記事となります。

自己紹介

私は現在、株式会社フューチャーショップにて、SaaS型ECサイト構築プラットフォームfutureshopのフロントエンド開発に従事しており、NewRelicを活用したオブザーバビリティの推進にも携わっています。
僅かな期間ではありますが、手探りでNewRelicに触れ、多岐にわたるその機能のあくまで一部についてですが理解を深めてきました。

具体的には、NewRelicエージェントの導入、NRQL（New Relic Query Language）の理解、ダッシュボード作成方法の把握、Custom Attributeを使用したカスタムデータの取得などの機能に触れてきました。

上記の理解が進むにつれて、データの可視化や分析のために活用できる機能の理解が進んでいることを実感しています。
しかし、実際の業務やビジネスシーンにおいて、「どのようなデータを選定し」「どのように可視化し」「その結果をどのように解釈し」「意思決定にどのように結びつけるか」という、実践的な課題に直面し、一層の難しさを感じています。

単に機能の理解を深めるだけではなく、実務において有効性を最大化するための活用方法を明確にすることが課題だと実感しています。

概要

今回の記事では、基本的な指標を用いて、可視化・分析・仮説立案・意思決定の一連のフローを確認することで、データの選定、可視化の手法、そしてその結果を意思決定に結びつけるまでの流れについて考えてみたいと思います。
具体的には、Core Web Vitalsの中でも特にLCP（Largest Contentful Paint）に注目し、基本的なグラフを作成して可視化と分析を行い、その結果をどのように解釈し、どのような判断を下すべきかを探ります。

データの選定

まず、データの選定について考えます。
Core Web Vitalsを選ぶ理由について説明する前に、以下のような言説に耳を傾けたことがある方も多いのではないでしょうか。

サイトスピードの100ミリ秒の改善ごとに、増分収益が最大1%増加する。

この言説はAmazonやWalmartによる15年以上前の調査結果に基づくものと思われます。¹²
しかし、当時と現在では、モバイルデバイスの普及やインターネット接続環境の向上、ユーザーの期待値の変化など、Webの環境が大きく異なります。そのため、この言説が現在も有効であるとは限らないでしょう。

本記事では、『100ミリ秒の改善で収益1%増加』という言説の有効性を再評価することは目的ではありません。ただし、過去のデータや調査に頼りすぎることが、現在の状況に即していない意思決定を招く可能性があることは指摘したいと思います。

つまり、インターネット黎明期に注目された『100ミリ秒の改善で収益1%増加』という言説は現在でも語り継がれていますが、その裏付けとなるエビデンスは十分でない可能性があります。そこで、信頼性の高いデータ指標としてGoogleが策定したCore Web Vitalsを選定し、現代のパフォーマンス評価に焦点を当てます。

過去の調査結果に過度に依存するリスクを避けるためには、指標そのものの信頼性を評価する姿勢が求められます。本記事では、ウェブ体験に対する業界標準として広く受け入れられているCore Web Vitals³を採用し、特にユーザー体感速度に直結するLargest Contentful Paint（LCP）⁴を分析対象としました。

Core Web Vitalsとは

Googleの取り組みであるWeb Vitalsは、ウェブ上で優れたユーザーエクスペリエンスを実現するための品質基準を統一することを目的として策定されています。
その中核を担うのがCore Web Vitalsで、ユーザーエクスペリエンスの重要な3つの側面に焦点を当てています。

次のとおりです。

読み込み（Loading）
ページがどれだけ速く主要なコンテンツを表示するかを示し、特にLargest Contentful Paint（LCP）が指標として使用されます。LCPは、視覚的に大きな要素が描画されるまでの時間を測定し、ページの速度感を評価します。
インタラクティビティ（Interactivity）
ページがユーザーの入力（クリックやタップ）に対してどれだけ迅速に反応するかを示す指標がFirst Input Delay（FID）です。FIDは、最初のユーザー操作からブラウザが応答するまでの時間を測定し、ページがどれだけ「使いやすい」かを表します。
視覚的安定性（Visual Stability）
Cumulative Layout Shift（CLS）という指標を使用し、ページ内の要素が突然動いたり、ずれたりしないかを測定します。CLSが高いと、ユーザーが誤ってリンクやボタンをクリックする可能性が高くなり、UXが悪化します。

Core Web Vitalsについて簡単な確認ができたところで、次は、Core Web Vitalsの中で、読み込みパフォーマンスを測定する指標、Largest Contentful Paint（LCP）についてみていきます。

Largest Contentful Paint（LCP）

Largest Contentful Paint（LCP）は、Core Web Vitalsの中でも読み込みパフォーマンスを測定するための重要な指標です。
LCPの特徴は、単にページ全体の読み込み時間ではなく、ユーザーが体感するperceived load speed、つまり「ユーザーに知覚される読み込みスピード」に焦点を当てている点にあります。
具体的には、ユーザーが最初に視認できる範囲内で最大のコンテンツ要素（例：画像やブロックレベルのテキスト）が表示されるまでの時間を測定し、実際のUXに近い読み込み速度を評価します。

過去には、ページの上部（ファーストビュー）の半分がどれだけ早く表示されるかを測るAbove The Fold Time（AFT）が用いられていましたが、デバイスの多様化や動的コンテンツの増加に伴い、LCPの様な、よりユーザー体験に直結する指標が必要とされるようになりました。⁵

LCPに影響を与える要素については、分析対象のアプリケーションのアーキテクチャや、文脈の違いによって様々に推測ができます。
例えば、シングルページアプリケーションでは、初期のJavaScript実行がブロック要因になる可能性が高いかもしれません。一方、マルチページアプリケーションでは、サーバーレスポンスの遅延をより考慮に入れる必要があるでしょう。
また、画像やフォントの最適化不足が原因の可能性も考慮から外せないケースが多いでしょう。

地理的に広範囲で展開するサービスであったなら、CDNのチューニングが効果的な施作となるかもしれません。

LCPを活用したパフォーマンス改善のシナリオは多岐にわたり、正しい指標の理解と、適切な仮説に基づいたアプローチが必要です。
（LCPのより詳細な仕様については、ドキュメント⁴を参照ください。）

今回取り扱う指標についての確認が済んだところで、具体的なシナリオに基づいた、LCPを使ったグラフの作成とその解釈を通して、可視化・分析・仮説立案・意思決定のフローをいくつかのパターンで確認したいと思います。

シナリオに基づく可視化・分析・意思決定

まずはシンプルにLCPを取得するNRQLとグラフです。

ドキュメントに従い、

モバイルデバイスかデスクトップデバイスを条件に指定（本記事のNRQLはデスクトップデバイスを指定）
読み込みの75 パーセンタイルを測定
の２点を押さえています。

また、2.5秒以内をGood、4.0秒以内をNeed Improvement（Warning）、それ以上をPoor（Critical）とするThresholds（閾値）も設定している想定です。

LCPを取得するNRQL

FROM PageViewTiming
SELECT 
    percentile(largestContentfulPaint, 75) AS 'Largest Contentful Paint'
WHERE deviceType = 'Desktop'
SINCE 24 hours ago

チャートのタイプはBillboardとします。
可視化される内容としては、一例として下記のようになるでしょう。

では、具体的なシナリオに基づく、LCPによる推測と、分析、仮説、意思決定のフローのパターンをいくつか考えてみます。

シナリオ1. 商品詳細ページのリニューアル後の効果測定

シナリオ:
商品詳細ページのデザインをリニューアルした後のUXへの影響をLCPを用いて測る。

可視化:

商品詳細ページのLCP値のビルボードチャートを作成
比較対象: リニューアル前後の75パーセンタイルのLCP値を「COMPARE WITH」を使用して比較

商品詳細ページのLCPを比較するNRQL

FROM PageViewTiming 
SELECT 
    percentile(largestContentfulPaint, 75) AS 'Largest Contentful Paint'
WHERE 
    deviceType = 'Desktop'
    AND pageUrl LIKE '%/products-detail/%'
SINCE 24 hours AGO
COMPARE WITH 1 week AGO

イメージ画像

分析:

新しいLCP値が古いLCP値と比較して向上しているかを確認
パフォーマンスが改善している場合は、具体的な改善要因を特定する（例: 新しい画像フォーマットの導入、CSS最適化など）
悪化している場合は、影響の大きい要因の発見を優先的に調査する・（例: JSの過剰な読み込み、レンダリングブロック要因の検証）

仮説:

改善の仮説: デザイン変更によるUXの改善により、LCPが改善すると想定
悪化の仮説:
- 画像最適化が不十分
- JSの非同期読み込みの不足
- サーバーレスポンスの遅延などが影響していると考えられる

意思決定（例）:

改善が確認された場合:
- 新しいデザインを維持し、他のページでも同様の最適化を適用する。
悪化が確認された場合:
- 特定されたボトルネックに対して次のアクションを実施:
  - 画像フォーマットの見直し
  - リソースの優先順位変更
  - サーバー応答時間の改善などを検討

シナリオ2: トラフィック急増時のLCP監視

シナリオ: 特定の時間帯にトラフィックが急増した際にLCPがどのように変化したかを追跡する。

可視化:

1. トラフィック量を基にしたアラート設定を有効化する
1. ダッシュボードでアラート発生時刻と終了時刻をNRQLで取得
1. 取得した時刻を条件に含めLCPを取得するNRQLでグラフを作成

1.トラフィック量を基にしたアラート設定を有効化

ページへのアクセス数を取得するNRQL

SELECT count(*) FROM PageView

アラート条件の詳細についてはドキュメントへのリンクのみで割愛します⁶。

policy名
条件
- クエリ
- Window Durationの設定
- 警告のレベル（Warning,Clitical）
- 閾値（分間のアクセス数の上限など）
  などを設定します。

ダッシュボードでアラート発生時刻と終了時刻をNRQLで取得

2.アラート発生時刻と終了時刻を取得するNRQL

FROM NrAiIncident 
SELECT 
	conditionName AS '条件名',
	openTime AS '開始時刻', 
	closeTime AS '終了時刻'
WHERE 
    policyName = 'YOUR_POLICY_NAME'
    AND event = 'close'
SINCE 1 day ago

上記NRQLで取得した情報をテーブル形式で表示させます。
先ほど作成した、policy名と、アラートがクローズしていることを条件に設定しています。
注意点として、ウェジットの設定で「開始時刻」と「終了時刻」のフォーマットをISO with timezoneとするのがいいです。

イメージ画像

3. 取得した時刻を条件に含めLCPを取得するNRQLでグラフを作成

3.取得した時刻を条件に含めLCPを取得するNRQL

FROM PageViewTiming 
SELECT 
    percentile(largestContentfulPaint, 75) AS 'Largest Contentful Paint'
WHERE deviceType = 'Desktop'
SINCE '2024-12-21T07:52:00.000+0900'
UNTIL '2024-12-21T08:03:00.000+0900'
COMPARE WITH 1 day ago
TIMESERIES 10 seconds

イメージ画像

前述の、2.のNRQLで取得した、アクセス急増の開始時刻・終了時刻を条件に含めたNRQLで可視化を行います。この例では、時系列で、通常時（一例として、1日前の同時刻）との比較を行っています。TIMESERIESの範囲は、短めに設定することで変化を捉えやすくなります。
条件の開始時刻を-1h、終了時刻を+1hとするなどで、アラート前後での変化の具合を観測することもできそうです。

3.のグラフの作成時に、手動で時刻の条件を入力するのは煩雑に感じますが、シームレスな作成方法を現時点では見つけられていません。ダッシュボードに変数を追加する方法もありますが、本記事の主題と離れますので、そちらについては別途ドキュメントへのリンクを掲載するのみとします⁷。
また、New Relic NerdGraph APIの使用によるスクリプト制御でのダッシュボードの更新も可能かもしれませんが、未検証です。この箇所について、何か知見をお持ちの方がいれば、情報をいただけると喜びます。

分析:

LCPが通常時と比較して急激に悪化した場合、以下の観点を確認する
- サーバー負荷（レスポンス時間の増加、エラーレート）
- リソースのロード時間（画像、CSS、JavaScriptの読み込み）
- トラフィック急増に伴うCDN遅延の有無

仮説:

サーバー側の問題仮説:
- 負荷分散の不備によるサーバー応答の遅延
- サーバーのスケーリングが適切でない
- バックエンドサービスの処理遅延
クライアント側の問題仮説:
- 初回ロードに必要なリソースの最適化不足
- JavaScriptの同期処理が多いためレンダリングが遅延している
- 大きなメディアファイルの遅延読み込みが設定されていない

意思決定（例）:

パフォーマンス悪化が確認された場合
- インフラ対策:
  - 負荷分散設定の見直し
  - サーバーオートスケーリングの再構成
  - バックエンド処理のパフォーマンス最適化
- フロントエンド対策:
  - リソースの最適化（画像圧縮、CSS/JavaScriptの縮小化）
  - JavaScriptの非同期ロード設定
  - CDN設定の最適化とエッジサーバーの増設
- 監視とアラート強化:
  - トラフィック増加時のリクエスト数、応答時間、エラー率に基づくリアルタイムアラートの設定

シナリオ3: 地域別のLCP分析

シナリオ: 特定の地域において、LCP(Largest Contentful Paint）のパフォーマンスに違いがあるかを分析し、問題の原因を特定する。

可視化:

地域ごとのLCPの75パーセンタイルを棒グラフで表示
地域を識別するため、countryCode または region 属性を使用

FROM PageViewTiming 
SELECT percentile(largestContentfulPaint, 75) AS 'Largest Contentful Paint'
WHERE deviceType = 'Desktop'
FACET countryCode
SINCE 1 day ago
LIMIT MAX

イメージ画像

分析:

各地域のLCPデータを比較し、パフォーマンスが悪い地域を特定する
パフォーマンスが悪い地域について次のような観点から分析する:
- リソース配信ネットワーク（CDN）の最適化の必要性
- サーバーの地理的な距離の影響によるレスポンスの遅延
- 地域固有のインターネット接続環境の問題

仮説:

特定の地域でLCPが悪化する可能性のある要因:
- インフラ要因: サーバーの地理的な配置が遠いため応答遅延の発生
- ネットワーク設定の問題: CDNのエッジサーバー構成の最適化不足
- 外部依存要因: ISPのネットワーク品質が低い、または遅延の多い経路を使用している

意思決定（例）:

パフォーマンスが良好な場合:
- 現行のCDN構成を維持
- エッジサーバーの分散状況の確認を続行
パフォーマンスが悪化した場合:
- 問題地域における対策検討:
  - エッジサーバーの増設やCDN設定の再構成
  - サーバー応答の遅延を減らすためのリソースキャッシュ設定の最適化
  - 地域ごとのISPの品質監視を実施し、代替設備の導入評価を進める

まとめ

LCP（Largest Contentful Paint）という基本的な指標でさえ、その活用方法や解釈は文脈によって異なることがわかります。

例えばLCPの変動が、サイトデザインやリソースの最適化に関連しているのか、またはユーザーのアクセス環境やトラフィック量に起因しているのか、シナリオごとに仮説を立て、異なるそれぞれの文脈に適した観点から分析を行うことが重要だと実感しました。

少し発展的な要素を加えるなら、LCPとコンバージョン率を関連付けることで、LCPの変動がユーザー行動やコンバージョン率に与える影響を定量的に観測することが可能かもしれません。

さらに、NewRelicのCustomAttributes機能を活用し、売上データの増減をNewRelicで監視することができれば、それとLCPを組み合わせ、LCPが収益に与える影響をより直接的に数値化することも可能かもしれません。

サイトパフォーマンスとビジネス成果との関連性を明確にし、パフォーマンス向上が収益向上にどのように貢献するのかを視覚化することがNewRelicによって実現できるでしょう。

基礎的な指標への理解を深めることで、より発展的な考察に説得力が増し、そこから得られた知見は、過去の調査結果に過度に依存しない、より確からしい仮説となり、成果を生む意思決定の礎となるのではないでしょうか。

感想

NewRelicを活用したオブザーバビリティの実現を通じて、開発者の視座を越え、ビジネス全体を見渡す広い視点が得られることを実感しています。フロントエンドのパフォーマンス改善が、最終的にビジネス成果にどのような影響を与えるのかを定量的に把握できるような活用法を考えることが特に重要だと感じています。

記事全体を通じて、Core Web Vitalsの指標に基づくパフォーマンス分析手法を考察しました。LCPという基本的な指標に焦点を当てましたが、その活用は単なる技術的な改善にとどまらず、ビジネスの意思決定に直結する可能性を感じています。

今後もNewRelicを用いたデータ主導のアプローチについて考え、実践し、実践的なビジネスの成果への貢献を目指していきたいと思います。

参考文献

The Cost of Latency | Digital Realty
（Amazonが公開したと言われる統計情報について、原本となる内容は見つかりませんでした。しかし、2015年に公開の記事「The Cost of Latency」で、「7年前のAmazonが公表した統計」として言及されていました。検索すると、他にも上記の調査に言及し引用する記事は複数見られますが、いずれも同じような結果となっており、15年以上前の調査に基づく言説であると判断しております。） ↩
How Website Speed Affects Conversion Rates | GlobalDots ↩
Web Vitals | Articles | web.dev ↩
Largest Contentful Paint（LCP） | Articles | web.dev ↩ ↩²
What is Above The Fold Time and What to Do With It | GlobalDots ↩
Create your first alert | New Relic Documentation ↩
Template variables: dynamically filter dashboards | New Relic Documentation ↩