ユーザーがフィルターボタンをタップする—300ミリ秒が経過してからUIが反応する。GoogleのReal User Monitoringが遅延を記録する。コンバージョン率がもう0.5%低下する。Core Web Vitalsは順位付けの興味事項から、サイトが成約するのか、それともユーザーを失血させるのかを測定する明確な分岐点へシフトした。2026年、INPがFIDを完全に置き換え、CLSの閾値が厳しくなり、うわさのSmoothness メトリクスはすでにChrome Canarybでテストされている。このガイドは、Social Animalで実施した200件以上のパフォーマンス監査から、フレームワーク固有の修正、実際のベンチマーク、実際に成果を出すコードスニペットに蒸留されている—「画像を最適化する」というような曖昧なアドバイスはない。Next.js 14 App RouterでINPが破損する3つの場所、LCPを40%削減したIntersection Observerの2行の調整、そして非同期だと思っていても依然としてCLSを低下させるサードパーティスクリプトの理由を示す。

目次

2026年のCore Web Vitalsとは

Core Web Vitalsは、検索順位に直接影響するGoogleの標準化されたUXメトリクスセットである—そして、正直に言えば？より重要なのはユーザー行動だ。それらは、ユーザーが実際に感じるものを測定する:コンテンツがいかに速く表示されるか、何かをタップしたときにページがいかに速く反応するか、そしてレイアウトが保たれるか、それとも悪霊に取り憑かれたかのように飛び回るかだ。

INPは2024年3月にFIDを公式に置き換えた。2025年中盤までに、ChromeのUsageデータは、オリジンの38%がまだINP閾値に失敗していることを示した—FIDが享受していた快適な92%パス率と比較してみてほしい。これはGoogleがゴールポストを動かしているのではなかった。彼らはついに実際に重要なことを測定していたのだ。

2026年初頭の状況:

  1. Largest Contentful Paint (LCP) — ロード性能
  2. Interaction to Next Paint (INP) — レスポンシブネス
  3. Cumulative Layout Shift (CLS) — ビジュアル安定性

Googleはまた、Smoothnessメトリクス(アニメーションフレームドロップとスクロールジャンク)への関心をシグナルしている。ただし、まだCore Web Vital ステータスに昇格していない。スマートなチームは、Long Animation Frames (LoAF) APIを通じてそれを既に追跡している。していないなら—今すぐ始めてほしい。

現在のメトリクスとその閾値

| メトリクス | 優 | 要改善 | 不可 | 測定内容 | |--------|------|-------------------|------|------------------|| | LCP | ≤ 2.5s | 2.5s – 4.0s | > 4.0s | 最大のビジブル要素がレンダリングされるまでの時間 | | INP | ≤ 200ms | 200ms – 500ms | > 500ms | セッション全体を通じた最悪ケースのインタラクションレイテンシ | | CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 | 予期しないレイアウトシフトスコアの合計 |

ここでは、人々が常に忘れることがある。これらの閾値は、実際のChrome User Experience Report (CrUX)データからのページロードの75パーセンタイルで測定される。つまり、実際の訪問者の75%が「優」に達する必要があるということだ。MacBook Proでのファイバーインターネットによるテストではない。実際のユーザー—3年前のSamsung、地下鉄を通って不安定なLTEに乗っている。大きな違いだ。

Largest Contentful Paint (LCP)最適化

LCPは、通常、チームが最もよく理解するメトリクス—しかし、それでも最も失敗するメトリクスだ。HTTP Archiveの2025年末データは、モバイルオリジンの63%だけがLCPをパスしていることを示した。それは...あまり良くない。

LCPのサブパート理解

Googleは2024年のドキュメントでLCPを4つのサブパートに分割した。このフレームワークは、私たちが見つけた唯一の最も効果的な診断ツール—他には何も遠くから及ばない:

