CLSの10倍改善でAmebaマンガの読者数が3倍増加　Webパフォーマンスの歴史とCore Web Vitalsの見直し

Webパフォーマンスにおける指標の歴史

原一成氏：サイバーエージェントの原と言います。今日は「Core Web Vitals in Practice」というタイトルで、Core Web Vitalsの実践的なお話をしたいと思います。

さっそくですがクイズです。以下の選択肢の中で、Core Web Vitalsに含まれないものはどれでしょうか。1.FID、2.PWA、3.LCP、4.CLS。簡単ですかね。ちょっと思い浮かべてもらって、さっそく解答です。ジャジャン。正解は2.PWAです。それ以外のFID、LCP、CLSがCore Web Vitalsの指標です。

今日はPWA Night CONFERENCEへようこそということで、このセッションでは直接PWAの話ではありませんが、Webアプリケーションの品質に関わる話をしたいと思います。

以前、サイバーエージェント社内で似たようなクイズを出した時には、なんと正答率が100パーセントで、この覚えやすさがCore Web Vitalsの特徴かなと考えています。

Core Web Vitalsの指標を考える上で、Webパフォーマンスにおける指標の歴史を振り返るのがとても役に立ちます。大きく分けてローディングに関する指標と、ランタイムでの動作に関する指標があります。

Time To First Byte（TTFB）やDOMContentLoaded、Start Renderといったページ初期化のタイミングや、First Contentful Paint、First Meaningful Paint、Largest Contentful Paint、Speed Index、Visually Completeといったビジュアル的なもの。そして、ページの表示に関連するリソースの読み込みが完了したページ、といったものがあります。

ランタイムでのパフォーマンスとしては、レイアウトの安定性を見るCumulative Layout Shift、操作の反応性を示すFirst Input Delay、Total Blocking Timeなどがあります。

特に、表示速度を測る指標は改善が重ねられています。昔は、DOMContentLoadedやPage Loadという指標が用いられていました。DOMContentLoadedはhtmlと読み込みとパースが完了したタイミング。Page Loadはhtmlとそれに依存するリソースの読み込みが完了したタイミングです。

かつてのWebページは読み込まれるリソースが少なかったり、非同期で実行したり、レンダリングされる要素も少なかったので、htmlとそれに関連するリソースのタイミングが重要でした。

ただ、Webページに表示される要素も増え、実際の画面上にどう表示されているのかが重要になってきました。

そこで提案されたのが、Speed Indexという指標です。ビジュアルの完了までをインターバルで区切り、それぞれのタイミングで表示されていない割合を足し合わせて、値が少ないほどよいという指標です。

多くのツールでは便宜上、秒で表していますが、その時間に何か起こったかは意味がないので注意してください。（スライドを指して）例えばこの図でいえば、Aのほうが速めにいくつかの要素が表示されているので、Speed Indexが低いということになります。

非常に有用ですが、今の説明を聞いても「ちょっとわかりにくい」という方もいると思います。わかりにくいことと、時間に意味がないために他の指標と比べられないなど、いろいろな問題がありました。

そこで登場したのが、First Contentful PaintやFirst Meaningful Paintです。しかし、「また仕様が追加されるの？　何やら多すぎて覚えられない」と感じることはよくあると思います。

それを改善するために、Core Web Vitalsが出てきたのだと思います。Core Web Vitalsでは、数ある指標の中から重要と思われるものに絞られています。ローディング、応答性、表示の安定性から、それぞれLCP、FID、CLSが選ばれています。

重要な特徴は、これらのデータは実デバイス、Chrome上で計測されている点と、データの全体のうち75パーセンタイルが閾値を下回ると“良好”とラベリングされる点です。つまり、それぞれの値は完璧にする必要がないという点で現実的です。

これらの指標は、Google検索結果のランキング要素になっています。また、アップデートが随時行われると発表されています。冒頭のクイズでも挙げたように、多くの方が思い浮かぶので、覚えやすさという点で成功しているのではないかと思います。

