[go: up one dir, main page]

この記事は Web Ecosystem Consultant - Saurabh Rajpal, Swetha Gopalakrishnan による web.dev の記事 "The business impact of core web vitals" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
LCP、FID、CLS

Core Web Vitals の採用について、ステークホルダーをなかなか説得できなかったり、実際にビジネスに役立つかどうか疑問に思ったりしていませんか？この記事では、すでにユーザーやビジネスに好影響が出ている企業の例を紹介し、Core Web Vitals と重要なビジネス指標にどのような相関関係があるのかをわかりやすく説明します。

動画で見たい方は、Google I/O のこちらのトークをご覧ください（日本語字幕付き）。

Core Web Vitals がユーザーやビジネスにとって重要な理由 #

組織では、ステークホルダーによって優先度が異なる場合があります。Core Web Vitals を導入すると、ユーザー中心の指標の最適化と、その結果としてのビジネスの成長に重点を置くことで、全員で共通の認識を持つことができます。

CWV について考える

Core Web Vitals のスコアを上げるまでの道のりは、サイトのパフォーマンスが現在どの段階にあるか、デザインがどれだけ複雑かによって、サイトごとに異なります。すぐにたやすく取り組めて有意義な結果につながる場合もあれば、複雑なソリューションを実装して困難な問題を解決しなければならない場合もあります。意思決定者は、費やす時間にかかわらず、これをビジネスの成長のための長期的な投資として扱うべきです。高速でシームレスなナビゲーション体験を提供すれば、ユーザーは喜び、忠実なリピーターになります。プロダクト マネージャーにとって、パフォーマンスは新しいプロダクト機能の質と成功を定義する重要な基準です。また、優れたプロダクトを生み出すことや、やりがいのある課題に取り組むことは、デベロッパーの満足度の向上にもつながります。

ランキング シグナルとしての Core Web Vitals は、パフォーマンスに時間をかけて取り組むもう 1 つの動機となりますが、Core Web Vitals を採用すると、ランキングにとどまらず、さまざまな短期的、長期的メリットが得られます。Core Web Vitals を（ランキングに反映される前に）採用したいくつかのグローバル ブランドやローカル ブランドの事例を確認してみましょう。採用の理由は、Core Web Vitals がユーザー エクスペリエンスに注目しているからです。

ケーススタディ #

Vodafone #

Vodafone（イタリア）は、LCP を 31% 改善することで、売上が 8% 増加しました。

売上が 8% 増加

テクニック #

  • 重要な HTML をサーバー側でレンダリング
  • レンダリングをブロックする JavaScript を削減
  • イメージ最適化テクニック
  • ヒーロー イメージのサイズ変更、重要でないリソースの遅延読み込み

重要な教訓 #

  • 結果の有意義性を測定するには A/B テストが最適
  • A/B はサーバー側で行う

iCook #

iCook は、CLS を 15% 改善することで、広告収入が 10% 増加しました。

広告収入の増加を示すグラフ

テクニック #

  • 広告ユニットのサイズ変化を減らして、UI で固定サイズの広告スロットをあらかじめ割り当てる
  • 広告スクリプト読み込みロジックを最適化してヘッダー入札を優先する、重要でない JS の遅延読み込みをする

重要な教訓 #

フィルレートに影響が出る可能性があるが、広告の視認性が上がるにつれて収益が向上する

Tokopedia #

Tokopedia は、LCP を 55% 改善することで、平均セッション時間が 23% 増加しました。

改善前 3.78 秒、改善後 1.72 秒

テクニック #

  • LCP 要素をサーバー側でレンダリング（SSR）
  • LCP 要素のプリロード
  • イメージ最適化（圧縮、WebP、重要でないイメージの遅延読み込み）

重要な教訓 #

  • パフォーマンス モニタリング ダッシュボードを構築し、すべてのチームの進捗と影響を監視
  • さまざまなレンダリング テクニックの実験（例 : LCP 要素を SSR、スクロールせずに見える範囲を SSR、フル クライアント側 レンダリング）

以上のケーススタディから、ベスト プラクティスを採用してすばやく成果を上げることで、大きな効果が得られることがわかります。この点に関する実例を、さらにいくつか紹介します。

GEDI は CLS を 77% 削減することで直帰率が 8% 減少、Lazada は LCP を 3 分の 1 にすることでモバイルのコンバージョン率が 16.9% 増加、GYAO は LCP 約 3 分の 1 にすることでクリックスルー率が 108% 増加

以上の結果は、以下のようなすぐにたやすく行えることを実施した結果です。

イメージ最適化 JavaScript 最適化 広告と動的コンテンツ
WebP 画像形式の利用 サードパーティ JS の遅延読み込み スクロールせずに見える範囲の広告スペースを予約
イメージ CDN の利用 レンダリングをブロックする未使用 JS の削除 動的コンテンツの高さを設定
圧縮 重要でない JS の遅延読み込み
重要でないイメージの遅延読み込み 重要な JS のプリロード
ヒーロー イメージのプリロード
アスペクト比の指定

その他のベスト プラクティスについては、Web Vitals ガイダンスを参照してください。PageSpeed Insights を使うと、ウェブサイトを監査して即座に実用的な推奨事項を確認できます。

ほかにもいくつものグローバル ブランドが Core Web Vitals に投資して、そのメリットを享受しています。

対応を始めるには #

ステップ 1: 測定を始める #

最初に、フィールド ツールを使ってサイトを計測しましょう。Google を含むプロバイダが、さまざまなツールを公開しています。

Google 製ツール #

  • Search Console
  • PageSpeed Insights
  • web-vitals JS
  • Chrome ユーザー エクスペリエンス レポート

サードパーティ製ツール #

  • Cloudflare
  • New Relic
  • Akamai
  • Calibre
  • WebPageTest
  • Blue Triangle
  • Sentry
  • SpeedCurve

皆さんにとって最適なツールを選択してください。もう一歩踏み込んで Google アナリティクス 4 を組み込むことで、Core Web Vitals とビジネス指標の相関関係を確認することもできます。

ステップ 2: ステークホルダーを説得する #

  • Core Web Vitals を採用してユーザー エクスペリエンスを改善することの重要性と、それが企業のビジネス指標に関連していることを、ステークホルダーに説明する
  • 社内で支援者を募り、小規模な実験を始める
  • すべてのチームで Core Web Vitals を改善するために、すべてのステークホルダーで共通の目標を定める

ステップ 3: 以下のヒントを活用して実装を成功に導く #

  • 優先度 : 有意義な結果につなげるため、トラフィックが高いページやコンバージョンへの影響が大きいページを選択する（広告ランディング ページ、コンバージョン ページ、人気のページなど）
  • A/B テスト : レンダリング コストの発生を避けるためにサーバー側でのテストを利用し、最適化したバージョンと最適化していないバージョンの結果を比較する
  • 監視 : 継続的なモニタリングをし、リグレッションを防ぐ

最後になりますが、Google では、パフォーマンスは目的ではなく過程であると考えています。そのため、注目すべき最新のケーススタディを紹介できるように、今後もこの記事を更新する予定です。ビジネスですばらしい成功を収め、この記事で取り上げてほしい事例がある方は、コンテンツの提案をお送りください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Naina Raisinghani（AMP Project、プロダクト マネージャー）による The AMP Blog の記事 "Optimizing your AMP page experience for Core Web Vitals" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Core Web Vitals は、サイトオーナーがウェブサイトのユーザー エクスペリエンスを改善する場所や方法を理解するために役立つ重要な一歩です。Google のページ エクスペリエンス シグナルでも、このような客観的な指標群に注目することを推奨する予定です。これらは、デベロッパーが現在のすばらしいユーザー エクスペリエンスを改善し、維持するために役立つだけではありません。今後もアップデートされていくので、デベロッパーはウェブが満たすべき最新のパフォーマンスについての情報を得ることができます。 

