Core Web Vitals：サイトを本当に速くする

「自分の環境では快適」では足りない

よくある罠：開発者は光回線、最新の MacBook、温まったキャッシュでテストする。一方、実際のユーザーは中位機種のスマホ、気まぐれな 4G、空のキャッシュでやって来る。両者の体験には、何の共通点もありません。

Core Web Vitals は、ユーザーが実際に体験しているものを測るために存在します。Google はこれをランキング要因にし——そして何より、コンバージョンを予測します。読み込みが 1 秒延びるごとに、訪問者は離れていきます。

大切な 3 つの指標

• LCP（Largest Contentful Paint） — 主要な要素（多くはヒーロー画像や見出し）が表示されるまでの時間。目標：2.5 秒未満。
• INP（Interaction to Next Paint） — 反応性：クリックから目に見える反応までの遅延。目標：200 ミリ秒未満。JavaScript の多いサイトでは、ここが勝負どころです。
• CLS（Cumulative Layout Shift） — 安定性：画像や広告が読み込まれた時に、思わぬ場所をクリックさせてしまうレイアウトのズレ。目標：0.1 未満。

美しくて遅いサイトは、失敗したサイトです。パフォーマンスはデザインの敵ではありません——明快な選択を迫る制約です。

私が使う手立て

サイトを速くするのに魔法はありません。判断の積み重ねです。

• 画像 — モダンなフォーマット（AVIF/WebP）、適切な寸法、ファーストビュー外の lazy loading、そしてズレ（CLS）を防ぐための場所の確保。
• フォント — font-display: swap、実際に使う字体だけを先読み、そして何より、それだけを読み込むこと。
• JavaScript — 送り出す量を可能な限り少なく。最も速いコードは、ブラウザに送らないコードです。サーバーコンポーネント、重要でないものの遅延読み込み。
• レンダリング — 内容が許すなら静的（ビルド時に生成済み）を優先。すでに用意されたファイルに勝るものはありません。
• 継続的な計測 — パフォーマンス予算と監視（Lighthouse、Speed Insights）で、リグレッションを本番の後ではなく前に見つける。

ラボではなく、フィールドで測る

測り方は二つあります。ラボデータ（Lighthouse、制御された環境）と、フィールドデータ（実ユーザー、Chrome UX Report 経由）。どちらも有用ですが、現実を映すのは後者だけです。ラボで 100 点でも、遅い回線や控えめな端末のせいで、フィールドでは期待外れになることがあります。

私の規律：速くするためにラボで最適化し、しかし勝利を宣言する前にフィールドで検証する。

それがクライアントにとってなぜ重要か

速いサイトは、技術者の気取りではありません。留まる訪問者が増え、Google での順位が上がり、コンバージョンが増える。速さは、ユーザーと順位と売上に同時に効く、数少ない改善の一つです。だから私はそれを、ボーナスではなく要件として扱います。