LCP要素のレンダリング遅延を最適化してください。

ダウンロードから表示まで：Largest Contentful Paintにおける要素のレンダリング遅延の改善方法を解説します。

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-07-10
  1. Ja
  2. Core Web Vitals
  3. Largest contentful paint
  4. Element render delay

このガイドはCore Web VitalsリソースセンターのLargest Contentful Paint (LCP)セクションの一部です。Element Render DelayはLCPタイムラインの最終フェーズであり、LCPリソースのダウンロード完了から画面に描画されるまでのギャップを表します。

LCPのElement Render Delayを最適化する

LCPの4つのフェーズのうち、Element Render Delayは最も誤解されています。開発チームはTTFBを最適化し、Resource Load Delayを排除し、アセットを圧縮してResource Load Durationを短縮します。ネットワークウォーターフォールが完了したのを見て、作業は終わったと考えます。それは間違いです。

Element Render Delayとは、LCPリソースのダウンロードが完了してから、ユーザーの画面に要素が完全に描画されるまでの時間です。これはネットワークの問題ではなく、main threadの問題です。レンダリング遅延が大きいということは、ブラウザが画像やフォントを取得済みであるにもかかわらず、他のタスクで忙しくて描画できないことを意味します。この遅延はLCPスコアを直接悪化させ、すべてのネットワークリクエストが完了した後に200ms以上加算されることもあります。

正確な定義：ラストマイルの問題

Element Render Delayは、LCPリソース（画像ファイルやWebフォントなど）の最後のバイトがブラウザに到着した瞬間から始まります。そして、LCP要素が実際に画面に描画されたときに終わります。文字通り、最終ステップです。

システムフォントを使用するテキストベースのLCP要素の場合、外部リソースが不要なため、この遅延は多くの場合ゼロです。しかし、LCP要素が画像であったり、カスタムWebフォントを使用している大多数のサイトでは、このフェーズが最大のボトルネックになりがちです。ブラウザはこの時間を、ダウンロードしたビットを画面上のピクセルに変換するという、CPUバウンドなタスクに費やします。

理由：詰まった組み立てライン

レンダリング遅延を解消するには、ブラウザがページを描画する仕組みを理解する必要があります。これはCritical Rendering Pathと呼ばれる複数段階のプロセスです。工場の組み立てラインと考えてください。

  1. 設計図の作成（DOMとCSSOM）： ブラウザはHTMLを解析してDocument Object Model（DOM）を構築し、CSSを解析してCSS Object Model（CSSOM）を構築します。これらはページコンテンツとスタイルの設計図です。
  2. 設計図の結合（Render Tree）： DOMとCSSOMを結合し、Render Treeを作成します。ここにはページの描画に必要なノードのみが含まれます。<head>やdisplay: none;が指定された要素は除外されます。
  3. ジオメトリの計算（Layout）： ブラウザはRender Tree内のすべての要素の正確なサイズと位置を計算します。この段階は「リフロー」とも呼ばれます。
  4. ピクセルの着色（Paint）： ブラウザはテキスト、色、画像、境界線、シャドウを考慮して、各要素のピクセルを塗りつぶします。
  5. レイヤーの組み立て（Composite）： ページを複数のレイヤーに描画し、それらを正しい順序で組み立てて最終的な画面画像を作成します。

Element Render Delayとは、Layout、Paint、Compositeという最終段階で消費される時間のことです。この組み立てライン全体は、main threadという1人の作業員によって実行されます。この作業員がJavaScriptのlong taskを実行したり、巨大なCSSファイルを解析したりして忙しいと、組み立てラインは停止します。LCP画像が到着していても、main threadが処理と描画を実行できるようになるまで、荷降ろし場で待機することになります。

Element Render Delayの特定方法

この問題の診断には、厳密な2段階のプロセスがあります。最初のステップを飛ばさないでください。

ステップ1：field data（RUM）で検証する
DevToolsを開く前に、Element Render Delayが実際のユーザーにとって本当に問題であるかを確認する必要があります。CoreDashのようなプロ仕様のReal User Monitoring（RUM）ツールが不可欠です。これにより、サイトのLCPが4つのサブパートに分解されます。RUMデータで75パーセンタイルにおいてElement Render Delayが大きい場合、解決すべき影響度の高い問題があることが確認できます。

