言語

クリティカルレンダリングパス

ブラウザーがバイト列を画面上のピクセルへ変換する工程を、DOM、CSSOM、レンダーツリー、レイアウト、描画の順に解説します。CSSとJavaScriptがレンダリングを妨げる仕組み、3つの最適化軸、FCP・LCP・Googlebotのレンダリングとの関係も扱います。

初回公開：2026年6月26日 · 最終更新：2026年8月11日 · Advanced
言語
AI執筆者：AI v2

クリティカルレンダリングパス（CRP）は、ブラウザーが最初のピクセルを描画するまでに依存関係に沿って行う処理です。HTMLからDOM、CSSからCSSOMを構築し、両者をレンダーツリーにまとめ、レイアウトと描画へ進みます。これは有用な説明モデルですが、常に一度だけ固定順序で動くわけではありません。適用対象のCSSはCSSOMができるまで描画を妨げ、同期JavaScriptはDOM解析を止めます。最適化では、クリティカルリソースの数、クリティカルパスの長さ、クリティカルバイト数を減らします。FCPはCRPの進行を示す節目で、長いCRPはLCPも遅らせ得ます。GooglebotのWeb Rendering ServiceもステートレスなヘッドレスChromiumを使うため、重要なCSSやJavaScriptをrobots.txtで遮断してはいけません。

要点 — CRPは、HTML → DOM、CSS → CSSOM、レンダーツリー → レイアウト → 描画という処理です。CSSはCSSOM完成まで描画を止め、同期JavaScriptはDOM解析を止めます。クリティカルリソース数、パス長、バイト数を減らしてください。FCPは節目であり原因診断ではありません。WRSはステートレスなヘッドレスChromiumを使うため、重要なCSSやJavaScriptをrobots.txtで遮断しないでください。対策にはクリティカルCSSのインライン化、メディアクエリ、defer、確認済みリソースへのpreloadがあります。

5段階の工程（バイト列からピクセルまで）

静的HTMLでもJavaScriptアプリでも依存順序は同じです。ただし固定した5段階を一度ずつ動かすわけではなく、到着するHTMLを順次解析し、処理を並行・再実行します。依存関係を考える説明モデルとして使ってください。

1. HTML → DOM。 “Bytes → characters → tokens → nodes → object model.” (翻訳) 「バイト列 → 文字 → トークン → ノード → オブジェクトモデル」です。 ブラウザーは “reads the raw bytes of HTML off the disk or network, and translates them to individual characters,” (翻訳) 「ディスクまたはネットワークからHTMLの生バイト列を読み、個々の文字へ変換」します。 “The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing.” (翻訳) 「最終出力がDOMであり、ブラウザーは以後の処理に使用します。」

2. CSS → CSSOM。 “The CSS bytes are converted into characters, then tokens, then nodes, and finally they are linked into a tree structure known as the ‘CSS Object Model’ (CSSOM).” (翻訳) 「CSSのバイト列は文字、トークン、ノードへ変換され、最後にCSSOMというツリーへ結合されます。」 “The CSSOM and DOM are independent data structures” (翻訳) 「CSSOMとDOMは独立したデータ構造」です。

3. DOM + CSSOM → レンダーツリー。 “The DOM and CSSOM trees combine to form the render tree,” (翻訳) 「DOMとCSSOMが結合してレンダーツリーを形成」し、 “captures all the visible DOM content on the page.” (翻訳) 「ページ上の可視DOMコンテンツを捉えます。」 display: noneは要素をツリーから外し、visibility: hiddenは領域を残して描画だけを止めます。

4. レイアウト。 “Layout computes the exact position and size of each object.” (翻訳) 「各オブジェクトの正確な位置と大きさを計算します。」 出力は “a ‘box model,’ which precisely captures the exact position and size of each element within the viewport.” (翻訳) 「ビューポート内の各要素を正確に表すボックスモデル」です。

5. 描画。 “The last step is paint, which takes in the final render tree and renders the pixels to the screen.” (翻訳) 「最後にレンダーツリーから画面へピクセルを描きます。」

6. 合成と表示。 描画レイヤーを合成して画面へ出します。transformやopacityはレイアウトや描画をやり直さず合成だけを再実行できるため、アニメーション負荷が低くなります。

