45. フロントエンドのレンダリングパターンを学ぼう【CSR、SSR、SSG】 #220
Conversation
| https://github.com/YamazakiYusuke/praha-challenge-front-end-rendering/pull/1/commits/70b8afd965d545dd1a89d307610e85b50cb10aa5 | ||
|
|
||
| > 作ったssg.tsxがSSGで描画されていることを確認してください | ||
| run buildするとssgとして認識されている。React賢い。 |
There was a problem hiding this comment.
SSGを実行しているのは、Reactではなく Next.js なので要注意です
| ## Client Side Rendering (CSR) | ||
| Client Side Rendering（略してCSR）は、JavaScriptを使用してブラウザ上でWebサイトやアプリケーションをレンダリングする手法である。CSRでは、コンテンツの処理とレンダリングはサーバーではなくブラウザで行う。 | ||
| 具体的には、サーバーはJavaScriptファイルへのリンクが含まれた最低限のHTMLファイルを送信し、ブラウザが必要なリソースをダウンロードしてページをレンダリングする。 | ||
| [What is Client-side Rendering (CSR)?](https://prismic.io/blog/client-side-rendering) | ||
|
|
||
| ### 適しているサイト | ||
| 1. 動的なコンテンツを持つサイト: | ||
| - チャットアプリ | ||
| - ソーシャルメディアプラットフォーム | ||
| 2. 高度なインタラクティブ性を必要とするアプリケーション: | ||
| - シングルページアプリケーション（SPA） | ||
| 3. 検索エンジンにインデックスされる必要のない内部アプリケーション: | ||
| - 管理画面 | ||
| - ユーザーダッシュボード | ||
|
|
||
| ### メリット | ||
| - **高速な結果表示**: 必要に応じてHTMLが生成される為、ページ全体のリフレッシュやリレンダーが発生せずに、SSRより高速に結果を表示することができる。 | ||
| - **スケーラビリティの向上**: サーバーの負荷が軽減されるため、スケーラビリティが向上する。 | ||
| - **効率的な開発プロセス**: フロントエンドとバックエンドの開発が分離されているため、開発プロセスが効率的になる。 | ||
| - **リアルタイムデータ更新**: リアルタイムでのデータ更新が容易で、WebSocketなどを利用した双方向通信が可能。 | ||
|
|
||
| ### デメリット | ||
| - **初期ロードの遅延**: 初期ロードで全てのJavaScriptをロードし、APIからデータを取得するので、時間がかかる。 | ||
| - **SEOの不利**: SEOで不利。Googleはクローラーは、データを取得する前の状態のページを見てコンテンツが充実していないと判断してしますので。 | ||
| - **キャッシングの問題**: ブラウザーがページをキャッシングできない。対策として、JavaScriptをキャッシングすることもできるが、ブラウザーのメモリーをより多く専有することになる。 | ||
|
|
||
| [Pros and Cons of Client-Side Rendering](https://www.pluralsight.com/resources/blog/guides/pros-and-cons-of-client-side-rendering) |
There was a problem hiding this comment.
なんかこの課題、議論が分かれるところをきっちり説明しろとか要求していて嫌ですね
| 3. コンテンツが頻繁に変わらないサイト: | ||
| - ドキュメントサイト | ||
| - 企業のコーポレートサイト |
There was a problem hiding this comment.
この例は通常、SPAやSSGの方が適してる例で出てくると思うのですが...(なぜなら、phpと同じでいちいち計算するのだから内容が変わらなくても鯖の負担は変わらない)
SSR + webサーバーのキャッシュ という例かな?
There was a problem hiding this comment.
キャッシングを含めた場合という意味で理解していました。
確かに、コンテンツが頻繁に変化しない場合はSSGのほうが適切ですね。
ただ、SPAについては、コンテンツが変化しないサイトに対して適しているとも適していないとも言えない気がします。なぜSPAが適していると思われたのでしょうか？
There was a problem hiding this comment.
なぜSPAが適していると思われたのでしょうか？
実際にはコーポレートサイトをSPAで作られることは少ないと思いますが
(Wordpress・レンタルサーバーを主にスタックとして扱う会社に依頼してる例をよくみる)
SPA,SSGだとJamstackな構成になるので、単純にホスティングにかかるランニングコストが安いからです。
あと、SSGは実現方法にもよりますが、だいたいSPAを包含していて
例えばReactをSSGする流れとしては
- ビルド時にSPAを一度レンダリング(pre-render)してhtmlとして吐き出す
/assets以外のリクエストが index.html に fallback される環境で配信する (多くのホスティングサービスがこの処理をサポートしているが、Next.jsの場合はディレクトリ毎にhtmlが生成されるので一般的なSPAとは少し異なる)- ブラウザに配信時にjsを読み込みReactアプリケーションとして動くようになる(hydration)
という流れなのでようは、例えば Next.js や Vite で SSG した React アプリケーションというのは SPA なんですよね
There was a problem hiding this comment.
という流れなのでようは、例えば Next.js や Vite で SSG した React アプリケーションというのは SPA なんですよね
なるほどです。色々調べてみましたが、純粋なSSGだけのツールはほぼなさそうですね。
SSGだけだとできることがかなり制限されますよね。一般的にはSSGはCSRと組み合わせて構築するのですね。
納得です。
| ### 課題2-2-1（CSR） | ||
| > 作ったcsr.tsxにhttps://jsonplaceholder.typicode.com/posts/1というAPIを叩いて取得できるデータを表示してください | ||
|
|
||
| https://github.com/YamazakiYusuke/praha-challenge-front-end-rendering/pull/1/commits/a1ccde114c64dc917318d0baf946ab4b5a7c882c |
| ### 課題2-2-2（SSR） | ||
| > このときサーバー側でデータが取得されるようにしてください | ||
|
|
||
| https://github.com/YamazakiYusuke/praha-challenge-front-end-rendering/pull/1/commits/616e50100c2c007cde7876d65b3712498336f939 |
お手隙の際にレビューお願いいたします🙇♂️