ブラウザの投機的読み込みと投機ルールAPIを理解し、Webサービスのパフォーマンスを最適化する

https://stmn.connpass.com/event/390165/ の登壇資料です

Transcript

1. ブラウザの投機的読み込みと 投機ルールAPIを理解し、 Webサービスのパフォーマンスを 最適化する 2026/05/08 did0es
2. Hirai Shuta | did0es（🗣 ディドス） SWE, Next Experts(Client - TypeScript) @ CyberAgent, Inc. FEC Tokyo lead organizer & FEC Nagoya adviser For more: did0.es
3. 【本資料のねらい】 ブラウザの投機的読み込み機能を理解して サービスに合わせて選択できるようになる
4. ブラウザの投機的読み込み 将来実⾏される可能性がある処理を予測して実⾏（投機的実⾏）し、 Webページを早く利⽤できるようにする仕組み。 以下の⽅法で実現： • 先読み：リソースの事前読み込み • 事前レンダリング：⽂書の事前レンダリング • 事前接続：接続ハンドシェイク（の⼀部）の事前実⾏
5. 投機的読み込み機能の種類 1. <link rel="dns-prefetch"> 2. <link rel="preconnect"> 3. <link rel="preload"> 4. <link rel="modulepreload"> 5. ⚠ <link rel="prefetch"> 6. ⚠🗑 <link rel="prerender"> 7. 🧪 投機ルール API a. 先読み b. 事前レンダリング
6. ① <link rel="dns-prefetch"> • DNS解決を事前に⾏う ◦ 対象オリジンのドメイン名をIPアドレスに解決するまでの待ち時間を短縮 ◦ DNSキャッシュとは別 • 同⼀オリジンのリクエストではメリットなし ◦ 同⼀オリジンであれば既にコネクションが開いている（ドメインのIP解決済み） • 使い⽅ ◦ 例：<link rel="dns-prefetch" href="https://example.com" /> ◦ HTTPヘッダのLinkでも設定可能： Link: <https://fonts.googleapis.com/>; rel=dns-prefetch
7. ② <link rel="preconnect"> • 接続ハンドシェイクの⼀部またはすべてを事前に⾏う ◦ DNS解決 + α の事前実⾏ ◦ HTTPのオリジン：DNS + TCP ◦ HTTPSのオリジン：DNS + TCP + TLS • 同⼀オリジンのリクエストではメリットなし ◦ 同⼀オリジンであれば既にコネクションが開いている（ドメインのIP解決済み） • 使い⽅ ◦ 例：<link rel="preconnect" href="https://example.com" /> ◦ HTTPヘッダのLinkでも設定可能： Link: <https://fonts.googleapis.com/>; rel=preconnect
8. dns-prefetchとpreconnectの使い分け preconnectの⽅が優秀じゃん！となるが... • 様々なドメインに接続する → dns-prefetch ◦ 全てのドメインのDNS解決だけ先に済ませる • あるドメインへの接続が必須 → preconnect ◦ 全てのドメインのDNS解決 + αまでやると重い ◦ 重要なドメインに対して⾏う
9. ③ <link rel="preload"> • 指定したリソースのダウンロードとキャッシュを⾏う ◦ ブラウザがレンダリングを開始する前に必要であることを⽰唆 ◦ 実⾏はしない • 使い⽅ ◦ 例：<link rel="preload" href="style.css" as="style" /> ◦ as属性にはリソースの種類(fetch, font, image, script, style, trackが設定可能) ◦ MIMEタイプによる制御や、CORSによる取得（fontファイルなどで利⽤）、 media属性によるレスポンシブな事前読み込みが可能
10. ④ <link rel="modulepreload"> • 指定したJavaScriptモジュールをダウンロード‧コンパイル‧ モジュールマップに格納し、実⾏できるようにする ◦ モジュールマップ：モジュール間の読み込みの状態を管理するもの ◦ JavaScriptモジュール特化のpreload + α • 使い⽅ ◦ 例：<link rel="modulepreload" href="main.js" />
11. modulepreloadとpreloadの違い • as属性は必要なし。scriptとして解釈される ◦ script関連（serviceworkerなど）の他の値も指定できる • ダウンロード後にただキャッシュするのではなく、 モジュールマップにコンパイルする • 指定したモジュールだけでなく、モジュールの依存関係も事前に読み込む
12. ⑤ ⚠ <link rel="prefetch"> • 指定したリソースのダウンロードとキャッシュを⾏う ◦ ユーザーの操作の中で必要であることを⽰唆 ◦ HTTPキャッシュとしてキャッシュ ◦ 実⾏はしない • 使い⽅ ◦ 例：<link rel="prefetch" href="https://news.example/article" />
13. prefetchとpreload系の違い • prefetch ◦ 優先度：低 ◦ ページを利⽤するとき将来的に必要 • preload ◦ 優先度：⾼ ◦ ページを表⽰するときに必要
14. ⑥ ⚠🗑 <link rel="prerender"> • 指定したリソースのダウンロード後、レンダリング結果をキャッシュする ◦ 画⾯外でページを開いている状態 ◦ キャッシュは5分間有効 • 使い⽅ ◦ 例：<link rel="prerender" href="/next-page" />
15. prerenderとprefetchが抱える問題 • Cache-Controlヘッダーにブロックされる可能性がある ◦ no-cache, no-storeなど • ブラウザのキャッシュ分割で無効になる ◦ 同⼀ドメインでもキャッシュ共有できない： あるリソースに対してa.example.comでprerender/prefetchした結果は、 b.example.comから⾒えない • prerenderのセキュリティ ◦ プロセス間のアクセス制御が⼗分に考慮できていない
16. ⑦ 🧪 投機ルールAPI • 前述の問題を解決するAPI • 先読み：prefetchの代替 ◦ ドキュメント単位でメモリにキャッシュ • 事前レンダリング：prerenderの代替 ◦ 先読み + αでレンダリング ◦ ⾮表⽰タブに読み込んでメモリにキャッシュ • 使い⽅ ◦ 投機ルールをJSON形式で記述 ▪ <script type="speculationrules">にインラインで記述 ▪ Speculation-Rulesヘッダーで記述したファイルを指定
17. 先読みの投機ルールの記述例 "prefetch": [ { "urls": ["next.html", "next2.html"], "requires": ["anonymous-client-ip-when-cross-origin"], "referrer_policy": "no-referrer" } ]
18. 事前読み込みの投機ルールの記述例 "prerender": [{ "where": { "href_matches": "/*" }, "eagerness": "moderate" }]
19. 投機ルールAPIを使う上での注意（※） • 先読み ◦ GETリクエストが⾶ぶ ▪ サーバー側がGETリクエスト駆動で何か処理する場合動いてしまう ◦ キャッシュを表⽰するため、リアルタイム性が損なわれる ▪ サーバー側でレンダリングされた結果とユーザーの操作結果との不整合 • 事前レンダリング ◦ ユーザーが操作したかのような動作をする場合がある ▪ 画像の読み込み、トラッキングスクリプトの実⾏など ◦ JSによる副作⽤が他のページに⼲渉 ▪ ブラウザのストレージを使う処理など ※ prefetch / prerenderでもこれらに注意が必要
20. 投機的読み込み機能の使い分け • 汎⽤的 ◦ dns-prefetch ◦ preconnect • アセット多め ◦ preload • SPA：管理画⾯ ◦ modulepreload ◦ prefetch(投機ルールAPIの先読み) • MPA：メディア、検索サイト ◦ 投機ルールAPI
21. ありがとうございました