CSR과 SSR, SSG

◼ 브라우저가 서버로부터 요청해 받은 내용을 브라우저 화면(view)에 표시해주는 작업을 브라우저 렌더링이라고 한다.

◼ 즉, 브라우저가 서버로부터 HTML, CSS, JavaScript 문서를 전달받아 브라우저 엔진이 각 문서를 해석해 화면에 그려주는 것이다.

◼ 그리고 이러한 브라우저 렌더링은 크게 CSR(Client Side Rendering), SSR(Server Side Rendering), SSG(Static Site Generation)으로 나뉘어 이에 대해 알아보고자 한다.

---

CSR(Client Side Rendering)

CSR은 클라이언트(브라우저)에서 렌더링이 이루어지는 방식을 말한다. 즉, 클라이언트는 서버로부터 HTML, CSS, JavaScript를 받아와서, 받아온 파일들을 이용해 클라이언트에서 렌더링을 진행하는 방식이다.

 

💬 방식

◼ CSR은 웹 서비스에서 사용하는 모든 JavaScript, CSS를 bundle.js, bundle.css와 같이 하나의 파일로 번들링한다.

◼ 모든 페이지에서 번들링된 파일들만을 이용해서 페이지를 렌더링하게 된다.

◼ 서버에서 페이지 요청이 오면, 서버는 빈 HTML(<div id="root"></div> 등의 정보만 존재)과 번들링된 bundle.js, bundle.css 파일을 제공하고, 브라우저가 응답을 받은 순간에는 페이지에 어떠한 내용도 표시되지 않는다.

◼ 이후, 브라우저에서 Javascript, CSS를 분석해서 사용자가 요청한 페이지를 렌더링하는 방식이다.

 

🎉 장점

◼ 모든 페이지가 동일한 파일을 요구하기 때문에, JS와 CSS 요청을 한 번만 수행하면 된다.

◼ 모든 화면이 자연스럽게 넘어가 UX를 향상시킬 수 있다.

🤦‍♂️ 단점

◼  번들링된 파일은 사이트에서 사용하는 모든 코드를 합친 것으로 용량이 매우 크다.

◼ 용량이 매우 크기 때문에, 페이지 초기 호출 시간의 지연이 발생한다.

◼ 서버에서 비어있는 HTML을 응답하기 때문에, SEO(Search Engine Optimization)에 불리하다.

---

SSR(Server Side Rendering)

◼ 서버에서 렌더링이 이루어지는 방식이다. 

◼ 각 URI마다 서버가 요청을 받고, 정의된 로직에 따라 페이지를 렌더링하여 응답하는 방식이다.

◼ 브라우저는 서버에서 제공한 파일을 그대로 표시하고, 스크립트를 수행하는 역할 정도가 끝이다.

◼ 즉, 요청이 올 때 마다 해당하는 HTML 문서를 그때 그때 생성하여 반환한다.

🎉 장점

◼ 서버는 클라이언트에게 기본적인 렌더링이 완료된 HTML을 전송해주기 때문에 초기 구동 속도가 빠르다.

◼ SEO 문제도 해결할 수 있다.

🤦‍♂️ 단점

◼ 동적인 UI를 구현하기 힘들다.

---

SSG(Static Site Generation)

◼ 각 페이지의 HTML, CSS, JavaScript를 빌드하고 Uri별 파일을 생성한다.

◼ 파일이 이미 정의되어 있으므로, 기능이 제한적이지만 매우 빠른 정적 렌더링을 사용할 수 있다.

◼ 즉, HTML을 빌드 타임(npm run build)에 각 페이지별로 생성하고, 해당 페이지로 요청이 올 경우 이미 생성된 HTML 문서를 반환한다.

🎉 장점

◼변경될 일이 없는 컨텐츠를 사용하는 경우 미리 빌드해서 제공한다. 이로 인해, 서버나 클라이언트에서 렌더링을 할 필요가 없기 때문에, 리프레시 속도가 매우 빠르다.

🤦‍♂️ 단점

◼ 컨텐츠가 변경될 때마다, 빌드 작업을 계속 수행해줘야 하기 때문에, 빌드 작업이 중요하다.

---

정리

💬 각 렌더링 방법에는 장, 단점이 존재하고 상황에 맞춰서 사용하는 것이 좋다.

💥 자주 변경되는 데이터를 불러오거나 사용자의 상호작용이 중요한 경우 -> CSR 활용

💥 자주 변경되는 데이터이며, 검색 엔진에 노출이 잘 되어야 하는 경우 -> SSR 활용

💥 자주 변경되지 않고 검색 엔진에 노출이 잘되어야 하는 경우 -> SSG