Chrome の Declarative Partial Updates - HTML 部分更新とアウトオブオーダー・ストリーミングがブラウザ標準になる(2026年6月時点)

Chrome の Declarative Partial Updates - HTML 部分更新とアウトオブオーダー・ストリーミングがブラウザ標準になる(2026年6月時点)

作成日:
読了:約16分
更新日:
ChromeWeb標準HTMLストリーミングフロントエンド

ページの一部だけを後から差し込む、読み込みが終わった順に表示する、という「部分更新」は、これまで React の Suspense や Astro の Islands、htmx といったフレームワーク/ライブラリの仕事でした。それをブラウザのプリミティブとして提供しようという提案が、Google I/O 2026 で発表された Declarative Partial Updates です。

この記事では、2026年5月19日公開の Chrome 公式ブログを一次ソースに、Declarative Partial Updates とは何か、<?marker> や <template for> を使ったアウトオブオーダーな HTML ストリーミングの構文、setHTML() / appendHTML() / streamHTML() といった新しい HTML 挿入 API、そして2026年6月時点でのステータスを、Web 開発者向けに整理します。

NOTE

本記事の内容は2026年6月時点のものです。Declarative Partial Updates は Chrome 148 で実験的フラグの背後で試せる段階であり、Web 標準として確定したものではありません。API 名や構文は今後変わる可能性があります。

何が問題だったのか

サーバーから HTML を返す Web では、長らく「上から順番（in-order）」にしかストリーミングできないのが基本でした。ページ上部のヘッダーから順に流すしかなく、下のほうで先に準備できたコンテンツがあっても、上が詰まっていれば待たされます。

これを回避するために、各フレームワークはそれぞれの仕組みを作ってきました。React の Server Components と Suspense によるストリーミング、Astro の Server Islands、htmx の hx-swap による部分差し替えなどです。発想は似ているのに、実装はバラバラで、しかもいずれもJavaScript ランタイムやフレームワーク固有の DOM 操作に依存していました。

Declarative Partial Updates は、この「部分更新」と「アウトオブオーダー・ストリーミング」を、フレームワークではなくHTML とブラウザ API のレベルで扱えるようにする提案です。Chrome 公式ブログ(著者は Barry Pollard と Noam Rosenthal)は、これを大きく2つのセットに分けて説明しています。

  1. アウトオブオーダーな HTML ストリーミング: <template> と処理命令(processing instruction)を使い、HTML 文書を順不同で組み立てる
  2. JavaScript からの HTML 挿入 API: setHTML() などの新メソッドで、既存文書へ宣言的に HTML を差し込む/ストリーミングする

順番に見ていきます。

アウトオブオーダーな HTML ストリーミング

最初のセットは、サーバーが HTML を「届いた順・準備できた順」で特定の場所へ流し込めるようにするものです。鍵になるのが、<template> 要素と、<?marker> のような処理命令(processing instruction)です。

プレースホルダーと template for

まず、後から埋めたい場所に名前付きのマーカーを置きます。

プレースホルダーを置く
<ul>
  <?marker name="results">
</ul>

そして、コンテンツが準備できたら、その名前を for 属性に指定した <template> を流します。

準備できたら template for で埋める
<template for="results">
  <li>最初の結果</li>
  <li>2番目の結果</li>
</template>

ブラウザは for="results" の <template> を受け取ると、その中身を name="results" のマーカー位置へ挿入します。文書のどこに template が来ても、指定した場所に差し込まれるため、HTML を順不同で流せるわけです。これが「アウトオブオーダー」の意味です。

範囲を置き換える start / end

マーカー1点ではなく、「ローディング表示を後から本物に差し替える」といった範囲の置き換えもできます。<?start> と <?end> で囲った部分が、後続の <template for> の中身で置き換わります。

ローディングを後から差し替える
<div>
  <?start name="placeholder">読み込み中…<?end>
</div>
 
<!-- 準備できたら -->
<template for="placeholder">
  <p>実際のコンテンツ</p>
</template>

最初に「読み込み中…」が表示され、データが揃ったタイミングで <template for="placeholder"> を流せば、その範囲が本物のコンテンツに置き換わります。JavaScript を一切書かずに、サーバー側のストリーミングだけで実現できるのがポイントです。

Loading diagram...

NOTE

セキュリティ上の理由から、<template for> のターゲットは同じ親要素の範囲に制限されるとされています。また、ストリーミング中に対象要素を移動させると予期しない挙動になり得ます。実験段階の制約として把握しておいてください。

JavaScript からの HTML 挿入 API

