【web制作】2023年フロントエンドをやるなら知っておくべき知識

前回は自分がなぜNext.jsを選んだかという記事だったのですが、技術選定はほんとめんどくさいと思いました。
ですがベストパフォーマンスを追い求めるなら最適な技術選定を追い求める必要があります。

技術選定をするにしても、最低限知っておかないといけない知識がいくつかあります。
それがアプリケーションの違いとレンダリングの違いです。
前回はちょっとやっつけでレンダリングの違いだけ書きましたが、今回はもう少し詳しく深掘りたいと思います。

ゴリゴリに開発している方は今更だと思いますが、今からウェブアプリやウェブサイトを開発する方、レンダリングやフレームワークに興味がある方には多少役立つかもしれません。

アプリケーションの違い

ややこしいですが、ページ遷移ごとにHTMLを取得しにいくのがMPA、ページ遷移ごとに差分をJSでレンダリングするのがSPAです。

MPA（Multi-Page Application）

MPAは、ウェブアプリケーションが複数のページで構成される形式です。ユーザーが異なるリンクをクリックすると、新しいページがロードされて画面が切り替わります。例えば、メインページから「お問い合わせ」をクリックすると、別のページに遷移してお問い合わせフォームが表示されるような形式です。

主な特徴

• ページごとに独立して表示・運用されるため、SEO（検索エンジン最適化）の観点では扱いやすい。

• サーバーとのリクエストが頻繁に発生するため、画面切り替え時にページ全体がリロードされる場合がある。

SPA（Single-Page Application）

SPAは、ウェブアプリケーションが1つのメインページのみで構成される形式です。初回アクセス時に必要なリソース（HTML、CSS、JavaScript）を一度ロードした後、ページの切り替え時にはサーバーとの通信を最小限に抑え、非同期でコンテンツをロードして表示します。ユーザーが異なる部分をクリックしてもページ自体はリロードされず、部分的にコンテンツが入れ替わるような形式です。

主な特徴

• 初回ロードに時間がかかる場合があるが、ページ切り替えが高速でスムーズ。

• SPAは1つのページで全てのコンテンツを処理するため、特定のページが検索エンジンにインデックスされにくい場合がある（SEOに対する対策が必要）。

レンダリングの違い

レンダリングとは何かを簡単にいうと、データなどを取得してHTMLにデータを埋め込む処理のことです。（ブラウザにおけるレンダリングもあってややこしいですが省略します）

JSフレームワークは(他にもありますが)データの取得、ビルドなどを経て最終的に静的なHTML、CSS、JSを生成し、それをブラウザが描画します。
その静的なファイルをどこで生成するかによって、SSR、CSR、SSGと大きく3つに大別されます。

分かりやすくするため、動的にブログ記事を取得してページを生成する流れを考えてみます。

CSR（クライアントサイドレンダリング）

クライアントサイド（ブラウザ）でレンダリングを行います。

例えば「/blog/post001」にアクセスがあったとします。
サーバーは最低限のHTMLとCSS、それにレンダリングに必要なJSをレスポンスします。
このJSはHTMLの文章構造やらテキストやらレイアウト情報やら、なんやかんや全部入りなのでサイズがかなり大きいです。

ブラウザはレスポンスを受け取るとJSを解析して「/blog/post001」に必要なデータを取得し、DOMツリーを形成し、レイアウト、ペイントを行います。

CSRを行う場合、そのほとんどはSPAであると思われます。
そのためページ遷移時には差分のみJSを取得しページを更新します。
「/blog/post001」から「/blog/post002」に遷移する場合、ナビゲーションバーやサイドメニューなどのテンプレートは変更する必要がない場合が多いでしょう。
そのためクライアントはpost002の情報のみ取得し、差分を更新するだけで済みます。

CSRに関してはGmailを想像していただけると分かりやすいと思います。
初回ロードでページをクライアントサイドで描画し、次のページボタンを押すとメールリストの内容のみ更新されます。

CSRはSSRに比べ初期ロードが重いものの、その後の動的な描画は速いと言われており、インタラクションを入れたりできるなどリッチな表現が可能です。

デメリットとしては初期ロードが遅いこと、SEOに弱いと言われることが挙げられます。

SSR（サーバーサイドレンダリング）

SSRはMPAに用いられるレンダリング手法です。
アクセスごとにサーバーでデータを取得し、ページを生成します。

「/blog/post001」にアクセスがあった場合を考えます。
クライアント（ブラウザ）からアクセスがやってくると、サーバーは/blog/post001のデータをDBから取得し、テンプレートにはめこみ静的なHTMLを生成し、クライアントにレスポンスを返します。

静的なファイルをレスポンスするためブラウザ上での処理が少なく済み、初期ロードはCSRに比べ速いです。
またGoogle botが正確にHTMLを解釈できるため、CSRに比べSEOに強いと言われています。(CSRはGoogle botがjsをレンダリングする必要があり、近年レンダリングの精度は高いと言われているものの、どのくらい正確なのかはブラックボックスです)

SSRを用いる場面としては、SEOを重視しつつ、例えばユーザーのコメントを取得して表示するといった更新頻度が高いアプリなどが挙げられます。

個人的にはSSRならNext.jsかなと思っています。

SSG(スタティックサイトジェネレーター）

SSGはSSRの進化版です。
サーバーでいちいちレンダリングするより、事前にレンダリングして配置しておけばよくない？という感じです。

事前にファイルを生成するためSSR、CSRに比べてロードが速いですが、動的にコンテンツの更新が必要な場合は向いていません。

SSGでウェブサイトを構築する場合、ホスティングサービスを使うことが多いと思います。
Vercel、Cloudflare pagesを個人的にはよく利用しますが、これらのサービスはgithubに連携させると、自動でウェブサイトをビルドし、生成された静的ファイルを配信してくれます。
しかもCDNに配信されるため、世界中どこからアクセスがあっても速いです。
それでいて無料枠が充実しているので本当に神だと思います。

デメリットとしては毎回ビルドの必要があるためアクセス毎にコンテンツを更新したいような動的なアプリは作れないことと、サイトの規模が大きくなるとビルドの時間が長くなることでしょうか。
最近だとビルド時間短縮問題を解決するために、Next.jsのISRというものが出てきたりしています。

個人的にはSSGはAstroが最強だと思っています。
Qwikが今後どうなるかは注視です。

どんな時にどれを採用すればいいの？

おおまかに言ってしまえば、

• SEOを重視せず操作感を重視するアプリならSPA

• SEOを重視して動的なコンテンツの更新頻度が低いならSSG

• SEOを重視して動的なコンテンツの更新頻度が高いならSSR

だと思っています。

まとめ

昨今はMPA化するSPA、SPA化するMPAと、どちらもお互いの良いところを取り入れようとしているように感じます。

フレームワークの特徴や得意なことをしっかりと把握し、ベストな技術選定を行いましょう。