2026年のCORE WEB VITALS

2026年のパフォーマンス施策は2つのキャンプに分かれます。リアクティブキャンプは、個々のページが閾値を下回ったら調整を加えます。ストラクチャルキャンプは、フレームワークの選択、デザインシステム、デプロイメントパイプライン、コンテンツの規律にパフォーマンスを組み込むため、パフォーマンスが作業のデフォルト成果となり、後で行う最適化パスではありません。長期的に成功したすべてのサイトはストラクチャルキャンプに属しています。

このガイドはストラクチャルなビューです。出荷したサイトからの具体的な数値、実際に実行するチェック、犯した最も高額なミス、実運用では間違っていることが判明した従来のアドバイスの一部です。CrUXのフィールドデータは常にPageSpeed Insightsのラボデータを上回るため、以下のほとんどの数値は75パーセンタイルの実ユーザーからのものです。

LCP (Largest Contentful Paint)

最大のアバブザフォールド要素がレンダリングされるまでの時間。目標：75パーセンタイルで2.5秒未満。最も引用されるCore Web Vitalで、LCP要素を正しく特定できればほぼ最も修正しやすい指標です。ほとんどのサイトではLCP要素として画像またはヒーロテキストブロックを持っており、修正はほぼ常に、画像の事前読み込み、適切なサイジング、JavaScriptがレンダリングをブロックしないことの確認です。

CLS（累積レイアウト変動）

ページ読み込み中に予期しないコンテンツシフトがどのくらい発生するか。目標：0.1未満。遅延読み込み画像に明示的な幅と高さがない場合、最初のレンダリング後に挿入される広告、またはフォールバックと異なるメトリクスを持つウェブフォントの置き換えにより最も頻繁に破損する指標です。アバブザフォール上のすべてのビジュアル要素に対する明示的な寸法に規律を持つことで、ほとんどの場合解決できます。

INP（インタラクションから次のペイントまで）

ページのライフタイム中に経験された最も遅いインタラクション時間。目標：200ms未満。2024年3月にFIDに置き換わりました。実際のユーザーがJavaScriptの長時間実行タスクで感じるフリクションを表面化するため、最も操作しにくいCWV指標です。クライアント側JavaScript が重いサイトはほぼ常にここで苦労します。修正は、JavaScriptの削減、長時間タスクのより小さいチャンクへの分割、緊急でない作業へのrequestIdleCallbackの使用です。

TTFB（最初のバイトまでの時間）

レンダリングが開始される前のサーバー応答時間。目標：600ms未満。公式にはCore Web Vitalではありませんが、他のすべての指標に上限を設定します。CDN上の静的レンダリングサイトは通常50～150msに達します。共有ホスティング上のWordPressはコールドキャッシュで800ms～2.5sに達します。ホスティングの決定がTTFBの最大のレバーです。

重要なポイント：「実際にランキングを左右する4つのメトリクス」を運用上の決定として捉えること。ツーリングは所有権が誠実である場合にのみ機能する。

ラボデータは、1つの場所で1つのマシンが制御された条件下のある時点で測定した内容を示します。フィールドデータは、規模でリアルユーザーが経験した内容を示します。この2つはほとんどのサイトで大きく異なり、Googleがランキング信号に使用するのはフィールドデータです。まずフィールドデータを、次にラボデータを最適化してください。

フィールドデータを読む場所

Search Console の Core Web Vitals レポート。BigQuery 上の CrUX データセットは生のイベントレベルデータが必要な場合。PageSpeed Insights の Field Data セクション（URL に十分な実ユーザーデータが存在する場合）。Calibre、SpeedCurve、Treo は有料ユーザー向けに CrUX 上にエンリッチされたダッシュボードを提供。Vercel Analytics や Cloudflare Web Analytics などの RUM ツール（Real User Monitoring）はさらに細かいレベルの詳細度を追加。

ラボデータを読む場所

PageSpeed Insights の Lab Data セクション。Chrome DevTools の Lighthouse。WebPageTest は詳細なウォーターフォール分析用。フィールドメトリクスの回帰の理由を診断するのに有用で、それを測定するためではない。

