本記事は、３つのコンテンツ「Web業界におけるCore Web Vitalsの影響」「Core Web Vitalsの基本」「New Relic におけるCore Web Vitalの活用方法」で Core Web Vitalsの理解を深める構成となっています。

Web業界におけるCore Web Vitalsの影響

2021年５月より、Google 検索へのページ エクスペリエンスの導入が始まります。SEO対策として、この３つの指標が関係してくるということです。これまでと同様、コンテンツの中身が充実している、意味のあるものかどうかというところが高く評価されるのですが、同様のコンテンツだと判断された場合には、Core Web Vitalsの数値が良いサイトが上位に出てくるということです。(Google ウェブマスター向け公式ブログ)

これまでもパフォーマンスアップデートなどシステムに関連する指標が盛り込まれることはあったものの、手をつける範囲が広すぎてSEO対策はマーケティングの仕事だ、と一線を引いていた方々も多いのではないでしょうか。顧客体験を可視化するのに適した定量的な指標ができた今、ウェブエンジニアやUI/UXエンジニアがマーケティング・ビジネスに直結するような対策を打てるアクションが取れるようになってきたと考えています。

今フロントエンジニアが身につけるべきCore Web Vitalsを理解し、効果的に顧客体験の改善が行えるようになりましょう！

Core Web Vitalsの基本

Webサービスの顧客満足度というと、コンテンツそのものの他にサービスの使いやすさがポイントとなります。たとえコンテンツがいいものであっても、なかなか画面がひらけない、操作がしづらい、ということがあると継続的にサービスを利用しようとは思わなくなります。そこで、ユーザーエクスペリエンス（顧客体験）を上げるための対策を行っていると思うのですが、評価をするのは簡単ではありませんでした。これまでにも、ウェブエンジニアやUI/UXエンジニアはどれだけ利用者が満足しているのかをどうにかして理解しようと、First Contentful Pain (FCP) や First Meaningful Paint (FMP) などの指標を考えてきました。しかし、計測値が想定外のものになることや、計測が難しいという課題があり、顧客体験を評価できる指標ではありませんでした。

そこで登場したのが「Core Web Vitals」です。

「Core Web Vitalsは　ユーザーエクスペリエンスの主要な側面を定量化した、ユーザー重視の現実的な指標のセットです。」（Google ウェブマスター向け公式ブログ抜粋)

Core Web Vitalsの指標をクリアすると、「ページ読み込みを諦める割合が２４％も低い」という具体的な調査結果があります。また３つの指標はわかりやすく、どうすれば満足度が高くなるか、次のアクションをこれまでよりも明確に立てることができるのではないかと思います。これもエンジニアにとって非常に嬉しいポイントだと考えています。

それでは、Core Web Vitalsがどういうものなのか具体的に見ていきましょう。

「ユーザー目線での読込時間」「操作に対するの反応性能」「画面の崩れ」を確認する３つの指標があります。

ユーザー目線での読込時間

LCP(Largest Contentful Paint)という指標で計測し、評価します。

Web画面は一般的にテキストと画像などのメディアファイルで構成されており、段階的に読み込まれます。段階的に読み込まれる際、画面内で一番広い範囲を占める要素は読み込むたびに変わってくることがあります。

LCPは画面内で一番広い範囲を占めるコンテンツが描画された時間を取得します。ですので、「画面のほとんどが読み込み終わったタイミング」を取得できることとなり、ユーザーにとっての読み込み時間と同等の時間を計測することができるのです。

対策としては、画像などのコンテンツのデータサイズ（通信量）を削減したり、処理描画に必要なものを取捨選択したり、CDNを活用する、などが挙げられます。

「全体の75パーセンタイルの値が2.5秒」、というのがGoogleから出されている目標値です。

操作に対するの反応性能

FID(First Input Delay)という指標で計測し、評価します。

例えば画面に次のページに遷移するボタンがあるとします。ページにボタンが描画され、押せるようになったにもかかわらず反応がなく、ある程度時間がかかって次のページに遷移した、というようなページがもっさり動くような経験はありませんでしょうか。

この、「ボタンが押せる」ようになってから「ボタンを押したことによる処理が開始される」までの遅延時間がこのFIDです。例えば最近ではリッチなコンテンツが多くなっていたり、「UXをよくしようとSPAを採用する」ということが増えてきたと思いますが、その分Javascriptでの処理も多くなってきています。画面内のコンテンツが大きいということもそうですが、この遅延時間にも気をつけてサービス開発を行いましょう。

対策としては、UIコンポーネントをページごとに最適化したり、必要なタイミングで追加でダウンロードするなど、ページの中でユーザーが作業する最小限の機能に絞ってリソースを読む、などが挙げられます。

「全体の75パーセンタイルの値が0.1秒」、というのがGoogleから出されている目標値です。

画面の崩れ

CLS(Cumulative Layout Shift)という指標で計測し、評価します。

画面の描画は部分的に行われることが多いのですが、自分が操作をしていないにもかかわらず読み込みまでに何度も画像や文字が移動してしまうと、もう見たくないと思うのではないでしょうか。コンテンツの読み込みやJavaScriptの処理によって移動してしまう症状を数値化したものがこのCLSです。

