弊社のHPをリニューアルするにあたってブログ機能を充実するということになり、HPの実装をよりSEOに強いSSRにする方向になりました。

なぜSSRのほうがSEOに強いの？っと言われると、
 

”SPAはクライアントサイドでページ遷移の処理を行なっているため、検索サイトの巡回ロボットがページを認識せず、ページがインデックスされていない可能性がある。SSR（ないし、SSG）はサーバーでページ遷移を含むその他諸々の処理をしているので巡回ロボットが認識しやすい”
 

という認識でした。（大枠で間違っていないとは思いますが、ほんとにざっくり）
 

この記事では、もう少し上記の内容を掘り下げて、

• なぜSSRはSEOに効くのか

を中心に書いていこうかと思います。
 

そもそもSPA、SSR、SSGの違いって何？

SPA（Single Page Applicationの略）

名前の意味をそのまま捉えると、単体ページのアプリケーションという意味になります。

実際そうなんですが、要はページの読み込み時に単体のページのみを読み込み、後の処理はクライアントサイドでやる（ページの遷移などは都度APIでデータを取ってきて、最初の１ページの上に表示させる）っというようなアプリケーションを指します。

この作りのいいところは、

ページを遷移する時に新しいデータを読み込んでレンダリング（表示形式にしている）する訳ではないので、ページの遷移が連続的でスムーズだというとこです。

難点としては、

大きなデータをAPIで取ってくるような処理になると少しもっさりしてしまうかもしれないところです。

あと、題材にもあるようにSEOに弱いということが挙げられます。

SSR(Server Side Renderingの略)

先ほどのSPAとは処理（画面遷移）をするときの、場所が異なります。

名前にサーバーと入っているように、処理の場所はサーバー。リクエストが投げられるたびにサーバーでレンダリング処理が走り、クライアントにはレンダリング済みのページが返るといった形の構造になっています。

いいところは、

SEOに強い。

サーバー側で処理を完結するのでスペックがそこまで高いパソコンでも表示に負担がかかりにくい。

ただし、その難点としては、

クライアント側での処理が軽くなる分、サーバーへの負担が高くなるといったことが挙げられます。

SSG（Static Site Generatorの略）

サーバー上には既にビルド（レンダリング済みの）した静的ファイルが用意されており、リクエストがあった際には用意されている静的ファイルを返すだけなので処理が圧倒的に速くなります（サーバー・クライアント双方で処理が軽くなるため）。

処理も早く、SEOに強いというのがこの作り方のいいとこではありますが、

その反面、デメリットとしては、

更新のためにビルドをその都度挟まなくてはいけないので、リアルタイムでの更新が望ましいサイトには向かないといったデメリットが挙げられます。

上記で挙げたそれぞれのメリットを考えて、今回ブログ機能を導入しSEOに重点を置くコーポレートサイトにリニューアルする際にSSRの作りを採用しました。

もちろん、SEOに重点をおかなくてもいいようなログイン機能付きのウェブアプリケーションであればSPAのほうがメリットはあるかもしれません。今回のように、それぞれの実装方法のメリット・デメリットを加味して、そのコンテンツに合った実装を選ぶことが重要です。