CSR(클라이언트 사이드 렌더링)의 몇가지 문제점들을 해결하기 위해서 나온 SSR(서버 사이드 렌더링)은 비교적 새로 나온 신기술 입니다. 그렇다면 모든 것을 서버 사이드 렌더링으로 처리하면 좋은 걸까요? 오늘은 서버 사이드 렌더링의 문제점과, 어떻게 하면 적절한 SSR을 사용할 수 있을 지에 대한 글을 써보고자 합니다.
흔히 CSR이라고 부르는 클라이언트 사이드 렌더링은 사용자가 웹 페이지를 방문했을 때, 브라우저는 빈 HTML 파일을 다운로드 합니다. 그리고 자바스크립트를 실행하여 API 요청을 통해 JSON을 받으면서, 나머지 동적 컨텐츠들에 대한 값을 가져오고 페이지에 그립니다.
CSR을 사용할 때는 자바스크립트 번들링에 신경을 써야하는 데, HTML 파일을 받아 올 때, 애플리케이션 실행에 필요한 모든 자바스크립트 파일, CSS까지 다운로드 해야하기 때문에, 초기 화면을 보기까지의 시간이 오래걸릴 수 있다.
초기 HTML 파일을 빠르게 응답받았다고 하더라도, HTML 파일을 받은 후 동적 컨텐츠의 값들을 재 렌더링 할 때까지 웹 페이지가 로딩 표시 등으로 블락되고, 깜빡임이 발생합니다.
SSR, 서버사이드 렌더링을 사용하면 브라우저가 서버에서 HTML을 받아올 때부터 서버에서 API 요청을 하고, 컨텐츠를 모두 처리하여 HTML을 완성한 상태에서 바로 보여줄 수 있습니다. SSR을 사용하면, HTML 파일만을 받아오면서 데이터를 수집하는 크롤러에 유리하기 때문에 SEO(검색 엔진 최적화)에 장점이 있어 검색이 잘 될 수 있습니다. 그렇지만, CSR과 비교했을 때, HTML 파일을 내려주기 위해서 API 요청 및 데이터를 처리 시간이 추가되기 때문에 최초 응답 시간까지 시간이 더 걸릴 수 있습니다.
표로 정리하자면 다음과 같습니다.
| CSR | SSR | |
| 최초 응답 시간 | 초기 HTML + 자바스크립트 파일을 다운 받는 시간 | 서버 API 요청 + HTML 렌더링 구성되는 시간 |
| HTML 응답 후 블락됨 | 서버 API 요청 + HTML 렌더링 | |
| SEO 최적화 | 불가 | 가능 |
SEO에 유리하다는 면에서 SSR을 사용하면 좋은 점은 있지만, 모든 API 요청을 서버사이드에서 처리하면 최초 응답 시간이 매우 길어지면서 사용자가 하얀 화면만 보게 되는 단점이 있습니다. 따라서 next등을 사용하며 SSR과 CSR을 적절히 혼용하여 사용하는 것을 추천합니다.
기본적인 페이지 구성, 검색에 포함이 되어야 하는 부분이나, 빠르게 호출되는 API는 서버에서 호출하여 SSR로 처리하도록 합니다. 오래 걸리는 API나 필수 요소 아닌 부분은 서버 사이드 렌더링이 된 후에 스켈레톤 등을 사용해서 로딩 애니메이션을 보여주고, 클라이언트 사이드에서 처리하여 사용자 경험을 개선할 수 있습니다.
출처
https://www.elasticpath.com/blog/html-rendering-in-digital-commerce-websites
https://tech.kakaopay.com/post/skeleton-ui-idea/
'프로젝트 > 경험정리' 카테고리의 다른 글
| FE개발자가 프로모션 페이지 개발을 할 때 고려할 점 (1) | 2024.04.29 |
|---|---|
| 타입스크립트에서 중복되는 타입 선언 리팩토링하기 (1) | 2023.11.26 |