ステップ2：DevToolsで診断する
RUMで問題のあるページを特定したら、Chrome DevToolsのPerformanceパネルを使用して原因を探ります。私たちのガイドChrome DevToolsのPerformanceパネルでLCPを診断するでは、スロットリングの設定と記録のワークフローを段階的に解説しています。特にレンダリング遅延については以下の通りです。

  1. 「Record and reload」ボタンでページの読み込みを記録します。
  2. Insightsサイドバーの「LCP breakdown」インサイトを開き、Element render delayの値を確認します。
  3. タイムラインのMainトラックを調べます。LCPリソースのネットワークリクエスト完了からLCPタイミングマーカーの間に発生しているlong task（角が赤い黄色のブロック）を探します。これらのタスクが遅延の直接的な原因です。マウスオーバーして、原因となっているスクリプトを特定します。

一般的な原因と影響の大きい解決策

Element Render Delayが大きい場合、ほぼ常にmain threadのブロックが原因です。

原因：render blockingなCSS

問題： デフォルトでは、CSSはrender blockingです。ブラウザは、<head>にリンクされたすべてのCSSファイルをダウンロードして解析するまで、ピクセルを描画しません。大規模で複雑なスタイルシートは数百ミリ秒にわたってmain threadを占有し、LayoutとPaintの段階の開始を遅らせます。サイトが複数のスタイルシートを読み込み、それぞれに個別のネットワークリクエストと解析サイクルが必要な場合、この問題はさらに悪化します。CSSのpayloadを削減する詳細な戦略については、未使用のCSSを削除するのガイドを参照してください。

解決策： CSSを小さくクリーンにし、キャッシュ可能にします。

  • 未使用のCSSを削除する： これは最も影響の大きい最適化です。大規模なサイトでは、未使用のCSSがスタイルシート全体のサイズの70%以上を占めることがあります。PurgeCSSなどのツールを使用すると、HTMLとJavaScriptをスキャンして未使用のセレクタを特定できます。不要なルールを削除することで、ダウンロード時間とmain threadでの解析時間の両方を削減できます。
  • 小さくキャッシュ可能なスタイルシートを目指す： CSSファイルの最適なサイズは、圧縮状態で約10〜15kBです。これより小さいと、多数の並列リクエストに分割され、それぞれに接続オーバーヘッドが発生するリスクがあります。これより大きいと、特に遅いモバイルネットワークではブロック時間が長くなります。この範囲にある適切に構造化された1つのスタイルシートであれば、高速にダウンロードされ、高速に解析され、再訪問時のためにブラウザにキャッシュされます。
  • CSSのインライン化は最終手段にする： クリティカルなCSSを<style>ブロックにインライン化すると、最初のページ読み込み時のネットワークリクエストはなくなりますが、代償が伴います。インライン化されたCSSはブラウザでキャッシュできません。再訪問するユーザーは、ページを開くたびにそれを再ダウンロードすることになります。再訪問者がいるほとんどのサイトでは、ブラウザがキャッシュできる小さな外部スタイルシートを使用する方が優れた選択です。インライン化が意味を持つのは、再訪問者が非常に少ないランディングページのみです。

CSSの影響を定量化する： CSSがレンダリング遅延にどの程度影響しているかを測定するには、Chrome DevToolsのCoverageタブを開きます（Ctrl+Shift+Pを押してから「Coverage」と入力）。ページを読み込み、CSSファイル内の未使用バイトの割合を確認してください。未使用のCSSの割合が高い場合、クリーンアップによってElement Render Delayを短縮できる明確なサインです。

原因：JavaScriptのlong task

問題： これが最も一般的な原因です。フレームワーク、分析スクリプト、A/Bテストツール、最適化が不十分なコードなどによる重いJavaScriptの実行は、main threadを独占します。1つの長時間のタスクがレンダリングを数百ミリ秒ブロックし、Element Render Delayを直接増加させます。Googleは50ms以上かかるタスクをlong taskと定義しており、200msを超えるタスクは致命的に長いとみなされます。JavaScriptの遅延戦略の完全なコレクションについては、JavaScriptを遅延させる14の方法に関する記事を参照してください。