実行する診断フロー

Search Console でのフィールドメトリクスの回帰。影響を受けた URL パターンを特定。3 つの場所から WebPageTest 経由でラボテストを実行して再現。ウォーターフォールを検査して問題のあるリクエストを特定。パッチを適用。CrUX フィールドデータが更新されるまで 28 日間待機。修正を確認。

私が最も頻繁にデプロイするプラットフォームのフィールドデータの 75 パーセンタイルで観測した実際の LCP 数値：

Static-rendered Astro on Netlify or Cloudflare Pages

LCP は通常 0.6～1.0 秒。4 つのメトリクスすべてで Lighthouse 100 がデフォルトの結果。初期 JavaScript は 30KB 以下。コンテンツサイトにおいて最も高い難易度。

Static-rendered Next.js (App Router with RSC, SSG mode)

LCP は 1.0～1.5 秒。初期 JavaScript は、クライアントコンポーネントの数によって 80～150KB。Lighthouse 90 以上は達成可能だが、意図的な最適化が必要。

ISR または SSR の Next.js

LCP は 2～2.5 秒、キャッシュヒット率とオリジンレスポンスタイムによる。キャッシュミスのコールドスタートは 3～5 秒。優れたテクノロジーだが、実際のコスト曲線と実際のパフォーマンスばらつきがある。

Kinsta または WP Engine 上の WordPress + Cloudflare

LCP は一般的に 1.8～2.8 秒。規律を持てば CWV 閾値をクリアすることは十分可能。このスタックで運用しているサイトは、最適化パスの後、75 パーセンタイルで一貫して CWV に合格している。

共有ホスティング上の WordPress

LCP は 3.5 秒以上。パフォーマンスが要件の一部であるサイトは避けるべき。

マーケティングページの約70%では、画像がLCP要素になっています。画像の最適化は、私が知っている中で最も高い効果を持つパフォーマンス改善の手段です。

フォーマットと圧縮

WebP品質82は、視覚的品質とファイルサイズのバランスが最適です。AVIFはより小さいですが、エンコーディングが遅く、ブラウザサポートに微妙なギャップがあります。ソースの真実となるオリジナル以外のあらゆる画像でJPEGとPNGをスキップしてください。WebP q=82は通常、ソースPNGより70～90%小さいファイルを知覚損失なく生成します。

実際にレンダリングされるサイズにリサイズ

4K JPEGを幅1200ピクセルでレンダリングするのは帯域幅の90%無駄です。常に画像がレンダリングされる最大サイズにリサイズし、高密度ディスプレイ向けに2xまたは3xバージョンを用意してください。SharpはこれをあらゆるNode.js build pipelineで約5行のコードで実現できます。

FAL hero pipeline

オートブログpipelineからFAL flux-pro/v1.1-ultraとImagen 4で直接hero画像を生成しています。生成された画像は600KB～1.5MBのJPEG（1200x675）です。Supabase Storageに生で大量アップロードすると、すべてのページはheroだけで約1MBを配信することになります。ストレージアップロード前にsharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer()を通します。ファイルサイズを90%削減でき、知覚損失はありません。単一のSeahawkサイトでこのpipelineを適用後、53個のhero画像全体で50MB削減されました。ストレージアップロード時にcacheControl: 31536000も設定してください。

すべてのimg要素に明示的なwidthとheight

ブラウザは、HTMLにwidthとheightが存在する場合のみ、画像ロード前にスペースを予約します。これらがないと、画像ロード時にレイアウトシフトが発生し、CLSが上昇します。AstroとNext.js Image componentは自動で処理しますが、生のimg タグは手動が必要です。

LCP画像プリロード

ファーストビュー内のhero画像は、headでlink rel="preload" as="image"でプリロードされるべきです。通常100～400ms短縮されます。ほとんどのマーケティングサイトで利用可能な最も影響力の高い1行の変更です。

JavaScriptは、ほとんどの現代的なサイトにおいて最大のパフォーマンス上の課題です。2026年に私が目標としているバジェットは以下の通りです：

