Report(以下、CrUX)をたしかに使っているとのことでした。ついてはクローラーに対する応答速度です。クロール頻度に影響があると言われています。秒以上掛かっているということですから、それは本当にあなたのサーバは遅い部類に属しているという兆候です。本来、私達がクローリングできるページ数を制限している一つの要因でしょう。よるダイナミックレンダリングを利用しています。対応していないクローラーに有効な手法です。対応していますが完全ではないようで、ダイナミックレンダリングの効果が期待できます。完全に解釈してダイナミックレンダリングの必要がなくなると思われますが、現時点では効果があると考えています。クローキング(クローラーにユーザーと異なるコンテンツを返すこと)を禁止していて、その上でダイナミックレンダリングはクローキングではないとしています。レンダリングをクローキングとは見なしません。次の図は移行前の構成です。等の静的ファイルを返します。サーバーに問い合わせます。サイトをレンダリングし、その結果を返します。レンダリング結果はキャッシュされます。通常アメリカ国内からアクセスしてきます。何度も往復して相当時間がかかっていたはずです。次の図が移行後の構成です。場合のやりとりがすべてアメリカ国内で完結するようになりました。適切なエッジサーバーにつながるため高速で処理されます。バケットに配備します。つのバケットを用意しています。アプリを使っています。等のメタデータを付けています。このデプロイ処理のために簡単なツールを作成しました。要求にも答える必要があります。甚大な悪影響を生じてしまいます。タイミングでアーカイブバケットを検索します。ファイル配備を行います。キャッシュ期間より前にリリースしたファイルは削除しても構いませんが、管理が面倒なので残しておきます。補助バケットアプリのリリースとは別のタイミングで生成、更新されるファイルを置くバケットです。バッチ処理で生成しています。このようなファイルをアプリと別で管理するためにバケットを分けています。ビヘイビアにより制御します。/sitemap.xmlを補助バケットにマップするルールを設定します。サーバーに転送します。サーバー側で圧縮しておきます。リクエストに応じた処理を行います。イベントに次のように処理を割り当てます。viewer-requestUser-Agentヘッダを見てクローラーかどうかを判別する。クローラーの場合はx-prerender-user-agentヘッダにUser-Agentヘッダの値をそのまま入れておきます。x-prerender-user-agentをキャッシュキーとして設定し、クローラーと一般のブラウザとでキャッシュを分けます。向けたカスタムオリジンを返します。問い合わせてくれます。no-storeを設定してダイナミックレンダリングの結果のキャッシュを避けます。側でキャッシュがあることと、挙動をシンプルにするためにここではキャッシュしません。リクエストが失敗した場合にアーカイブバケットを参照します。配信して高速化することができました。提供など考慮すべき事柄がいくつかありましたが、無事に稼動させることができました。