解決策： 作業を分割します。

  • main threadへyieldする： long taskは小さなチャンクに分割する必要があります。これは、setTimeout(..., 0)や新しいscheduler.yield()APIを使用して、定期的にブラウザに制御をyieldすることで実現できます。これにより、ブラウザはタスク間でレンダリングの更新を実行できます。
  • サードパーティスクリプトを最適化して遅延させる： すべてのサードパーティスクリプトを監査します。最初のレンダリングに不可欠でない場合は、defer属性を使用して読み込むか、ページの読み込み後に注入します。A/Bテストのスクリプトは、意図的にレンダリングをブロックすることが多いため、特に問題となります。
  • 視覚的な更新にはrequestAnimationFrameを使用する： ページの読み込み中にJavaScriptでDOM操作を行う必要がある場合は、その作業をrequestAnimationFrameでラップします。これにより、次のPaintの直前に作業がスケジュールされ、JavaScriptの操作の間にブラウザがフレームをレンダリングする機会を確実に得られます。

DevToolsでlong taskを特定する

Chrome DevToolsのPerformanceパネルでは、long taskは「Main」トラックの右上に赤い三角形がある黄色のブロックとして表示されます。原因となっているスクリプトを特定するには：

  1. Performanceパネルでページの読み込みを記録します。
  2. TimingsトラックでLCPマーカーを見つけます。
  3. Mainトラックで、LCPリソースのネットワークリクエスト完了からLCPマーカーの間に発生しているlong taskを調べます。
  4. これらのタスクをクリックして、Summaryパネルでコールスタックを確認します。コールスタックから、long taskの原因となっているソースファイルと関数がわかります。

問題を起こしやすい一般的なサードパーティスクリプト

実際のコンサルティング経験に基づくと、Element Render Delayの原因となる最も一般的なサードパーティスクリプトには以下のものがあります。

  • A/Bテストツール（Optimizely、VWO、AB Tasty）：これらは、バリアント間のコンテンツのちらつきを防ぐために、意図的にレンダリングをブロックすることがよくあります。実験の決定をサーバー側に移動する（サーバーサイドテスト）ことで、この問題を完全に排除できます。
  • 同期タグを使用するタグマネージャー： 同期（非async）タグが設定されたタグマネージャーは、render blockingなスクリプトを注入する可能性があります。コンテナを監査し、すべてのタグがDOM readyまたはwindow loadの後に発火するように設定されていることを確認してください。
  • 同意管理プラットフォーム： 決定が下されるまでレンダリングをブロックするCookie同意バナーは、LCPを遅らせる可能性があります。Critical Rendering Pathをブロックしないasyncの実装を使用してください。
  • チャットウィジェット： ライブチャットのスクリプトは、ページの読み込み時に重い初期化コードを実行することがよくあります。ページがインタラクティブになるまで読み込みを遅延させるか、ユーザーの操作（クリックなど）をきっかけに読み込んでください。

原因：クライアントサイドレンダリング（CSR）

問題： 純粋なクライアントサイドレンダリングでは、初期HTMLにLCP要素が存在しないことがよくあります。まずJavaScriptが実行されてDOMを構築し、LCP要素を挿入して、ようやくブラウザがそれをレンダリングできます。このプロセス全体が巨大なレンダリング遅延となります。

解決策： サーバーでレンダリングします。他に方法はありません。Server-Side Rendering（SSR）またはStatic Site Generation（SSG）を使用して、サーバーから送信される初期HTMLドキュメントにLCP要素が確実に含まれるようにします。これにより、JavaScript駆動のレンダリングフェーズ全体が遅延の原因から排除されます。

原因：他のコードによってコンテンツが隠されている

問題： LCP要素がDOM内にあっても、CSS（例：opacity: 0）や、「スクロール時に表示」するアニメーション、どのバリアントを表示するかをまだ決定中のA/Bテストツールなどのスクリプトによって隠されていることがあります。要素はダウンロードされて準備ができていますが、まだ表示されていないため描画できません。

解決策： 即座に表示されるようにします。LCP要素には、初期読み込み時に要素を隠すようなエントリーアニメーションやロジックを使用しないでください。要素はDOM内で表示され、最初のPaintから表示されるようにスタイル設定されている必要があります。A/Bテストツールが非同期で実行されるように設定するか、LCP要素の可視性への影響を最小限に抑えるようにしてください。