コンテンツサイトにおける初期JavaScriptは100KB未満

100KB以下であれば、フレームワーク、サイト、分析タグやマーケティングピクセルを組み合わせても、ミッドレンジのモバイルデバイスで高速に解析・実行できます。100KBを超えると、デスクトップ開発者が高速ノートパソコンでテストしていても目に見えない形でINPやTTIに影響が出ます。

ファーストビュー以外はすべて遅延読み込みする

分析タグ、ソーシャルピクセル、チャットウィジェット、A/Bテストスクリプト。これらの多くは初回ペイント時にブロックされる必要がありません。defer属性を使用するか、ユーザーの操作時に読み込んでください。CWVの改善は劇的なことが多く、エンゲージメント低下はほぼゼロです。

ファーストビュー上に重いクライアントコンポーネントを配置しない

React + framer-motionと30KBのサポートコードが必要なヒーロー画像カルーセルは、パフォーマンス上の課題です。最初のスライドを静的HTMLとしてレンダリングし、ユーザーが操作しようとするときだけカルーセルをハイドレートしてください。

サードパーティスクリプトを四半期ごとに監査する

マーケティングスクリプトは目に見えないうちに増殖します。2020年に分析タグが1つだったサイトも、誰も監査しなければ2026年には8つのスクリプトになっています。LighthouseやWebPageTestで四半期ごとにチェックを実行し、価値を生み出しているものを特定し、必要のないものはすべて削除してください。

重要なポイント：「JavaScript予算の規律」を運用上の決定として捉えること。ツーリングは所有権が誠実である場合にのみ機能する。

クリティカルCSSをインライン化、その他は遅延読込

ファーストビュー上部をレンダリングするのに必要なCSSはheadにインライン化すべきです。残りは非同期で読込可能です。AstroとNext.jsはCSSスコーピングによって自動で処理します。手動で構築するサイトはビルドパイプラインにクリティカルCSS抽出ステップが必要です。

フォントを自社ホストし、font-display: swapを使用する

Google Fontsから読込むWebフォントは通常100～300msを要します。サイトと同じオリジンから自社ホストすればDNSルックアップが不要になります。font-display: swapはWebフォント読込中もフォールバックテキストを即座にレンダリングし、FOIT（フォント読込中のテキスト非表示）を排除します。対応環境ではバリアブルフォントで複数のウェイトを単一ファイルから提供できます。

フォントを実際に配信する言語にサブセット化する

ラテン文字フォントのサブセットは30～60KBです。多言語対応の完全ファイルは250KB以上になることが多いです。サブセット化はほとんどのビルドパイプラインで1行の変更で済み、すべてのページ読込で大幅な帯域幅削減になります。

ホスティングとエッジレイヤーはほとんどのチームが信用するより重要です。あまり明白ではないアドバイス：

オリジンの前に常にCloudflareを配置する

オリジンがVercel、Netlify、AWS、またはマネージドWordPressホストのいずれであろうと、Cloudflareをオリジンの前に配置することで全世界的なレイテンシが改善され、ボット トラフィックが吸収され、オリジンが通常提供するキャッシングが追加されます。無料ティアはほとんどのサイトに十分で、有料ティアは可視性とセキュリティ機能が追加されます。

静的レンダリングが最大のパフォーマンス向上の要因である

CDNエッジノードから提供される事前レンダリング済みHTMLは、グローバルで100ms未満のTTFBを実現します。オリジンへのホップなし、データベースクエリなし、テンプレートレンダリングなし。コンテンツが厳密に動的である必要がない場合は、静的にレンダリングしてください。

動的な部分にはエッジ関数を使用する

動的な動作が必要な場合（認証、パーソナライゼーション、A/B テスト）、Cloudflare Workers または Vercel Edge Functions のエッジ関数はオリジンサーバーよりもユーザーに近い場所で実行されます。インフラストラクチャを運用する負担なしにレイテンシーが大幅に低下します。

Vercel の ISR 課金をスケールで注視する

