SSR CSR
https://youtu.be/C6uELkDh-60
화라리님 영상: SPA 등장 배경과 CSR
client - server
client가 요청을 보내면 server는 요청을 보고, 알맞은 html을 내려줌(응답)
client는 그 응답(html문서)을 바탕으로 DOM에 그림
(DOM을 그리면서 css처리 + js를 로드하겠죠?)
이 과정을 반복함.
그러나 점점 웹이 진화하고, 내려줘야 하는 양도 늘어남.
js 등장 이후로 사용자와의 인터랙션도 늘어남.
정적인 정보만을 보여주는 웹의 초기 역할을 넘어섬!
요청/응답 과정이 많아지는거겠져
따라서 server 부하 & client 페이지 깜빡임(html을 새로 받아 그리기 때문)이 발생함
AJAX의 등장!
페이지의 일부분만 바꾸는 컨셉.
비동기처리
fetchAPI 가 가능해짐
여기서 만족하지 않고,
SPA의 등장!
url을 움직이더라도 html을 다시 내려주고 싶지 않음!
react가 SPA 만드는 것을 지원하는 라이브러리.
이 react는 CSR 방식으로 동작함!
CSR는 앞에서 설명한 방식과 다르게, client가 알아서 화면을 그림
(쉽게 말해.. client 혼자 다 해먹음)
여기부턴 화라리님 프로젝트 코드로.
투두리스트 프로젝트를 실행하고, Network 탭 - Doc을 클릭하면
server가 응답해주는 html을 볼 수 있는데,
클릭해보면, body 태그에 텅빈 div 태그 하나만 있음. 익숙한 id="root"만 있고,
즉, server에서 내려준 html은 비어있었는데, 실제 화면에서는 많은 게 그려지고 있음.
그럼 이것들은 어디서 나온 것이냐?
script 태그로 불러오고 있는 bundle.js 파일을 통해 만들어진 것!
리액트는 build를 할 때, 내가 짠 모든 리액트 코드를 하나의 자바스크립트 파일로(여기서는 bundle.js) 만들어줌!
(babel로 transpiling, webpack으로 bundling)
그리고, 사용자가 처음 사이트에 들어왔을 때,
server는 비어있는 html을 응답해버리고 client에서 bundle.js를 읽음
이 bundle.js를 읽고 DOM 화면을 그려주게 되는 것!
또한, 이 프로젝트에서 버튼을 클릭해서 url이 변경되어도(페이지가 변경되어도)
Network 탭에서 확인해보면, server는 새로운 html을 반환하지 않음.
client에서, 변경된 url에 맞는 코드를 bundle.js에서 찾아서 그림
이러한 CSR의 장점은 웹을 앱처럼 사용할 수 있다는 것!
url이 바뀌어도 html을 다시 내려 받지 않고, client에서 알아서 그림
따라서 화면 깜빡임없이 앱과 같은 경험으로 웹사이트를 사용할 수 있다.
단점은, 서비스 커질수록 코드가 많아지면 번들링된 하나의 자바스크립트 파일의 크기가 커질 수밖에 없음.
파일의 크기가 커지면 커질수록 파일을 로드하는 시간이 오래 걸림.
로드하는 시간이 오래 걸린다 = 사용자가 첫 화면을 보기까지가 오래 걸린다.
화면에 뭔가가 그려지는 것을 보는데까지 시간이 너무 오래 걸린다.
(화면에 그려지는 타이밍 = interaction을 할 수 있는 타이밍)
즉, 유저가 첫 화면을 보는 시점이 너무 늦다. 심지어 SEO 관련 문제까지!
이러한 단점을 해결하기 위해서 CSR과 SSR을 합쳐서 만들면 어떨까? 라는 아이디어가 나왔고,
react에서 이 기술을 할 수 있게 도와주는 게 next.js라는 기술임
(이어서) next.js로 살펴보는 SSR
유저가 첫 화면을 보는 시점이 너무 늦다. 화면에 뭔가가 그려지는 데까지 시간이 너무 오래 걸리는 이 단점은,
사실 code splitting(코드를 쪼개는 것)으로 어느정도 해결할 수 있다.
CSR이라고 하더라도 url이 고정적으로 하나는 아니잖아요.
url마다 각각 번들링된 js파일을 만들 수 있다.
그러면 bundle.js에 몰빵되지 않기 때문에 로드 시간이 빨라진다!
하지만, SEO 검색 엔진 최적화 대응은 힘들다는 단점이 있었지.
국내 검색봇들은 html을 기반으로 요소를 찾기 때문에
빈 html을 내려주는 CSR을 사용하면 불리해진다.
이러한 단점을 극복하기 위해
사용자가 처음 들어왔을 때의 페이지는 server에서 받아 렌더링하고,
그 뒤에 발생하는 라우팅은 CSR 으로 하면 어떨까? (CSR, SSR 각각의 장점을 합친 방식)
첫 페이지를 server에서 받는다는 의미는
내용이 모두 채워져있는 html을 받는다는 것!
그러면 client에서는 DOM을 그대로 그리기만 하면 되겠죠.
(이후 interaction이 가능한 js파일은 따로 load) --> 그래서 ttv와 tti 사이 공백이 생기는 것..
js를 DOM으로 변환하는 과정 없이요.
그러면 당연히 SEO 대응이 가능해지고,
code splitting 안했을 때 CSR 방식보다 사용자가 화면을 보는 타이밍도 빨라짐.
그래서 next.js 라는 프레임워크
next.js의 중요한 컨셉 중 하나는, page를 기반으로 build 한다는 것!
page는 여러개의 component로 이루어짐
넥스트는 pages 폴더 내에 있는 파일 이름을 기반하여 라우팅이 동작함.
화면에 보여지는 내용이 server에서 받은 내용인지 확인하기 위해 Network 탭을 열어서 확인해보면,
이렇게 초기렌더링은 SSR 방식으로 구현되고 있는 것을 확인할 수 있고,
이제 내부에서 페이지 이동을 할 때 CSR 방식을 사용하려면 next/link나 next/router를 활용하면 됨
이렇게 Link태그를 사용하고 각 페이지를(pages 폴더 내에 있는 파일) 연결한 뒤
링크를 클릭하면 해당 페이지로 이동하고 + 새로운 html을 응답받지 않는다!
처음 html 파일 그대로 인데 CSR이 동작하면 해당하는 js파일이 실행돼서 DOM의 내용이 변경되는 것.
(실제로 해당 html 파일을 클릭해서 확인해보면
DOM 내용만 변경된 것을 확인할 수 있다!)
이렇게, 최초 렌더 시 SSR로 동작하고, 그 뒤로는 CSR로 동작한다는 것을 알게 됨.