Core Web Vitalsの改善は効果があるのか？

「Core Web Vitalsの改善は実際に効果があるの？」について、Amebaマンガではこんな事例がありました。CLSを10倍改善したところ、セッションにおける読書数が約3倍に増えました。

（スライドを指して）ご覧のとおり、スクロールからページ遷移のレイアウトが安定しています。サイト内の行き来が多い、Amebaマンガというサイトの特性にマッチしたのではないかと考えています。

詳細はサイバーエージェントの開発ブログにも書かれているので、ぜひ見てください。

その他に、Google I/Oでの発表でも、Core Web Vitalsがフォーカスされています。パフォーマンスを改善したことでビジネス上にもよい影響が出ているという、いわば当たり前と言えるようなことが発表されていました。

Core Web Vitalsの計測や改善にどのツールを使えばいいのか？

実際にCore Web Vitalsの計測や改善を始めようとした時、最初に思い浮かぶのは「どのツールを使ったらよいのか」だと思います。

（スライドを指して）こちらはWeb.devに掲載されている、Google社が提供しているツールの一覧ですが、けっこう種類があって。「どれから使ったらよいのだろう」というのがわからないことがあります。

ツールを利用する上で、それがLab環境なのか、Fields環境なのかを理解していくことが重要です。Lab環境は管理された環境で、デバイスやネットワークなどを指定した状態でパフォーマンスを計測します。

Webページのパフォーマンスに影響する要素をいくつか固定できるので、定期的に品質チェックしたり、原因調査したり、リグレッションの検知などに向いています。よくあるツールでは、Lighthouse、WebPageTest、Chrome DevToolsなどが該当します。

対してFields環境は、実際のデバイスでパフォーマンスを計測して、他のデータを収集します。実際に利用者が感じた、真のサイトパフォーマンスに近いものと言えるでしょう。

Core Web Vitalsでは、Chromeで取得されたChrome User Experience Report（CrUX）を利用しています。気づいている方もいると思いますが、Core Web VitalsではChromeでのデータのみが対象なので、注意してください。

それぞれシンセティックやリアルユーザーモニタリングなどと呼ぶこともありますが、本セッションではCore Web Vitalsの文脈で使われる、Lab、Fieldという名前に統一します。

（スライドを指して）このヒストグラムは、Lab Dataを表したものですが、場所、デバイス、時間、ネットワークデバイスの設定などにばらつきがあることがわかります。CrUXでは良好な値を緑色、改善が必要な値を黄色、低速の値を赤色で表示しています。

対してLighthouseに代表されるラボツールは、特定の1箇所のみを計測しています。ちなみに日本で考えた場合、Lighthouseのモバイルデフォルトセッティングはけっこう悪い環境での計測になるので、ふだん遅いと感じないページでも、比較的低い点になることがあるのではないかと感じています。

Lighthouseの使い方について、1点注意したいことがあります。Lighthouseのスコアは、あらかじめ固定した環境で特定の1ページを計測したものにすぎません。そのため、このばらつきを表現できず、サイトの全体の品質そのものを保証しないことがよくあります。ただし、固定された環境でスコアリングを活かして計測したり、変化を見ることには有効です。

計測・改善の流れ

「数あるツールの中でどれを使ったらいいの？」という中で、個人的にはサイトのパフォーマンスの大枠をつかんでから、詳細に進んでいくことをおすすめします。

長期間での概況を見られるChrome User Experienceレポートや、PageSpeed Insightからはじめて、Search Consoleで直近の改善できるURLを探して、WebPageTestやChrome DevToolsで原因や改善点を探ります。それぞれ軽く見ていきましょう。

Core Web Vitalsの値を大枠で見るには、CrUX Dashboardが便利です。CrUXのデータをData Studioで見られるように配置されているテンプレートで、長期間の傾向を見るのに便利です。（スライドを指して）例えばこのサイトの場合では、2021年に入ってCLSの値の緑が大きくなっていて、改善されていることが見て取れます。

