SSR & CSR 되새김

• SSR (전통적)

장점: 화면에 전체가 한방에 렌더 됨, 검색 엔진에 최적화 되어있다.

단점: 한번에 데이터까지 받아오기 때문에 그 과정이 길어 로딩 속도가 느리다.
(방문 하지도 않을 페이지 까지 받아오기 때문에 비효율적)

브라우저 -> 프론트엔드 서버 -> 백엔드 서버 -> 데이터베이스

ex)

1. 브라우저가 프론트 서버로 blog page를 요청함

2. 프론트 서버는 백엔드 서버에 blog page의 게시글을 요청함

3. 백엔드 서버는 데이터베이스에 실제 게시글을 요청함

4. 역순으로 (데이터베이스 -> 백엔드 서버 -> 프론트엔드 서버 -> 브라우저) 전달

• CSR (리액트)

장점: 우선적으로 화면을 표출 해주고 데이터를 받아오기 때문에 각각의 요청 응답 과정이 짧다.
(사용자는 빠른 사용자 경험을 느낀다고 착각)

단점: 결국 모든 데이터를 받아오는 시간은 SSR보다는 길다.
우선적으로 화면을 표출할때(로딩창) 컨텐츠가 없기 때문에 검색 엔진에는 최적화 되어있지 않다.

브라우저 -> 프론트엔드 서버 -> 브라우저 -> 백엔드 서버
-> 데이터베이스 -> 백엔드서버 -> 브라우저

ex)

1. 브라우저가 프론트 서버로 blog page를 요청함

2. 프론트 서버는 blog page에 필요한 html, js, css img 파일등 전달 (데이터 없음)

3. 데이터가 없으니 프론트엔드 개발자는 로딩창을 구현해서 브라우저에 렌더 시켜놔야 함

4. 한번 더 요청을 보냄 백엔드 서버에 직접 게시글을 요청

5. 백엔드 서버는 데이터베이스에 게시글을 요청하고 응답을 받아 브라우저에 응답

보통 3초안에 화면이 렌더 되지 않는다면 사용자들은 속도가 느리다고 판단한다.

그래서 CSR이 좋은게 데이터를 바로 받아오지는 않지만,
우선 렌더 되는 화면(로딩창)을 받아와 이를 이용해서 데이터를 받아올 시간을 번다.

대부분의 서비스는 속도와 검색엔진 두마리 토끼를 잡아야 한다.
그래서 CSR, SSR을 섞어 사용 (코드 스플리팅)

ex) 첫 방문만 SSR방식으로 진행 이후 페이지를 옮길때에는 CSR방식으로 진행

쿠팡 잘 보면 공통 데이터는 ssr한 다음에 개인정보 관련된 것만 얼른 csr한다.
많은 개발자들이 이 방식을 선호 한다.

• 붉은 선: SSR
• 검은 선: CSR