コンテンツの画面内に占める割合と画面サイズの何割くらい移動したかを掛け合わせた値がCLSのスコアとなります。パフォーマンスと同じく、数値が高い方が悪い印象を与えているという評価となります。特にユーザーが操作を行うまでのレイアウトは基本的には変わらないような設計がユーザーに不快感を与えないようなページであると解釈できます。

対策としては、表示する画像はオリジナルのサイズにかかわらず描画サイズを固定する、リストを表示するとなったとしても画面が崩れないようにページングを行う、などが挙げられます。

「全体の75パーセンタイルの値が0.1」、というのがGoogleから出されている目標値です。

New Relic におけるCore Web Vitalsの活用方法

Core Web Vitalsは評価用のサービスにアクセスすれば、今どのようなスコアなのかはわかります。しかし、コンテンツが動的に変わるようなサービスであったり、SaaSでお客様が自由に画面を組み立てられるような仕組みの場合、評価を手作業で行うことは現実的ではありません。

New Relic を使って常にCore Web Vitalsの情報を集め、必要な時にすぐに利用できるようにしましょう。

1, ダッシュボードなどの設定不要、New Relic One [ Browser ] でアプリケーションの全体把握

どのようにすれば値が取れるのかを知らなくても、New Relic One [ Browser ] の画面にはすでに Core Web Vitalsが組み込まれています。どう見ればいいかわからない、そんな時はまず Browserの画面を開きましょう。

2, 指標の悪い値をドリルダウンする

Core Web Vitalsについて、Browserの画面上で怪しい値があった場合、すぐに大きなイメージがないかどうかを探しに行くというよりは、まずどこに焦点を絞らないといけないかを確認することが重要です。特に、「FACET」で見る軸を変えて分析することがポイントです。分析の仕方をご紹介します。

Step 1, 画面上の「・・・」を押してでてくるメニューのView Queryをクリック

Step 2, 右側にオーバーレイされる画面の「Open in query builder」をクリック

Step 3, 例：画面ごとに状況を確認したいので、「FACET pageUrl」を追加し「Run」をクリック

これ以外にも、「特に不満足なユーザー」を洗い出す場合にはカスタム属性でuserIdなどを追加すれば分析できますし、

SaaSやPaaSのようにお客様に利用してもらっている場合はテナント情報としてtenantIdなどを追加すれば、お客様のカスタマイズに依存するような状況の確認などができるようになります。

おまけ：すぐに使えるサンプル集（「New Relic の画面で試す」クリックで利用できます。一部要カスタマイズ)

画面の反応性(FID)がよくないと感じているユーザー(カスタム属性: userId)のランキング。( New Relicの画面で試す)

SELECT count(*) FROM PageViewTiming WHERE firstInputDelay >= 300 FACET userId

画面のロード時間(LCP)の長いテナント(カスタム属性: tenantId)のランキング。( New Relicの画面で試す)

SELECT count(*) FROM PageViewTiming WHERE largestContentfulPaint >= 4 FACET tenantId

CLSが悪いユーザーの割合(New Relicの画面で試す)

SELECT percentage(count(*), WHERE cumulativeLayoutShift >= 0.25) AS 'poor' FROM PageViewTiming

国（country code）×ページでのCLSが悪いユーザーの割合( New Relicの画面で試す)

SELECT percentage(count(*), WHERE cumulativeLayoutShift >= 0.25) AS 'poor' FROM PageViewTiming FACET pageUrl, countryCode

3, 顧客満足度の低いページをランキング化して洗い出す

Core Web Vitalsを利用し、サービス全体の中でどのページを改善しないといけないかをランキング化しましょう。

各指標ごとに、Good：１点　Needs Improvement：２点　Poor：３点としてポイント付けし集計した、評価の悪いランキングTop50（Good ３点〜９点 Poor）を確認できます。 (New Relicの画面で試す)

FROM(SELECT ceil(clamp_max(clamp_min(percentile(largestContentfulPaint, 75) / 0.75 - 2.3334, 1),3)) as 'LCP', ceil(clamp_max(clamp_min(percentile(firstInputDelay, 75) / 100, 1),3)) as 'FID', ceil(clamp_max(clamp_min(percentile(cumulativeLayoutShift, 75) / 0.075 - 0.33334, 1),3)) as 'CLS', filter(count(*), where eventType()='PageView') as 'PV', filter(average(duration), where eventType()='PageView') as 'Time' FROM PageViewTiming, PageView facet pageUrl limit max) SELECT max(LCP) + max(FID) + max(CLS) as 'Total', max(LCP) as 'LCP', max(FID) as 'FID', max(CLS) as 'CLS', max(PV) as 'PV', max(Time) as 'Time(sec)' WHERE LCP > 1 or FID > 1 or CLS > 1 FACET pageUrl limit 50

さらなる活用のために

よりCore Web Vitalsについて理解を深めたり、どうすれば今抱えている課題が分析できるかについて疑問点がありましたら担当の営業やSC（テクニカルメンバー）にご質問ください。課題の解決・サービスの発展を皆様とともにチャレンジしていきます。