サブパート 目標 カバー内容
Time to First Byte (TTFB) < 800ms サーバー応答、DNS、TLS、リダイレクト
Resource Load Delay < 10% of LCP TTFBからLCPリソースのロード開始までの時間
Resource Load Duration < 40% of LCP LCPリソースのダウンロード時間
Element Render Delay < 10% of LCP リソースロードからピクセルレンダリングまでの時間

サーバーサイド修正

TTFBを削減する エッジコンピューティングに移動することで。それでも単一の起点からサービス提供しているのか？あなたは、サーバーから遠いユーザーのために200-800msを与えている。無料で全部だ。

// Next.js ミドルウェア エッジファースト レンダリング
// next.config.js
export default {
  experimental: {
    runtime: 'edge',
  },
};

// middleware.ts — エッジで実行
import { NextResponse } from 'next/server';
export const config = { matcher: ['/((?!api|_next/static|favicon.ico).*)'] };

export function middleware(request) {
  const response = NextResponse.next();
  // デバッグ用のサーバータイミング ヘッダーを追加
  response.headers.set('Server-Timing', `edge;desc="Edge Middleware"`);
  return response;
}

AstroまたはNext.jsのチームの場合、エッジレンダリングページは一貫して全世界でTTFB 200ms以下に達する。私たちのNext.js開発とAstro開発実務は、デフォルトでエッジデプロイメントを指定する。

リソース検出最適化

ここが、ほとんどの人が見落としている場所—2026年の最大のLCP殺傷因は遅いサーバーではない。それは、LCPリソースの遅い検出だ。ヒーロー画像URLがCSSファイル内に隠されているか、JavaScriptバンドル内に隠されている場合、ブラウザはそのチェーン全体が解決するまで、それをフェッチすることさえ開始できない。あなたは基本的に、ページで最も重要なものを宝探しの後ろに隠している。

<!-- fetchpriorityでLCP画像をプリロード -->
<link
  rel="preload"
  as="image"
  href="/hero-2400.webp"
  fetchpriority="high"
  media="(min-width: 768px)"
/>
<link
  rel="preload"
  as="image"
  href="/hero-800.webp"
  fetchpriority="high"
  media="(max-width: 767px)"
/>

<!-- 画像要素自体の上 -->
<img
  src="/hero-2400.webp"
  alt="Product dashboard"
  width="2400"
  height="1200"
  fetchpriority="high"
  decoding="async"
  sizes="100vw"
  srcset="/hero-800.webp 800w, /hero-1600.webp 1600w, /hero-2400.webp 2400w"
/>

主要ルール:

  • LCP要素を遅延ロードしない。これは譲歩の余地がない。
  • LCP画像のfetchpriority="high"を使用する—2025年現在、すべての最新ブラウザでサポートされている。
  • クリティカルCSSをインライン化するか、フォントをブロックレンダリングする<link rel="preload">。
  • AVIFをWebPフォールバック付きで画像を提供する。AVIFは同等の品質でWebPより30-50%小さく実行される。2026年でプライマリフォーマットとしてWebPを配布しているなら、あなたはバイトをテーブルに残している。

テキストベース要素のLCP

LCP要素が見出しまたは段落である場合(コンテンツサイトではごく普通)、レンダリングをブロックするリソースはあなたの敵になる:

<!-- プライマリフォントをプリロード -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-v.woff2" crossorigin />

<!-- font-display: optionalを使用して最速のペイント -->
<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-v.woff2') format('woff2');
    font-display: optional; /* フォント スワップからのレイアウト シフトを排除 */
  }
</style>

font-display: optionalは、Webフォントがキャッシュされていない場合、システムフォントにフォールバックすることで、FOITとFOUTの両方を防止する。トレードオフ？初回訪問者はシステムフォントを見る。ゲイン: フォント交換からのゼロCLSと高速なLCP。私たちはその取引を毎回受ける。

Interaction to Next Paint (INP)最適化

