- ブラウザURL入力今ここ
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理
- DB保存
第27週でリクエストがアプリに届くまでの段を追いました。今回はその先、受け取ったHTMLとCSSが画面のピクセルになるまでに、ブラウザの内側でどう段が区切られているかを扱います。
まず結論
Chromium公式(RenderingNG)がレンダリングパイプラインとして挙げているのは **12段**です。逐語の1段目は **Animate** で、通説の先頭にある **Parse という段はこの一覧に存在しません**。
広く教えられている「Parse → Style → Layout → Paint → Composite」や CSSOM・render tree・Critical Rendering Path・reflow は、**Chromium の設計文書には出てきません**。4語を揃えて使うのは2014年の web.dev 解説記事で、CSSOM は W3C の仕様名、render tree は WebKit、reflow は Gecko の用語でもあります。誤りだと公式が書いているわけではなく、**出所が違う**という話です。
Chromium公式の設計文書(RenderingNG)が挙げるレンダリングパイプラインの1段目は、次のどれでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
公式が挙げているのは12段
レンダリングの段について尋ねれば、ほぼ確実に5つの語が返ってきます。Parse → Style → Layout → Paint → Composite。
Chromium公式の RenderingNG は、同じものをこう書いています。
Rendering proceeds in a pipeline with a number of stages and artifacts created along the way. Each stage represents code that does one well-defined task within rendering.
The stages are:
続く一覧は12段です。
1 Animate 計算済みスタイルとプロパティツリーを時間とともに変える2 Style apply CSS to the DOM, and create computed styles3 Layout 大きさと位置を決め、the immutable fragment tree を作る4 Pre-paint プロパティツリーを計算し、既存の display list とGPUテクスチャタイルを必要に応じて無効化する5 Scroll スクロール量を更新する(プロパティツリーの変更として)6 Paint display list を計算する7 Commit プロパティツリーと display list をコンポジタスレッドへコピー8 Layerize display list を合成レイヤのリストに分割する9 Raster, decode and paint workletsGPUテクスチャタイルに変換する10 Activate コンポジタフレームを作る11 Aggregate 見えている全フレームを1つの大域フレームにまとめる12 Draw GPU上で実行してピクセルを作る
1段目は Animate です。Parse ではありません。 そして一覧のどこにも Composite という名前の段はありません。
ハイライトした4行が、通説と公式のズレが出る場所です。Pre-paint と Commit は通説の5段に対応物がありません。通説が「Composite」の1語でまとめている部分を、公式は Commit 以降の6段に割っています。
公式12段の中で、通説の「Composite」に相当する処理はどうなっていますか。
では5段モデルはどこから来たのか
ここで大事なのは、5段モデルを「間違い」と断じないことです。分かっているのは出所です。
語 Chromium設計文書 HTML仕様 web.dev 2014年記事 ほかの出所CSSOM 0件 参照あり あり W3C 仕様名(2011年)render tree 0件 0件 あり WebKit(2007年)Critical Rendering Path 0件 0件 あり -reflow 0件 0件 あり(layoutの別名) Gecko の段名
4語とも、RenderingNG の全ページ・Chromium ソース内の docs/how_cc_works.md と paint の README・CSS Will Change 仕様のいずれにも1回も出てきません。HTML Living Standard でも render tree・Critical Rendering Path・reflow は0件ですが、CSSOM だけは参照する仕様の名前として出てきます(CSSOM defines what happens when the attribute is dynamically set, changed, or removed.)。
4語を揃えて使っているのは web.dev の連載記事です。公開日は 2014年3月31日。「Render-tree Construction, Layout, and Paint」にはこうあります。
The DOM and CSSOM trees combine to form the render tree.
「Constructing the Object Model」にはこうあります。
DOM and CSSOM are independent data structures.
5ステップのまとめは、前者の記事にあります。
Process HTML markup and build the DOM tree. Process CSS markup and build the CSSOM tree. Combine the DOM and CSSOM into a render tree. Run layout on the render tree to compute geometry of each node. Paint the individual nodes to the screen.
この5ステップは DOM → CSSOM → render tree → layout → paint で、Composite は出てきません(連載3本で composit を含む語は0件)。Composite まで入った型は、web.dev の別記事「Rendering performance」の JS / CSS > Style > Layout > Paint > Composite です(最終更新 2023-12-13。初出の年は確かめられていません)。Parse から Composite までをこの並びで書いた出所は、探した範囲では特定できていません。 一方、公式が Layout の出力として挙げるのは render tree ではなく the immutable fragment tree です。
reflow は同じ記事に1箇所だけ出てきます。
that's the "layout" stage, also known as "reflow."
この語は Firefox(Gecko)では現役の段名で、Layout Overview は Reflow is the process of computing the positions and sizes of frames. と書いています。Chromium 公式の呼称は Layout です。
「CSSOM」という語は、RenderingNG や Chromium のソース内ドキュメントにどれくらい出てきますか。
「5段モデルは公式仕様」という帰属
5段という整理そのものは、web.dev の解説記事などに実在する説明モデルです。誤りが生まれるのは「これはブラウザの公式な区分だ」と一段付け足された瞬間です。公式12段には Parse も Composite も無く、Pre-paint と Commit という対応物の無い段があります。
web.dev 2014年記事に5ステップがある 確認済み公式は12段で1段目は Animate 確認済み公式に Parse 段 / Composite 段は無い 確認済み公式が5段モデルを誤りと述べている 確認できず
第48週で見た「398日」の型
証明書の有効期間をAIが「398日です」と即答する現象を第48週で扱いました。値が解説記事に強く残っていること、そして曖昧に答えるより具体的に断定するほうが報われる採点の形が重なっています。ここでも誤っているのは語そのものではなく、いつ・どこの規定かという限定が落ちている点です。
元の状態 「解説記事ではこう説明される」落ちた後 「ブラウザのレンダリングは5段である」元の状態 「その時期に発行された証明書は398日」落ちた後 「証明書の有効期間は398日です」
片方はレンダリングの段の数、もう片方は証明書の日数です。まったく別の話題ですが、同じ形の誤りが生まれています。共通する構造は何でしょうか。
「何が書かれているか」ではなく、「いつ・どこに書かれているか」という限定に注目して両方を追ってください。
この章のまとめ
- Chromium公式(RenderingNG)が挙げるのは 12段。1段目は Animate で、Parse という段は一覧に無い。
- 通説が「Composite」1語でまとめる部分を、公式は Commit / Layerize / Raster / Activate / Aggregate / Draw の6段に割っている。通説に対応物の無い段が Pre-paint と Commit。
- CSSOM・render tree・Critical Rendering Path・reflow は、確認した Chromium 設計文書にヒット0件。 4語を揃えて使うのは web.dev の2014年3月31日の記事で、個々の語には W3C・WebKit・Gecko という別の出所もある。
- ★ ただし「これらの語は誤り」と書いた公式文書は見つかっていない。 誤るのは語そのものではなく、「公式の用語だ」という帰属のほう。
- 公式が段を分ける理由は「飛ばせるから」。逐語は
Stages of the rendering pipeline can be skipped if they aren't needed.という 条件付きの言い方。 - 第48週と同じ型。内容は実在するのに、限定が落ちると短く強い断定になり、再生産される。
- 検証の限界も記録されている。**「0件」は「この範囲では見つからなかった」**という意味。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「ブラウザのレンダリングは Parse → Style → Layout → Paint → Composite の5段である。これは Chromium の公式仕様だ」——この記述の評価はどれですか。
用語集(5語)
- RenderingNG
- Chromium のレンダリングアーキテクチャについての公式解説群(Chrome for Developers)。レンダリングパイプラインを12段に区切って記述している。
- Animate(1段目)
- 公式の逐語は `change computed styles and mutate property trees over time based on declarative timelines.` 宣言的なタイムラインに沿って、計算済みスタイルとプロパティツリーを時間とともに変える段。
- Pre-paint(4段目)
- 通説の5段に対応するものが無い段。公式の逐語は `compute property trees and invalidate any existing display lists and GPU texture tiles as appropriate.`
- Commit(7段目)
- 同じく通説に対応物が無い段。公式の逐語は `copy property trees and the display list to the compositor thread.` スレッドをまたぐコピーがここで起きる。
- Critical Rendering Path
- web.dev の2014年3月31日公開の記事の用語。Chromium設計文書・HTML仕様には出てこない(grep ヒット0件)。誤りとされているわけではなく、出所が解説記事である、ということ。
出典(一次ソース)
- RenderingNG architecture — The rendering pipeline(12段の逐語) ↗
- Critical Rendering Path(web.dev, 2014-03-31) ↗
- Render-tree Construction, Layout, and Paint(web.dev, 2014-03-31 — render tree と reflow を使う解説) ↗
- Constructing the Object Model(web.dev — 「DOM と CSSOM は independent data structures」の出所) ↗
- Rendering performance(web.dev — JS / CSS > Style > Layout > Paint > Composite の型) ↗
- CSSOM, W3C First Public Working Draft(2011-07-12) ↗
- WebCore Rendering I – The Basics(WebKit blog, 2007-08-08 — render tree) ↗
- Layout Overview(Firefox Source Docs — Gecko の Reflow) ↗
- HTML Standard — References([CSSOM] の参照) ↗