世界中の AMP Project の貢献者のおかげで、サイトオーナーは AMP ページを作成する際に、パフォーマンスに優れた体験の構築に向けて良いスタートを切ることができます。ただし、他の多くのフレームワークと同様に、AMP でもウェブ開発のベスト プラクティスをすべて実装することはできません。このブログ投稿では、AMP ページを確実に最適化するためにデベロッパーが行うべきことについて共有します。この内容は、AMP ページがパブリッシャーのサイトから提供される場合と、AMP キャッシュから提供される場合の両方に適用できます。

AMP ページのパフォーマンスをさらに高め、Core Web Vitals を満たす

AMP の目的は、優れたユーザー エクスペリエンスを簡単に作れるようにすることです。しかし、優れたユーザー エクスペリエンスに不可欠だと AMP チームが確信しているいくつかの開発プラクティスでは、追加の作業が必要になる場合があります。

AMP のトラフィックを理解する

ページの Core Web Vitals 指標は、ウェブページで実際のユーザー インタラクションを測定して算出されます。AMP では、ユーザーがどのようにコンテンツにアクセスしたかによって、パブリッシャーのドメインか AMP キャッシュのどちらかからページが提供されます。多くの場合、AMP へのアクセスの大部分（半分以上）が自分のドメインで発生します。こちらのガイドに従うと、AMP デベロッパーが AMP キャッシュ上とそれ以外での Core Web Vitals 指標を測定できます。

ウェブ開発のベスト プラクティスを導入する

Google の調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。主なポイントは以下のとおりです。

  • サーバーの応答時間を改善する : サーバーが遅い、またはエンドユーザーから離れた場所に存在する場合は、ほぼすべてのものが遅くなってしまいます。CDN と同じように、配信は AMP キャッシュによって最適化されますが、ほぼすべての AMP サイトに AMP キャッシュ外のトラフィックが存在します。つまり、優れたユーザー エクスペリエンスを実現するには、高速で応答が速いサーバーが不可欠です。
  • 大きすぎるイメージの使用を控える : サイトでユーザーが期待する速さを実現するには、ユーザーが使っているデバイスのディスプレイよりも大きいイメージは使わないようにします。 
  • フォントによるレイアウトのずれを回避する : レイアウトのずれは、ウェブページの要素が動的に変更され、コンテンツに「ずれ」が発生することによって起こります。ウェブフォントを取得してレンダリングすると、直接的にレイアウトのずれが発生する可能性があります。 現在推奨している方法は、最初のビューポートで利用するすべての重要なフォントについて、フォントのプリロードと font-display: optional を組み合わせることです。このレイアウトのずれはあらゆるウェブページで日常的に起こっているので、標準化団体とともに追加のガイダンスを提供する作業を進めています。
  • data-hero を使ってヒーロー イメージをマークアップする : 多くのウェブページにとって、ヒーロー イメージは重要なパーツです。そのため、ユーザーが期待する速さで読み込む必要があります。<amp-img data-hero src="…"> のようにして data-hero 属性を使ってヒーロー イメージをマークアップすると、AMP Cache と Optimizer がヒーロー イメージを認識して最適化してくれるので、イメージのレンダリング時間が最大 50% 速くなります。

さらに AMP を改善するためのツール

AMP ページで可能な限り充実したユーザー エクスペリエンスを実現するため、すべてのサイトオーナーの皆さんに、ご自身で対応できるさまざまな最適化を追加で実施することを強く推奨します。最も簡単な方法は、最新の AMP Optimizer を使うことです。これにより、AMP の新しいサーバー側最適化をすべて自動で適用できます。また、昨年には、AMP Page Experience Guide（下図）も公開しました。公開以降、アクションにつながるフィードバックが AMP Page Experience Guide にさらに追加され、利便性が高まりました。この取り組みを推進する原動力となっているのは、このツールを使って AMP ページをテストするウェブサイトです。たとえば、カスタム フォントの読み込みに関する推奨事項が表示されるようになったので、LCP と CLS を最適化できます。

AMP Page Experience Guide の結果のスクリーンショット

AMP ページをこれらの基準に適合させるためのアクションにつながる推奨事項が存在しない場合は、お知らせください。直接サポートいたします。次に示すように、リクエストは AMP Page Experience Guide の中から送信できます。または、Github から直接連絡することもできます。

AMP Page Experience Guide から直接 AMP の問題を送信

まとめ

AMP Project は、ユーザー ファーストなオープンウェブを作るというビジョンただ一点に集中しています。AMP Page Experience Guide を使うと、Core Web Vitals に基づく AMP ページのパフォーマンスを確認できます。パブリッシャーのドメインと AMP キャッシュで、推奨された最適化を実施することをお勧めします。

AMP 開発コミュニティや、皆さんのフィードバックに感謝いたします。いつものように、問題や機能リクエストがありましたら遠慮なくお知らせください。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Ben Galbraith & Dion Almaer による Chromium Blog の記事 "Chrome Dev Summit 2020: Building an open web for our users and developers" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

すべての人は、安全で強力、そして高速なオープンウェブの恩恵を受けています。私たちはここ 1 年で、次にあげる 3 つの領域について、集中的にウェブの強化を行ってきました。

  1. 安全、安心なウェブをどのように提供できるかを再考する
  2. 強力、高度、多様なアプリケーションを構築するために必要な機能を追加する
  3. ユーザーとデベロッパーの両者に対してパフォーマンスを最適化する

この投稿では、本日（元記事公開当時）の Chrome Dev Summit の基調講演で共有したアップデートの概要をまとめます。

ゼロからプライバシーを再考する

私たちはプライバシー サンドボックスの作業を継続し、ウェブのプライバシーを抜本的に強化するオープンな基準を作ろうとしています。そして、ウェブ コミュニティと協力しつつ、サードパーティ Cookie やクロスサイト トラッキング メカニズムに代わり、プライバシーを守ることができる新たな仕組みを構築しようとしています。Client Hints API では Chrome でフィンガープリンティングに使える領域を減らし、Chrome オリジン トライアルを通して実験できる 2 つのソリューションも提供しています。Click Conversion Measurement API は、クロスサイト識別子を使わずに広告コンバージョンを測定します。Trust Token API は、パッシブなトラッキングを行うことなく、あるコンテキストから別のコンテキストに信頼を伝える際に役立ちます。

オリジン トライアルで利用可能
詳細はこちら: web.dev/trust-tokens/

同様に、数億人のユーザーが利用する Chrome ウェブストアの 250,000 件以上の拡張機能でも、セキュリティとプライバシーが最重要になっています。私たちは、拡張機能はデフォルトで信頼できるものでなければならないと考えています。そのため、拡張機能プラットフォームにたくさんの変更を行うドラフト提案についてお知らせしました。拡張機能デベロッパーからのさまざまな提案を反映すれば、Manifest V3 の安定版リリースに向けた準備が整います。その目的は、セキュリティの強化、ユーザーの制御とプライバシーの向上、パフォーマンスの改善です。

