서버 사이드 렌더링
서버 사이드 렌더링(SSR, Server Side Rendering)은 서버에서 페이지를 구성한다음 클라이언트에 보여주는 방식입니다. 기존의 웹 개발에서 주로 사용되는 방식으로 브라우저에 렌더링되는 형태를 HTML 문서로 만들어서 전송하게 됩니다. 이 방식은 HTML 문서 전체를 다시 보내기 때문에 새로고침이 필요합니다. 또한 페이지 갱신시에 클라이언트 사이드 렌더링 방식에 비해 오래걸린다는 점이 있습니다.
장점
- 검색 엔진의 최적화가 가능하다. = 별다른 설정 없이 크롤러의 작동이 원활하다.
- 첫 접속 때 HTML문서만 빠르게 로딩해서 보여주기 때문에, 초기 로딩 속도가 빠르다고 느낄 수 있고 조작도 가능하다.
단점
- 서버 트래픽을 사용하게 되므로, 과부하를 대비한 성능 최적화 등이 필요하다.
- 코드 스플리팅, 라우터 등의 문제로 인해 코드가 복잡해 질 수 있다.
현대에 와서는 요청마다 새로고침이 발생하고, 한 페이지에서 보여주는 정보가 무수히 많은 웹 페이지에서 사용자 경험을 해칠 수 있으므로 이 문제를 해결하기 위해서 클라이언트 사이드 렌더링이 등장하게 되었습니다.
클라이언트 사이드 렌더링
클라이언트 사이드 렌더링(CSR, Client Side Rendering)은 클라이언트측에서 자바스크립트 파일을 통해 페이지의 콘텐츠들을 렌더링 하는 방식입니다. 처음에는 자바스크립트 링크만이 걸려있는 빈 문서를 빠르게 로딩시키고, 사용자와 첫 상호작용을 하는 순간 필요한 콘텐츠들을 렌더링 해줍니다. 이 덕분에 사용자는 SSR방식보다 빠르다고 느낄 수 있게 됩니다.
CSR은 먼저 사용자에게 렌더링하고, 필요하면 추가/삭제를 하는 개념 덕에 처음 보여주는 화면 구성은 SSR보다 빠르지만 전체적으로 봤을 때는 SSR방식보다는 느려진다는 점이 있습니다.
장점
- 필요하거나 수정된 부분의 데이터만 서버에서 로드하기에, 서버 트래픽이 SSR에 비해 낮아진다.
- 새로고침이 없어서 사용자는 편하게 느낀다.
단점
- 검색 엔진 크롤러가 제대로 된 수집을 할 수 없다.
SSR? vs CSR?
그렇다면 과연 SSR과 CSR 중에서 무엇을 선택해야 할까요? 위의 설명만 들으면 SSR 방식은 오래된 방식이고 느리다고 생각될 수 있습니다. 어느정도 맞는 이야기지만 그렇다고 SSR이 나쁜 방식이라는 것은 아닙니다.
결국 상황에 맞춰서 SSR과 CSR을 선택해서 개발해야합니다. 각 방식의 장.단점에서 확인했듯이 SSR은 크롤러가 정보 수집을 잘 하고, CSR은 크롤러가 정보 수집을 잘 하지 못합니다. 그래서 빠르게 정보를 보여줘야하는 페이지라면 CSR을 사용하고, 검색 엔진에 잘 잡혀야 한다면(쇼핑몰, 블로그 등) SSR을 선택하는 것이 좋습니다. 두 방식은 서로 뭐가 더 뛰어나다의 차이는 없고 특징이 다릅니다. 결국 우리는 상황에 맞게 각 방식의 특징과 장단점을 생각해서 적절한 렌더링 방식을 선택하는 것이 중요합니다.