原因：過大なDOMサイズ

問題： DOMサイズが大きい（1,500ノード以上）と、すべてのレンダリング操作のコストが増加します。Layout計算、スタイルの再計算、Paint操作のそれぞれでより多くのノードを処理する必要があり、main threadにより多くの時間がかかります。CSSとJavaScriptが適切に最適化されていても、肥大化したDOMはその量だけでレンダリング遅延を増加させます。DOMサイズを縮小する詳細な戦略については、過大なDOMサイズを回避するのガイドを参照してください。

解決策： 最初のレンダリングに参加するDOMノードの数を減らします。

  • HTML構造を簡素化する： 不要なラッパー要素を削除します。深くネストされた構造をフラットにします。レイアウトのための余分な<div>要素の代わりに、CSS GridやFlexboxを使用します。
  • 長いリストを仮想化する： 何百ものリスト項目（製品グリッド、データテーブルなど）があるページでは、viewportに現在表示されている項目のみをレンダリングする仮想化ライブラリを使用します。
  • ファーストビュー外のコンテンツを遅延レンダリングする： content-visibility: auto（後述）を使用して、画面外のセクションのレンダリングを完全にスキップします。

高度な戦術：レンダリングを完全に制御する

複雑なアプリケーションでは、main threadをさらに制御する必要があります。

content-visibilityでパフォーマンスを解放する

CSSのcontent-visibilityプロパティは、大きなページ向けに構築されています。ファーストビュー外のセクションにcontent-visibility: auto;を設定することで、そのコンテンツがviewportに入る直前まで、ブラウザにLayout、Paint、Compositeの作業をスキップできることを伝えます。これにより初期レンダリングの作業負荷が削減され、main threadが解放されて、より早くLCP要素を描画できるようになります。

重要なのは、content-visibility: autoとcontain-intrinsic-sizeを組み合わせることです。これにより、非表示のコンテンツにプレースホルダーのサイズが提供されます。これがないと、ブラウザは非表示のセクションの高さがわからないため、スクロールバーの動作が不安定になります。

/* ファーストビュー外のセクションに適用 */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* セクションの推定高 */
}

/* 例：長い記事ページ */
.article-comments {
  content-visibility: auto;
  contain-intrinsic-size: auto 800px;
}

