[レベル: 上級]
Dynamic Rendering（ダイナミック レンダリング）は、JavaScript で生成されるコンテンツを確実にインデックスさせるために利用できる仕組みです。
しかし、一時的な回避策としてみなしたほうがいいでしょう。
数年後には必要性が薄れているかもしれません。
最終的には、Server-side Rendering（サーバー サイド レンダリング）の実装が望まれます。
ダイナミックレンダリングよりも SSR
JavaScript が関わってくるコンテンツのインデックスに特に問題を感じていないのであれば、Googlebot のレンダリング（正確には、Web Rendering Service）に任せて構いません。
特別な構成は不要です。
しかしながら、Googlebot が実行できない JavaScript を使っていたりインデックスされるまでに時間がかかりすぎたりするなど、何らかの問題が発生しているようであれば、JavaScript をあらかじめ実行した状態の静的な HTML を配信することで解決できます。
この解決策として選択できる手段がサーバー サイド レンダリング（以下、SSR）とダイナミック レンダリングです。
※ほかにも、Pre-rendering や SSR + Hydration などもありますが、話をシンプルにするためにここでは触れません。ウェブのレンダリングに関してはこちらの技術ドキュメントが詳しく解説しています。
SSR とダイナミック レンダリングのどちらが推奨されるかと問われれば、SSR です。
SSR には次のようなメリットがあります。
- 確実なインデックス: JS はサーバーで処理されクローラが実行する必要がないため、コンテンツを確実にインデックスさせられる
- インデックスの遅延なし: JS のレンダリングが完了した状態で配信するので Google 側でのレンダリングが不要。”セカンドウェーブ“によるインデックスの遅延を心配しなくていい。
- 表示速度の向上: クライアント（ブラウザ）側で JS を実行しなくていいので、表示速度の向上が見込める（JS はパフォーマンスを下げる元凶）。
ダイナミック レンダリングでも、1 つ目と 2 つ目は実現できます。
ですが、ブラウザには JS をそのまま返すため、3 つ目の高速化には何ら貢献しません。
一方で、SSR にはデメリットもあります。
それは、コードの変更、環境によっては大掛かりな変更が必要な点です。
SSR を実装するには、Angular なら Angular Universal、React なら Next.js、Vue.js なら Nuxt.js がよく用いられる技術です。
これらに合わせて、既存のコードを書き換えなければなりません。
対して、ダイナミック レンダリングでは SSR とは異なり既存のコードの変更は不要です。
クローラからのリクエストを、Puppeteer などのミドルウェアに回してレンダリングさせるという処理のためのコードは作成しなければなりませんが、今使っている JavaScript のコード自体には手を加えません。
多くの場合、SSR に比べたら導入は容易なはずです。
メリットが多い SSR を最終的なゴールに設定しつつ、ダイナミック レンダリングは、どちらかといえば 一時的な回避策としての位置付けになります。
John Mueller（ジョン・ミューラー）氏に言わせれば、ダイナミックレンダリングは 2、3 年後にはさほど役に立たなくなっている可能性もあるだろうとのことです。
Googlebot のレンダリング能力がもっと向上するだろうし、Google 以外のクローラ（ソーシャルメディアのクローラ含む）も JavaScript を処理できるようになっていくことが予想されるからです。