2つ目のセットは、すでに表示されている文書に対して、JavaScript から宣言的に HTML を挿入・ストリーミングするための新しいメソッド群です。これまで innerHTML や insertAdjacentHTML()、setHTMLUnsafe() などが場当たり的に増えてきた部分を、一貫した命名で整理し直す狙いがあります。

一括挿入のメソッド

要素に対して、位置ごとに対応するメソッドが用意されます。Chrome 公式ブログでは次のような名前が挙げられています。

メソッド役割
setHTML(html, options)要素の中身を置き換える
appendHTML(html, options)要素の末尾に追加する
prependHTML(html, options)要素の先頭に追加する
beforeHTML(html, options)要素の直前に挿入する
afterHTML(html, options)要素の直後に挿入する
replaceWithHTML(html, options)要素自身を置き換える

insertAdjacentHTML() の beforebegin / afterbegin / beforeend / afterend という分かりにくい指定が、それぞれ独立したメソッドとして整理されたイメージです。

重要なのは、これらがデフォルトでサニタイズされる方向で設計されている点です。options でサニタイザを渡したり、明示的に危険を承知で使う場合は Unsafe 接尾辞付きのメソッド(setHTMLUnsafe() など)を使う、という整理になっています。

サニタイズ前提の挿入とオプション
// 既定でサニタイズされる
contentElement.setHTML(newHTML);
 
// カスタムサニタイザを渡す
contentElement.setHTML(newHTML, { sanitizer: customSanitizer });
 
// 危険を承知でスクリプトを実行したい場合は Unsafe 版
contentElement.setHTMLUnsafe(newHTML, { runScripts: true });

innerHTML = ... がサニタイズしないのに対し、新 API はサニタイズを既定にすることで、XSS の事故を起きにくくする思想です。

ストリーミング版のメソッド

さらに、一括ではなく少しずつ流し込むためのストリーミング版も提案されています。streamHTML() や streamAppendHTML() など、上記メソッドに対応する stream...HTML() が用意され、Streams API の Writable Writer を介して書き込む形です。

ストリーミングで少しずつ書き込む
const writer = contentElement.streamHTMLUnsafe().getWriter();
await writer.write(`<p>${chunk1}</p>`);
await writer.write(`<p>${chunk2}</p>`);
// …受信した分だけ順次反映される

fetch() のレスポンスを読みながら、届いた分だけ DOM に反映する、といった用途を素直に書けるようになります。これまで ReadableStream を自前でパースして DOM を組み立てていた処理が、ブラウザ側のプリミティブで完結する可能性があります。

どんな場面で効くのか

Chrome 公式ブログが挙げているユースケースを、実務の言葉に置き換えると次のようになります。

  • Islands アーキテクチャ: 静的な HTML の上に、個別にハイドレーション/差し込みされるコンポーネントを置く構成。Astro が広めたパターンを、<template for> で HTML レベルに近い形で扱える。関連して Astro 7 リリース のような Islands 系フレームワークの動きも押さえておくとよいです
  • 準備できたものから出す: DB クエリや外部 API 待ちのブロックを <?start>/<?end> でプレースホルダーにしておき、揃った順にストリーミングする
  • パフォーマンス目的の並べ替え: HTML の見た目の順序と、サーバーが準備できる順序を切り離す
  • SPA 的な動的更新: streamHTML() 系で、受信しながら部分的に画面を更新する

特に「フレームワークなしでも、サーバーが順不同に HTML を流すだけで段階的レンダリングができる」点が、これまでとの大きな違いです。

現状のステータス(2026年6月時点)

ここはとても重要なので、正確に押さえてください。

Declarative Partial Updates は2026年6月時点で Web 標準として確定したものではありません。Chrome 公式ブログ(2026年5月19日公開)によれば、Chrome 148 で実験的フラグ chrome://flags/#enable-experimental-web-platform-features を有効にすると試せる段階です。Chrome 148 自体は2026年5月にステーブルへ到達していますが、この機能はその中で既定オフの実験的機能という位置づけです。

仕様の立場としては、Barry Pollard と Noam Rosenthal による2つの Web プラットフォーム提案であり、現時点では Chrome を中心に進んでいます。他ブラウザでの実装状況や、最終的な API の確定形は未確定/要確認です。API 名(setHTML などの命名や Unsafe の扱い)も、標準化の過程で変わる可能性があります。

WARNING

本番投入はまだ時期尚早です。実験的フラグ下の API は、予告なく変更・削除され得ます。クロスブラウザでの可用性が固まったかどうかは、Baseline などで最新状況を確認してください。ブラウザ対応の確認の考え方は Web Baseline とブラウザ対応の調べ方 を参考にしてください。