INPは、2026年に優れたサイトと優秀なサイトを分ける、そのメトリクスだ。ほとんどの代理店がこれを間違う。最初のインタラクションののみのインプット遅延を測定したFIDとは異なり、INPはすべてのインタラクションの完全なライフサイクルをキャプチャする: インプット遅延、処理時間、およびプレゼンテーション遅延—その後、大ざっぱに最悪の1つをレポート(98パーセンタイル)。

インタラクションの解剖

[ユーザークリック] → [インプット遅延] → [イベント処理] → [プレゼンテーション遅延] → [次のフレーム描画]
                 ↑                ↑                     ↑
                 メインスレッドでブロック       あなたのクリック              ブラウザはレンダリング
                                  ハンドラー実行           DOMの変更

インプット遅延の削減

インプット遅延は、ユーザーがタップしたときにメインスレッドが他の何かをしているときに発生する。通常の容疑者:

  1. サードパーティスクリプト — 分析、チャットウィジェット、A/Bテストツール。典型的なエンタープライズサイトは15-30個のサードパーティスクリプトをロードし、それぞれがメインスレッド時間のために戦う。そこは群衆シーンだ。
  2. ハイドレーション嵐 — ページ全体を一度にハイドレートするSPA は、メインスレッドを200-2000msブロックする。誰かがボタンをタップしようとしているときは、それは永遠だ。
  3. 長いタスク — 50msを超えるJavaScriptタスクは入力を遅延させる。ピリオド。
// scheduler.yield()で長いタスクを分割—Chrome 129+で利用可能
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    
    // 5項目ごとにメインスレッドに譲歩
    if (i % 5 === 0) {
      await scheduler.yield();
    }
  }
}

scheduler.yield()なしのブラウザの場合、ここがフォールバック:

function yieldToMain() {
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

処理時間の削減

これはあなたのイベントハンドラーが住んでいるところだ。修正はコスメティックではなく、アーキテクチャだ:

  • 高価なハンドラー(スクロール、リサイズ、入力)をデバウンスおよびスロットル。
  • Web Workersまたはscheduler.postTask() APIを使用して、計算をメインスレッドから移動。
  • JavaScriptの代わりにCSSでアニメーションを使用。transformとopacityの変更は、レイアウトまたはペイントをトリガーしない。
// scheduler.postTask()を非緊急作業に使用
button.addEventListener('click', async () => {
  // 緊急: ビジュアル フィードバック は即座に
  button.classList.add('active');
  
  // 非緊急: 分析、状態更新
  scheduler.postTask(() => {
    analytics.track('button_clicked');
  }, { priority: 'background' });
  
  // ユーザー可視但し即時ではない
  scheduler.postTask(() => {
    updateDashboard();
  }, { priority: 'user-visible' });
});

プレゼンテーション遅延の削減

プレゼンテーション遅延は、イベントハンドラー終了とブラウザが実際に次フレームをペイントする間のギャップだ。その原因:

  • 過剰なDOM サイズ — 1,400個を超えるDOM要素を持つページは、測定可能に悪いINPを示す。2025年HTTP Archiveの中央値？モバイル上の1,600要素。ほとんどのサイトはあまりに肥大化している。
  • 複雑なCSSセレクタ — 深くネストされたセレクタは、何かが変わるたびに高価なスタイル再計算を強制する。
  • レイアウトスラッシング — offsetHeightのようなレイアウトプロパティをDOMへの書き込みの直後に読み取ることで、同期的レイアウトを強制する。このことは常に人々を噛む。彼らはそれが来るのを決して見ない。
// BAD: レイアウト スラッシング
elements.forEach(el => {
  const height = el.offsetHeight; // レイアウトを強制
  el.style.height = height + 10 + 'px'; // レイアウトを無効化
});

// GOOD: 読み取りをバッチし、その後書き込みをバッチ
const heights = elements.map(el => el.offsetHeight); // すべての読み取り最初
elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px'; // すべての書き込み2番目
});

