SPAは,第3世代のWebの出現に伴い,既存のWebでは提供できない豊富なUXを実現できる重要な概念である.SPAはCSRとSSRの2つの方法でサポートできます.

SPA vs MPA

MPAはマルチページアプリケーションの略で、複数の静的Webサイトが開発したHTMLページからなる.(第2世代)

SPAは単一ページアプリケーションの略で、第3世代インターネットの発展に伴い、単一HTMLでページを変更することなく、必要な部分をJavaScriptに変換する動的Webを実現することができます.

cf. SPAとMPAの概念

CSR vs SSR

SPAはCSRとSSRの2つの方法で実現でき、CSRは「不合理な出前」にたとえることができ、SSRは「筋道のある出前」、例えば小麦セットである.

非調理出前(CSR)

レストランは材料のみを包装し、顧客(index.html、index.jsなど)

に出荷する.

材料はお客様が最終的に調理し、食後の食事は

です.
最終的に

を形成する段階はクライアント段階

である.

調理型テイクアウト(SSR)

レストランですべての料理を完成した後、お客様に

を出荷します.

調理済みの食べ物は、お客様が直ちに

食事をします.
最終的に

を形成する段階は、サーバ側

である.

Client Side rendering(CSR)

これは、

ページのレンダリングがクライアント(ブラウザ)で発生することを意味する.

ブラウザは、最初のリクエストでhtml、js、およびcss拡張子のファイルを順次ダウンロードし、最初にロードされたhtmlコンテンツは空です.(index.html:html、bodyラベルのみ)

JavaScriptファイルのダウンロードが完了すると、jsファイルは空のHTML上でDOMの描画を開始します.

バックエンドコールの最小化
html、js、cssは、

が最初に呼び出されたときにのみ要求されます.

以降は、画面上で変更が必要なデータのみを要求する.(ex. JSON)

ルーティング(新しいページに移動)でもhtml自体は変わりませんが、JavaScriptの角度から新しい画面を描きます.

レンダリング速度が速く、トラフィックが大きい場合に便利です.

ex Create Resact App(CRA)は、CSRのみを提供するアプリケーションであり、初期設定なしでSPAサイトを実装するのに役立ちます.
=>しかしCSRの欠点は,検索エンジン最適化(SEO)が脆弱であることである.

Server Side Rendering(SSR)

前述したCSRとSSRの違いから、SSRがサーバ上の最初のページのレンダリングを処理する方法は、クライアントではなくサーバ側であることがわかります.

CSRと比べると、

1)UX側面のガラス

CSRと比較すると、ページ組織の速度は遅くなるかもしれませんが、ユーザーに表示されるコンテンツ構成が完了するまでの時間がかかります.

コード分割(分割コード)

最初のページ構成で不要なJSファイルを受け取ったら?

バンドルファイルのサイズが大きいとしたら?

サーバ側が最初のページに必要な静的部分のみを処理し、JS以降は必要に応じてロードするだけで、不要なコンテンツは受信されませんか?

2)SEO側面のガラス

サーバは、ユーザーに表示されるすべてのページを統合し、CSRの欠点である「トップページのゴミ」状態を克服します.

週)ページ構成エラーが発生した場合、サーバの負荷がCSRより大きくなるか、最初の負荷が非常に遅くなる可能性があります.

Search Engine Optimization(SEO)

ページスクロールがページをスクロールすると、CSRからなるページが空白ページと認識され、正しくスクロールできない場合があります.

CSRレンダリングの最初のページは空のインデックスです.htmlであるため、JavaScriptファイルをダウンロードしてページをロードするまで空と認識できます.=>未露出を検索!

とは対照的に、SSR方式は、最初のページをロードすると、すべての情報を含むページ全体が表示されるため、ロールバックが容易であるため、容易に発見される.
=>そこで、SPAの良さを生かしつつSEOを両立させる方法を考えました.=>SSR
cf.サイトドメインで/robot.txtを検索すると、各サイトのスクロール可能/スクロール不可項目が表示されます.

SPA for SSR(補足)

CSRとSSRを混合して使用できます.

1)初めてSSR 2としてレンダリングされた後、CSRとしてレンダリングされます.

SSR要素

node.jsとして構成するフロントエンドサーバ

pyhton,Djangoバックエンドサーバ

SSRプロセス

ユーザー  /と入力します.

プリランFEサーバは要求を受信してSSR

を実行する.
生成されたHTMLをブラウザに送信します.図は、

ブラウザ応答のHTMLである.

HTML  **index.js**ファイルをダウンロードします.(hydration)

ダウンロードが完了すると、  go to second  リンクをクリックします.

2/secondにルーティングされ、第2のページコードが生成される.

hydration

サーバから送信された静的ドキュメントを、データ変更に反応可能な動的形式のクライアントプロセスに変換する.

renderと同じですが、DOMは既に描画されている状態なので、イベントハンドラのみがアタッチされます.

import React from "react";
import ReactDom from "react-dom";
import App from "./App";

const initialData = window.__INITIAL_DATA__;

ReactDom.hydrate(
  <App page={initialData?.page} />,
  document.getElementById("root")
);
// 출처: <실전 리액트 프로그래밍>, 이재승 저

Next.js

ReactJS専用フレーム、

サーバー側レンダリングとコード分割をサポート
主に

の生産性に使用され、SSRのCRAを簡単に構成できます.

SSRに加えて、React Appに必要な多くの必須機能も提供しています.
(動的ルーティング、プリレンダリング、CS-In-JS)