Streaming UIプラクティス

アプリケーションユーザーにとってパフォーマンスとは、特定の指標に基づいて判断される定量的なものだけでなく、アプリケーションの総合的な体験を通じて感じる定性的なものでもあります。そのため、ユーザーがアプリケーションを「遅い」と感じる要因は様々です。

Googleは以前より、ユーザー中心のパフォーマンスを提唱しています。Core Web Vitalsは、ユーザーが感じるパフォーマンスを定量的に計測するために作成された指標群で、現在最も重要なパフォーマンス指標の一つです。しかし、Core Web Vitalsだけではパフォーマンスに関するUXの全てを網羅できるわけではありません。Core Web Vitalsの改善は重要ですが、最終的にはUX全体を最適化することが必要です。

本稿では、ページ読み込み時に「遅い」という印象をユーザーに与えないために筆者がよく用いるStreaming UIとそのプラクティスについて、UXの観点から解説します。

本稿はUX観点でのプラクティスを解説するものであり、技術的な実現方法を解説するものではありません。

要約

1. 早期のレイアウト表示
2. 動的UI要素の並行読み込み
3. ローダーやスケルトンUIは遅い時のみ
4. Fade-inアニメーションの活用

前提

Streaming UIを採用するにあたり、以下の考え方を前提としています。

SEOとJavaScript

Streaming UIの実現には、多くの場合JavaScriptによるクライアントサイドでの処理が伴います。コンテンツ表示にJavaScriptが必須となることについて、SEOへの影響を懸念される方もいるかもしれません。

かつて、JavaScriptに依存するコンテンツとSEOの関係については様々な議論がありましたが、Vercelが2024年に公開した調査によると、近年ではGoogleによるJavaScriptの処理能力が向上し、SEOへの影響は以前ほど大きくないことが示唆されています。

詳細については以下の記事をご参照ください。非常に興味深い結果が報告されています。

https://vercel.com/blog/how-google-handles-javascript-throughout-the-indexing-process

解説

Streaming UIとは、UI要素が段階的に読み込まれ、徐々に表示されていくようなユーザー体験（UX）を指します。これは、ユーザーに「読み込みが遅い」と感じさせないための有効なテクニックです。

引用: Next.js公式ドキュメント

ただし、Streaming UIによってユーザー体験を向上させるためには、いくつかの配慮と工夫が必要です。

1. 早期のレイアウト表示

アプリケーションはユーザーの操作に対して、可能な限り速やかにフィードバックを返すことがUX観点で望ましいとされています。Streaming UIは、ユーザーへのフィードバックを段階的に行うことで、ページ遷移時などに早期のフィードバックが実現できます。

具体的には、ページの基本的なレイアウトをできるだけ早く表示することで、ユーザーに対する無応答時間を短縮できます。

例

以下は、早期にレイアウトを表示し、少し遅れて記事一覧が表示される例です。

レイアウトを構成するUI要素は、静的なコンテンツやキャッシュ可能なデータを中心にすることで、より迅速な表示が可能となります。

注意点

ページ読み込み中にレイアウトが大きく変動すると、操作性が損なわれ、ユーザーに不快感を与えます。これはCore Web VitalsにおけるCumulative Layout Shift (CLS)という指標で計測可能です。Lighthouseなどのツールを利用してCLSを最小限に抑えることを心がけましょう。

2. 動的UI要素の並行読み込み

Streaming UIに限らず、データ取得処理の並行性はパフォーマンス上重要です。

引用: Next.js公式ドキュメント

Streaming UIを設計する際は、静的なUI要素を初期レイアウトに含めつつ、データの取得が必要となる動的なUI要素は、並行して読み込まれるよう設計しましょう。

一般的に、クライアントサイドからのデータ取得は低速になりがちなため、データ取得を多数行うことは好ましくありません。筆者はサーバー間通信を推奨しますが、クライアントサイドからデータ取得せざるを得ない場合には、慎重にトレードオフを検証しましょう。

例

以下は、記事一覧とログイン状態を示すユーザーアバターが並行して読み込まれ、段階的に表示される例です。この例ではアバターが少し遅れて表示されています。

注意点

UX上各要素が並行して読み込まれているように見えるだけでなく、実際のデータ取得処理も並行で行われるよう実装する必要があるので、注意しましょう。

3. ローダーやスケルトンUIは遅い時のみ

コンテンツの読み込みに時間がかかる場合はローダーやスケルトンUIを用いて、ユーザーに対し読み込み中であることを伝えましょう。

例

以下は、記事の読み込みに時間がかかっている場合にスケルトンUIを表示する例です。

記事カードの高さが事前に分かっている場合、スケルトンUIも同じ高さにすることで、コンテンツ表示時のレイアウトシフトを防ぐことができます。

注意点

ローダーやスケルトンUIは、読み込みが速い場合に表示されるとかえって画面がチラついて見える原因となり、ユーザーに不快感を与える可能性があります。そのため、筆者は読み込み速度に応じて以下のような基準でこれらのUI使用を判断しています。

UI要素の表示速度	ローダー・スケルトンUIの要否
安定して速い	不要
安定して遅い	必要
不安定（遅い場合がある）	遅い時のみ表示

「速い」「遅い」の判断は主観的な側面もありますが、筆者の場合、レイアウトの表示から500ms近くかかるようであれば「遅い」と判断します。

4. Fade-inアニメーションの活用

遅れて表示されるコンテンツには、Fade-inアニメーションを適用しましょう。Fade-inアニメーションは、Streaming UIで起こりがちなUI要素の唐突な出現によるちらつきを抑え、ユーザーが感じる違和感を軽減する効果が期待できます。

例

以下は、記事一覧が読み込まれる際にFade-inアニメーションを適用した例です。この例では記事一覧の読み込みが安定して速いため、スケルトンUIは表示されていません。

アニメーションGIFでは伝わりにくいかもしれませんが、Fade-inアニメーションを用いることで、レイアウトと記事一覧がほとんど同時に読み込まれたかのような体験になります。

まとめ

パフォーマンスは、ユーザーにとってアプリケーションが備えていて当然の当たり前品質であり、これが損なわれるとユーザーは不快感を抱きます。

Core Web Vitalsのような定量的な指標を用いてパフォーマンスを計測し、改善していくことは非常に重要ですが、同様に、UXの工夫によってユーザーのパフォーマンス体験を改善することも非常に重要です。

本稿で紹介したプラクティス以外にも筆者が意識できてない、もしくは言語化できてないプラクティスが様々あると思います。今後もユーザーのパフォーマンス体験をより良いものにすべく、精進したいと思います。