웹 에서의 렌더링
웹 에서의 렌더링이란, 웹 브라우저가 HTML, CSS, JavaScript 및 기타 웹 기술을 사용하여 웹 페이지의 내용을 화면에 표시하는 프로세스를 말한다.
일반적으로, 웹 브라우저는 HTML 문서를 먼저 다운로드하고 파싱한 후, CSS 스타일을 적용하여 각 요소의 크기, 색상, 배치 등을 결정한다. 그런 다음 JavaScript 코드를 실행하여 동적으로 콘텐츠를 변경하거나 추가적인 기능을 제공한다.
이러한 렌더링 방식은 대표적인 세 가지로 분류할 수 있다.
CSR (Client Side Rendering)
말 그대로 위의 그림과 같이 '클라이언트(브라우저)'에서 모든 로직, 데이터 가져오기, 템플릿, 라우팅 등이 이루어지는 렌더링 방식을 말한다.
서버로부터 웹 페이지에 관한 HTML, CSS, 스크립트 파일을 받아와 클라이언트의 브라우저에서 직접 렌더링을 진행하고, 동적인 컨텐츠의 경우엔 Ajax 를 통해 API 요청을 수행하여 렌더링한다.
장점
- 서버로부터 초기에 전체 UI 를 받아오기 때문에 후속 페이지 로드 시간이 빠르다.
- 페이지가 로드된 이후, 클라이언트에서 동적으로 콘텐츠를 업데이트 할 수 있어 사용자 경험(UX)이 향상된다.
- 프론트엔드와 백엔드가 분리되어 개발할 수 있어 협업과 개발 생산성을 향상된다.
단점
- 초기에 기본 HTML, CSS, 스크립트 파일들을 서버로부터 로드해와야 하기 때문에 초기 페이지 로드 시간이 SSR 에 비해 느리고, 사용자의 이탈률에 큰 영향을 미칠 수 있다.
- 검색 엔진 크롤러가 페이지 콘텐츠를 인식하는 데 어려움이 있을 수 있어, SEO(Search Engine Optimization) 에 친화적이지 않다.
- 클라이언트의 하드웨어 및 소프트웨어에 과하게 의존하므로, 렌더링 시간에 개인차가 존재할 수 있다.
- 브라우저가 페이지를 표시할 때 데이터를 서버에서 받아오는 동안 사용자는 빈 페이지를 보게되므로, 사용자경험(UX) 가 좋지 않다.
적용 상황
- 유저와 상호작용하며 클라이언트에서 관리해야 하는 상태가 복잡하고 많을 때
- 클라이언트에서의 상태 변경이 잦을 때
- 사용자 경험과 상호작용 속도가 중요할 때
SSR (Server Side Rendering)
위 그림과 같이 서버에서 뷰 구성에 필요한 전체 HTML을 요청을 받은 즉시 생성해서 반환하는 방식을 말한다.
이를 통해 클라이언트 브라우저에서는 응답을 받은 후, 이미 완성된 뷰가 그대로 보여지게 된다.
장점
- 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 초기 페이지 로드 시간이 빠르다.
- 서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다.
- 검색 엔진이 SEO(Search Engine Optimization) 에 친화적이다.
단점
- 페이지 이동 시마다 서버에서 페이지를 생성하는데 시간이 걸리므로 TTFB(Time to First Byte) 가 느리다. 이 때문에 사용자 경험(UX)을 해칠 수 있다.
- 서버 사이드에서 HTML 파일과 안의 내용을 생성해야 하기 때문에 서버 호스팅이 필요하다.
- CSR 에 비해 더 많은 개발 노력이 필요하며, SSR 프레임워크를 사용할 경우 추가적인 비용이 발생한다.
적용 상황
- 첫 페이지 로딩 속도가 중요할 때
- SEO가 중요할 때
- 보안 상의 이슈로 서버에서 데이터를 받아오고 클라이언트에서는 숨겨야 할 때
SSG (Static Site Generation)
웹 사이트를 빌드할 때, 미리 페이지를 렌더링하여 정적인 HTML 파일을 생성하는 방식을 말한다.
이렇게 생성된 HTML 파일들은 서버에 배포되어 사용자가 요청할 때마다 동적으로 생성하는 것이 아니라, 이미 미리 생성되어 있는 파일을 제공함으로써 빠르고 안정적인 웹 사이트를 제공한다.
장점
- 미리 정적으로 페이지를 생성하기 때문에 초기 로딩속도가 빠르고, 페이지 요청마다 서버에서 따로 페이지 렌더링을 기다릴 필요가 없어 후속 페이지 로드 시간도 빠르다.
- 이미 생성된 HTML 파일을 받기 때문에 SEO 에 친화적이다.
단점
- 미리 모든 URL에 대한 페이지를 빌드 단계에서 생성하기 때문에, 예측 불가능한 URL 에 대해서는 적용이 어렵고 페이지 수가 많고 빈번하게 변경되는 경우에는 서버 부하가 증가할 수 있다.
- 동적인 컨텐츠를 처리하기가 상대적으로 어렵다.
- 빌드 시점의 페이지 데이터를 가져오므로, 최신 정보를 표시하는데 어려움이 있을 수 있다.
적용 상황
- 한 번 콘텐츠를 발행하면 잘 변하지 않는 경우
- 유저와의 상호작용 보다는 정적인 콘텐츠의 빠른 전달이 중요할 때