概要

Google Developersが提供するwebサイトのパフォーマンス分析ツールweb.devでは、Web VitalsというWebの閲覧において優れたUXを提供するための指標が定義されています。

Webのパフォーマンスを測るツールは、web.devの他にLighthouseやChrome DevToolsなどいくつかありますが、Web Vitalsを参考にすればこれらの数値は改善されるらしい。2020年時点のWeb Vitalsは、WebのUXの観点から読み込み、インタラクティブ性、視覚的安定性を重要視している。

Web VitalsにおけるMetrics

ここからはWebVitalsのMetricsの要約などを書きます。

Largest Contentful Paint (LCP)

HTMLドキュメントからページの読み込みが開始されてから、<img>,<svg>,<video>などのうち、最大のコンテンツが表示されるまでの時間。優れたUXのためには2.5秒以内に表示が完了されることが推奨される。

重い画像などがロードを妨げているようであれば、それの最適化が重要そうです。

First Input Delay (FID)

ユーザーが最初にページを操作した時に、ブラウザが応答できるまでの時間。優れたUXのためには遅延が100ミリ秒未満であることが推奨される。

画面にコンテンツが表示されていてもなおメインスレッドの処理があれば、ユーザーの入力への応答に遅延が発生します。これを防ぐことがスコアの改善になりそうです。

Cumulative Layout Shift (CLS)

リソースが非同期で読み込まれたり、DOM Elemenrtが動的に追加されたりした際に発生する、予期せぬレイアウト変更をスコアにしたもの。優れたUXのためにはCLSの指標が0.1未満であることが推奨される。

webロード後や閲覧中にDOMを操作するようなwebサイトはCLSのスコアが高くなってしまいそう。

Lighthouseのパフォーマンス計測におけるMetrics

LighthouseのMetricsを中心に知っておこう。

First Contentful Paint (FCP)

ブラウザがDOMのコンテンツをレンダリングするまでの時間。これを改善するには、リソースのダウンロードを早くするか、DOMレンダリングのブロックを減らす。

First Contentful Paint | Tools for Web Developers | Google Developers

First Meaningful Paint (FMP)

ヒーロー要素がどのタイミングでユーザーに見えるか。スクロールせずに見えるコンテンツが表示されるまでの時間。ちなみにchromeのdeveloperツールでは、iframe内のコンテンツが表示された時、FMPは計測する一方FCPはiframe内のコンテンツが表示されても計測しない。Largest Contentful Paintを改善する方法と同じく、サーバーレスポンス、CSSブロッキング、アセットのロードを最適化する。

First Meaningful Paint

Speed Index

視覚的に表示される速度のこと。LighthouseやChrome DevToolsは、ブラウザが表示するまでの過程をキャプチャしていて、この時の視覚的な進行をスコアにしたものらしい。

Speed Index

First CPU Idle

ページが最小限応答できる状態になるまでの時間。

現在この指標は非推奨。Total Blocking Time (TBT)や、Time To Interactive(TTI)を使用するべきらしい。

First CPU Idle

Time To Interactive

Webページが完全にインタラクティブになるまでの時間。

インタラクティブ性を犠牲にしてリソースのロードに時間がかかっていたりすると、ユーザーに不満を与えることになり、UXを損なうことになる。

ここでいうインタラクティブな状態というのは、Web ページのリソースのロードや Long Tasks が一通り落ち着いて、RAIL(Response / Animation / Idle / Load) モデルにおける Idle の要件を満たす状態。(50ms以上のタスクが無い状態)

Time to Interactive

User-centric performance metrics

Max Potential First Input Delay

これはWeb VitalsのFirst Input Delay (FID）とほぼ同じものである。

WebのUXに関して思うこと

ここからはWeb Vitals自体と関係なく僕が思うことを書きます。

web.devはGoogle Developers公式のwebサイトであり、Webの仕組みや気にするべき指標を知るうえで本当に勉強になります。🙏

Webにおけるユーザーインターフェースの指標を測る取り組みとして、現在のWeb Vitalsでは読み込みの速度、インタラクティブ性、視覚的安定性を重視しているようです。

UXを損ねるものの例

Web Vitalsの指標を元に、UXを損ないそうなあるあるを適当に挙げてみる。

バックエンド

クソクエリなどで処理が長い
画像リソースが最適化されていない(サイズが大きすぎるなど)
多くのリソースを扱うのにHTTP/1.1
ロードバランシングなど負荷の分散が不十分

クライアント側

webフォントの読み込みに時間がかかっている。
過度に広告タグを貼っている
記事のレコメンド機能をたくさんつけている
ロード後にアニメーションとかが始まる
ユーザーのスクロール制御している
過度なパララックスを使用している
JavaScriptがメインスレッドを占有している
DOM操作でレイアウトが変わる

Webのユーザーインターフェース

Webの「UI」というとさまざまな解釈があり、狭義にWebサービスのレイアウトなどの見た目をイメージしてしまうことが多いですが、もっと広い領域です。Webと人間との間のインターフェースですから、レイアウトなど視覚的な領域もUIだし、ユーザーへのレスポンスの速さに関わるコンピューティングもUIと考えることができます。

例えばユーザーを待たせてしまうWebのUIを改善するとします。適切なローディングアニメーションで待ち時間を短く感じさせる方法や、バックエンドを改善してしてレスポンスの速さを向上させる方法もあります。この2つの方法どちらもUIの改善になりうるものです。

WebはもともとHTML文書を相互に公開・閲覧するためのシステムだったけど、なにかと処理を行うことで、コンテンツをかっこよく動かして魅力的に見せたり、Webサービス・アプリケーションを提供したりできるようになりました。

何か工夫をしたリッチな表現をしたい時もあるかもしれませんが、WebのUIを考えるときは、「ユーザーは情報を知りたいだけで、インタースティシャル広告のように主張して表示されるロゴマークを知る必要はないし、アニメーションを眺める必要はないかもしれない」ということを頭の片隅に置いておく必要があると思います。💡

ユーザーがスマホやPCを操作し、自分の意思でどんどん情報を得ている時の自己帰属感がWebの体験だとしたら、Webの「UI」はこの体験を損なわないための、読み込みの速度と、インタラクティブ性の維持が大事です。Web VitalsはこのようなWebの体験を優先して、Largest Contentful Paint (LCP), First Input Delay (FID), Cumulative Layout Shift (CLS)を最も重要な指標として定義しているのだと思います。そしてこれらの指標を理解して改善することが、WebのUXを考えることになりそう。

リンク

web.devの情報は本当に参考になりました。
Web Vitals

Next.jsは静的サイト生成やサーバサイドレンダリングなどができるフレームワーク。バージョン9.4でWeb Vitalsのレポートをサポートした。正直Web Vitalsをこれで知った。
Next.js 9.4

「自己帰属感」というキーワードを軸にインターフェイスとは何かについて書いてある本。おもしろいです。
融けるデザイン ―ハード×ソフト×ネット時代の新たな設計論
 融けるデザイン2020 #1｜渡邊恵太｜note

(この記事はわたしのブログから修正して投稿した内容です。)