“SSR doesn’t replace CSR; it complements it. Use the right tool for the right scenario.”
렌더링 방식(CSR, SSR)에 대해서 말하기 전에 '왜 렌더링 방식이 바뀐거지?' 라는 의문 먼저 해결하고자 하니.. 페이지 구조(MPA, SPA)에 대해 모르면 안되는 거였다. 이래서 CSR,SSR을 검색하면 MPA와 SPA를 같이 설명하는 블로그가 있는 것이였다.
MPA + SSR
MPA는 SSR이다.
왜??
MPA는 서버 중심의 웹이다.
사용자가 /about 페이지를 요청하면 서버가 완성된 HTML을 생성하고 브라우저는 HTML을 받아 DOM으로 렌더링하는 것이다.
MPA는 페이지마다 HTML 파일이 있기때문에 이동할 때마다 새 HTML 요청 -> 다시 DOM 전체 재생성으로 브라우저는 그저 "그려주는 역할"만 했고 렌더링의 주도권은 서버에게 있었다.
이때는 HTML을 그리는 주체가 서버, 브라우저의 JS는 단순히 "보조 역할"에 그쳤다고 한다.
그래도 브라우저에서 JS로 렌더링할 수 있는 거 아닌가?
⭐️ MPA 파일 구조를 사용할 때는 브라우저 성능이 낮아서 JS 실행이 느렸고 ES6 문법도 없었을 뿐더러 fetch,Promise,async/await 같은 비동기 통신 도구도 없었기때문에..
데이터를 가져와서 브라우저에서 조립하고 렌더링한다는 것 자체가 성능적으로 불가능하고 비효율적이다.
⭐️ MPA는 애초에 HTML을 서버에서 렌더링하는 구조다. 서버가 이미 완성된 HTML을 줘버린다.
서버가 이미 완성된 HTML을 브라우저한테 넘기는 것이므로 결론은 MPA는 SSR이다.
SPA는 왜 나왔을까? 부터
크게 두 가지로 요약하자면
-
우리가 알고 있는 전통적인 페이지 구조(MPA)는 다른 페이지로 이동할 때마다 서버로부터 HTML,CSS,JavaScript 등 전체 페이지 리소스를 새로 다운로드하고 렌더링을 해야하는데 이과정에서 페이지 깜빡임이 발생하고 불필요한 리소스 재다운로드가 반복되며 비효율적.
-
스마트폰 보급과 함께 모바일 웹 사용이 증가하면서, MPA 방식의 성능 문제가 모바일 환경에서 부담이되면서 빠른 반응 속도를 제공.
결론적으론 웹앱이 복잡해지고 사용자 경험(UX)이 중요해지면서, 페이지 이동마다 새로고침하는 구조(MPA)는 너무 느려진 이유로 인해 Single Page Application이 탄생(?) 하였다는 것이다...
이러한 배경들로 인해 SPA가 나왔고 비동기 통신 도구들도 나왔고 ES6, JS도 발전했으니 서버가 렌더링의 주최가 아닌 브라우저가 렌더링 주최인 CSR을 도전(?)!!
CSR과 SSR
간단하게 말하면 HTML 완성이 브라우저에서냐 서버에서냐의 차이..
CSR (client-side rendering)
..적어야해
SPA + CSR
SPA(Single Page Application) + CSR 은 말 그대로 1)HTML 페이지가 한 개이다. 따라서 2)페이지 전환은 JS가 처리한다. 3)모든 렌더링은 브라우저에서 일어난다.
SPA(1번 + 2번) + CSR(3번) => React의 탄생이다.
처음에는 React에 맞춰서 이런 개념이 생긴 줄 알았으나.. 역방향이였다. 그래서 React가 하는 일은 컴포넌트를 JavaScript 객체로 만들고 이것을 브라우저의 DOM에 그리는것!
SPA에서 페이지 전환은 DOM 조작(교체)으로 한다. DOM 조작(교체)은 브라우저에서만 가능한다 == CSR이다.
SPA + CSR/SSR
언능 적자..