Manifest V3 と合わせて、リモートでホストされたコードは許可されなくなります。これは、ユーザーのプライバシーやセキュリティを侵害する悪意のある拡張機能を防ぐためです。また、新しい拡張機能モデルでは、ユーザーがインストール時にセンシティブな情報へのアクセスを許可しないことを選択できるようになります。さらに、バックグラウンド ロジックに新たなアプローチを導入します。バックグラウンド ページに Service Worker を導入し、拡張機能 API に新たな宣言的モデルを適用することで、ユーザーに一貫したパフォーマンス保証を提供します。現在、Manifest V3 は Chrome 88 ベータ版で試験運用版として利用できます。Chrome ウェブストアは、Chrome 88 が安定版になる 1 月中旬から、Manifest V3 拡張機能を受け付ける予定です。

高度なアプリに強力な機能を提供

ウェブで新しい体験を構築しているデベロッパーから、すばらしい活用例が登場しています。Gravit Designer は、File System Access API を使ってユーザーが簡単にファイルの読み書きを行えるようにし、さらに新しい Local Font Access API でローカルにインストールした特別なフォントを利用できるようにしています。Adobe は、Spark ウェブアプリでユーザーがすばらしいビジュアル ストーリーや美しいデザインのコンテンツを簡単に作れるようにしています。

本日（元記事公開当時）、Progress Web App（PWA）に新機能を追加します。これによって、PWA を Google Play ストアに掲載して見つけてもらいやすくすることができます。Chrome 86 では、Trusted Web Activity を使っている PWA を Play ストアで一覧表示できるようになります。また、Chrome 88 では、新しい Digital Goods API を使って支払いを受け取れるようにしています。

パフォーマンスの最適化

デベロッパーの皆さんがすべてのユーザーに最適な体験を提供できるようにするため、Chrome のパフォーマンス（スピードのほか、電力、メモリ、CPU などのリソースの使用量）は常に私たちの最優先事項になっています。

今年は、プロファイルによる最適化とタブ スロットリングによって、スピードに関するいくつかの重要な改善を行いました。そして本日は、V8 のメモリ フットプリントを大幅に削減したことをお知らせします。V8 ポインタ圧縮でメモリの節約に向けた大きな一歩を踏み出したことに加え、ウェブページの JavaScript ファイルを並列に読み込むことで解析による中断を完全に無くしました。これによって、ページで必要になるときには既にスクリプトの実行準備が整っているように、スクリプトの解析とコンパイルを実行できます。

Web Vitals の取り組みについて発表して以来、ウェブページのパフォーマンスを測定する際にこの基準が使われることが多くなっています。Google 検索は、2021 年 5 月より、検索ランキングの新たなシグナルに Core Web Vitals を含めることを発表しました。Chrome ユーザー エクスペリエンス レポートに加え、Search Console の Core Web Vitals レポートやその他多くの Google 製ツール、Cloudflare などの他のプロバイダで、Core Web Vitals がウェブページのパフォーマンス指標として表示されています。

この夏、Google アナリティクスを使っているサイト向けに、web-vitals Javascript ライブラリをリリースしました。本日、オープンソースのウェブサイトおよびツールである Web Vitals Report についてお知らせしました。これを使うと、Google アナリティクスで Web Vitals 指標データのクエリや視覚化ができるので、セグメント間で簡単にパフォーマンス データを比較することもできます。

最後になりますが、皆さんのフィードバックや、ウェブ インターフェースの構築が難しい点についてのご意見をお待ちしています。私たちは、ウェブのスタイリング機能の改善を進めており、レンダリング パフォーマンスを大幅に向上させる content-visibility CSS 機能を公開しました。簡単に CSS を拡張できる API セットである Houdini.how のお知らせなど、UI スタイリングを改善するアップデートやツールにご期待ください。

バーチャル カンファレンスの実験

Chrome Dev Summit は、常にコミュニティとのつながりを大切にしています。今回は直接顔を合わせることはできませんでしたが、Chrome チームは、偶然の会話や新しい発見、記念品の収集など、実際のカンファレンスのいい所を集めた PWA、Chrome Dev Summit Adventure をリリースしました。この実験について皆さんからの感想を聞いたり、リアルタイムでチャットしたりするのが楽しみです。

さらに詳しく知る

コミュニティの一員になり、世界中の Google Developer Group に参加しましょう。CDS Extended イベントでは、地域のデベロッパー コミュニティを集めて、Chrome Dev Summit 2020 のハイライトを確認したり、インタラクティブなセッションがライブで行われたりします。このイベントのすべてのリストをチェックしてください。

YouTube チャンネルでは、いつでもセッションを視聴できます。また、web.dev ニュースレターにサインアップしてウェブの最新アップデートを受け取ってください。

また来年にお会いしましょう！

※ 日本では Chrome Dev Summit の日本版となる Chrome Dev Summit Recap 2020 を開催しました。アーカイブは 2021 年 1 月中旬まで閲覧可能ですので、ぜひ今からでも登録・ご視聴下さい。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は高速なページのファン、Addy Osmani、Ben Greenstein、Josh Simmons による Chromium Blog の記事 "Highlighting great user experiences on the mobile web" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

この 10 年間、Chrome とウェブ開発コミュニティは、高速かつレスポンシブで快適なブラウジング体験をユーザーに提供するための作業を続けています。<link rel=preload> やネイティブ遅延読み込みをはじめとするさまざまな機能は、この目的の実現に貢献しています。Chrome は従来より、HTTPS などのベスト プラクティスの採用も進め、成功に導いてきました。これは、Chrome の UI で安全なブラウジングと安全でないブラウジングを区別することで実現しています。

ユーザーがブラウジングする際に優れたユーザー エクスペリエンスを認識できるように、Chrome はウェブ上の高品質なユーザー エクスペリエンスを強調表示するようになります。その第一歩として、Android 版の Chrome で高速なリンクのコンテキスト メニューにラベルを表示します。この変更は、Chrome 85 ベータ版以降でロールアウトされる予定です。

ラベル表示は、実際の Chrome ユーザーが体験するユーザー エクスペリエンスの重要な側面を定量化した Core Web Vitals 指標のシグナルに基づいています。Core Web Vitals 指標は、読み込み時間、応答の早さ、読み込み時のコンテンツの安定性など、ウェブのユーザビリティの要素を測り、優れたユーザー エクスペリエンスの基準となる指標のしきい値を定義します。

サイト所有者がこれらの指標を改善するために変更を加えると、ユーザーがどんなウェブブラウザを使っていたとしても、ウェブ体験が快適になります。このようなユーザー中心の重要指標に注力することで、ユーザビリティの改善が進み、企業のエンゲージメントも向上する可能性があります。

Core Web Vitals のすべての指標のしきい値を満たすかそれを上回っているページへのリンクは、“高速版ページ” という新しいラベルとともに表示されます。このラベルは、ページに移動する前にユーザーがリンクを長押しした場合に表示され、そこへ移動したユーザーの大半が特に優れた体験をしていることを示します。


"高速版ページ" ラベルはリンクが高速であることを示します。これが表示される可能性があるのは、これまで他のユーザーが高速に開くことができた実績のある URL（あるいはそれに似た URL）です。ラベルを表示するにあたって、同じ構造を持つサイトの URL の履歴データが集計されます。たとえば、URL が新しい、あまり人気がないなど、URL のデータが十分ではないためスピードが評価できない場合や URL データを利用できない場合、履歴データはホスト単位に評価されます。