今すぐ試したい場合(ポリフィル)

提案者側は、ネイティブ対応を待たずに試せるよう npm でポリフィルを公開しているとされています。Chrome 公式ブログでは次の2つが紹介されています。

  • アウトオブオーダー・ストリーミング(<template for>)向けのポリフィル
  • HTML 挿入メソッド向けのポリフィル(ただしバッファリングして適用するため、真の意味でのストリーミングにはならない、とされる)

ポリフィルには制約があるため、挙動はクロスブラウザで検証する前提で扱うのが安全です。

既存技術との関係

この機能は単独で出てきたわけではなく、近年の「宣言的・ネイティブ志向」の流れの一部です。

  • View Transitions API: 画面遷移のアニメーションをブラウザ標準で扱う流れ。部分更新と組み合わせると、差し替え時の見せ方を滑らかにできます。詳しくは View Transitions API 入門 を参照してください
  • Speculation Rules API: 次に遷移しそうなページを宣言的に先読みする仕組み。こちらも「フレームワーク任せだった最適化をブラウザへ」という同じ思想です。Speculation Rules API ガイド で扱っています
  • 2026年のブラウザネイティブ機能全般: CSS を含めてブラウザ標準でできることが増えています。全体像は 2026年のブラウザネイティブ機能 を合わせて読むと位置づけが分かりやすいです

つまり Declarative Partial Updates は、「これまでフレームワークが埋めていた隙間を、Web プラットフォーム自身が埋めにいく」という近年の大きな潮流の中の1つ、と捉えると理解しやすいです。

まとめ

  • Declarative Partial Updates は、HTML の部分更新とアウトオブオーダー・ストリーミングをブラウザのプリミティブにする提案。Google I/O 2026 で発表されました
  • アウトオブオーダー・ストリーミングは <?marker> / <?start>・<?end> と <template for> の組み合わせで、HTML を順不同に組み立てます
  • HTML 挿入 API は setHTML() / appendHTML() / prependHTML() などと、対応する stream...HTML() 系で、サニタイズ既定・Unsafe 明示という設計です
  • ユースケースは Islands、準備できた順のストリーミング、SPA 的な部分更新など、これまでフレームワークが担っていた領域です
  • 2026年6月時点では Chrome 148 の実験的フラグ下の機能であり、Web 標準として確定していません。API 名や構文、他ブラウザ対応は未確定/要確認です。本番投入は時期尚早です

「部分更新はフレームワークの仕事」という前提が、少しずつブラウザ側へ移りつつあります。まだ実験段階ですが、サーバー駆動の段階的レンダリングを素のプラットフォームで書ける未来は、追いかける価値があります。

参考リンク

関連記事

Speculation Rules API 入門 - SPAでなくてもページ遷移を一瞬にする

Speculation Rules API 入門 - SPAでなくてもページ遷移を一瞬にする

約9分

Speculation Rules API を実務目線で整理します。script type=speculationrules の JSON でブラウザに prefetch / prerender を指示し、次に読まれるページを先読みして遷移を一瞬にする仕組みです。prefetch と prerender の違い、eagerness（immediate / eager / moderate / conservative）、list rules と document rules、そして prerender でアナリティクスが二重計上される落とし穴まで、ブログや EC で安全に使う勘所をまとめます。

パフォーマンスWeb標準ChromeフロントエンドWeb Vitals
Baseline 入門 - 「この機能もう使っていい？」をチームの共通語にする

Baseline 入門 - 「この機能もう使っていい？」をチームの共通語にする

約7分

Web の機能を採用するときの判断軸 Baseline を整理します。Newly available と Widely available の2段階、コアブラウザ集合の定義、Baseline 年バッジ、MDN / Can I Use / web.dev での表示、そして Browserslist や ESLint への組み込みまで。「caniuse を毎回見る」から「Baseline で判断する」へ、チームの共通言語にする方法をまとめます。

BaselineブラウザCSSフロントエンドWeb標準
Chrome の組み込み AI APIs 入門 - ブラウザ内 Gemini Nano で何ができて何がまだ実験的か

Chrome の組み込み AI APIs 入門 - ブラウザ内 Gemini Nano で何ができて何がまだ実験的か

約9分

Chrome に搭載されたオンデバイス AI（Gemini Nano）を使う組み込み AI APIs を整理します。Translator・Summarizer・Language Detector・Prompt・Writer・Rewriter・Proofreader それぞれの安定度、availability から create で使う共通の作法、サーバー LLM との使い分け、そしてフォールバック設計まで、実務で踏むべき注意点をまとめます。

ChromeAIフロントエンドGemini開発ツール