Evidence for this claim The browser constructs the DOM and CSSOM, combines them into a render tree, performs layout, and paints pixels. Scope: web.dev explanation of the browser's critical rendering path. Confidence: high · Verified: web.dev: Constructing the object model

CRPは初回描画前に完了すべき部分です。web.devは “all about understanding what happens in these intermediate steps between receiving the HTML, CSS, and JavaScript bytes and the required processing to turn them into rendered pixels.” (翻訳) 「HTML、CSS、JavaScriptのバイト列を受け取ってから描画済みピクセルへ変えるまでの中間段階を理解することが重要」と説明します。

2種類のブロックと異なる仕組み

SEO解説で混同されやすい違いを正確に押さえます。

CSSは適用対象なら描画を止めます。 “By default, CSS is treated as a render-blocking resource, which means that the browser won’t render any processed content until the CSSOM is constructed.” (翻訳) 「既定ではCSSはレンダリング阻害リソースで、CSSOM構築まで処理済みコンテンツを描画しません。」 DOMとCSSOMがそろうまで描画を待ちます。ただし、条件に一致しないmedia="print"などは初回描画を妨げません。適用条件は後から変わり得るため、遅い対象スタイルシートは初回描画全体を待たせます。 現在の条件は <link> の media 属性で決まり、例は <link rel="stylesheet" media="print"> です。

JavaScriptはDOM解析を止めます。 “whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML,” (翻訳) 「パーサーはスクリプトに遭遇すると停止・実行してからHTML解析を続けます。」 “in the case of an external script the parser is also forced to wait for the resource to download.” (翻訳) 「外部スクリプトでは取得完了も待ちます。」 “By default JavaScript blocks DOM construction and thus delays the time to first render.” (翻訳) 「既定ではJavaScriptがDOM構築を止め、初回レンダリングを遅らせます。」 プリロードスキャナーは停止中も後続リソースを取得します。asyncは到着時に解析を中断し得るため、通常は順序を保つdeferが安全です。

Evidence for this claim CSS is render-blocking by default, while parser-blocking scripts stop DOM construction until execution completes. Scope: Default stylesheet and synchronous script behavior in the critical rendering path. Confidence: high · Verified: web.dev: Render-blocking CSS web.dev: Adding interactivity with JavaScript

3つの最適化軸

“To deliver the fastest possible time to first render, we need to minimize three variables: The number of critical resources. The critical path length. The number of critical bytes.” (翻訳) 「初回レンダリングを最速にするには、クリティカルリソース数、パス長、バイト数を最小化します。」 “critical resource is a resource that could block initial rendering of the page.” (翻訳) 「クリティカルリソースは初回レンダリングを妨げ得るリソース」です。

  • リソース数を減らす — 削除、遅延、非同期化します。
  • パス長を短くする — “a function of the dependency graph between the critical resources.” (翻訳) 「クリティカルリソース間の依存グラフで決まる」ため往復を減らします。
  • バイト数を減らす — “the fewer critical bytes the browser has to download, the faster it can process content.” (翻訳) 「取得するクリティカルバイトが少ないほど処理が速くなります。」

クリティカルCSSを<head>へインライン化し、残りを非同期化します。非クリティカルCSSはメディアクエリ、JavaScriptはdefer、確認済みリソースはpreloadします。AhrefsのLCPガイドでは “you want to rearrange the order in which the resources are downloaded and processed” (翻訳) 「リソースの取得・処理順を組み替える」と説明しています。 クリティカルCSSは “takes the part of the CSS needed to load the content users see immediately and then applies it directly into the HTML.” (翻訳) 「すぐ見える内容に必要なCSSを取り出し、HTMLへ直接適用する」方法です。

preloadとfetchpriorityは別物です。 前者は未発見リソースを早期取得し、後者は既存リクエストの優先度を示します。誤ったURL、as、資格情報モードは未使用や重複取得を招きます。ウォーターフォールで経路上にあると確認し、変更前後を再測定してください。

Core Web Vitalsとの関係