ページのラベル表示機能は、ユーザー エクスペリエンス全体を最も的確に表す指標に対して常に最適化されるように、Core Web Vitals の進化に合わせてゆきたいと考えています。以前にも記載しましたが、デベロッパーの皆さんは、Core Web Vitals の定義としきい値が安定版になり、予測可能な 1 年単位のアップデートとその事前通知が行われると考えてください。

Core Web Vitals を最適化するには、ページの質を改善する作業が必要になる場合があります。これをサポートするため、デベロッパー ツールをアップデートし、情報や推奨事項が表示されるようにしました。Lighthouse、DevTools、PageSpeed Insights、Search Console チームも、Core Web Vitals 専用のレポートを追加しました。


現在、ラベル表示機能は Chrome 85 ベータ版にロールアウトされていますが、chrome://flags を開いて “Context menu performance info and remote hint fetching” を有効にすると、すぐに試すことができます。このフラグは Android 版 Chrome のみで有効ですのでご注意ください。完全にロールアウトされると、Lite モードか “Make Searches and Browsing Better” をオンにしているユーザーにラベルが表示されます。次に、Wikipedia の Internet のページなど、条件を満たすページに移動し、いずれかのリンクを長押ししてみてください。

私たちは、ウェブが私たちの生活において重要な役割を果たしていると確信しており、今回のラベル表示が遅いネットワークや接続状態の悪いネットワークを使っているユーザーの役に立つことを期待しています。今後は、Chrome の UI のその他の部分に試験的にラベル表示を行うことも検討しています。私たちの最終的な目的は、ページを開いたときに体験する可能性があるエクスペリエンスを、健全なレベルの透過性をもってウェブのユーザーに提供することにあります。

Chrome は、今後もウェブの繁栄のためにエコシステムと連携してゆきます。ここで紹介したようなステップは、その目的を念頭において検討されています。


Reviewed by Eiji Kitamura - Developer Relations Team

この記事は Patrick Kettner による The AMP Blog の記事 "AMP + Web Vitals – a better web, together" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


今週、Google は Web Vitals の取り組みについてお知らせしました。Web Vitals は、優れたウェブのユーザー エクスペリエンスに不可欠と Google が判断した一連のガイドラインです。AMP Project の目標は常に変わることなく「すべての人に、すべての場所で、より良く高速に表示されるウェブ」です。そこで、Web Vitals で推奨されているパフォーマンス目標をサイトオーナーが達成するにあたって、AMP がいかに役立つのかをご説明します。また、高速でさらに優れたウェブにするための作業についても詳しくお知らせします。 

Core Web Vitals とは

Web Vitals についてお話しすべきことはたくさんありますが、この投稿では Core Web Vitals について取り上げます。この 2 つの違いについては、web.dev をご覧ください。このサイトから、最も関連する部分を引用します。

Core Web Vitals は、すべてのウェブページに適用される Web Vitals のサブセットで、すべてのサイトオーナーが測定すべき内容です。また、すべての Google 製のツールで表示されるようになります。Core Web Vitals の各項目は、ユーザー エクスペリエンスの個々の側面を表します。いずれも現場で測定でき、ユーザーを重視する視点で重要になる実際のパフォーマンスを反映しています。

Core Web Vitals に含まれる指標は、時間とともに進化します。2020 年時点での項目は、読み込み、 インタラクティブ性、 視覚的な安定性というユーザー エクスペリエンスの 3 つの側面に注目しており、以下の指標（とそれぞれのしきい値）が含まれます。

Largest Contentful Paint（LCP）: 読み込み パフォーマンスを測定します。優れたユーザー エクスペリエンスを実現するには、LCP はページの最初の読み込みが始まってから 2.5 秒以内である必要があります。

First Input Delay（FID）: インタラクティブ性を測定します。優れたユーザー エクスペリエンスを実現するには、ページの FID が 100 ミリ秒未満である必要があります。

Cumulative Layout Shift（CLS）: 視覚的な安定性を測定します。優れたユーザー エクスペリエンスを実現するには、ページの CLS が 0.1 未満である必要があります。

専門用語に惑わされないようにしてください。重要な点は、サイトに期待される重要なユーザー エクスペリエンスを実現する上でこれらの指標が役立つこと、そして新しいクロスブラウザ API を使って現場で測定できることです。

すべてが現場で測定できるので（そして測定すべきです）、単なる理論的な結果ではなく、ユーザーが実際に経験していることを追跡できます。それでは、新しいガイドラインの内容がわかったので、これを満たすために AMP がどう役立つかについて見ていきましょう。 

First Input Delay

First Input Delay（FID）はインタラクティブ性を評価する際に役立つ

FID スコアが低い場合、ユーザーがボタンをクリックしたり入力項目をタップしたりすると、サイトがほぼ瞬時に応答し、待たされることはありません。web.dev のドキュメントによれば、ここでの目標は 75 パーセンタイルで 100 ミリ秒です。 これは、ユーザーが初めて入力項目を操作するとき、ページが表示されている時間の 75% 以上において、100 ミリ秒未満で反応するという意味になります。すべての Core Web Vitals と同じく、この情報はユーザーから収集する必要があります。まだ収集していない場合は、開発マシンで測定するだけでなく、実際のユーザーデータ（ヒント: まずは PageSpeed Insights から始めるのがおすすめです）に関するレポートを参照して、しきい値を満たしているかどうかを確認してください。

開発環境で実際の FID を測定することは できません 。意味のあるデータを得る唯一の方法は、実際のサイトのユーザーのインタラクションにかかる時間を確認することです。開発中に使える類似指標として、合計ブロック時間を表す Total Blocking Time があります。この 2 つは同じものを測定しているわけではありませんが、TBT が下がれば FID も下がるのが一般的です。FID 値が高くなっていることが多い場合、ほとんどはブラウザのメインスレッドが別の作業（コードのパースやサードパーティ製のリソースの読み込みなど）を行っています。FID スコアを改善する詳しい方法については、web.dev をご覧ください。

AMP は、さまざまな方法を用いて低い FID スコアを維持しています。

AMP のコードはユーザーをブロックしない

AMP は非同期 JavaScript のみを許可しており、遅い操作や負荷がかかる計算操作が紛れ込むことはありません。そうでなければ、このような操作によって実際のサイトの利用がブロックされる可能性があります。 

遅延レイアウト

AMP は、サイトの即時性を保つため、読み込み時にすぐには表示されないと思われる要素のレンダリングを遅らせます。つまり、AMP では、サイトの下部に JavaScript を使った重い動画プレーヤーがあっても、サイトの読み込み中にプレーヤーの処理が行われているという理由でユーザーのクリックやタップがブロックされることはありません。 

プロセスの分割

AMP は、ページが無応答にならないように、プロセスのチャンク化を実装して長時間実行されるタスクを分割しています。大きなタスクを小さく分割し続けることで、すべての操作がすぐに応答するように感じるサイトを実現しています。 

その他すべてをサンドボックス化

AMP の外側のコードが必要になる場合、それは専用の iframe で実行されます。コードを専用のコンテナで実行することで、ユーザーによるページ操作がブロックされないようにしています。つまり、遅い広告やたくさんのコードが必要な動画プレーヤーによって、ユーザーのサイトの利用が妨げられることはありません。

Cumulative Layout Shift

Cumulative Layout Shift（CLS）は視覚的な安定性の測定に役立つ

