「0ミリ秒の体感」を実現する：Speculation Rules APIが変えるレンダリングの未来
フロントエンドの現場にいると、どうしても「いかに今の表示を速くするか」という最適化にリソースを割きがちだよな。Lighthouseのスコアを1点上げるために、画像を圧縮し、バンドルサイズを削り、再レンダリングを抑える。それはもちろん大事だ。
だが、最近のブラウザはもっと「先」を見ている。「ユーザーが次にどこをクリックするか」を予測し、まだページを開く前から裏側でレンダリングを開始する。それがSpeculation Rules APIだ。
今日は、この「未来を先取りする」技術について、現場のシニアエンジニアの視点で深掘りしていこうと思う。
—
1. そもそも、ブラウザは何を「先取り」しているのか？
これまで僕たちが使ってきた `rel=”prefetch”` や `rel=”preload”` は、言ってみれば「個別のリソース」を先読みするためのツールだ。一方で、Speculation Rulesは「ドキュメントそのもの」を先読みし、あまつさえレンダリングまで済ませてしまうという、いわば「裏で別ブラウザを立ち上げてページを開いておく」ような荒技なんだ。
レンダリングパイプラインへの影響
通常、リンクをクリックするとブラウザは以下のプロセスを辿る。
1. Network: リクエストを投げる
2. Response: HTMLを受け取る
3. Parsing: HTMLを解析し、DOMを構築する
4. Style/Layout/Paint: CSSOMを適用し、画面を描画する
Speculation Rulesを使うと、ユーザーがリンクを押す前に、バックグラウンドの「非表示のプロセス」で上記1〜4を完了させてしまう。ユーザーがクリックした瞬間、ブラウザは「既にメモリ上に存在するDOMツリー」をフォアグラウンドのタブにスワップさせるだけ。結果、遷移が0秒で完了するというわけだ。
—
2. 実装：JSONで「予言」を書き込む
Speculation Rulesは、HTML内に `
注意点：なぜ「全部」やってはいけないのか
「じゃあサイト内の全リンクに適用すれば爆速じゃん！」と思ったそこの君、ちょっと待て。
プリレンダリングは、クライアントのメモリとCPU、そしてサーバーのリソースを確実に消費する。 ログインが必要な動的ページや、POSTリクエストを伴うページを無闇にプリレンダリングすると、サーバー側のアクセスログが荒れるし、ユーザーの端末が発熱して不快な思いをさせることになる。
---
3. 実務で「事故らない」ための戦略
この技術を導入する際、最も恐ろしいのは「副作用」だ。例えば、プリレンダリングされた瞬間に解析ツール（Google Analyticsなど）が発火してしまい、PVが水増しされる問題だ。
これを回避するために、今のフロントエンド界隈では以下の実装パターンが定石となっている。
解析ツール発火の防止
プリレンダリング中は `document.prerendering` が `true` になっている。これを使って、解析系のスクリプトを抑制するのが現場の知恵だ。
// Analyticsの計測コード例
if (document.prerendering) {
// プリレンダリング完了後に計測を開始する
document.addEventListener('prerenderingchange', () => {
console.log('本番表示されたので計測開始');
// ここで計測処理を実行
});
} else {
// 通常のロード時は即時実行
console.log('通常ロードなので計測開始');
}
---
最後に：シニアからのアドバイス
Speculation Rules APIは、ブラウザの「先読み」という泥臭い仕組みを、僕たちがJSONという洗練されたインタフェースで制御できるようになった画期的な仕様だ。
ただ、これを導入する前に必ず考えるべきことがある。
「そのページ遷移は、本当に先読みしてまで速くすべき価値があるか？」 という点だ。
無意味な先読みは、ユーザーの通信量を無駄に消費するだけの「悪」にもなり得る。だからこそ、まずは重要なCTA（Call to Action）や、ユーザーが遷移する可能性が極めて高いページに絞って導入してみてほしい。
Webパフォーマンスの究極系は「読み込みを速くすること」ではなく、「読み込みを感じさせないこと」だ。Speculation Rulesは、まさにその領域へ踏み込むための強力な武器になるはずだ。
次はぜひ、君自身のプロダクトでこの魔法を試してくれ。現場からは以上だ。
コメント