デバイスや月ごとに絞ることもできます。

CrUX Dashboardで大枠を把握した後に、直近の具体的なデータを見にいきます。その時にはPageSpeed Insightsが便利で、直近28日のCrUXデータが見られます。ただ、このページにはLab DataとField Dataが混在しているので、注意が必要です。特定のURLを指定すると、Lab DataとしてLighthouseで計測された結果が表示されます。

これも非常に重要だと思いますが、「Origin Summaryを表示する」というチェックボックスをオンにすると、特定の1ページだけではなく、サイト全体の直近28日のField Dataを表示してくれます。このデータから、サイト全体では指定したページよりも、実際のパフォーマンスがよいことが見て取れると思います。

また、PageSpeed Insightsには、LighthouseのデータからWeb Vitalsの指標に応じた改善点を表示してくれる機能もあります。

特定のページとサイト全体のデータを見た後には、改善の重要度、どのページが重要なのかを見ていきます。トップページは計測しているけれど、実際にアクセスの多い詳細ページや商品ページみたいなところは計測していないパターンもあり得ます。そういう時には、Search Consoleが便利です。

Search Consoleでは、Core Web Vitalsのサマリーのほか、URLをグルーピングしてリストアップしてくれます。これは実際にSearchのクローラのデータと連動していたりすると思われるので、実際のアクセスや、重要なページを見つけるのに役に立ちます。

改善すべきURLがわかった後は、ラボ環境で検証していきます。WebPageTestでは、計測するとCore Web Vitalsの値を表示してくれます。WebPageTestはWebサービスなので、ブラウザーさえあれば簡単に結果を取得できて、その結果をチームに共有することにも役立ちます。

特にレイアウトシフトの表示はおもしろくて、カーソルを合わせると、どこがレイアウトしたのかを表示してくれます。

Chrome DevToolsでも、同様にCore Web Vitalsの値をパフォーマンスタブで表示してくれます。ブラウザー上で計測できるため、開発環境やファイルを実際に上書きしてみて、その場で変化を見られます。

さて、ここまでちょっと駆け足気味でCore Web Vitalsのツールを見てきましたが、いかがでしたでしょうか。なんか多かったですよね。ただ「便利だな」って感じたこともあるかもしれません。

常にCore Web Vitalsを計測したい方にはWeb Vitals Extensionがおすすめ

もうこれで、あなたはCore Web Vitalsのことが頭から離れなくなってしまったかもしれません。（スライドを指して）これは弊社の小林さんの例ですが、頭から離れないと。

そういう常にCore Web Vitalsを計測したいマニアックな方には、Web Vitals Extensionがおすすめです。これをインストールすると、各ページにアクセスしたタイミングでCore Web Vitalsが計測されます。問題があれば赤く表示されて、その詳細を見れます。

Core Web Vitalsは実環境でのデータを集計していますが、時には十分な数のデータがないと表示されることがあります。これは、キャンペーンページやカンファレントのサイトでよく起こります。

そういったサイトでCore Web Vitalsを集計するか、改善するべきかの判断は分かれると思いますが、実際に集計する場合には、web-vitals JS Libraryが便利です。npmやCDN経由で配信されており、簡単に読み込んでCore Web Vitals各仕様の値を取得できます。

各値はブラウザーのパフォーマンスAPIから取得できますが、計算方法が異なる場合があるので、Web Vitalsのスコアとして取得したい場合には、ライブラリを利用したほうがよいでしょう。

web-vitals JSを使ってGoogle Analyticsに値を送信していくとダッシュボードを作成してくれる、Web Vitals Reportというツールもあります。

それ以外にも、さまざまなサードパーティツールでCore Web Vitalsのデータを収集できるので、サービスごとに選ぶとよいでしょう。

（次回につづく）