오늘은 SPA CSR SSR에 대해 정리를 해보자!
이전에도 정리를 한 기억이 있지만 한번 더 정리하면서 복습도하고 또 제대로 기억하고자 이 주제를 선택했다.
SPA ❓
SPA는 Single Page Application의 약자이다. 즉 , HTML 파일이 1개인 웹 페이지를 말한다. 페이지의 갱신이 없고 URL의 경로에 따라 페이지를 렌더링 해 줄 수 있다. 즉 라우팅이 가능하다. 또 동적으로 렌더링이된다. javascript 파일에 의해 DOM이 동적으로 수정되고 이를 렌더링한다.
정리하면 다음과 같다.
SPA ?
1. HTML이 1개!
2. 페이지의 갱신이 필요없다!
3. 라우팅이 가능하다(URL에 따른 갱신없는 렌더링)
4. 동적 렌더링! (javascript파일로 동적으로 HTML을 꾸며준다)
그럼 React는 SPA프레임워크일까? 더 정확하게 말하면 CSR 프레임 워크이다.
자, 복습할겸 사용자가 웹 페이지를 요청했을 때의 상황을 정리해보자
유저가 웹 페이지를 요청하면 ❓
사용자가 요청한다 => 어이 나 네이버좀 보여줘 =>사용자: www.naver.com 입력 => 자동으로 https적용해서 naver.com과 통신하고자함 => 일단 DNS 캐싱 기록을 살핌 => DNS 정보없네 아으 DNS 서버한테 물어봐야겠다. => 야! 나 naver.com 도메인입력들어왔는데 이거 IP주소좀알려주라 => DNS 서버: ㅇㅇ 기달 여기 이거임 ㅋㅋ 152.xx.xxx => 브라우저: 오 받았다. 이제 http 요청 메세지 보낼게 네이버 HTML, 쿠키 , Javascrip파일 등등좀 받아올게 => HTTP요청메세지 전송중 (TCP/IP 루트를 사용중) => 서버: 오 나받았음 오키 여기 reponse 메세지에 담아서줄게 => 브라우저: ㅇㅇ ㄱㅅ 받았음 나이제 렌더링할게 => 브라우저 렌더링 엔진 : 아으 드디어 받았네 HTML 파일은 파싱해서 DOM트리로바꾸고 CSS파일은 CSSOM 트리로 바꿀게 => 아으 바꿨따. 이제 두개 조합해서 Render 트리만들게 => 이제 뷰포트에 맞게 조정좀하자 어디에 이거 노드 넣어야할지좀 (Layout)=> 예상 위치 다 그렸다 이제 그릴게 (Paint)
아침이라 그런지 제 정신이 아닌거 같지만 이러한 과정을 거쳐 웹 페이지를 유저는 볼 수 있게 된다.
그럼 저기에 CSR 과 SSR을 구분짓는건 어떤 HTML 파일과 어떤 JS파일을 보내주냐에 따라 다른 것이다. 즉, 렌더링할 때 어떤 HTML 파일과 어떤 JS파일을 렌더링하느냐에 따라 달렷다.
CSR ❓
CSR은 Client Side Rendering의 약자이다.
즉, Client에서 모두 다 그리는 것이다. 이게 헷갈리면 안되는게 결국 Rendering은 브라우저의 렌더링엔진에 의해 일어난다.
어디서 HTML파일을 꾸미느냐에 따른 렌더링 구분이다.
먼저 CSR 은 빈 HTML이 보내진다. 애초에 React는 HTML이 텅텅비어있어 id="root"인 div 안에 javascript를 통해 웹 페이지를 그린다.
그럼 CSR은 서버로부터 빈 HTML 파일과 모든 javascript 파일을 받는다.
CSR은 서버로부터 빈 HTML 파일과 모든 Javascript 파일을 받는다.
그렇기 때문에 어떤가?? 처음 로딩이 있을 수 밖에없다. Javascript 파일이 정말 대용량이라면?? 엄청나게 오래 걸릴 것이다.
대신 이미 받아놓은 javascript 파일만 있으면 다음 페이지 전환시에는 매끄러운 전환이 가능하다. UX가 좋아질 것이다.
그리고 HTML이 비어있기 때문에 검색엔진(SEO)에 불리할것이다.
그럼 특징을 정리할 수 있다.
- 첫 페이지 로딩이 오래걸린다.
- 페이지 전환은 빠르다(로딩x)
- SEO에 불리하다.
- 서버자원을 많이 사용하지 않는다.(처음 javascript와 html을 받아올때 사용, 그 후 동적으로 서버에 요청할 때만 사용)
SSR ❓
SSR은 서버에서 HTML을 꾸며서 가져다준다. 자세하게 말하면 다음과 같은 순서로 SSR은 일어난다.
사용자가 요청 => 서버에서 html 파일에 "동적으로" javascript를 입혀 렌더링이 가능한 상태의 html파일을 만든다. (Ready To Render) => 이를 클라이언트(브라우저)에 보낸다 => 브라우저는 이를 렌더링한다.=> 서버로부터 Interaction에 필요한 javascript 파일을 받아온다. => 받아온 후 Interation이 가능한 페이지 완성!
이때, 브라우저가 렌더링 한 후 javascript파일을 다운로드하는데 이때 interation이 일어나지 않는 시점이 발생할 수 있다.
여기서 또 페이지 전환이 일어난다며 위와 같은 과정이 똑같이 일어난다.
필요한 html 파일을 서버가 그려주고 이를 받아서 브라우저는 렌더링하고 그 동안 javascript 파일을 다운받는데 이떄 interation이 발생하지 않을 수 있고 javascript 파일이 다 받아지면 website rendering 끝
핵심은 "필요한 부분의 HTML을 꾸며서 가져다주고 필요한 부분의 javascript 파일을 받아와 interation이 가능하게한다."
그럼 특징을 정리할 수 있다.
- HTML이 꾸며져있어 SEO(검색엔진)에 유리하다
- 초기 로딩속도가 빠르다(필요한 부분만 가져오니까)
- 대신 페이지 로딩이 매끄럽지않다(그때 또 서버로부터 html파일과 javascript를 받아야하니까)
- 서버에 무리가간다. (페이지 전환 할 때마다 서버에 요청)
TTV TTI ❓
CSR은 사용자가 화면을 보는 시점(Time To View)과 상호작용(Time To Interact)이 가능한 시점이 동일하다.
반면 SSR은 사용자가 화면을 보는 시점(Time To View)과 상호작용(Time To Interact)사이에 공백이 있다.
즉, TTV, TTI 시점에서는 CSR 방식이 더 좋다고 말할 수 있다.
그럼 언제 CSR SSR ❓
CSR
- 유저가 매끄러운 UX를 느꼈으면 한다!
- 나는 main javascript 파일이 크지 않다!
- 나는 SEO는 별로 상관없다!
- 내 서버는 싼 서버라 뭔가 불안하다!
SSR
- 나는 첫 페이지 로딩이 길지 않았으면 좋겠다!
- 내 main javascript의 크기가 크니까 좀 분할해야겠다!
- SEO 중요하다!
- 서버도 빵빵하고 사용자도 많을 거 같다!
