서버 사이드 렌더링

서버 사이드 렌더링(Server-Side Rendering, SSR)은 웹 애플리케이션의 렌더링 방식 중 하나다. 서버에서 페이지를 만들어 클라이언트로 보내는 방법이다. 흔히 클라이언트 사이드 렌더링(Client-Side Rendering, CSR)과 비교한다.

렌더링이란?

렌더링이라는 용어는 문맥에 따라 의미를 다르게 해석할 수 있다. 브라우저에서 렌더링이란 HTML, CSS 및 자바스크립트를 파싱하는 것부터 페이지를 화면에 보여주기까지의 전 과정을 의미한다. 그렇다면 서버 사이드 렌더링은 서버에서 브라우저의 화면을 그리는걸까? 화면을 그리는 건 브라우저가 하는 일이다. 따라서 브라우저에서의 렌더링과 그 의미가 다르다. SSR의 렌더링은 서버에서 HTML을 만드는 과정이다. 그렇다면 정적 렌더링(Static Rendering)과는 어떤 차이가 있는걸까? 정적 렌더링 방식도 서버에서 HTML을 생성하기 때문에 그 둘을 구별할 수 있어야 한다. 그 차이는 렌더링을 하는 시점에 있다. 정적 렌더링은 빌드 시점에 HTML을 생성하지만 서버 사이드 렌더링은 클라이언트 요청에 따라 동적으로 렌더링한다. 즉 서버 사이드 렌더링은 서버 사이드 "동적" 렌더링이라고 할 수 있다.

왜 초기 화면일까?

SSR의 장점으로 가장 많이 언급되는 것 중 하나는 초기 로딩이 빠르다는 점이다. 브라우저 입장에서 본다면 서버가 자신이 할 일, 예를 들어 리액트 앱이면 자바스크립트를 파싱하여 HTML을 채우는 작업을 서버가 대신 해준 셈이다. 상대적으로 고용량인 자바스크립트 파일이 도착할 때까지 기다리지 않아도 된다. 덕분에 사용자는 빠르게 화면을 볼 수 있다. 만약 DOM을 변경할 필요가 없는 페이지에서는 서버가 처음에 보내준 문서가 곧 엔드 콘텐츠가 될 수 있다. 따라서 정적 콘텐츠의 비중이 높은 서비스에서 SSR은 좋은 전략이 될 수 있다. 반면 DOM을 자주 변경하는 페이지라면 초기 렌더링의 이점은 누릴 수 있겠지만 상호작용에 따라 서버로 HTML을 다시 요청해야 하므로 이는 UX에 나쁜 영향을 주기 쉽다. CSR은 초기 렌더링이 상대적으로 느릴 뿐이지(이마저도 코드 스플리팅으로 어느 정도 극복이 가능함) 렌더링된 이후에는 부드럽고 빠른 화면 전환을 보여준다. 따라서 SSR과 CSR의 장점을 적절히 조합하는 것이 중요하다.

장점

초기 로딩이 빠르다. 자바스크립트를 해석하여 빈 문서로부터 모든 것을 그려야 하는 CSR과 다르게 서버에서 초기 렌더링을 책임지기 때문에 사용자는 빠르게 초기 화면을 볼 수 있다.
검색 엔진 최적화에 좋다. 검색 엔진의 크롤러는 주로 HTML을 크롤링하는데, 서버에서 미리 만들어진 HTML이 바로 노출되므로 웹 페이지가 담고 있는 정보를 크롤러가 쉽게 수집할 수 있다.
클라이언트의 성능이나 호환성에 제약을 덜 받는다. 성능의 장점은 서버의 컴퓨팅 성능이 클라이언트보다 더 좋을 때 누릴 수 있다.

단점

상호작용에 따라 화면이 전체적으로 렌더링될 수 있다. 이는 좋지 않은 사용자 경험으로 이어진다.
웹 서버를 관리해야 한다. 리소스가 많아지고 트랙픽이 증가하면 이는 서버 부담으로 이어진다. 요청이 많아지는 경우 지연이 발생하여 오히려 초기 로딩이 느려질 수 있다.

언제 도입해야 할까?

검색 엔진 최적화가 필요할 때
동적 콘텐츠가 많지 않은 경우
초기 로딩 속도가 중요한 경우
서버의 강력한 성능이 필요한 경우