CSR, SSR

들어가기에 앞서

SPA(Single Page Application)

1. 미리 모든 페이지에 필요한 js파일들을 받아두고 이후 페이지 요청에 따라(페이지 이동 시) 갱신에 필요한 데이터만 받고 JS 실행해 컴포넌트를 렌더링하고 화면 업데이트
2. 클라이언트 사이드 라우팅
3. 새로고침 시 불필요한 부분까지 화면이 깜빡이며 새로고침되는 것이 비효율적이라 등장

CSR (Client Side Rendering)

1. 초기 로드 시 빈 HTML과 모든 로직이 담긴 JS를 다운로드
2. 이후 빈 HTML에 JS를 이용해 DOM(or 컴포넌트)을 동적으로 렌더링
3. 클라이언트에서 렌더링

장점

클라이언트 자원을 사용하므로 서버 부하가 적음

단점

1. 처음 페이지 로드 시 빈 HTML을 가져오므로 SEO에 필요한 meta 태그가 비어있어 검색 엔진 최적화(SEO)에 불리
2. 첫 로드 시 모든 로직이 담긴 JS를 다운받아 초기 로딩이 길다

SSR(Server Side Rendering)

1. 서버에서 렌더링해 완성된 HTML 파일을 제공
2. 최초 js파일 로드 없이도 HTML이 이미 렌더되어 보여지기 때문에 페이지 로딩이 빠름

장점

1. 초기 로딩 속도가 빠름
2. 서버에서 렌더링 후 보내주기에 JS번들을 모두 다운받을 필요가 없으므로 TTI(Time to Interactive)이 짧다
3. 완성된 HTML을 받으므로 검색 엔진 최적화(SEO)에 유리
4. 클라이언트 부담이 적다

단점

1. 브라우저 API를 사용할 때 Hydration을 고려
2. 페이지마다 서버에서 페이지를 생성하기에 TTFB(Time To First Byte)가 CSR에 비해 느리다.

둘만 있나?

아니다. CSR, SSR 둘은 대척점에 있는 것 같다.
둘 중 하나만 선택해야하는건 아니다.
언제나 문제를 해결하기 위한 새로운 기술들이 나온다 이 둘을 적절하게 섞은 기법들이 있다.(SSG, Universer Rendering 등)
여기서는 SSG까지만 언급하겠다

SSG (Static Sit Generation)

번역하면 정적 사이트 생성이다.
빌드 타임에 페이지별로 HTML파일을 미리 생성해서 배포해둘 수 있다.
FCP(First Contentful Painting), TTI(Time To Interactive) 모두 시간이 빨라진다.
이미 생성된 HTML을 받으므로 SEO 친화적이다.

이런 SSG도 커버하지 못하는 부분도 있다

모든 URL에 대해 개별 HTML을 생성해야한다 동적인 URL은 HTML을 미리 생성해둘 수 없다.

아래는 서버-클라이언트측 렌더링 기볍에 대해 정리한 표니 한번 보길 추천

마치며

렌더링 방식은 결국 주된 사용자와 서비스 특성에 맞게 선택
개발자는 코드가 최종 렌더링 될 때까지 어떻게 작동하는지 상상하며 개발하는 것이 중요
웹의 동작 원리를 이해하고 최적화까지 해야한다.