클라이언트 사이드 렌더링(CSR)
자바스크립트로 DOM을 조작하여 브라우저에서 HTML을 렌더링하는 방식입니다. 프로세스는 다음과 같습니다.
- 서버에 HTTP 요청이 이루어집니다.
- 서버는 요청을 수신한 후, 번들된 자바스크립트와 함께 빈 HTML shell을 클라이언트에 전송하여 응답합니다.
- 클라이언트는 빈 HTML shell을 수신하고, 모든 자바스크립트를 처리합니다.
- 자바스크립트는 DOM을 광범위하게 수정하여 최종 사용자에게 최종 HTML을 렌더링 합니다.
즉, 서버가 아닌 브라우저에서 자바스크립트를 처리하여 HTML로 렌더링 하는 것을 말합니다.
CSR의 장점
CSR의 장점은 본질적으로 SSR과 정반대입니다. 전체 HTML 페이지가 클라이언트에서 자바스크립트로 빌드되므로, 인터랙티브 한 기능에 대한 가용성이 뛰어납니다. 페이지가 처음 로드되면 모든 콘텐츠가 최종 사용자에게 매우 빠르게 반응합니다. 모든 다른 페이지의 코드도 초기 페이지가 로드될 때 함께 로드되기 때문입니다. 사실 개발자 입장에서 클라이언트 사이드 렌더링은 훌륭한 경험을 가져다줍니다. 서버와 워크로드를 공유해야 하는데서 오는 복잡성이 사라지고, 재사용 가능한 인터랙티브 컴포넌트를 구축하는 데 집중할 수 있어 개발 프로세스가 간소화됩니다.
CSR의 단점
하지만 CSR 프레임워크가 폭발적으로 증가한 지 얼마 되지 않아, SEO 전문가들은 Google 및 기타 검색 엔진이 이러한 페이지의 인덱싱을 제대로 수행하지 못한다는 사실을 깨닫기 시작했습니다. 초기 페이지 로딩 속도가 가장 큰 단점입니다. CSR 환경에서 페이지는 처음에 콘텐츠가 없는 빈 HTML 셸로 클라이언트에 전송됩니다. 이 빈 껍질이 Google 및 기타 검색 엔진에 표시되는 경우가 많았고 이는 명백히 바람직하지 않습니다. 자바스크립트가 페이지를 매우 빠르게 빌드하긴 하지만, 실제로 대부분 검색 엔진은 DOM 조작이 완료되고 HTML이 렌더링 된 후에도 여전히 콘텐츠를 인덱싱하는 데 어려움을 겪습니다. 최악의 경우에는 잘못 빌드된 클라이언트 사이드 렌더링 앱의 형편없는 로드 시간이 사용자 경험에 매우 부정적인 영향을 미치기도 합니다.
서버 사이드 렌더링(SSR)
SSR은 CSR과는 정반대로 웹사이트의 HTML을 서버에서 렌더링 하는 방식입니다. 프로세스는 다음과 같습니다.
- HTTP 요청이 서버로 전송됩니다.
- 서버는 요청을 수신하고, 필요한 모든 코드(또는 대부분의 코드)를 그 자리에서 처리합니다.
- 최종 결과는 완전한 형태를 갖춘 HTML 페이지로, 서버 응답을 통해 클라이언트의 브라우저로 전송됩니다.
겉으로 보기에는 매우 간단한 개념이지만, 사실 자바스크립트를 요하는 인터랙티브 한 컴포넌트를 클라이언트에 포함시키는 방법을 고려해 보면 상황이 상당히 복잡해질 수도 있겠습니다.
SSR의 장점
SSR의 최대 이점은 페이지 로드 속도입니다. 페이지 로드 속도는 사용자 경험과 SEO측면에서 중요한 지표입니다. SSR 환경에서는 페이지가 서버에서 HTML로 렌더링 될 때 모든 무거운 작업이 함께 처리됩니다. 이러한 이유로 응답이 클라이언트의 브라우저에 도달하고 나면, 브라우저에서는 페이지를 표시하기 위해 추가로 해야 할 작업이 많지 않습니다. 전송되는 즉시 준비가 됐다고 볼 수 있어요.
SSR의 단점
초기 페이지 로드가 우선순위고 SEO가 중요하다면 서버 사이드 렌더링이 훌륭한 선택이라는 것은 놀라운 일이 아닙니다. 대부분 자바스크립트 프레임워크가 렌더링 옵션에 SSR을 포함한 데에는 이유가 있습니다. 하지만 SSR에도 몇 가지 단점이 있습니다.
예를 들면 디자이너는 페이지가 인터랙티브 하길 원할 수 있는데, 동적 콘텐츠를 구현하려면 서버와 클라이언트가 추가적인 데이터를 주고받아야 해 CSR에 비해 제약이 많습니다. 그렇다고 페이지를 순수 HTML로만 렌더링 하면 사용자 경험이 매우 단조로워질 겁니다. 그리고 애플리케이션의 데이터 로드가 주는 영향 역시 염두에 두어야 합니다. 데이터 로드가 많으면 SSR 프로세스가 느려지고 결국 애플리케이션 성능에 영향을 미칠 수 있습니다. 이는 개발자가 클라이언트에서도 데이터를 페치 하는 이유 중 하나기도 합니다. 또한 서버 사이드에서 데이터를 처리하는 경우 호스팅 제공업체로부터 꽤 많은 수수료가 발생할 수도 있습니다. 프로젝트에 많은 외부 데이터가 필요한 경우 이 점을 주의 깊게 살펴봐야 합니다.
프로젝트에 SSR을 활용하는 방법
자체 프레임워크를 구축하려는 것이 아니라면 SSR을 처음부터 구현하기는 어렵습니다. 다행히도 프로젝트에서 SSR을 활용하는 데 도움이 되는 프레임워크와 라이브러리가 많이 있습니다. 인기 있는 옵션 중 하나는 곧 챌린지에서 학습하게 될 React 프레임워크 Next.js입니다. 코드 분할 및 기타 성능 최적화와 함께 SSR에 대한 기본 지원을 제공합니다.
3. SSR 적용 여부 확인 방법
사이트에서 서버 사이드 렌더링을 사용하고 있는지 확인해야 할 때가 있습니다. 예를 들어, 개발자와 SEO 전문가 모두 SEO 문제를 해결하고 최적화하기 위해서 이 정보가 필요한 경우가 많습니다. 이를 확인하는 데 일반적으로 사용되는 몇 가지 기법에 대해 설명하겠습니다.
Page Source 확인
사이트에서 SSR을 사용하는지 쉽게 확인할 수 있는 방법은 페이지 소스를 확인하는 것입니다. HTML 코드에 body, image, text 등 모든 콘텐츠가 포함되어 있다면 해당 사이트가 SSR을 사용하고 있을 가능성이 높습니다. 반면에 HTML 코드가 bare-bone이라면 콘텐츠를 렌더링 하는 데 자바스크립트가 필요합니다. 이 경우 서버 사이드 렌더링을 사용하지 않을 가능성이 높습니다.
웹 브라우저에서 마우스 오른쪽 버튼을 클릭하고 View Page Source를 눌러보면 <p>, <h1>과 같은 콘텐츠 요소를 쉽게 찾아볼 수 있습니다. 여기에 해당 요소가 표시되면 서버 사이드에서 렌더링 되고 있을 가능성이 높습니다:
Google Cache 확인
콘텐츠가 서버 사이드에서 렌더링 되는지 쉽게 확인할 수 있는 또 다른 방법은 Google Cache를 확인하는 것입니다. 주소창 URL 앞에 cache:를 입력하고 엔터 치기만 하면 됩니다. 아니면 Google 검색창에 해당 URL 검색 후 About this result창에서 cached를 선택해도 스냅숏 페이지로 이동합니다. 일반적으로 시각적으로 보이는 모든 부분이 서버 사이드에서 렌더링 되는 것입니다. 만약 자바스크립트로 렌더링 하는 경우라면 대부분 볼 수 없을 것입니다:
자바스크립트 비활성화
브라우저에서 자바스크립트를 비활성화하여 사이트에서 SSR을 사용하는지 테스트할 수도 있습니다. 웹사이트의 콘텐츠가 자바스크립트 없이도 여전히 표시된다면 SSR을 사용하고 있을 가능성이 높습니다. 웹사이트가 공백으로 표시되면 SSR을 사용하지 않는 것입니다. 아래 사진에서는 에어비앤비가 홈페이지에서 서버 측 렌더링을 활용하지 않고 있음을 알 수 있습니다:
*비활성화하는 방법
4. 결론
서버 사이드 렌더링은 웹 애플리케이션의 성능과 사용자 경험을 개선하는 강력한 도구가 될 수 있습니다. HTML을 클라이언트로 전송하기 전에 서버에서 렌더링함으로써 웹 페이지를 표시하는 데 필요한 시간을 크게 줄여 로드 시간을 단축하고 사용자 환경을 개선할 수 있습니다. 올바르게 사용하면 검색 엔진이 쉽게 크롤링할 수 있는 HTML 문서를 제공하기 때문에, SSR의 기술적 장점은 일반적으로 SEO 개선으로 이어집니다.
*참조
https://www.freecodecamp.org/news/server-side-rendering-javascript/
https://www.linkedin.com/pulse/server-side-rendering-pros-cons-consider-seo-prahlad-rawat