.related-products {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

.site-footer {
  content-visibility: auto;
  contain-intrinsic-size: auto 300px;
}

パフォーマンスへの影響： Chrome Developersのブログ記事によると、ブログページのファーストビュー外のセクションにcontent-visibility: autoを適用すると、レンダリング時間が最大1/7に短縮されました。ブラウザはこれらのセクションのLayout、Paint、Compositeの作業を完全にスキップするため、main threadが解放され、LCP要素を含むファーストビューのコンテンツに集中できます。ブラウザのサポートは、Chromium、Firefox、Safari 18+など、すべてのモダンブラウザをカバーしています。

Web Workersで作業をオフロードする

Web Workersを使用すると、main threadから完全に離れたバックグラウンドスレッドでJavaScriptを実行できます。Workerで実行される重い計算はレンダリングをブロックしません。このサイト（corewebvitals.io）は、分析処理にWeb Workerを使用しており、パフォーマンス上のメリットは本物です。main threadは中断されることなくPaintのために空いた状態を維持します。

とはいえ、Web WorkersはほとんどのWebサイトで一般的なパターンではありません。個別のJavaScriptファイルや、postMessageによる通信が必要であり、DOMにはアクセスできません。ほとんどのCMSプラットフォームやサイトビルダーはWeb Workersを組み込みでサポートしていないため、カスタム開発なしで実装するのは困難です。使用できる技術力がある場合、main threadを空けておくための最も効果的な方法の1つです。しかし、ほとんどのチームにとっては、このページで紹介している他の最適化の方が実践的な効果は大きくなります。

// main.js：Workerを作成し、処理用のデータを送信する
const worker = new Worker('/js/analytics-worker.js');

// 重い分析処理をWorkerスレッドにオフロードする
worker.postMessage({
  type: 'process-events',
  events: collectedEvents
});

// main threadをブロックせずに結果を受け取る
worker.onmessage = (event) => {
  console.log('Analytics processed:', event.data.summary);
};

// analytics-worker.js：バックグラウンドスレッドで実行される
self.onmessage = (event) => {
  if (event.data.type === 'process-events') {
    // ここでmain thread外で重い計算が行われる
    const summary = processEvents(event.data.events);
    self.postMessage({ summary });
  }
};

現実世界での影響

  • ケース1：render blockingなCSSによるボトルネック： DebugBearの分析によると、あるサイトでは巨大なCSSファイルが顕著なレンダリング遅延を引き起こしていました。LCP画像はダウンロードされていましたが、ブラウザはCSSの解析で立ち往生していました。クリティカルなCSSをインライン化するだけで、HTMLの解析後ほぼすぐにLCP要素を含むページコンテンツを描画できるようになり、スタイルシートによるレンダリング遅延が実質的になくなりました。
  • ケース2：A/Bテストによるペナルティ： ある大手Eコマースサイトは、同期型のA/BテストスクリプトがLCPの足を引っ張っていることを発見しました。LCP画像がすばやくダウンロードされても、どの製品画像を表示するかを決定する間、スクリプトがmain threadをブロックしていました。クリティカルではない要素のA/Bテストを最初のページ読み込み後に実行するように移動したところ、LCPが即座に400ms以上改善され、そのすべてがElement Render Delayから回復したものでした。

チェックリスト：Element Render Delayを排除する方法

Element Render Delayが大きい場合、main threadが混雑していることを示します。解決策は、ブラウザがPaintを行えるようにその混雑を解消することです。

  1. RUMで検証する： 最適化を始める前に、実際のユーザーデータを使用して、Element Render DelayがLCPの主要なボトルネックであることを確認してください。
  2. 未使用のCSSを削除する： 適用されないCSSルールを監査して削除します。これは最も影響の大きいCSS最適化です。PurgeCSSやDevToolsのCoverageタブなどのツールを使用してください。
  3. スタイルシートを小さく、キャッシュ可能に保つ： CSSファイルあたり約10〜15kB（圧縮時）を目指します。高速にダウンロードできるほど小さく、過剰な並列リクエストを避けられるほど十分な大きさです。再訪問者のためにブラウザにキャッシュさせてください。
  4. JavaScriptのlong taskを分割する： 1つのスクリプトを50ms以上実行しないでください。main threadへyieldして、レンダリングの更新を許可してください。
  5. サードパーティスクリプトを監査して遅延させる： 各サードパーティスクリプトが本当にページに必要か自問してください。最初のPaintに不可欠でないものはすべて遅延させます。
  6. SSRまたはSSGを使用する： LCP要素のレンダリングをクライアントサイドのJavaScriptに依存しないでください。サーバーから完全に構築されたHTMLを送信してください。
  7. 即座にLCPが表示されるようにする： ページ読み込み時にLCP要素を隠すようなアニメーション、スクリプト、スタイルを削除してください。
  8. content-visibility: autoを使用する： 長いページでは、画面外のコンテンツのレンダリングをスキップするようブラウザに指示し、ファーストビューのPaintのためにmain threadを解放してください。
  9. DOMサイズを縮小する： 深くネストされたHTMLをフラットにし、不要なラッパーを削除し、長いリストを仮想化して、LayoutとPaintの操作コストを削減してください。

次のステップ：LCPの最適化を続ける

Element Render Delayは最終フェーズです。4つすべてをカバーするには、以下を続けてください。

  • LCPの課題を特定して修正する：field dataとラボツールを使用してすべてのLCPの問題を見つけて修正するための、完全な診断手法です。
  • LCP画像を最適化する：画像フォーマットの選択、レスポンシブ画像、preload、および一般的な画像最適化のミスについて解説します。
  • Resource Load Delay：ブラウザができるだけ早くLCPリソースを発見できるようにします。これは多くの場合、LCPの最大のボトルネックとなります。
  • Resource Load Duration：圧縮、モダンなフォーマット、CDN構成、ネットワークの最適化を通じて、ダウンロード時間を短縮します。

大規模サイトのCore Web Vitalsを通してきました。

欧州の大手メディアやEコマース基盤で50万ページ超。修正コードを書き、フィールドデータで効果を検証します。

進め方を見る
LCP要素のレンダリング遅延を最適化してください。 Core Web Vitals LCP要素のレンダリング遅延を最適化してください。