もう SPA だからといって SEO の心配をしなくていいのでは？

SPA の優位性（ポエム） #

Angular や React をはじめとした CSR ライブラリが登場して以来、SSR が登場し、SSG が登場し、ISR が登場しました。

技術の登場順に従って、一番初めに登場した CSR よりもその後登場した技術の方が上位だと考える人もいるかもしれません。

（ただし思い出してください、Ruby on Rails や Larabel や Django の存在を。これらが行なっていたことは SSR です。SSR は CSR よりも前から存在していたのです。）

このようにいろいろな技術が出てきた今でも、私はウェブアプリを作成する際、可能な限り SPA（CSR）で開発を始めたいと考えています。

SPA には圧倒的なメリットがあります。運用にかかる労力を限りなく削減できる点です。特に小規模なチームにとってみれば、SPA がもたらすこの恩恵は計り知れません。

初回レンダリングをはじめとした性能面では SSR などに強みがあることは確かです。ただしサービスがある程度成熟するまでは、わずかなレスポンスの速さを改善するよりも、求められている機能を追加するほうが優先されます。

こういった点から、サービスを立ち上げる際は極力 SPA で作り始めたいと考えています。サービスが成功して体制が整ってきてから SSR などへの移行を検討してもそう遅くはないはずです。

性能向上に頭を悩ますことのできるステージまで到達できたのであれば、そのサービスはかなり成功しています。

確かに SPA（CSR）は問題点を抱えていました。それが SEO 対策です。実際、これに対応するために SSR が開発されました。

でもそれももう昔のこと。もう SPA だからといって SEO の心配はしなくていいのではないでしょうか。

Google のクローラである Googlebot も相当に進化を重ねており、現在は SPA でも問題なくインデックスできるようになっています。しかも最近の話というわけでもなく、かなり昔から対応済みです。

以下の記事は非常に参考になります。2018 年末に書かれた記事ですが、逆にいうと 2018 年時点でさえここまで SPA に対応できています。

上記記事の内容を拝借しつつ、いまだに誤解されていそうな点とその実際を並べます。

一方で Facebook や Twitter の OGP 対応という点での課題は残存しています。Facebook や Twitter のクローラは未だ JavaScript を実行しません。

これに関しては OGP に必要なメタデータ部分のみをサーバ側で生成して返すのが良いです。実装もそれほど大変ではなく、運用不可もほとんどありません。

例えば AWS ならば Lambda@Edge を、Firebase ならば Cloud Functions for Firebase を利用すれば実現可能です。

このように以前言われていた懸念点はもはや解消されています。今後はこういったかつての前提に囚われずに考えていきたいですね。

（補足：Googlebot は問題ありませんが、Bing の Bingbot をはじめとした他のクローラ含めて SEO 対策が必要であればそこは改めてお調べください。）

どのような要件の場合に SSR を検討すべきか、以下の記事がわかりやすいです。