`rel=”prerender”` の深淵：ブラウザの先読み戦略を「制御」するアーキテクトの視点
Webフロントエンドのパフォーマンスチューニングにおいて、私たちは常に「0ミリ秒への執着」と戦っています。`preload` や `prefetch` がリソースの先読みという「点」の最適化であるならば、`rel=”prerender”` は、ページ全体をバックグラウンドで構築するという「面」の最適化を試みる、非常に野心的な技術です。
しかし、この強力な魔法は、使い方を誤ればユーザーの端末を焼き尽くす諸刃の剣ともなり得ます。今回は、上級エンジニアが避けて通れない `prerender` の裏側と、現場で生き残るための高度な設計論を紐解いていきます。
—
1. `prerender` の本質：隠されたブラウザの挙動
`rel=”prerender”` を宣言すると、ブラウザは隠れたタブ（またはプロセスの別インスタンス）で対象ページを完全にレンダリングしようとします。ここには、単なるキャッシュとは一線を画す「負荷」が存在します。
- リフローとリペイントの先行実行: DOMツリーの構築はもちろん、CSSOMの構築、さらにはJSの実行までが含まれます。
- ネットワーク優先度の競合: プリレンダリング中のページが重いスクリプトや画像を取得し始めると、現在表示中のページのリソース取得と帯域を奪い合います。
「高速化のために導入したはずが、メインスレッドの競合で現在のページのLCP（Largest Contentful Paint）が悪化した」という事例は、大規模アプリケーションでは珍しくありません。
—
2. 賢明なエンジニアのための「条件付き注入」アーキテクチャ
`prerender` を全ページに雑に注入するのは、メモリをドブに捨てるようなものです。パフォーマンス・バジェットを厳密に管理するテックリードとしては、TypeScriptを用いて「ユーザーの意図」と「端末スペック」を考慮した動的な注入ロジックを組むべきです。
以下に、実戦で使える型安全な注入モジュールの例を示します。
/
- プリレンダリングを制御するための型定義
/
interface PrerenderOptions {
url: string;
// 低速回線や省電力モードでの実行を抑制するためのフラグ
respectBatteryLife?: boolean;
}
/
- 動的なリンク注入ユーティリティ
/
const injectPrerender = ({ url, respectBatteryLife = true }: PrerenderOptions): void => {
// ネットワーク状態やセーブデータモードの判定（Navigator APIを活用）
const connection = (navigator as any).connection;
if (connection?.saveData) return;
if (respectBatteryLife && (navigator as any).getBattery?.()) {
// バッテリー消費を抑える必要がある場合はスキップする設計
}
const link = document.createElement(‘link’);
link.rel = ‘prerender’;
link.href = url;
// 重複挿入の防止はDOMのステート管理に含めるべき
document.head.appendChild(link);
};
// 使用例：ユーザーがリンクへマウスホバーした時など、
// 「次に遷移する確率」が高い瞬間に限定して実行する
document.querySelector(‘#target-link’)?.addEventListener(‘mouseenter’, () => {
injectPrerender({ url: ‘/next-page’ });
}, { once: true });
—
3. 避けるべきエッジケースと、陥りやすい「非同期の罠」
`prerender` を扱う上で最も恐ろしいのは、「副作用の重複」です。
サーバーサイドへの影響
プリレンダリングされたページは、バックグラウンドでサーバーへリクエストを投げます。もし、そのページが `POST` リクエストをトリガーするような初期化処理を含んでいれば、ユーザーが一度も遷移していないのに、サーバー側のデータベースが書き換わる可能性があります。
- 回避策: サーバー側で `Sec-Purpose: prefetch` ヘッダーを確認し、プリレンダリング中のリクエストに対しては副作用（データ更新や分析ログの送信）を抑制するロジックを実装してください。
ブラウザの「推測」とリソースの競合
Chromeの `Speculation Rules API` の台頭により、従来の `rel=”prerender”` は徐々にそちらへ移行しつつあります。しかし、依然として従来のタグを考慮するブラウザも存在します。ここで重要なのは、「サードパーティスクリプトを隔離する」ことです。
プリレンダリング中に広告用スクリプトやトラッキングタグが勝手に発火し、メインページの帯域を占有しては本末転倒です。プリレンダリング対象のページには、クリティカルなレンダリングに必要な最小限のリソースのみを読み込ませるアーキテクチャを徹底してください。
—
4. 総括：私たちは何を最適化すべきか
`rel=”prerender”` は単なるHTMLタグではありません。それは、ユーザーの未来の行動を先取りする「予測アルゴリズムの一部」です。
上級エンジニアとして目指すべきは、「ユーザーにプリレンダリングを感じさせないこと」です。もしプリレンダリングが原因で現在の体験が少しでも損なわれるなら、それは失敗です。`prefetch` や `preload` といった「軽い」手段を優先し、`prerender` は「遷移確率が極めて高く、かつリソース負荷が許容範囲内である」と確信できるクリティカルパスにのみ、外科手術のように適用してください。
Webのパフォーマンスは、常に「引き算」の哲学の上に成り立っています。この強力な武器を、ぜひ貴方のアプリケーションの最適化戦略という名のパズルに、慎重に組み込んでみてください。
コメント