Article by: Lazar Nikolov
Eコマースでは、スピードが収益に直結することは、皆さんご存じだと思います。私も知っていますし、皆さんも知っているでしょう。Amazonも、eBayも、Shopifyも、誰もが認識している事実です。この記事では、製品詳細ページやカートページ、チェックアウトページといった重要なページのパフォーマンスをどのように向上させることができるかをご紹介します。Speculation Rules API（SRA）を活用して、これらのページをプリレンダリング/プリフェッチし、さらにNext.jsのような特定のフレームワークが提供する独自のプリフェッチ機構についても説明します。
Speculation Rules API
SRAは、現在 Chromiumブラウザでのみ利用可能な実験的な機能で、ウェブサイト側から「ユーザーが次にどのページを訪れる可能性があるか」をブラウザにヒントとして伝えることができます。ブラウザはそのヒントをもとに、あらかじめページをプリロードまたはプリレンダリングし始めます。これにより、そのページへの遷移がほぼ瞬時に感じられるようになります。
プリレンダリングルール（prerender rules）は、ブラウザに対して対象ページを「見えないタブ」の中で完全にダウンロードし、レンダリングし、読み込むよう指示します。これにはすべてのサブリソースの読み込み、すべての JavaScript の実行、さらに JavaScript から開始されるデータフェッチも含まれます。プリレンダリング済みページへの遷移は即座に完了します。文字通り、ブラウザが「すでに完全に読み込み済みのタブに切り替える」だけの動きになります。
プリフェッチルール（prefetch rules）は、ブラウザに対してページのドキュメント本体だけをダウンロードさせます。バックグラウンドでページをレンダリングしたり、JavaScript を実行したり、サブリソースを読み込んだりはしません。ナビゲーション時のメインドキュメントの HTTP リクエストをスキップするだけで、その後のレンダリングやリソースの読み込みは通常どおり必要になります。それでもパフォーマンスは大きく改善されますが、プリレンダリングルールに比べると処理はかなり軽量です。
これらのルールは、ページ内に <script type="speculationrules"> 要素を追加し、その中で JSON 形式で定義します。
上記の speculation rules によって、そのページ内に存在する /products/* にマッチするすべての URL が積極的にプリフェッチされ、さらに /cart ページも 同様に処理されます。これらのルールをどのように追加するかは問いません。<head> の末尾にハードコードしてもよいですし、JavaScript でランタイムに動的生成してもかまいません。これらのルールには「締め切り」はなく、ブラウザは DOM 内でルールを見つけた瞬間にプリフェッチやプリレンダリングを開始します。
どれだけ積極的に先読みするかや、さまざまな種類のマッチャーやセレクタ、その他の注意点についてもオプションが用意されていますが、この記事では取り上げませんので、詳しくは必ずMDN の Speculation rules APIのドキュメントを確認してください。
ブラウザごとの Speculation rules APIのフォールバック
SRA は Chromium ベースのブラウザのモダン版でしか利用できないため、Safari や Firefox のユーザーはその恩恵を受けられません。とはいえ、そうしたユーザー向けにもできることはまだあります。SRA とまったく同じ機能を再現することはできませんが、多くのモダンなフレームワークが備えているフレームワーク固有のプリフェッチ機能を活用できます。たいていの場合、これはリンクに付与する prop や要素属性の形で提供されており、そのリンク先ページをページ読み込み時やホバー時にプリフェッチするか、あるいはプリフェッチ自体をスキップするかを指定できるようになっています。
ほとんどのフレームワークは、ページ読み込み時やスクロール時に自動的にプリフェッチを行います。たとえば Next.js（docs）と Nuxt 3（docs）はデフォルトでページをプリフェッチします。SvelteKit（docs）と Remix（docs）はデフォルトでプリフェッチを行いませんが、プリフェッチの挙動を定義するためのオプションが用意されています。お使いのフレームワークのドキュメントを確認し、どのようにプリフェッチを設定できるかを確認してください。
フレームワークレベルのプリフェッチを有効にしておくことは、非常に優れたフォールバックになります。というのも、Chromium 以外のブラウザでもナビゲーション性能を向上させられる一方で、Chromium ブラウザに対して悪影響を与えることもないからです。Chromium ブラウザで、speculation rules とフレームワーク固有のプリフェッチの両方が設定されたページを読み込んだ場合には、speculation rules が優先されます。たとえば、すべての /product/* ページが speculation rules によって prefetch されている一方で、ホバー時のプリフェッチも設定されているとします。ユーザーがそのページに到達すると、speculation rules によってブラウザはすべての商品ページをプリフェッチしてキャッシュします。そのため、ユーザーがいずれかの商品にホバーしたとしても、そのページはすでにキャッシュに存在するため、ブラウザは再度プリフェッチを実行しません。
SRA はストアフロントのパフォーマンスをどのように向上させるか
これらの効果を実際に検証するために、私は（えっと、ノリでサクッと）Next.js 製のデモ用ストアフロントを作成し、Sentry Next.js SDK でインストゥルメンテーションしました。SDK はページロードを自動的に計測してくれますが、プリレンダリング時のメトリクスとプリフェッチ時のメトリクスを区別する必要があったため、最適化モードが変わるタイミングで、その値を示すタグを 1 つ追加するだけで済みました。
このあと行ったのは、最適化方法ごとにナビゲーションをグルーピングして可視化するカスタムウィジェットを作成することだけでした。
（ウィジェット仕様：spans データセット、span.duration の p90 を可視化、フィルタ：span.description に /products/:id を含み、span.name に navigation を含むもの、optimization_mode ごとにグループ化）
そして、この結果を見てください！プリフェッチ、プリレンダリングを行った場合と、まったく最適化していない場合とでは、大きな差が出ています。ここでいう no optimization には、フレームワークレベルのプリフェッチを無効にした状態も含まれます。
このデータは、自動スクリプトによってトリガーされる Vercel へのデプロイから取得したものです。私の非常にシンプルなデモアプリでも、これだけの改善が見られます。実際の EC ストアフロントのように、アナリティクスやウィジェット、さまざまなスクリプトなどを大量に含むサイトであれば、その効果はさらに大きくなるだろうと考えています。
とはいえ、このグラフだけを見ても、「プリレンダリングの方がプリフェッチより速い/良い（あるいはその逆）」とまでは断言できません。ただ一つはっきり言えるのは、何の最適化もしない状態より、どんな最適化でもはるかに良いということです。
ぜひご自身のアプリケーションにも Sentry Next.js SDK を導入して計測し、自分の環境でどのような差が出るかを確認してみてください。そこで得られる数値は、ここで紹介したものとはきっと異なるはずですし、プリレンダリングとプリフェッチの違いが、もっと明確に表れるかもしれません。
Speculation rules の落とし穴
SRA は「無料で性能が爆上がりする魔法」ではありません。どのような仕組みにも言えることですが、いくつか注意しておくべきポイントがあります。代表的なものを以下にご紹介します。
サーバー負荷とコスト
- プレレンダリングを行うと、ユーザーがそのページを一度もクリックしなかったとしても、フルの SSR（サーバーサイドレンダリング）とデータ取得が実行されます。これを抑えるには、基本的にはプレレンダリングよりプリフェッチを優先し、プリレンダリングはクリックされる可能性が非常に高いリンクにだけ、控えめに使うようにしてください。
- ビューポート内にリンクが多い場合、それだけプリフェッチ、プリレンダリングも多く発生します。これは典型的な thundering herd 問題（一斉アクセスで負荷が集中する状況）になります。これを防ぐには、SRA 側の先読みの強さ（eagerness）を控えめに設定し、遷移確率の低いリンクには
prefetch={false}を設定して プリフェッチしないようにするのが有効です。
アナリティクスと実験
- プリレンダリングは、対象ページ上のすべての JavaScript を実行するため、アナリティクス SDK も同様に実行されてしまいます。その結果、ページビューやコンバージョン数が実際よりも水増しされてしまう可能性があります。これを防ぐには、「アクティベーション（実際にユーザーがそのページに遷移したタイミング）」でアナリティクスイベントを発火するようにします。具体的には、
visibilitychangeイベントのあとでdocument.visibilityState === 'visible'をチェックしてからイベントを送信します。サーバーサイドでアナリティクスを行っている場合は、Speculation Rule Tag を付与してそのヘッダーを見るか、Sec-Purpose ヘッダーを参照するようにします。 - A/B テストを実行している場合も、同様に結果の歪みが発生します。これを防ぐには、実験の割り当てをアクティベーション時に行い、ビーコン送信も「ページが visible になるまで遅延させる」ようにしてください。
プロダクトの挙動上のクセ
- プリレンダリングでは、現在のクッキーがそのまま使われる場合があります。アクティベーション前にトークンが期限切れになると、認証情報の不整合や古いセッションが発生してしまいます。これを防ぐには有効期限の短いクッキーを使い、アクティベーション時にリフレッシュするようにしてください。
- レンダリング中には、在庫の仮押さえ、インプレッション計測、最終閲覧時刻のトラッキングなど、さまざまな副作用が発生し得ます。これに対処するには、SSR やデータ処理を冪等かつ読み取り専用にし、副作用はアクティベーション時またはクリック時に移すようにしてください。
ここで挙げたのは、プリレンダリングとプリフェッチにおける落とし穴のごく一部にすぎません。そのため、本格的に展開する前に、実トラフィックのプロファイリング、サーバー負荷の監視、アナリティクスの精度検証、本番相当の条件でのテストなど、十分な検証を行うようにしてください。
アプリケーションでの Speculation rules 活用
メリットと注意点が分かったところで、Speculation Rules API をどのようにバランス良く、戦略的に使っていくかを見ていきましょう。
プリレンダリングはプリフェッチよりも処理が重いものの、その分だけ事前に多くの読み込みを済ませられるため、本来はより高いパフォーマンスが期待できます。そうした前提を踏まえると、プリレンダリングは控えめに使うのがよいと思います。
EC のストアフロントを想定するなら、自分ならプリレンダリングを使うのは、より小さな商品セクションに限ります。たとえば、ページ上部に最大 4〜5 点ほどの商品だけを並べた「注目の商品」セクションや、「Black Friday」のような見逃せないキャンペーンバナーのセクションなどです。こうしたセクションは大きな CTAを持っていることが多く、クリックが集まりやすい場所です。
一方のプリフェッチはより軽量ですが、それでも重要な最適化アプローチです。私なら、相対的には優先度が少し落ちるものの、それでも重要なその他の商品カードや、ナビゲーションバーからリンクされているカテゴリーページなどにプリフェッチを使います。安全側をとるなら、ページ読み込み時ではなく「ホバー時」にプリフェッチするように設定してもよいでしょう。もし Black Friday セクションを「ファーストクラス（最優先）」とするなら、これらは「セカンドクラス」という位置づけです。プリフェッチ自体は行うものの（ホバー時プリフェッチにしない限りは）どれだけ多くのページをプリフェッチしているかには注意する必要があります。
それほど重要ではないその他のページについては、サーバー負荷とコストを抑えるために、フレームワークがデフォルトで行う自動プリフェッチを無効化するか、ホバー時のみのプリフェッチにとどめるとよいでしょう。
必ずプリレンダリングを使いたいのは、「お金を生む」クリティカルフローです。たとえばユーザーがホームページに来て、商品ページを見て、カートに追加し、チェックアウトに進む……といった一連の流れです。このフロー上のページに対して戦略的にプリレンダリングのルールを配置していくことで、クリティカルフロー全体のパフォーマンスを大きく向上させ、コンバージョンやチェックアウトの件数を増やし、その結果としてサイト上で使われる金額を増やすことができます。究極的に目指しているのはそこですよね。Speculation Rules API を使えば、ここをかなり賢くチューニングできます。
そして何より重要なのは、改善をデプロイしたあとに本番環境でのパフォーマンスを継続的に監視することです。プロジェクトに Sentry を導入し、クリティカルフローがどうパフォーマンスしているかを俯瞰できる Critical Experience Monitoring ダッシュボードを作成して、そのフローがどう機能しているのか、どこを改善すべきかを常に確認できるようにしておきましょう。
まとめ
この記事では、Speculation Rules API（とフレームワークレベルのプリフェッチ）が、「あらかじめ読み込んでおく」ことで EC ストアフロントの体感パフォーマンスを大きく向上できることを見てきました。Sentry を使って本番環境でパフォーマンス向上を計測し、最適化をまったく行わない状態と比べて、プリレンダリングやプリフェッチを行ったページではページロード性能が明確に改善される、という結論に至りました。
一方で、こうした改善には注意点も付きまといます。SRAやプリフェッチによってサーバー負荷が増加したり、アナリティクスの値が歪んだり、さらには古い認証クッキーを持ったページがプリレンダリングされてしまう可能性もあります。とはいえ、必要以上に怖がることはありません。本番環境のアプリにきちんと目を配っていれば（Sentry を使っていれば！）、多くのユーザーに影響が出る前に発生した問題へ素早く対応し、修正することができます。
Original Page: <100ms E-commerce: Instant loads with Speculation Rules API
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