AMP ブログで CLS について詳しく取り上げた最近の記事をご覧になったかもしれませんが、読み込みが遅いコンテンツや大きすぎるイメージや動画があるためにウェブページが動き回ることがあり、それが現在のユーザーのさまざまな不満につながっています。優れたサイトに優れた CLS スコアが不可欠なのはそのためです。Google は、CLS を 0.1 未満にすることを推奨しています。これは、他の Core Web Vitals よりも少々複雑な測定が必要になるので、web.dev のドキュメントに目を通して理解を深めることをおすすめします。理解しておくべき重要な点は、CLS が低ければ、ユーザーに予測可能な安定したレイアウトが表示され、要素が動き回らないことです。

CLS は、AMP が非常に効果を発揮するもう 1 つの領域です。AMP は、CLS スコアが悪いサイトがよくはまる落とし穴を回避するためにゼロから開発され、以下のようなたくさんのルールを設けることで、この数値を低く保っています。 

静的サイズ レイアウト システム

AMP のレイアウト システムは、リソースをダウンロードする前にサイズを推定できるように作られています。たとえば、イメージや動画、iframes などのテキスト以外の要素が必要な AMP では、ビルトイン コンポーネントを通して読み込みを行う必要があります。その際に、デベロッパーはリソースの高さと幅をブラウザに伝えなければなりません。 

<amp-img height="200" width="400" src=...

これらの属性には、コンテンツがダウンロードされる前でもアクセスできるので、ブラウザはイメージを読み込んだ後のようにページをレイアウトすることができます。これがなければ、ダウンロードが完了して各要素に必要なスペースが決まったタイミングでレイアウトをずらすしかありません。

動的コンテンツに必要なインタラクション

再レイアウトが発生する可能性のあるページのアップデートを行う場合は、ユーザーによるインタラクションが必須になっています。ユーザーが何かをタップする前に、ウィジェットをポップアップさせることはできません。アップデートをインタラクションの応答時に限定することで、ユーザーが不快な驚きを経験する可能性は低くなります。

効率的なフォントの読み込み

多くのウェブサイトは、外部フォントを使ってページのスタイルを設定しています。外部 CSS ファイルをダウンロードし、参照先を見つけて、フォントをダウンロードしなければならない場合、ページの読み込みはスムーズではなくなり、ユーザーも混乱しやすくなります。AMP では、すべての CSS をインラインにしてウェブサイトのソースコードの上部に記述しなければならないので、これが緩和されます。すべてのフォントはすぐに検出され、ダウンロードされます。また、FID の説明で触れたように、JavaScript の読み込みは非同期なので、JavaScript のダウンロードによってブラウザのカスタム フォントの処理がブロックされることはありません。 

Largest Contentful Paint

Largest Contentful Paint（LCP）は読み込み速度の監視と把握に役立つ

ユーザーは、ページを読み込んでも、ネットワークのコールバックなどのパフォーマンス インジケーターを見ることはできません。見ることができるのは、視覚的な出力、あるいはその出力がないことだけです。LCP は、最大の要素がレンダリングされたタイミングを測定します。LCP のタイミングを測定することで、ユーザーが実際にページをどのくらい速く 感じているか に関するさまざまな知見を得ることができます。LCP が非常に重要な指標である理由はこの点にあります。web.dev の推奨では、LCP は 75 パーセンタイルで 2500 ミリ秒以内です。

Largest Contentful Paint をできる限り高速にするために、AMP では以下のようなたくさんの最適化が行われています。

インテリジェントなリソースの読み込み

AMP の目的は、常に体感速度の向上にあります。この実現には多くのことが必要ですが、その 1 つは、イメージや広告を最初にダウンロードするのは、それが画面の表示範囲に含まれているか、ユーザーがすばやくスクロールした場合に限ることです。AMP は、ページの読み込み時に取得するリソースの量を限定し、ユーザーが実際に目にするコンテンツを優先します。その結果、ユーザーが速いと感じられるサイトになります。 

プリロードとプリレンダリング

AMP ページを AMP キャッシュにホストする場合、コンテンツのプリロードなど、ページに対してさらに多くの最適化が行われ、極限まで高速化されます。通常、ユーザーがプリレンダリングされた AMP ページをタップするときには、ブラウザは既にすべてのダウンロードとレンダリングを終えています。そのため、速く感じられます。

AMP ページのパフォーマンスをさらに高める

ここまで紹介したのは、特に手を加えていない AMP の動作です。しかし、私たちのチームは、優れたユーザー エクスペリエンスには、実行時では実現できない開発作業が欠かせないと考えています。私たちは、AMP が Core Web Vitals の基準を大きく上回るよう懸命に努力していますが、それに到達しない可能性もあります。AMP のパフォーマンスを さらに高めるために、皆さん自身でできる追加の最適化はたくさんあります。私たちの調査によれば、デベロッパーが AMP ページを提供する方法には、まだ最適化の余地があります。主なポイントは以下のとおりです。

サーバーの応答時間を改善する

サーバーが遅いと、ほぼすべてが遅くなります。CDN と同じように、配信は AMP キャッシュによって最適化されますが、ほぼすべての AMP サイトには いくらかの AMP キャッシュ以外のトラフィックも存在します。つまり、優れた Core Web Vitals の実現には、サーバーが高速で素早く応答することが欠かせません。

大きすぎるイメージの使用を控える

サイトをできる限り速くするには、実際の表示よりも大きいイメージの利用を避ける必要があります。多くの場合、ウェブサイトで最適化されていないイメージを読み込むと、ダウンロード サイズが数百キロバイト単位で増加し、Core Web Vitals の LCP が直接的に損なわれます。AMP オリジンのイメージを最適化し、ユーザーが時間や帯域幅を節約できるようにしてください。

AMP キャッシュでは、こういった問題を避けるためにコードが最適化されますが、この最適化はキャッシュ上でのみ行われる点に注意してください。ソーシャル メディアで共有されたリンクを経由する場合や、直接サイトに移動する場合など、サイトに直接アクセスしたユーザーは同じ動作にはなりません。 あらゆる ユーザーに対して優れた Core Web Vitals スコアを実現するには、オリジンでサイトを最適化することが非常に重要です。 

さらに AMP を改善するためのツール

AMP チームは、サイトを最適化するためのさまざまなオープンソース ツールを提供しています。 

AMP Optimizer

AMP Optimizer は、AMP のレンダリング パフォーマンスを改善するためのすばらしい選択肢です。サーバー側レンダリングやコード圧縮などの機能が搭載されており、サイトの読み込みの高速化に向けた大きな一歩となります。

AMP for WordPress Plugin

WordPress を使っていて AMP に興味がある方は、公式 AMP プラグインを確認してみてください。開発とメンテナンスは AMP チームが担当しており、WordPress から WordPress 的に AMP コンテンツを生成できるようになります。そのため、パフォーマンス最適化技術についての深い専門性がなくても、高速な AMP ページをすぐに公開できます。また、公式 AMP プラグインは、WordPress で AMP 開発を行うための高度なツールも提供しています。

Next.js

Next を使うと、1 行のコードを追加するだけで React サイトを AMP サイトに変えることができます。これにより、サーバー側レンダリング（LCP の高速化が可能）や AMP Optimizer 統合など、さまざまなパフォーマンス最適化が自動的に行われます。どうぞご覧ください！ 

