漆黒の空白を塗りつぶせ：Paint Holdingが支える「遷移の幻想」
ブラウザのレンダリングパイプラインを深く掘り下げている諸君なら、一度は「ページ遷移時のあの瞬間の空白」に苛立ちを覚えたことがあるはずだ。HTMLがパースされ、DOMツリーが構築され、リフローが発生し、ようやく最初のピクセルが描画される。その間の数ミリ秒から数百ミリ秒。この「空白」をいかにしてユーザーの視界から消し去るか、それが現代のWebパフォーマンスチューニングの最前線だ。
今回は、ブラウザが密かに実行している魔法、「Paint Holding（ペイントホールド）」の深層に切り込む。
—
Paint Holdingとは何か：視覚的連続性のための「時間稼ぎ」
Paint Holdingは、Chromiumエンジンが採用している「遷移時の視覚的な繋ぎ」を最適化する技術だ。簡潔に言えば、「次のページが準備できるまで、前のページのスクリーンショットを（あるいは現在の状態を）保持して表示し続ける」というものだ。
ユーザーにとって、ページ遷移とは「情報の更新」であって「画面が真っ白になること」ではない。Paint Holdingは、メインスレッドがJavaScriptの実行やLayout計算で忙殺されている間、前ページの状態を「一時的なビットマップ」として保持し、それを compositor thread（合成スレッド）経由でスクリーンに貼り付ける。これによって、ユーザーは「アプリがフリーズした」という感覚を抱かずに済むわけだ。
メモリとトレードオフの境界線
しかし、アーキテクトとして冷静に考えるべきは、この「保持」がただの魔法ではないという点だ。
1. VRAMの占有: 前ページのスクリーンショットを保持するということは、GPUメモリ（VRAM）にそのテクスチャを確保し続けることを意味する。低スペック端末で巨大なDOMを持つページから遷移しようとすると、メモリ負荷が急上昇する。
2. Stale Contentの罠: Paint Holdingは強力だが、裏を返せば「古い情報を表示し続けるリスク」を孕んでいる。例えば、遷移先が非常に速いレスポンスを返したのに、Paint Holdingの保持時間が長すぎると、一瞬だけ「古いページが二重に見える」「更新されていないように見える」といった違和感が生じる。
実務で遭遇する「Paint Holdingの敵」と回避策
エンジニアとして最も警戒すべきは、「Paint Holdingが機能しない（あるいは期待外れな）状況」を自ら作り出してしまうことだ。
特に、SPA（Single Page Application）のルーター設計でやってはいけないのが、「遷移のトリガー直後に重い同期処理を走らせること」である。
回避策：プログレッシブ・レンダリングの意識
ReactやVueのコンポーネント設計において、遷移時に巨大な重い初期化処理を `useLayoutEffect` などで同期実行すると、ブラウザの合成スレッドがPaint Holdingを解除するタイミングを見失うことがある。
// 悪い例：遷移直後に重い同期処理を行い、レンダリングをブロックする
// これによりPaint Holdingの恩恵が帳消しになり、真っ白な画面が露出する
function heavyInitialization() {
const start = performance.now();
while (performance.now() – start < 100) {
// 100msの同期的なブロック：ここでブラウザはPaint Holdingを維持できなくなる
}
}
// 良い例：非同期で処理を逃がし、ブラウザのレンダリングサイクルを優先する
async function optimizedInitialization() {
await new Promise(resolve => requestAnimationFrame(resolve));
// 描画サイクルに一度制御を戻してから計算を行う
performComplexTask();
}
アーキテクトが知るべき「合成スレッド」との対話
Paint Holdingを最大限に活かすためには、「 Compositor-Only Properties」を意識しなければならない。
ブラウザのレンダリングパイプラインにおいて、JavaScriptやLayout計算を避けることができれば、CompositorスレッドはPaint Holdingを維持したまま、スムーズに次のフレームへ移行できる。
- Avoid Layout-Triggering: `width`/`height` ではなく `transform` を使う。
- Layer Optimization: `will-change: transform` を適切に適用し、要素を独立した合成レイヤーとして扱う。
もし、貴方のアプリケーションの遷移がガタつくなら、Paint Holdingが機能していないのではなく、「Paint Holdingを維持するためのGPUリソースが、過剰なレイヤー生成によって食い潰されている」可能性を疑うべきだ。
結論：技術は「騙し」の連続である
Webブラウザの仕組みとは、詰まるところ「いかにしてユーザーの脳を騙し、滑らかであると信じ込ませるか」という高度な欺瞞の歴史である。Paint Holdingはその中でも、非常に泥臭く、しかし極めて効果的な「視覚的バッファ」だ。
我々上級エンジニアの責務は、この仕組みに依存し切るのではなく、ブラウザが「保持」しやすく、かつ「次」へスムーズに引き継げるような、クリーンで軽量なレンダリングツリーを構築することにある。
次回のブログでは、このPaint Holdingをさらに加速させる「Back/Forward Cache (bfcache)」との連携と、その時のメモリ管理の闇について深掘りしようと思う。現場からは以上だ。コードの最適化を怠るな。
コメント