Cumulative Layout Shift (CLS)最適化

CLSはビジュアル不安定性を測定する—ページロード中またはインタラクション中に飛び回るもの。Googleは「セッションウィンドウ」アプローチを使用: 1秒以内のシフト、5秒ごとのウィンドウで上限は、一緒にグループ化される。CLSは、最大のセッションウィンドウをレポートする。

通常の容疑者

原因 修正 インパクト
寸法なし画像 widthとheight属性を追加 高
動的に挿入されたコンテンツ(広告、埋め込み) min-heightまたはaspect-ratioでスペースを予約 高
Webフォントが原因でFOUT font-display: optionalまたはsize-adjustを使用 中
後期ロードCSS クリティカルCSSをインライン化し、残りをプリロード 中
アニメーションが原因でレイアウト top/left/width/heightの代わりにtransformを使用 低~中

`aspect-ratio` CSSプロパティ

このプロパティが一晩でCLSの問題全体のクラスを排除したと言う場合、誇張していない。どこでも使用:

/* 画像のスペースを予約 */
img {
  aspect-ratio: attr(width) / attr(height);
  width: 100%;
  height: auto;
}

/* ビデオ埋め込みのスペースを予約 */
.video-embed {
  aspect-ratio: 16 / 9;
  width: 100%;
  background: #1a1a1a;
}

/* 広告スロットのスペースを予約 */
.ad-slot-leaderboard {
  aspect-ratio: 728 / 90;
  min-height: 90px;
  contain: layout;
}

`content-visibility`プロパティ

content-visibility: autoは、画面外のコンテンツのレンダリングをスキップするようにブラウザに伝える。これは、初期レイアウトコストを劇的に削減でき、CLSとINPの両方を改善できる:

.below-the-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* CLSを防止するための推定高さ */
}

私たちは、長いフォーム ページでこの技術を使用して、レンダリング時間を30-50%削減することを測定しました。ほぼ無料のパフォーマンス。それを使用しないよい理由がない。コンテンツ豊富なページでそれを使用してください。

フレームワーク固有の戦略

Next.js (App Router, v15+)

Next.js 15は、Partial Prerendering (PPR)を安定版として配布し、正直に言えば—それは、LCPのための本物のゲームチェンジャーだ。静的シェルはエッジで即座にレンダリング; 動的コンテンツはReact Suspense境界を通じてストリーム入力される。

// app/page.tsx — 動的アイランドの静的シェル
import { Suspense } from 'react';
import { HeroSection } from '@/components/HeroSection'; // Static
import { PersonalizedOffers } from '@/components/PersonalizedOffers'; // Dynamic

export default function HomePage() {
  return (
    <>
      <HeroSection /> {/* ビルド時にレンダリング—即座のLCP */}
      <Suspense fallback={<OffersSkeleton />}>
        <PersonalizedOffers /> {/* シェル後にストリーム */}
      </Suspense>
    </>
  );
}

Next.jsの<Image>コンポーネントは、srcset、AVIF/WebP交渉、および遅延ロードを自動的に処理する。しかし—そしてこれは常に人々をつまずかせる—あなたはまだLCP画像にpriorityを設定する必要がある。あなたのために推測することはない:

<Image
  src="/hero.jpg"
  alt="Hero"
  width={2400}
  height={1200}
  priority // fetchpriority="high"を設定し、遅延ロードを無効化
  sizes="100vw"
/>

私たちの完全なパフォーマンスファースト Next.jsビルドへのアプローチは、私たちのNext.js開発機能ページにある。

Astro

AstroのゼロJavaScript-デフォルトアーキテクチャは、ほとんどのAstroサイトがCore Web Vitalsをすぐに箱から出した状態で合格することを意味する。2025年HTTP Archive Web Almanacは、Astroサイトが任意のフレームワークの中で最も高いCore Web Vitalsパス率を82%で示した。それは偶然ではない—それはデフォルトがゼロクライアント側JavaScriptの配布である場合に何が起こるかだ。