Incremental Static Regeneration は優れたテクノロジーですが、実際のコスト曲線があります。2026年3月、Deluxe Astrology で月間数百万イベント規模の ISR 課金に達しました。修正は「週2回の本番マージ」という明示的なルールでした。各マージはおよそ600万の ISR 書き込みイベントを発火させ、91,000ページの規模です。大規模なサイトで ISR を実行している場合は、これを計画に入れてください。

新しいサイトやテンプレートをローンチ準備完了と宣言する前に、このチェックリストを実行します。意図的に短くしています。長いチェックリストは実際には使われません。

1. ヒーロー画像は link rel preload で画像として事前読み込みされている。2. ファーストビュー内の画像に明示的な幅と高さがある。3. WebP 形式、品質 82、レンダリング寸法にリサイズ。4. 重要な CSS はインライン化、その他は遅延。5. Webフォントは自主ホスト、font-display: swap。6. 初期 JavaScript は 100KB 未満。7. アナリティクスとマーケティングスクリプトは遅延。8. CSS Grid 列は 1fr ではなく minmax(0, 1fr) を使用（長いコンテンツでのオーバーフローを防止）。9. コンテンツが許す場合は静的レンダリング。10. オリジンの前に Cloudflare を配置。11. Search Console 経由で週次にフィールドデータを測定。12. ビルド時 SEO リンターがリグレッションでビルドを失敗させる。

12 項目すべてを導入した状態でリリースされるサイトは、CWV の問題を抱えることは稀です。3 つか 4 つをスキップするサイトは、最終的に 75 パーセンタイルで失敗し、Google が既に気づいた後にチームが修正に奔走することになります。

すべてのサイトがLighthouse 100を達成する必要があるわけではありません。「どの程度のパフォーマンス作業が十分か」という質問に対する正直な枠組みは次の通りです。

月間訪問者数が10,000未満で検索ランキングに商業的な依存がないサイト：CWVの閾値を75パーセンタイルで満たして終了します。さらなる最適化は収益逓減をもたらします。その時間をコンテンツやプロダクトに充ててください。

有料トラフィックがあり、コンバージョン率が重要なサイト：LCPが100ms増えるごとに、平均ベンチマークでコンバージョンがおよそ1～4%低下します。CWVの閾値を超えた最適化は規模での効果が期待できます。計算を実行し、優先順位を決めてください。

Lighthouseスコアがブランドブリーフの一部であるサイト：Lighthouse 100を達成し、あらゆる退行をバグとして扱います。チームが退行をリリースしないようにするため、最適化作業の効果が複合します。

最適化の規律を維持しないエディトリアルチームがいるサイト：デフォルトでパフォーマンスを提供するフレームワーク（Astro、静的レンダリングされたNext.js、管理ホスティングを備えたheadless WordPress）を選び、その制約を受け入れてください。チームが維持できない手動のパフォーマンスチューニングは、わずかに最適ではないが存続するデフォルトより価値が低いです。

2026年のパフォーマンスは構造的な姿勢です。フレームワークの選択、ホスティングの選択、画像パイプラインの規律、JavaScriptバジェット、CSSとフォントの規律、エッジキャッシング、そしてすべてのローンチで適用されるCWVチェックリスト。これらを早期に組み込んだサイトは、複合していくパフォーマンスフロアを手に入れます。後から追加したサイトは、より多くを費やしてより少ない効果を得ます。

初日にこのガイドのすべての行が必要なわけではありません。まだ引いていないレバーがどれかを知る必要があり、フィールドデータが既に手遅れであることを告げる前に次のレバーを引く必要があります。

特定のサイトに対してCore Web Vitals監査をご希望の場合、Seahawk Mediaでは2,500 USD からの価格で実施しています。この監査により、フィールドデータの分析、優先順位付けされた改善策、および時間をかけて追跡できるターゲットメトリクスプロファイルが得られます。

重要なポイント：「最終的な成果」を運用上の決定として捉えること。ツーリングは所有権が誠実である場合にのみ機能する。