CSR vs SSR vs SSG

웹 페이지를 렌더링하는 방식에는 크게 CSR(Client Side Rendering), SSR(Server Side Rendering)이 있다. 이 둘의 차이점을 살펴보자.

들어가기 전에, FCP, TTI에 대해 알아보자.

FCP & TTI

FCP (최초 컨텐츠풀 페인트, FCP)

• 브라우저가 DOM에서 첫 번째 컨텐츠 비트를 렌더링하여, 페이지가 실제로 로드되고 있다는 첫 번째 피드백을 사용자에게 제공하는 것.

• 최초 컨텐츠풀 페인트는 브라우저가 텍스트, 이미지, 비디오 등을 처음 렌더링한 시점임.

TTI ( Time To Interactive)

• 사용자가 웹사이트를 방문하고 웹 페이지가 완전히 반응하는데 걸리는 시간

FP, FCP, TTI

CSR(Client Side Rendering)

• 클라이언트(브라우저)에서 웹 페이지를 렌더링하는 것

• 모든 로직, 데이터 가져오기, 템플릿, 라우팅은 서버가 아닌 클라이언트에서 처리된다.

• Javascript 번들 크기의 영향을 많이 받으므로 code splitting을 고려해야 한다.

• 필요한 것만, 필요할 때만 제공해야 한다.

CSR 동작 방식

1. 사용자가 웹 페이지를 방문하면(request), 브라우저는 최소한의 HTML파일을 다운로드한다.(response) 이 HTML파일은 script, meta, link 등의 태그를 포함하며, 빈 컨텐츠의 index.html파일이다.

2. 브라우저는 index.html에 있는 javascript 번들 파일을 다운로드한 다음, Ajax를 통해 API를 수행하여 동적으로 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링한다.

3. 사용자가 페이지를 이동할 경우, 서버에 추가 HTML 파일을 요청하지 않고 이미 받은 javascript를 이용하여 렌더링한다.

CSR 장점

• CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.

• 후속페이지 로드 시간이 더 빠르다. CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문이다.

• 별도의 API를 호출할 필요가 없는 페이지의 경우, 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.

CSR 단점

• 초기 페이지 로드 시간이 SSR에 비해 느리다. CSR을 사용하면 브라우저는 브라우저에서 HTML을 컴파일하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다.

• 브라우저가 페이지를 표시하기 전에 HTML, Javascript 파일을 다운로드하고 프레임워크를 실행하는 동안 사용자는 빈페이지를 보게 되므로 사용자 경험(UX)이 좋지 않다.

SSR (Server Side Rendering)

SSR 동작 방식

SSR 장점

SSR 단점

SSG (Static Site Generator)

SSG 동작 방식

SSG 단점