CRPは開発者だけの問題ではありません。

  • FCPは節目であり完全な診断ではありません。 遅いFCPを手掛かりにトレースで原因を特定します。
  • LCPも遅延を引き継ぎます。 Abby Hamiltonは “Optimizing the critical rendering path will typically have the largest impact on Largest Contentful Paint (LCP) since it’s specifically focused on how long it takes for pixels to appear on the screen.” (翻訳) 「CRP最適化は通常LCPに最も大きく影響します。ピクセルが画面へ現れる時間に焦点を当てるためです。」 web.devは “A large delta between TTFB and FCP could indicate that the browser needs to download a lot of render-blocking assets.” (翻訳) 「TTFBとFCPの差が大きいと、多数の阻害リソース取得を示す可能性があります。」根本原因はウォーターフォールで確認します。
  • TBTとINPはJavaScriptの影響を受けます。 メインスレッド上の長いタスクは操作性を損ないます。

LCPとFCPは経路の速さに左右されます。LCPはランキングシグナルですが、個別の影響はCrUXやSearch Consoleで確認してください。

Googlebotへの影響

GoogleのWRSは “processes JavaScript web apps in three main phases: Crawling, Rendering, Indexing,” (翻訳) 「JavaScriptアプリをクロール、レンダリング、インデックス登録の3段階で処理」します。 “Once Google’s resources allow, a headless Chromium renders the page and executes the JavaScript” (翻訳) 「リソースに余裕ができるとヘッドレスChromiumがページを描画しJavaScriptを実行」し、 “an evergreen version of Chromium.” (翻訳) 「常に最新のChromium」を使います。 共通基盤から阻害リソースがGooglebotも遅らせると推測できますが、ユーザーとの完全な同等性やランキング影響を証明するものではありません。

覚えておくべき影響は3つです。

  • レンダーキューが遅延を加えます。 “a few seconds, but it can take longer than that” (翻訳) 「数秒、ときにはそれ以上」待つため、遅いCRPが加算されます。
  • WRSはステートレスです。 JavaScript SEOガイドの “Google loads each page stateless like it’s a fresh load.” (翻訳) 「Googleは各ページを初回のようにステートレスで読み込みます。」 WRSは “may ignore caching headers,” (翻訳) 「キャッシュヘッダーを無視する場合があり」、 “may lead WRS to use outdated JavaScript or CSS resources.” (翻訳) 「古いJavaScriptやCSSを使う可能性があります。」
  • robots.txtで重要リソースを遮断しない。 “Don’t block access to resources if they are needed to build part of the page or add to the content.” (翻訳) 「ページ構築やコンテンツ追加に必要ならアクセスを遮断しないでください。」

Bingにも同じ原則が当てはまります。BingbotのJavaScript予算はより厳しいため、軽い経路が重要です。

例外：早い描画でも実コンテンツがあるとは限らない

クライアントレンダリング型アプリはシェルだけを早く描いてFCPを満たし、実コンテンツはJavaScriptの取得・実行・データ取得を待つことがあります。これはシェルの経路が終わっただけです。

サーバーレンダリングや静的HTMLは意味のある内容を初期マークアップに含みます。JavaScriptの多いページではFCP時点の画面と主要コンテンツの表示時点を別々に確認します。

SEO担当者がCRPに出会う場所

PageSpeed InsightsやLighthouseの監査が主な接点です。Abby Hamiltonは “navigate to ‘Eliminate render-blocking resources’ under ‘Diagnostics,’ and expand the content to see a list of first-party and third-party resources blocking the first paint.” (翻訳) 「Diagnosticsの該当項目を展開し、初回描画を妨げる自社・第三者リソースを確認する」と説明します。WebPageTestの「Start Render」とDevToolsのCoverageも使い、単一計測は環境で変わる標本として扱います。

関連トピック

このページはレンダリング阻害問題のハブです。実践的な詳細は次の階層にあります。

  • レンダリングを妨げるリソース — PageSpeed Insights、Lighthouse、WebPageTestでCSSとJavaScriptを特定し、asyncとdefer、クリティカルCSS、メディアクエリ、監査警告の修正を扱います。

関連指標はCore Web Vitals、Largest Contentful Paint（LCP）、First Contentful Paint（FCP）を参照してください。Googlebotの工程はJavaScript SEOと検索の仕組みで扱います。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.