主要パターン:

---
// src/pages/index.astro
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---

<!-- Astroはこれをビルド時にAVIF/WebPにsrcsetで最適化 -->
<Image
  src={heroImage}
  alt="Hero"
  widths={[400, 800, 1600, 2400]}
  sizes="100vw"
  loading="eager"
  fetchpriority="high"
/>

<!-- インタラクティブアイランド—表示時にのみJSをロード -->
<SearchBar client:visible />

client:visibleディレクティブは、ユーザーがスクロールするまでサーチバーのJavaScriptがロードされないことを意味し、初期ロード中にメインスレッドをクリアに保つ。私たちのAstro開発アプローチの詳細。

ヘッドレスCMS考慮事項

ヘッドレスCMSを使用—Contentful、Sanity、Storyblok、あなたが実行しているもの何でも—CMS APIレスポンスタイムはあなたのTTFBの一部になる。誰もこれについて考えない、それが彼らを噛むまで。

クライアントプロジェクト全体での私たちのベンチマーク:

CMS 平均APIレスポンス(キャッシュCDN) 平均APIレスポンス(起点) ノート
Contentful 45ms 180ms GraphQL APIはRESTより少し遅い
Sanity 35ms 120ms GROQクエリは速い; CDNは優秀
Storyblok 50ms 200ms V2 APIは大幅に改善
Strapi (Self-hosted) 変数 変数 あなたのインフラに完全に依存

クリティカルパターン: 要求時間にCMS APIを呼び出さない 個性化が本当に必要でない限り。ISRまたはオンデマンド再検証を使用して事前構築ページを提供する。私たちは、サーバーコンポーネントでfetch呼び出しを配線している、キャッシュされるべきチーム300ms+をTTFBに付け加えたのを見た。気が狂いそう。私たちのヘッドレスCMS開発実務は、デフォルトでこれを構築する。

本番環境での測定と監視

ラボ対フィールドデータ

ラボデータ(Lighthouse、WebPageTest)は何ができるかを伝える。フィールドデータ(CrUX、RUM)は何が実際に起こるかを伝える。彼らは発散する—時々ワイルドに。そして、Lighthouse 100スコアを戦利品のように振り回しながら、CrUXデータが失敗している利害関係者がいるときは？そう。私たちはそれより多くの場合その話をしている。

ラボツールが単に説明できないもの:

  • 遅いデバイス(中央値のAndroidフォンはiPhone 15のCPUパワーの約1/5)を持つ)
  • 実世界のネットワーク可変性
  • ブラウザ拡張機能が神知っているかすることをしている
  • 本番環境でのサードパーティスクリプト動作—ステージング環境からは完全に異なる動作をする

推奨監視スタック(2026)

ツール タイプ コスト 最適
Google CrUX フィールド(28日) 無料 SEOインパクト—これはGoogleが実際に使用するもの
web-vitals.js フィールド(リアルタイム) 無料 カスタムRUMパイプライン
Vercel Speed Insights フィールド 無料(Vercel搭載) Vercel上のNext.jsサイト
SpeedCurve ラボ+フィールド $12-200/月 競争ベンチマーク、フィルムストリップ
Sentry Performance フィールド $26+/月 パフォーマンスをエラーに結合
DebugBear ラボ+フィールド+CrUX $99+/月 最高のCrUXチェンジトラッキングを使用した

web-vitals.jsのセットアップ

import { onLCP, onINP, onCLS } from 'web-vitals/attribution';

function sendToAnalytics(metric) {
  const body = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good', 'needs-improvement', 'poor'
    delta: metric.delta,
    id: metric.id,
    navigationType: metric.navigationType,
    // 帰属データ—メトリクスが悪い理由を伝える
    attribution: metric.attribution,
  };

  // 信頼性のためにsendBeaconを使用
  if (navigator.sendBeacon) {
    navigator.sendBeacon('/api/vitals', JSON.stringify(body));
  }
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