パフォーマンスの最適化は、早く行うほどメリットがあります。ここで紹介したようなツールを使えば、キャッシュされたページからアクセスするユーザーだけでなく、すべてのユーザーに対して高速でスムーズな体験を提供できるようになります。

まとめ

Web Vitals と Core Web Vitals は、サイトオーナーにウェブのユーザー エクスペリエンスを改善する場所や方法を理解してもらうための重要な一歩です。これらは、デベロッパーが現在のすばらしいユーザー エクスペリエンスを改善し、維持するために役立つだけではありません。今後もアップデートされていくので、デベロッパーはウェブが満たすべき最新のパフォーマンスについての情報を得ることができます。 

世界中の AMP Project の貢献者のおかげで、AMP ページを作成したサイトオーナーは、最大限のパフォーマンス保証を得ることができます。AMP チームは、ウェブ上の AMP ページのパフォーマンスを継続的に監視し、定期的に AMP ライブラリのパフォーマンスを強化するアップデートを行っています。AMP は常に最新のライブラリなので、デベロッパーやユーザーは何もしなくても最新の AMP の改善による恩恵を得られます。 

質問がある方はお知らせください。それ以外の方は、Twitter をフォローするかニュースレターにサインアップして、AMP の変更についての最新情報を受け取れるようにしてください。

投稿者: Patrick Kettner、 Google、AMP Project、デベロッパー チアリーダー


Reviewed by Chiko Shimizu - Developer Relations Team

この記事は スタッフ インタラクション デザイナー、Amar Sagoo、ソフトウェア エンジニア、Annie Sullivan、プロダクト マネージャー、Vivek Sekhar による Chromium Blog の記事 "The Science Behind Web Vitals" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Web Vitals とは、ビジネス オーナー、マーケティング担当者、デベロッパーを等しく支え、ユーザー エクスペリエンスを改善する機会を提供するための Google による取り組みです。ヒューマン コンピュータ インタラクション（HCI）やユーザー エクスペリエンス（UX）の研究者たちの広範囲にわたった研究が、これらの指標を導き出しています。しかし、適切な指標やしきい値を見つける作業は、研究論文を参照し答えを見つけるような、単純なものではありません。
ページではなく旅である 重要な予定があり、約束の場所に向かうため、見知らぬ街を歩いていることを想像してみてください。途中でさまざまな街路や繁華街を通ります。しかしあちこちで、でこぼこした敷石につまずいたり、反応が遅い自動ドアで待たされたり、予想外の工事により迂回を余儀なくされたりして、道に迷ってしまいます。こういった出来事は、すべて皆さんの歩みを遅らせ、ストレスを増加させ、目的地に向かおうという集中力を奪います。
ウェブを使う人も旅をしています。一回一回のアクションが一歩一歩で、それがスムーズに連続しているのが理想です。また、現実世界と同じように、遅延により行動の中断を余儀なくされたり、気が散って誤った操作をしてしまったりします。このような出来事は、満足度の低下、サイトやユーザージャーニーそのものからの離脱につながる可能性があります。
どちらの場合でも、スムーズな旅やユーザーの満足度につながる鍵になるのは、中断や障害物を取り除くことです。
ウェブの世界では、ユーザーはどんなことにつまずいているのでしょうか？
待ち時間による中断 ユーザーが最もよく経験する中断は、ページ読み込みの待ち時間です。デベロッパーの皆さんにとっては、ページ読み込みはページ固有の出来事であり、多少の待ち時間は避けられないと思うかもしれません。しかし、多くの場合、ページ読み込みはユーザージャーニーの 途中 で発生します。たとえば、最新ニュースを読む、新しい製品を調べる、商品を購入するためにカートに追加するときなどです。ユーザーの視点で見れば、特定のページで発生する読み込み時間は自然な中断ではありませんし、ユーザーはまだ目的を果たしてはいないので、待ち時間に対して寛容ではないかもしれません。1 スムーズなユーザージャーニーを実現するため、ページは高速に読み込まれる必要があります。
では、どのくらい速ければよいのでしょうか？これはある意味では不適切な質問です。魔法の数字は出てきません。それには、主に 3 つの理由があります。
まず、この答えは、離脱率やユーザー満足度、実行するタスクの効率など、皆さんが期待する成果によって異なります。研究によって着目する結果が異なり、結論も異なります。
次に、待ち時間による影響は、ユーザーの個性や過去の経験、抱えているタスクの緊急度などによって大きく異なります。2 たとえば、サイトにとどまるユーザー数を、発生している待ち時間の関数としてプロットしても、X 秒後のユーザー数は 100% から 0% のきれいな階段状にはならないでしょう。おそらく、次のようななめらかな分散になるはずです。
待ち時間が大きくなるにつれて残るユーザーの割合が減ることを示したグラフ
つまり、この曲線のどの点をターゲットにするか、ということを問わねばなりません。言い換えれば、どのくらいスピードに投資するか、もしくはどのくらいのユーザーを失うか、ということです。
最後の理由は、待ち時間の影響は状況や状態によって異なるという点です。ユーザージャーニーはニュースサイト、ショッピング サイト、旅行サイトで多くの場合異なりますし、先ほどの曲線の全体像も、それぞれで違うかもしれません。状況は同じでも、時間が経てばサイトのデザインやユーザーの行動が変わってくることもあります。
これは私たちが予想していた以上に難しいことですが、異なるレベルでのパフォーマンス結果の分散から、有用なヒントを得ることが可能です。とりわけ、この分散によって、ある地点でどのくらいの数のユーザーを失う可能性があるか（または、現在失っているか）が明らかになります。さらに、さまざまな点における曲線の傾きからスピードを特定の量だけ改善した場合、どのくらいの成果が得られるかがわかります。こういった点は、トレードオフを決め、判断を下す上で重要な要素になります。ユーザーの時間が貴重なように、デザイナーやエンジニアとしての皆さんの時間も貴重です。
つまり、私たちの目標は、魔法の数字を探すのではなく、実用的な範囲と合理的なガイドラインを調査することにあります。次に例を示します。
  • ある研究から、待ち時間によって満足度や復帰率が下がることがわかっています。なじみのないサイトの場合、2 秒待たされればほとんどのユーザーが離脱します。なじみのあるサイトであれば、完全に離脱するまでの時間はもっと長くなります。なじみのないサイトではタスクの効率も下がり、最大 4 秒待たされればほとんどのユーザーが離脱します。3
  • ウェブページのメニュー階層の移動に関する別の研究もあります。各パネルを読み込む際に、待ち時間の範囲を 3 秒間隔で評価したものです。満足度が低下したのは、待ち時間が 0 秒から 3 秒に増加したときと、9 秒から 12 秒に増加したときでした。12 秒の待ち時間が発生すると、復帰率も低下しました。6 秒の待ち時間でサイトを遅いと見なす参加者もいました。4
  • ある研究によると、モバイルウェブのユーザーが画面に注意を向け続けるのは、一度に 4 秒から 8 秒までという傾向があります。5 つまり、ページが読み込まれる前に注意がそれると、よそ見している時間によって、さらに最終的にページを見るまでの時間が長くなります。そのため、5 秒の読み込み時間が実質的に 10 秒の待ち時間になる可能性もあります。
  • システムの応答速度は、人間同士がやり取りする際に体感する待ち時間と同じくらいにすべきだという提案があります。そこから導き出されるレスポンスは、およそ 1 秒から 4 秒になります。6
