[WEB #12] SPA vs MPA, CSR vs SSR
SPAは,第3世代のWebの出現に伴い,既存のWebでは提供できない豊富なUXを実現できる重要な概念である.SPAはCSRとSSRの2つの方法でサポートできます.
MPAはマルチページアプリケーションの略で、複数の静的Webサイトが開発したHTMLページからなる.(第2世代) SPAは単一ページアプリケーションの略で、第3世代インターネットの発展に伴い、単一HTMLでページを変更することなく、必要な部分をJavaScriptに変換する動的Webを実現することができます. cf. SPAとMPAの概念 SPAはCSRとSSRの2つの方法で実現でき、CSRは「不合理な出前」にたとえることができ、SSRは「筋道のある出前」、例えば小麦セットである. 非調理出前(CSR) レストランは材料のみを包装し、顧客(index.html、index.jsなど) に出荷する.材料はお客様が最終的に調理し、食後の食事は です.
最終的にを形成する段階はクライアント段階 である.
調理型テイクアウト(SSR) レストランですべての料理を完成した後、お客様に を出荷します.調理済みの食べ物は、お客様が直ちに 食事をします.
最終的にを形成する段階は、サーバ側 である.
これは、ページのレンダリングがクライアント(ブラウザ)で発生することを意味する. ブラウザは、最初のリクエストで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)が脆弱であることである.
前述したCSRとSSRの違いから、SSRがサーバ上の最初のページのレンダリングを処理する方法は、クライアントではなくサーバ側であることがわかります. CSRと比べると、 1)UX側面のガラス CSRと比較すると、ページ組織の速度は遅くなるかもしれませんが、ユーザーに表示されるコンテンツ構成が完了するまでの時間がかかります. コード分割(分割コード) 最初のページ構成で不要なJSファイルを受け取ったら? バンドルファイルのサイズが大きいとしたら? サーバ側が最初のページに必要な静的部分のみを処理し、JS以降は必要に応じてロードするだけで、不要なコンテンツは受信されませんか? 2)SEO側面のガラス サーバは、ユーザーに表示されるすべてのページを統合し、CSRの欠点である「トップページのゴミ」状態を克服します. 週)ページ構成エラーが発生した場合、サーバの負荷がCSRより大きくなるか、最初の負荷が非常に遅くなる可能性があります.
ページスクロールがページをスクロールすると、CSRからなるページが空白ページと認識され、正しくスクロールできない場合があります. CSRレンダリングの最初のページは空のインデックスです.htmlであるため、JavaScriptファイルをダウンロードしてページをロードするまで空と認識できます.=>未露出を検索! とは対照的に、SSR方式は、最初のページをロードすると、すべての情報を含むページ全体が表示されるため、ロールバックが容易であるため、容易に発見される.
=>そこで、SPAの良さを生かしつつSEOを両立させる方法を考えました.=>SSR
cf.サイトドメインで CSRとSSRを混合して使用できます. 1)初めてSSR 2としてレンダリングされた後、CSRとしてレンダリングされます.
SSR要素 node.jsとして構成するフロントエンドサーバ pyhton,Djangoバックエンドサーバ SSRプロセス ユーザー プリランFEサーバは要求を受信してSSR を実行する.
生成されたHTMLをブラウザに送信します.図は、ブラウザ応答のHTMLである. HTML ダウンロードが完了すると、 2 サーバから送信された静的ドキュメントを、データ変更に反応可能な動的形式のクライアントプロセスに変換する. renderと同じですが、DOMは既に描画されている状態なので、イベントハンドラのみがアタッチされます.
ReactJS専用フレーム、サーバー側レンダリングとコード分割をサポート
主に の生産性に使用され、SSRのCRAを簡単に構成できます. SSRに加えて、React Appに必要な多くの必須機能も提供しています.
(動的ルーティング、プリレンダリング、CS-In-JS)
SPA vs MPA
CSR vs SSR
最終的に
最終的に
Client Side rendering(CSR)
これは、
html、js、cssは、
=>しかしCSRの欠点は,検索エンジン最適化(SEO)が脆弱であることである.
Server Side Rendering(SSR)
前述したCSRとSSRの違いから、SSRがサーバ上の最初のページのレンダリングを処理する方法は、クライアントではなくサーバ側であることがわかります.
Search Engine Optimization(SEO)
=>そこで、SPAの良さを生かしつつSEOを両立させる方法を考えました.=>SSR
cf.サイトドメインで
/robot.txt
を検索すると、各サイトのスクロール可能/スクロール不可項目が表示されます.SPA for SSR(補足)
/
と入力します.生成されたHTMLをブラウザに送信します.図は、
**index.js**
ファイルをダウンロードします.(hydration) go to second
リンクをクリックします./second
にルーティングされ、第2のページコードが生成される.hydration
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専用フレーム、
主に
(動的ルーティング、プリレンダリング、CS-In-JS)
Reference
この問題について([WEB #12] SPA vs MPA, CSR vs SSR), 我々は、より多くの情報をここで見つけました https://velog.io/@kykim_dev/WEB-12-SPA-vs-MPA-CSR-vs-SSRテキストは自由に共有またはコピーできます。ただし、このドキュメントのURLは参考URLとして残しておいてください。
Collection and Share based on the CC Protocol