개발
[10분 테코톡] 타미의 CSR과 SSR
| 웹 애플리케이션의 역사
초창기 웹은 텍스트 중심의 단순 문서
MPA(Multi Page Application) : 다중 페이지로 이루어져 있어, 변경사항이 있을 때마다 서버로 페이지를 요청해서 새로 렌더링함
페이지를 이동할 때마다 서버로부터 새로운 html 파일을 내려받기 때문에 새로고침 발생
웹에 사진, 영상, 인터렉션이 많이 생기고, 복잡도가 높아지면서 성능 이슈가 생김
AJAX의 등장 : 필요한 부분만 리로드할 수 있게 해줌
SPA(Single Page Applicatio) : 단일 페이지로 이루어져 있어, 갱신될 부분에 대해서만 데이터를 요청하여 렌더링함
새로고침이 발생하지 않아, 사용자 경험에 좋음
MPA -> SSR 방식 채택, SPA -> CSR 방식 채택
| CSR & SSR & SSG
어디서 렌더링을 처리할 지에 따라 차이남
CSR(Client Side Rendering)
클라이언트 측에서 렌더링을 담당하는 것
첫 로딩에 빈 html 파일에 필요한 번들파일을 모두 다운로드 받음
사용자가 웹 접속하고, 브라우저가 서버에 리소스를 요청함. 이후 서버가 JS/CSS를 불러올 수 있는 빈 html 파일을 브라우저에게 주고, 브라우저가 JS 코드를 다운받아 사용자에게 페이지를 제공
Good : TTFB(Time to First Byte) : 요청을 보내고 응답의 첫 번째 바이트가 도착하기까지의 시간
Bad : FCP(First Contentful Paint) : 사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫 번째 지점
SSR(Server Side Rendering)
서버 측에서 렌더링 될 페이지를 그려 클라이언트로 보내주는 방식
사용자가 웹에 접속하고, 브라우저가 리소스를 요청함. 이후 서버가 초기 콘텐츠가 로딩된 페이지를 브라우저에게 제공하고, 브라우저는 JS 코드를 다운 받고 사용자에게 정적인 페이지를 제공한 뒤에, 이벤트리스너를 할당해 인터랙티브한 페이지를 제공
Good : FCP(First Contentful Paint) : 사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫 번째 지점
Bad : TBT(Total Block Time) : FCP로부터 TTI(Time To Interact) 사이의 시간
TTI(Time To Interact) : 사용자가 페이지에서 상호작용이 가능하기까지의 시간
SSG(Static Site Generation)
요청 즉시 HTML 파일을 만드냐 vs 미리 다 만들어둔 정적 페이지를 제공하느냐
| CSR과 SSR의 장단점
CSR
장점
화면 깜빡임이 없어 좋은 사용자 경험을 제공
한 번에 번들 파일을 다운로드받기에, 초기 로딩 이후 구동 속도가 빠름
단점
초기에 다운 받느라 구동 속도가 느림
SEO가 어려움
SSR
장점
초기 로딩속도가 빠름
SEO가 쉬움
단점
페이지를 이동할 때 화면이 깜빡여 사용자 경험 저하
매번 요청을 보내기 때문에 서버가 과부화 될 수 있음
| SEO(Search Engine Optimization) : 웹사이트 검색 결과가 더 잘 보이도록 최적화 하는 과정
검색봇이 웹사이트를 크롤링하면서 수집된 정보를 색인화
저장된 정보를 바탕으로 SEO를 한다.
만약, 빈 html 파일을 읽게 되면 검색봇이 해석하기 어려워함
구글의 검색봇은 JS를 실행시킬 수 있어 해석할 수 있음
| 뭐가 더 좋은 렌더링 방식일까?
SEO vs 사용자 경험
뭐가 더 좋은 렌더링 방식은 없고, 프로젝트에 필요한 방식을 채택하는 것이 중요
| 언제 어떤 방식을 써야 할까?
CSR
사내에서만 쓰는 서비스라 SEO가 불필요한 경우
SSR
이커머스 사이트처럼 검색 유입이 중요한 경우
초기 로딩 속도가 중요한 경우
SSG
데이터 변동이 없는 정적 사이트를 렌더링할 경우
| CSR+SSR(Universal Rendering)
초기 렌더링은 초기 구동 속도가 빠르다는 SSR 방식 사용
다른 페이지로 이동할 때는 깜빡임이 없는 CSR 방식 사용
| CSR과 SSR을 사용하는 라이브러리 & 프레임워크