これらの研究は、厳密なしきい値から得られたものではありません。そうではなく、ばらつきが大きく、徐々に低下するデータから得られた結果です。それ以外の研究は、理論に基づく予測によるものです。しかし、全体として見れば、読み込み時間を数秒以内に抑えることを目指すべきだという結論になります。
Largest Contentful Paint（LCP）指標は、ページ間ナビゲーションが完了したように見える時間を測定します。私たちの推奨は、サイトのページ読み込みの 75 パーセンタイルで LCP を 2.5 秒未満にすることです。この推奨事項は、Chrome による現在のウェブの分析情報も参考にしつつ、十分な数のサイトで実際に達成できるような実用的なものを目指しています。この分析の詳細については、Core Web Vitals 指標のしきい値定義に関する記事をご覧ください。
不安定さによる中断やエラー ほとんどのウェブページでは、複数の要素を読み込む必要があります。また、多くの場合、読み込みは徐々に行われます。これは、実際にはよいことです。一部のコンテンツができる限り早く表示されれば、ユーザーは読み込みの完了を待たなくても、目的に向かって作業を始めることができるかもしれません。
しかし、ある要素が読み込まれたときに、既に表示されている要素が移動してしまうと、2 つの形でユーザー エクスペリエンスに悪影響が生じる可能性があります。
1 つは、注目している要素が突然移動すると、ユーザーは視覚的にその新しい場所を見つけるために少なくとも数百ミリ秒が必要になることです。7 スクロールしなければ見えない場所に移動してしまった場合は、さらに多くの時間がかかります。このような中断は、ユーザージャーニーを妨げ、ユーザーを苛立たせるかもしれません。
もっと深刻なのは、予期しないレイアウトのずれがエラーにつながる可能性があることです。ユーザーがタップしようとした要素が移動してしまうと、元々の場所に移動してきた別の要素をタップしてしまうかもしれません。ずれを認識してから、操作をやめようとして実際にやめるまでには時間がかかるので、人間がこれに適切に反応するのは 不可能 です。そのため、意図せずにリンクや広告、あるいは「今すぐ購入」ボタンをクリックしてしまい、ユーザーが想定したジャーニーが台無しになってしまう可能性があります。
Cumulative Layout Shift（CLS）は、ページで発生する予期しないレイアウトのずれの頻度や度合いを測ります。ずれが少ないということは、中断やエラーが起こる可能性も減るということです。私たちの推奨は、サイトのページ読み込みの 75 パーセンタイルで CLS を 0.1 未満にすることです。
反応の遅さによる注意力低下やエラー ページ読み込みは、ユーザーにとって大きな遷移で、たとえるなら屋外から建物に入るようなものです。その一方で、小さな一歩一歩に目を向けることも重要です。
歩いているとき、歩行の仕組みなど意識したくはないでしょう。実際に歩いていることは意識せず、別のこと、たとえば道を探すことに集中できるのが理想です。しかし、靴の中に石が入ったりすると、その集中が途切れてしまいます。
ウェブ上でも同じように、インタラクションの際の細かなストレスによって、ユーザー エクスペリエンスを損なうことは避けたいでしょう。反応の遅さに関連した研究をいくつか紹介します。
  • ある研究から、タッチ スクリーンのボタンで視覚的なフィードバックの遅れが 70 ミリ秒から 100 ミリ秒に増加すると、ユーザーがその遅れに気づくことがわかっています。さらに、遅れが 100 ミリ秒から 150 ミリ秒に増加すると、ボタンの質が非常に悪いと評価するようになります。8
  • ある実験から、1 つのイベントが別のイベントを起こすように錯覚させるアニメーションでは、およそ 100 ミリ秒の遅れがあると、その錯覚が失われることがわかっています。9 同様に、ユーザー インターフェースを直接操作しているように錯覚させる場合も、これより長い遅れが生じると、錯覚が失われると考えられています。10 （この指標は、操作は 100 ミリ秒から 200 ミリ秒以内に視覚効果を表示するべきだという先ほどの推測的推奨事項も参考にしていると思われます11）
LCP と同じく、これにも「魔法の数字」はありません。分散を表すマーカーがあるだけです。敏感さには個人差もあります。12 また、触覚や聴覚によるフィードバックも踏まえると、短い遅れでも気づかれやすくなる可能性があります。13
ユーザーがほぼ瞬時に応答が返ってくると期待している場合、反応に時間がかかると、UI への印象が変わるだけでなく、操作ミスにつながる可能性もあります。動作しないと思い込んで操作を繰り返し、2 回目の操作が思わぬ結果につながるかもしれません。たとえば、「カートに追加」ボタンを 2 回クリックしてしまい、2 つの商品を購入しそうになっていることに気づいていないかもしれません。
応答性はこのような体験と関連があります。応答性の計測は First Input Delay（FID）で行います。私たちは、サイトのページ読み込みの 75 パーセンタイルで 100 ミリ秒未満の FID を目指すことを推奨しています。
インパクト 私たちは、これらの指標やしきい値がどのようにユーザーに影響するかを理解するため、膨大なページ インプレッションを分析しました。そこから、これらのしきい値を満たしているサイトでは、ページ読み込みをやめる（読み込みが完了する前にページを離れる）ユーザーが 24% 少なくなることがわかりました。
また、ビジネスがトラフィックやタスクの完了に依存している、ニュースサイトやショッピング サイトに注目した場合も、同じような数値が出ています。具体的には、離脱率がニュースサイトでは 22%、ショッピング サイトでは 24% 低下しています。オンライン ビジネスでこのレベルの改善を行える方法はほとんどありません。このような結果は、私たちや私たちのエコシステムのパートナーが Web Vitals 指標を最優先にしている理由の 1 つです。
スムーズなユーザージャーニーを提供することは、オンライン トラフィックやウェブベースのビジネスを効率的に拡大する方法の 1 つです。Web Vitals の指標やしきい値が、パブリッシャーやデベロッパー、ビジネス オーナーにとって、明確かつ実施可能な手段になることを期待しています。多くのユーザーが、高速で中断のない旅を続けられるようなサイトの構築に役立てていただければ幸いです。
スタッフ インタラクション デザイナー、Amar Sagoo
ソフトウェア エンジニア、Annie Sullivan
プロダクト マネージャー、Vivek Sekhar
1 Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
2 Shneiderman, B. (1984). Response Time and Display Rate in Human Performance with Computers. ACM Computing Surveys (CSUR), 16(3), 265–285.
3 Galletta, D. F., Henry, R., McCoy, S. & Polak, P. (2004). Web Site Delays: How Tolerant are Users? Journal of the Association for Information Systems, 5(1), 1.
4 Hoxmeier, J. A. & DiCesare, C. (2000). System Response Time and User Satisfaction: An Experimental Study of Browser-based Applications. AMCIS 2000 Proceedings, 347.
5 Oulasvirta, A., Tamminen, S., Roto, V. & Kuorelahti, J. (2005). Interaction in 4-Second Bursts: The Fragmented Nature of Attentional Resources in Mobile HCI. In Proceedings of the SIGCHI conference on Human factors in computing systems (pp. 919–928).
6 Card, S. K., Robertson, G. G., & Mackinlay, J. D. (1991). The information visualizer, an information workspace. In Proceedings of the SIGCHI Conference on Human factors in computing systems (pp. 181-186).
Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
7 Purves D., Augustine G. J., Fitzpatrick D., et al. (2001). Types of Eye Movements and Their Functions. Neuroscience (2nd edition).
8 Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.
9 Card, S. K. (Ed.). (2018). The psychology of human-computer interaction. Crc Press.
10 Nielsen, J. (1993). Response Times: The 3 Important Limits. Nielsen Norman Group.
11 Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proceedings of the December 9-11, 1968, fall joint computer conference, part I (pp. 267–277).
12 Jota, R., Ng, A., Dietz, P., & Wigdor, D. (2013, April). How fast is fast enough? a study of the effects of latency in direct-touch pointing tasks. In Proceedings of the sigchi conference on human factors in computing systems (pp. 2291-2300).
13 Kaaresoja, T., Brewster, S., & Lantz, V. (2014). Towards the Temporally Perfect Virtual Button: Touch-Feedback Simultaneity and Perceived Quality in Mobile Touchscreen Press Interactions. ACM Transactions on Applied Perception (TAP), 11(2), 1–25.

