Try T.M Engineer Blog

多摩市で生息するエンジニアが「アウトプットする事は大事だ」と思って始めたブログ

新年早々Vue.jsのSPA／SSR／SSGを整理してみた話

JavaScript/TypeScript

はじめに

明けまして、おめでとうございます。
まだまだコロナで苦しい日々が続きますが、皆様頑張ってのりきりましょう（T T;;

さて、新年早々（ホントは年末から）、Vue.jsを使ってSSR、SSGで作るのってどうするんだ？と思って、色々調べてたので、調べたことを纏めて書いておこうと思います。
SPA、SSRの定義から曖昧な人なので、定義から確認していくこと・・・

SPA vs SSR

  • SPA(Single Page Application) ・・・ 1つのHTML内でコンテンツのみを切り替えるアプリケーションのこと。
  • SSR(erevr Side Rendering) ・・・ コンテンツ毎にサーバー側でHTMLを生成してブラウザに返す仕組みのこと。

SPAの場合、コンテンツの切り替えをブラウザ側のJavaScriptを使って行うため、必ずしもサーバーが必要というわけではありません。
SSRの場合、HTMLをサーバーサイドで生成する必要があるため、必ずサーバーが必要になってきます。

f:id:special-moucom:20210103001142p:plain

どうしてSSRが必要なのか？

SSRを使う理由の1つとして「SEO」が上げられます。

クローラーは、完全に描画されたページ（HTML）を直接解析しています。
そのため、SPAのようなJavaScriptを使ってコンテンツを切り替えているようなページ（HTML）は、クローラー側で正しくページを評価できない（正確には、JavaScriptを正しく実行して、切り替えたコンテンツを解析してくれているかわからない）という問題があります。

とはいえ、昨今ではクローラーの機能も向上しており、今後はSPAで作られたページ（HTML）でも正しく評価されるようになると思われます。
それまでは、「SEO」を重視するのであればSSRが必要となります。

もう1つの理由は、JavaScriptのダウンロード時間です。

SPAは、JavaScriptを使ってコンテンツを切り替えるため、JavaScriptの容量が大きくなりがちです。
そうなると、JavaScriptのダウンロードに時間が掛かり、クローラーの評価を落とす要因になります。

こういった観点からもSSRが必要になってくるケースは多いと思われます。

SSR vs SSG(プリレンダリング（事前描画）)

Vue.jsでは、「SEO」目的でSSRするなら、SSG（プリレンダリング（事前描画））がオススメですよ。と書いてある。

SSR vs プリレンダリング (事前描画)

もしあなたが、幾つかのマーケティングのページの SEO を向上させるためだけに SSR を調べているとしたら (たとえば /, /about, /contact など)、代わりに プリレンダリング (事前描画) を使用することをオススメします。 
HTML を急いでコンパイルするために Web サーバーを使用するのではなく、プリレンダリングは、ビルド時に特定のルートに対して静的な HTML ファイルを生成します。
利点はプリレンダリングを設定する方が遥かに簡単で、フロントエンドを完全に静的なサイトとして保つことができることです。

プリレンダリングとは事前描画のことで、コンテンツ毎に必要なHTMLを事前に作成しておく仕組みのこと。つまり、Static Site Generator（SSG）。
JavaScriptを使ってコンテンツを切り替えるが、切り替えたコンテンツは事前に作成しておいたHTMLを表示しようというもの。
そのため、必ずしもサーバーが必要というわけではありません。

f:id:special-moucom:20210103001152p:plain

HTMLは事前に作成しているため、クローラーからも正しく評価されるし、JavaScriptの容量も大きくなり辛いので、ちょうどSPAとSSRの良いとこ取りみたいな感じですね。

SSRを再評価してみる

じゃあ、これからはSSRではなく、全部プリレンダリングで作れば良いじゃん・・・
とは、大きな声では言えませんがクローラーの機能も向上しているのでSSRのメリットが少なくなっているのは事実です。

SSRは、SPAやプリレンダリングでは得られない以下のようなメリットもあるので、要件によってどれを選択するかを決めたほうがよさそうです。

  • クライアントサイドでAPIを実行してHTMLを生成するよりも、サーバーサイドでAPIを実行してHTMLを生成して表示した方が、クローラー側で正しくページを評価してくれる。
  • コンテンツ表示までの時間を短縮できる。
  • コンテンツのアップロードの度にビルドをする必要がないので、大量ページを必要とする場合にむいている。

また、どうせ裏の仕組み（API等）を作る必要があるのなら、いっそのことSSRにするという選択肢もありますね。
その裏の仕組みもJavaScriptを使って作るアイソモーフィック（Isomorphic）やユニバーサル（Universal）といった単語も最近では良く聞きます。

アイソモーフィックJavaScript

アイソモーフィック（Isomorphic）とは、「同型の」という意味で、クライアントサイドとサーバサイドを同じ言語（JavaScript）を使って実装して、コードの共有を行うこと。 つまり、「JavaScriptを使ってSSRやりましょう」イコール「アイソモーフィックJavaScriptでやりましょう」ということ。

ユニバーサルJavaScript

ユニバーサル（Universal）とは、「全般の」という意味で、クライアントサイドとサーバサイドだけでなく、モバイル端末や組み込みデバイス上まで同じ言語（JavaScript）を使って実装して、コードの共有を行うこと。 アイソモーフィックJavaScriptの考え方をさらに広げようといった意味が込められている。

上記のように、SSRは「SSRで作るメリット」があるので、ケースバイケースでSPA、SSR、SSGを選択しましょう。

最後に

去年末のAdvカレンダーで、Vue.jsのSSGフレームワークGridsomeについて調べたことを書きました。

qiita.com

データソースをGraphQLを使ってアクセスできる面白いフレームワークなので、興味のある方は是非読んでみてください。

さて、個人的な観点で、SPA、SSR、SSGについて、整理してみました。
タイトルに「Vue.jsの」と書きましたが、「Vue.js」の内容はあまり含んでいなかったですね。（Vue.jsのWebサイトから抜粋してきたものが多いですが・・・）