generateの機能は、静的サイト生成とか、単に静的生成といわれることが多いですが、文中で多用するのがツラいので、より短く「静的化」で統一しています。
Nuxt.jsについてざっくり
Vue.jsで開発する際に大変なところを、やさしく包みこんでくれるフレームワークです。開発環境の構築や、ミドルウェアなどの仕組み、いい感じのディレクトリ構成や、SSR/静的化など、かゆいところをサポートしてくれるため、本当に大切な機能の開発に集中できます。
ReactのフレームワークであるNext.jsから着想を得たとのことですが、あまりにもいさぎよい名前です。
Next.jsと、開発元のZEITのWebサイトがシンプルでかっこいいですね。
Nuxt.jsにおけるビルドの選択肢
Nuxt.jsでは、SPA・SSR・静的化の中から、好きなものを選んで開発できます。
初期設定ではSSRで動作するようになっていますが、流れとして自然なのでSPAから順に利点と欠点をまとめました。それぞれのビルドを行うため設定は、ドキュメントにわかりやすく書いてあるので、そちらでご確認ください。
SPA（Single Page Application）
利点
- 実装しやすい
- サーバーの準備が楽
欠点
- 初期表示が遅い
- SEOに不安がある
- OGをページごとに設定できない
SPAは、最もシンプルに実装でき、ホスティング先の選択肢が多いのが魅力です。
ドキュメントで、NetlifyやGitHub Pagesへのデプロイ方法が紹介されていますが、単にファイルをアップすればいいだけなので、ロリポップのようなレンタルサーバーでも動きます。
フロントエンドでルーティングするため、ページ遷移は快適ですが、最初の見た目もJavaScriptで組み立てることになるので、初期表示の遅れが気になるかもしれません。
we decided to try to understand pages by executing JavaScript. It’s hard to do that at the scale of the current web, but we decided that it’s worth it.
また、GoogleのクローラーはJSの実行を待ってページを解釈してくれますが、完全に意図したとおりにインデックスしてくれるかは不安が残るのと、TwitterやFacebookは・・・という懸念もあります。
ユニバーサルをうたってるNuxt.jsなのにSSRしないの？それならNuxt.jsいらなくない？という疑問があるかもですが、個人的には、環境構築の手軽さや規約によって生まれる秩序に魅力を感じるので、Nuxt.jsでSPAという選択もありだと思います。
SSR（Server Side Rendering）
利点
- SPAの欠点を解消できる
欠点
- 実装が少し面倒
- サーバーの準備が面倒
初回のリクエストをサーバーサイドでレンダリングして返すため、SPAの欠点を補うことができます。一方で、レンダリングするためのサーバーと、SSRを考慮した実装が必要になります。
ドキュメントで、HerokuやNowへのデプロイ方法が紹介されていますが、Node.jsが動作するサーバーを用意できればなんでも大丈夫です。インフラに弱い人にはこのハードルが高い気がしますが、インフラに強い人や、好きなPaaSがある人にとっては、SSRが魅力的な選択肢になると思います。
静的化（Static Site）
利点
- SPAの欠点を解消できる
- サーバーの準備が楽
- SSRよりも速い
欠点
- 実装が少し面倒
- 用途が限られる
各ルートのHTMLをあらかじめ生成するため、SSRよりもレスポンスが速いのが魅力です。また、静的ファイルを生成するおかげで、SPAと同じようにホスティング先の選択肢が広がります。
生成時にはサーバーサイドでレンダリングすることになるので、SSRを考慮した実装が必要になるのと、静的化には向き不向きがあるので、Webサイトの要件を考えて慎重に選択する必要があります。
静的化の向き不向き
HTMLを事前に生成するため、向いているサイトと、そうでないサイトがあります。
向いているサイト
- 更新が少ないWebサイト
- ドキュメントやブログ
漠然とした表現になりますが、Webサイトっぽいものは向いています。
具体的には、ユーザーごとの最適化がされておらず、みんなが同じ内容のページを見るような、HTMLを事前に生成しても問題がないWebサイトに適しています。
更新のたびに再生成が必要になるので、あまりにも更新が多い場合は再生成が渋滞します。
最も良い例はこのウェブサイト自体です。このサイトは生成され GitHub Pages でホストされています
Nuxt.jsのドキュメントも静的化されているようです。
向いていないサイト
- ログインが必要
- コンテンツが動的に変わる
一方で、ログインが必要だったり、ユーザーごとに最適化されたタイムラインが表示されるような場合は、あらかじめHTMLを生成する利点が少ないどころか、実装が面倒になるので、静的化には向いていません。
気合で解決できるケースもありますが、労力が割に合わないことが多いと思うので、後悔することになるかもしれません。（しました）
迷ったときのフロー
初期表示の速度やSEOがあまり気にならない場合には、SSRや静的化は不要だと思います。Nuxt.jsのおかげで、SSRのことはあまり意識せずに開発できますが、ブラウザに依存しているライブラリが～とか、サーバーの設定が〜とかで、なんやかんや時間をとられるので。
手軽に実装できるSPA
高速だが用途が限られる静的化
もっともバランスが良いのがSSR
という印象です。
個人的には、静的化の利点が大きいと思っているので、少し頑張って静的化できるように実装することが多いです。
「Nuxt.jsで静的化」の良さ
静的サイトには、ホスティングの手軽さやレスポンスの速さなど、多くの魅力がありますが、ただ静的であることを求めるのなら、生のHTMLを書けば済むわけです。
生はちょっと・・・という方は、数ある静的サイトジェネレータの中から好みのものを選ぶことができます。
「Nuxt.jsで静的化」の良さは、使い慣れたVue.jsの延長線上に、その選択肢があるところだと思っています。静的サイトを、コンポーネントベースで組み立てられるのは嬉しいですし、Scoped CSSをはじめとした強力な機能は、静的サイトに秩序をもたらしてくれます。
Nuxt.jsに限らず、Next.jsやGatsbyのように、自分が好んで使っているものの先に、静的化という選択肢があることは、学習コストの面でも嬉しいことだと思います。
SPAという言葉が歩き始めた頃には、まさかそれが一周回って静的サイトになるなんて想像もできませんでしたが、こんなことを考える人は本当にすごいですね。
好きなものを選ぶ
ここまで、静的化の良さを前面に押し出す内容になっていますが、手軽に済ませたい場合はSPAがいいですし、静的化が難しい場合はSSRが適しています。どれを選ぶにしても、あまり意識せずに実装できるのがNuxt.jsのいいところなので、適当に好きなものを選んでみては。