Reviewed by Shunya Shishido - Web Ecosystem Consultant, gTech

この記事は ウェブ パフォーマンス エンジニア、Ilya Grigorik による Chromium Blog の記事 "Introducing Web Vitals: essential metrics for a healthy site" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。



ユーザー エクスペリエンスの質の最適化は、ウェブのあらゆるサイトにとっての長期的な成功の秘訣です。私たちは、たくさんのウェブ デベロッパーやサイトオーナーと連携を続け、Google のあらゆる場所で多くの便利な指標やツールを作成してきました。これは、ビジネス オーナー、マーケティング担当者、デベロッパーなどが等しくユーザー エクスペリエンスを改善する機会を特定できるようにするためです。しかし、たくさんの指標やツールが存在することで、優先度や明確さ、整合性の面で課題が生まれていることも事実です。
本日は、Google が手掛ける新たなプログラム Web Vitals について紹介します。これは、ウェブで優れたユーザー エクスペリエンスを実現するために重要と思われる品質シグナルの統合ガイドを提供する取り組みです。


Core Web Vitals

ユーザー エクスペリエンスの質の測定には、多くの側面があります。そのほとんどはサイトやコンテキストに固有のものですが、すべてのウェブ エクスペリエンスにとって重要な共通シグナル、つまり「Core Web Vitals」が存在します。このようなユーザー エクスペリエンスの核となるニーズには、読み込み時間、インタラクティブ性、ページ コンテンツの視覚的な安定性などが含まれ、これらを組み合わせたものが 2020 Core Web Vitals の土台になります。

  • Largest Contentful Paint は、ユーザーがページで最も有意義なコンテンツをどのくらい早く見ることができるかを表します。感覚的な読み込みスピードを測定し、ページ読み込みタイムラインにおいてページの主要コンテンツが読み込まれたと思われるタイミングを指します。
  • First Input Delay は、最初の入力までの遅延を表します。応答性を測定して、ユーザーが最初にページを操作しようとする場合に感じるエクスペリエンスを定量化します。
  • Cumulative Layout Shift は、ページがどのくらい安定しているように感じられるかを表します。視覚的な安定性を測定し、表示されるページ コンテンツにおける予期しないレイアウトのずれの量を定量化します。
これらの指標はすべて、ユーザー中心の指標であり、フィールド計測可能で、同等の補助的なラボ診断指標やツールも存在します。たとえば、Largest Contentful Paint はトップラインの読み込み指標ですが、最初のコンテンツの描画を表す First Contentful Paint（FCP）や、最初のバイトを受け取るまでの時間を表す Time to First Byte（TTFB）にも大きく依存します。これらをあわせて監視して改善することも重要です。


Core Web Vitals の測定

私たちは、Core Web Vitals をすべてのサイトオーナーやデベロッパーにとってシンプルで使いやすく、測定しやすいものにすることを目指しています。この点は、Google のインターフェースにも、皆さん独自のダッシュボードやツールにも当てはまります。

サイトオーナーの皆さんは、Chrome UX Report で自分のサイトのそれぞれの Web Vitals のパフォーマンスを簡単に評価できます。すべての Core Web Vitals のヒストグラムは、既に BigQuery データセットとして一般公開されています。また、URL レベルとオリジンの両方のデータに簡単にアクセスするための新しい REST API も準備しているところですので、ご期待ください。

すべてのサイトオーナーの皆さんに、Core Web Vitals の実際のユーザーの測定値を収集してみることを強くお勧めします。これを実現するために、Google Chrome を始めとするいくつかのブラウザで、現在 Core Web Vitals のドラフト仕様である Largest Contentful Paint、Layout Instability、Event Timing が実装されました。また、オープンソース JavaScript ライブラリである web-vitals もリリースします。これは、カスタム指標をサポートする任意のアナリティクス プロバイダで利用することができ、また Core Web Vitals をそれぞれ正確に取得する方法を示すリファレンス実装として使うこともできます。


// web-vitals を使って CLS、FID、LCP を測定、レポートする例

import {getCLS, getFID, getLCP} from 'web-vitals';


function reportToAnalytics(data) {

  const body = JSON.stringify(data);

  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||

      fetch('/analytics', {body, method: 'POST', keepalive: true});

}


getCLS((metric) => reportToAnalytics({cls: metric.value}));

getFID((metric) => reportToAnalytics({fid: metric.value}));

getLCP((metric) => reportToAnalytics({lcp: metric.value}));


私たちはテストや開発の過程で、Core Web Vitals のそれぞれの状態に簡単にアクセスできれば非常に有益であると気づきました。これは、開発作業中にもウェブの閲覧中にも当てはまります。そこで、デベロッパーの皆さんが最適化を行うチャンスを見つけやすくなるように、Core Web Vitals の Chrome 拡張機能のデベロッパー プレビュー版もリリースします。この拡張機能を導入してウェブを閲覧すると、それぞれの Vitals の状態についてのインジケーターが Chrome に表示されます。将来的には、現在の URL とオリジンのそれぞれの Core Vitals の状態について、実際のユーザーからの集計結果（Chrome UX Report が提供するもの）も表示できるようにしたいと考えています。


さらに、今後数か月間で Lighthouse、Chrome DevTools、PageSpeed Insights、Search Console のスピード レポートなどの多くのユーザーに利用されているツールをアップデートし、Core Web Vitals を改善するためのアクションにつながる一貫したガイドを提供できるようにする予定です。


進化する Core Web Vitals

現在の Core Web Vitals で利用している 3 つの指標は、ウェブのユーザー エクスペリエンスを測る重要な要素ではありますが、ユーザー エクスペリエンスはそれ以外の側面も多く関係してきます。従って Core Web Vitals は今後も毎年アップデートする予定です。また、今後の指標の候補、目的、実装状況についても、定期的なアップデート行います。 

2021 年に向けて、ページのスピードを含む重要なユーザー エクスペリエンス特性について理解を深め、それを測定する機能の構築を進めています。たとえば、最初のインタラクションだけでなく、すべてのインタラクションの入力の遅延を測定するように機能を拡張することを考えています。また、スムーズさを定量化する新しい指標の作成や、ウェブ上でプライバシーを保護しつつ瞬間的にコンテンツを配信できるようにする方法なども検討しています。

Core Web Vitals やウェブ全般に関する今後の最新情報にアクセスしたい方は、web.dev の最新情報をフォローし、メーリング リストをサブスクライブしてください。


ウェブ パフォーマンス エンジニア、Ilya Grigorik

Reviewed by Yusuke Utsunomiya - Web Ecosystem Consultant, gTech