Next.jsのSSG、本番にデプロイして初めて速さを実感した

私は今まで現場ではReact案件ばかりをこなしてきました。 なのでReactをベースにしたフレームワークであるNext.js、 特にApp Routerやレンダリング方法にバリエーションが出てくるNext13以降には、 「どちら様ですか・・・？」状態の苦手意識を持っていました。

ここではそんな私がこのブログを通じてSSGってこういうことなんだ・・・！を 実感したお話をしていこうと思います。

きっかけ

このブログは、NotionをCMSにしてNext.jsでSSGを利用して作成しています。 Next.jsで作りたかったのは、案件による経験不足を補いたかったのもありますが、 面談のたびにSSGはビルド時にHTMLを生成しておくんだな、 SSRはリクエストごとにサーバーがHTMLを作るんだな、 と丸暗記していたのをやめたかったからです。

要は知識としてではなく、体感したものを知識に昇華したかったので、SSGを利用しました。 本当はAstroとか爆速ブログ構築フレームワークがあるのは承知の上で、あえてNextを選んでいます。

最初の疑問

そんなこんなで、いざSSGでブログ開発を開始。

ただ、、ローカル環境で開発しても、一覧→記事ページへの遷移が、、遅い・・・！ なんで！？？SSGってこんなに遅い！？実装間違ってる！？？

開発中はずっと「SSGってこんなもの？？言うほど早くなくない？？」と思っていました。

デプロイして気づいたこと

「まあいいや、一回デプロイしてみよ。」 この決断が正しかった。

Vercelでデプロイ、公開してみたら明らかに表示が速い・・・！ ここで初めて私はSSGの「速さ」を実感しました。

ビルド時にページが静的に生成される。 クライアントがアクセスするときは、すでに生成済みのページを配信するだけだから、SSGは爆速なんだ。 SSGは、Static Site Generation。Generation。すでに生成済みということなのか！

SSRやCSRはともかく、「SSG」に関しては完全に理解できた瞬間でした。 （SPAはいつもReactでやってるからさておき。）

SSGの仕組みを自分のブログに当てはめる

このブログの場合、ざっくり分けると「ビルド時」と「アクセス時」で次のような流れになります。

ブログ記事取得処理は、ブラウザからのアクセスのたびに行われているわけではなく、 ビルド時にNotionから記事データを取得してページを生成しておき、アクセスがあったときには生成済みのページを配信する。

アクセスのたびにHTMLを構築しない分、早く表示ができるということですね。

今回の学び

わからないなら、作ってみるといい。そして体感してみるといい。 これが今回の最大の学びです。

SSGはStatic Site Generation、と覚えるのではなく、 SSGはこのブログで使った。つまりビルド時にHTMLを生成しておいて、アクセス時は生成済みのものを表示するだけ。だから速い。

動くものを見て、実感して、そこで初めて仕組みを理解する。 これからもよくわからないものは作って体感してを意識したいと思えた一件でした。