/attributionビルドは重要—LCPだった要素、最悪のINPを引き起こしたインタラクション、CLSでシフトした要素などの診断情報を追加する。なし、あなたは盲目で飛行している。ゼロコンテキストで修正するために実際に何かをただ数字を見つめている。

2026年の高度なテクニック

Speculation Rules API

Speculation Rules API (Chrome 121+、2026年で~75%ブラウザサポート)は、ユーザーが実際にクリックする前にページをプリレンダー。その結果？後続ナビゲーション上のほぼインスタントLCP:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

"eagerness": "moderate"はホバーでプリレンダー—ユーザーの帯域幅を設定していない位置を炬燵に感じるのに十分積極的。私たちはそれに到達するために多くの試行錯誤の後。これは甘いスポットだ。

View Transitions API

ネイティブビュー遷移(クロス文書、Chrome 126+でサポート)は、JavaScriptフレームワークオーバーヘッドなしで、滑らかなページ間アニメーションを与える。それらは直接知覚されるパフォーマンスを改善し、ナビゲーション中のCLSを削減する:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease-out;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease-in;
}

Long Animation Frames (LoAF) API

LoAFは長いタスクを置き換え、あなたにはるかに多くの診断力を与える。3年前にこれを持っていたことを心から望む:

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) {
      console.log('Long animation frame:', {
        duration: entry.duration,
        blockingDuration: entry.blockingDuration,
        scripts: entry.scripts.map(s => ({
          sourceURL: s.sourceURL,
          sourceFunctionName: s.sourceFunctionName,
          duration: s.duration,
        })),
      });
    }
  }
});
observer.observe({ type: 'long-animation-frame', buffered: true });

これは、長いフレームを引き起こした正確にどのスクリプトと正確にどの機能をあなたに伝える。我々はまったく監査セッションを費やしているだけのLoAFアウトプットを見て、分単位でなく時間でなく犯人を見つけた。INP デバッグのため、それは存在する最高のツール。他には何も遠くから近い。

ビジネスインパクト: 実数

パフォーマンス最適化は虚栄心プロジェクトではない。それは開発者がそれがクールだと思うので、あなたがグリーンライトする何かではない。2025年のケーススタディから:

  • VodafoneはLCPを31%改善し、売上が8%増加した。
  • TokopediaはINPを40%削減し、セッション持続時間が15%増加した。
  • NDTVはCLSを55%改善し、バウンス率が50%削減した。
  • Rakuten 24はCLSを0.2ポイント改善し、訪問者あたりの収益を33.1%増加させた。

Social Animalでの我々独自のクライアントデータは、3つのCore Web Vitals全てを合格するサイトが事前最適化ベースラインと比較して、平均23%低いバウンス率と12%高いコンバージョン率を見ることを示す。

eコマースの場合、数学は死んでいる簡単だ: LCPで1秒の改善はコンバージョン率の2-5%増加に相関する。$10M/年のストア上では、それは追加収益の$200K-$500K。最適化のコスト？その一部。価格設定ページで詳細をチェックするか、あなたの状況について話をするために直接到達。

FAQ

2026年のCore Web Vitalsメトリクスは何か?

3つのCore Web Vitalsはlargest Contentful Paint (LCP)、Interaction to Next Paint (INP)、およびCumulative Layout Shift (CLS)。INPは2024年3月にFID (First Input Delay)を置き換え、まだレスポンシブネスメトリクスだ。Googleはメトリクスの平滑化についてはっきりしたが、それはまだCore Web Vitalとして追加されていない。

Core Web Vitalsはどの程度SEO順位に影響するか?

