Core Web Vitals
Core Web Vitalsとは
- ユーザー体験を測定する一連の指標
- 良いユーザー体験を提供するためのGoogleが取り組んでいるガイダンス
- Core Web VitalsはSEOにも影響する
LCP - Largest Contentful Paint
ビューポート内に表示される一番大きいコンテンツ（画像、テキストロック、動画）のレンダリングにどれだけ時間がかかるか
CLS - Cumulative Layout Shift
レイアウトのズレや崩れを数値化したもの
レイアウトのズレや崩れとして・・・
- 突然バナーが出現して推したいボタンが押せない
- 画像に
heightを設定していない場合、画像が表示されると画像の高さ分、レイアウトが下にずれ、意図しないボタンを押してしまう
FID - First Input Delay
ユーザーが最初にページを操作（リンクのクリック、ボタンのタップなど）してから、イベント ハンドラの処理を開始するまでの時間
レンダリングパターン
なぜCSRが生まれたか？
- サーバーでデータを取得してそれをサーバー上でレンダリングし、それをブラウザに配信していた（PHPやPerl）
- ブラウザはサーバーで生成されたHTMLを表示するだけで、インタラクティブではなかった
- JavaScriptの改善とブラウザ性能が向上したことで、最小限のHTMLとJSでクライアント側で全て行うようになる
- WebがよりインタラクティブになったことでSPAが広まった
CSRの問題点
WEBでできることが増えすぎたことで、Javascriptのバンドルサイズが肥大化し、ユーザーの環境（デバイスや通信環境）によっては表示が遅くなった
環境によって初回のバンドルファイルのダウンロードに時間がかかりUXが最悪（初回表示速度はバンドルサイズに依存する）
どのユーザーにも同じように同じようにコンテンツを配信するには、SSRに戻すのが良いよねってなった
SSRでCSRの問題を解決する
SSRの流れ
- クライアントからリククエスト
- リクエストを受け取ったサーバーは文字列のHTMLを生成し、クライアントに返却
- 受け取った文字列HTMLにイベントハンドラをアタッチして、生きた仮想DOMとして再開させる（ハイドレーション）
SSRにするとCSRに比べてどうなるのか？
- 初回のレスポンスはサーバーでレンダリングするので少し遅くなる
- 最初の要素が表示される時間は多少早くなる
- 大きい要素の表示も早くなる
- FIDは逆に悪くなってしまう可能性がある
参考