それらはGoogleのページ体験信号内で確認された順位付けシグナルだが、彼らはプライマリファクターより多くスコアリング結び目で動作する—コンテンツ関連性がまだ支配する。ここで彼らは本当に彼らの重さを上に打つは: ユーザー行動; バウンス率、エンゲージメント、ページ滞在時間。そのもの、直接にしまう方法で順位付けに影響するが、無視できない。Core Web Vitalsすべて合格するサイトは、一貫してより良いエンゲージメント数を示し、それは時間をかけて混合する。

2026年の良いINPスコアとは何か?

200ミリ秒以下、実ユーザーデータの75パーセンタイルで測定。200msと500msの間は改善が必要。500msを超えは悪い。モバイル上の中央値Webサイトインターネットは、2026年初期の時点で約280msのINPに位置する—ほとんどのサイトがまだ合格しないことを意味する。それを沈ませてください。

Lighthouse スコアなぜは異なるか、CrUXデータか?

なぜなら彼らは根本的に異なるものを測定するから。Lightouseは、スロットル化されたCPUとネットワークの単一ページロードで、シミュレートされた環境で実行される。CrUXデータは、実際のChromeユーザーから28日間のローリング ウィンドウ全体のあなたの起点上のすべてのページ。ギャップは、デバイス多様性(遅いAndroid携帯電話の上の実際のユーザー)、本番環境でのサードパーティスクリプト動作、サーバーからの地理的距離、とCrUXが完全なセッションをキャプチャするという事実から来る—すべてのインタラクション INP、すべてのレイアウトシフト CLS—Lightouseは1つのロードをキャプチャ。私たちはLighthouse 95+スコアを見るサイトと、CrUX全体で失敗する。ラボデータだけを信頼しないでください。

ヘッドレスCMSはCore Web Vitalsを支援または傷つけるか?

ヘッドレスCMSアーキテクチャは本質的に支援するため、プレゼンテーションレイアー、それから内容管理を分離する。Next.jsまたはAstroのような最新フレームワーク、とエッジレンダリング ペアリング、静的またはサーバーレンダリングHTML、最小JavaScriptで動作。典型的なモノリシックプラットフォーム—重い最適化なしのWordPress、すぐにDrupal—通常ずっと多くのJavaScriptと遅いTTFBを配布。主要もの: 要求時間にCMS APIコールが起こることを確認、個性化が本当に必要でない限り。ISRまたはオンデマンド再検証を使用すべき事前構築ページ提供。

悪いINPスコアをサードパーティスクリプトが引き起こされたはどう修正するか?

Long Animation FramesAPIまたはChrome DevToolsパフォーマンスパネルで監査を開始するために、メインスレッド、ホッグがどのスクリプト特定。次に: asyncまたはdeferを持つ非クリティカルスクリプト ロード、初期化を遅延するためにsetTimeoutまたはrequestIdleCallbackを使用、Web Worker(Partytown素晴しい)経由メインスレッド、そしてオフ移動サードパーティスクリプト— このの部分誰も聞きたくない—測定ビジネス価値を提供しない何でも無情に削除。そのチャット ウィジェット誰も使うか? 殺す。我々は、チャット ウィジェットとA/Bテストツールを遅延するだけで、500ms+INPから下500msまた150msを見有しているサイト。ほぼ常にサードパーティブロート。

Next.js サイト上のLCPを改善するための最速の方法は何か?

影響の順: Partial Prerendering (PPR)を有効にする(即座の静的シェルについて)、エッジランタイム展開(Vercel EdgeまたはCloudflare)、あなたのLCP<Image>コンポーネント上でpriorityを設定、折りの上の非必要クライアントコンポーネントをやめるレンダリングをブロック、そしてクリティカルフォントをプリロード。ただし、ここで実務で我々が実際に見ること: ルート原因はサーバーコンポーネントでなければならなかった'use client'からクライアント側データフェッチ。単一コンポーネントをサーバーコンポーネントに移動は、LCP完全修正を切ることができます500ms+を削除。それは、ワイルド頻繁の成り行きだ。