SSR 과 CSR 의 차이 (Feat. SPA, MPA, SEO)
처음 웹을 개발할 때 SSR 과 CSR 의 차이점을 명확하게 알지 않고 단지 UX 측면에서 CSR 이 더 유리하기 때문에 무조건 CSR 방식이 좋다고 생각하였다. 하지만 현 시점, SSR 방식의 웹페이지가 다시 사용되고 있다는 아티클을 접하고, 두 방식에 대해 정확하게 알아보기 위해 공부하고 작성하기로 한다. 이번 글에서는 SSR 과 CSR 의 차이점, 이를 이해하기 위해 필요한 개념 SPA 와 MPA 그리고 SEO 에 관해서 다뤄보기로 하고, 어떤 방법이 어떤 웹 개발시 적합한지에 대해 작성한다.
0. SEO 알아보기
SSR 과 CSR 을 알아보기 전에 SPA 와 MPA 를 알아야 하는데, SPA 와 MPA 를 공부하다보니 SEO 라는 용어가 나와 이것 또한 공부해보기로 한다.
SEO (Search Engine Optimization) 으로 검색 엔진 최적화 이다. 사용자가 구글, 네이버 같은 검색창에 무언가를 검색했을 때, 내 웹사이트가 더 위에 노출되도록 만드는 기술/전략 이다. 평소 우리가 구글링을 할 때, 대부분 가장 위에 있는 사이트나 1페이지에 있는 검색창을 활용한다. 특히 상위 3개 결과가 전체 클릭의 50 ~ 70% 를 차지한다는 통계가 있다.
SEO 는 크롤링, 인덱싱, 랭킹을 통해 작동한다. 크롤링은 웹페이지에서 데이터를 수집하는 작업을 뜻한다. 이를 수행하는 소프트웨어를 크롤라고 한다. 인덱싱은 수집한 정보를 검색 엔진 내부 DB 에 정리/저장 하는 과정이며 랭킹은 누군가 검색했을 때, 가장 적절한 페이지를 상위에 보여주는 과정을 뜻한다.
1. SPA 와 MPA 짚어보기
SPA 와 MPA 는 웹에 구조적 방식에 관한 개념으로, 어떤 방식으로 페이지를 구성하고 전환하는지에 대한 차이를 가지고 있다. SPA 와 MPA 개념을 공부하게 되면 SEO 와 관련된 내용이 등장한다.
1.1 SPA (Single Page Application)
SPA (Single Page Application) 는 한 개의 HTML 파일로 모든 페이지를 구성하고, JavaScript 로 페이지를 전환하는 구조이다. 쉽게 말해 사용자가 클릭했을 때 전체 페이지를 다시 로드하지 않고, 필요한 부분만 바뀌는 형식이다. React, Vue, Angular 등 요즘 프론트엔드 프레임워크들이 대표적인 SPA 방식이다. 페이지 간 이동은 JS 기반의 가상 라우팅으로 처리한다. 따라서 SEO 에 약하다. SEO 의 경우 첫페이지 로딩시 해당 HTML 에 있는 정보를 기준으로 크롤링을 하게 되는데, 이 때 처음 받은 페이지는 JS 실행 전이기 때문에 비어 있는 페이지이므로 크롤링에 불리하다. 요즘 구글봇이 발전하여 SEO가 발전했다고 하지만 그럼에도 불구하고 MPA 방식보다 불리한건 사실이다.
붕어빵 틀로 비유 하자면, 하나의 붕어빵 틀에서 손님이 팥과 크림중 하나를 요청을 하게 되면, 그 틀에서 재료만 바꿔서 즉석에서 제공한다고 보면 된다.
1.2 MPA (Multi Page Application)
MAP (Multi Page Application) 는 요청할 때마다 새로운 HTML 파일을 받아오는 전통적인 웹 방식이다. 쉽게 말해 페이지마다 별도 URL 과 HTML 이 존재한다. 따라서 페이지가 변경될 때 마다 서버에 요청하여 응답하는 방식이다. 서버가 각 요청에 맞는 HTML 문서를 생성 또는 반환하며 PHP, JSP, Django 등 이 대표적인 MPA 방식이다. 따라서 SPA 와 다르게 서버가 완성된 HTML 을 제공하기 때문에 SEO 에 유리하고, 크롤러가 페이지 내용을 쉽게 인식할 수 있다.
붕어빵 틀로 비유하자면 팥붕, 크림붕 각각 미리 완성된 붕어빵이 준비되어 있고, 손님이 팥을 요청할 경우 미리 만들어둔 팥붕을 꺼내서 주는 셈이다.
2. SSR, CSR 그리고 SSG 알아보기
일반적으로 SPA 는 CSR 로, MPA는 SSR 로 렌더링되는 경우가 많다.
SPA 는 웹 애플리케이션에서 필요한 정적 리소스를 한꺼번에 모두 다운받은 뒤, 이후 페이지 전환은 클라이언트에서 처리하는 CSR 구조를 사용한다.
반면 MPA 는 각 페이지마다 HTML 파일이 존재하고, 페이지 전환마다 서버에서 HTML 을 새로 받아오기 때문에 SSR 로 동작하는 경우가 많다.
이러한 특징 때문에 SPA 는 CSR, MPA 는 SSR 이라고 착각하지만, SPA/MPA 는 페이지 구조 방식, CSR/SSR 은 렌더링 방식이라는 점에서 구분되어야 한다.
2.1 SSR (Server Sider Rendering)
말 그대로 서버쪽에서 렌더링 하여 화면을 보여주는 방식이다. 서버로부터 완전하게 만들어진 HTML 파일을 받아와 화면을 제공하기 때문에 첫 화면 로딩 속도가 빠르다. SSR 과 CSR 에 대해 검색하면 나오는 유명한 그림이다. 해당 그림을 하나하나 해석해보자면 다음과 같다.
- 서버가 사용자 요청에 따라 이미 렌더링이 완료된 HTML 문서를 브라우저에 전송.
- 브라우저는 전달받은 HTML 을 바로 렌더링하여 사용자가 페이지를 볼 수 있게 만듬.
- 브라우저가 다운로드 한 JS를 실행하여 애플리케이션을 클라이언트에서 활성화 함.
- 페이지가 사용자와 상호작용할 수 있는 상태가 됨.
위와 같은 방식으로 SSR 에서는 서버가 HTML 을 미리 렌더링해 사용자에게 보여줌으로써 빠른 첫 화면 제공과 SEO 를 해결하고, 이후 브라우저가 JS를 다운로드하여 React 를 실행함으로써 페이지를 인터랙티브하게 완성시킨다. 이 과정은 HTML → Viewable → Hydration → Interactable이라는 순서로 이루어진다.
2.2 CSR (Client Side Rendering)
마찬가지로 클라이언트 단에서 렌더링 하여 화면을 보여주는 방식이다. 초기에 비어있는 HTML 을 받고, 브라우저에서 JS를 실행한 뒤 컨텐츠를 렌더링 하는 방식이다. 다음은 CSR 방식의 그림을 하나하나 해석해본다.
- 서버가 브라우저에 응답을 보냄.
- 브라우저는 JS 를 다운로드함.
- 브라우저가 React 를 실행함.
- 페이지가 이제 보이고 상호작용 또한 가능함.
위와 같은 방식으로 CSR은 브라우저가 초기 비어 있는 HTML 을 받은 뒤, JS를 다운로드 하고 React 를 실행하여 화면을 구성한다. 첫 화면 로딩은 느릴 수 있지만, 페이지 전환은 빠르고 유연한 사용자 경험을 제공한다. 다만, SSR 과 달리 초기 HTML 이 비어있기 때문에 SEO에는 불리한 구조이다.
2.3 SSG (Static Site Generation)
SSG 는 페이지를 미리 빌드 시점에서 HTML 로 만들어서 정적인 파일로 저장해두고, 사용자가 요청하면 바로 그 HTML 을 서버 없이 제공하는 렌더링 방식이다. 쉽게 말해, SSR 이 요청이 들어올 때 마다 HTML 을 "실시간" 으로 만든다면, SSG 는 애초에 HTML 을 "미리" 만들어 둔 뒤 제공하는 방식이다. 따라서 SSG의 장단점은 명확하다.
3. 사용 예시
그렇다면 SSR, CSR, SSG 는 어디서 어떻게 사용되어야 좋을까 ?
SSG 는 빌드 타임에 HTML 미리 생성하여 정적으로 제공되기 때문에 내용이 자주 바뀌지 않고 SEO 가 중요한 블로그, 포트폴리오, 문서 사이트 (Documentation) 등에 적합하게 사용될 수 있다.
CSR 은 렌더링을 브라웆가 직접 수행하며, 사용자와의 상호작용이 많은 웹엡에 적합하고 초기 로딩은 느릴 수 있지만, 이후 전환은 빠르고 앱처럼 부드럽기 때문에 SNS, 대시보드, 관리자 페이지 등에 적합하게 사용될 수 있다.
SSR 은 요청이 들어올 때마다 서버에서 HTML을 실시간으로 렌더링하기 때문에, SEO가 중요히면서도 사용자별 맞춤 콘텐츠가 필요한 이커머스 상세 페이지, 뉴스 기사, 마케팅 랜딩 페이지 등에 적합하게 사용될 수 있다. 단, 서버 부하가 커질 수 있기 때문에 트래픽 예측이 필요하다.
4. 그렇다면 초기 로딩은 SSR 로 진행하고, 이후는 CSR 로 하면 안되나 ?
가능하다. SSR + CSR 하이브리드 렌더링 방식이며, 실제로 현업에서는 널리 사용되는 방식 중 하나라고 한다.
이 방법은 SEO 에 약하고 초기 로딩이 느린 CSR 의 단점과 서버 부하가 크고 UX에 영향을 끼치는 SSR 의 단점을 보안한 방법으로써 초기 로딩시 SSR 로 HTML 을 완성해서 보내고, 이후 페이지 전환은 CSR 처럼 JS 가 라우팅하고 화면을 바꾸는 방식이다.
그 역할을 하는 기술이 바로 Next.js 이다. Next.js 에서는 getServerSideProps 를 통해 요청마다 SSR 를 처리하고, getStaticProps 를 통해 빌드시 SSG 를 처리하며, useEffect + fetch 를 통해 CSR 처리를 할 수 있는 방식을 제공하는 프레임워크이다.
5. 번외
현재 사이트가 어떤 방식으로 만들어졌는지 알 수 있는 방법은 다양하게 있다. 물론 체감적으로 차이를 느낄 수 있지만 대게 느낄 수 없다. 번외로 SSR, CSR 의 방법을 사용한 각 페이지를 소개하며, 간단하게 해당 사이트가 어떤 방식의 기법을 사용하여 렌더링 하는지 알아보도록 한다. SSR(SSG), CSR 을 확인하는 방법에는 다양한 경우가 있지만 그 중 가장 간단한 방법은 개발자 모드에서 "Disable JavaScript" 옵션을 사용하는 것인다. 해당 옵션을 사용한 후 새로고침을 하였을 때, 페이지가 로드 된다면 SSR(SSG), 빈 페이지가 출력된다면 CSR 방식을 활용한 페이지 임을 알 수 있다.
5.1 SSR (SSG)
SSR 사이트로는 Next.js 공식 사이트로 들 수 있다. (물론 현재 Next.js 공식 사이트가 100% SSR 방식은 아닌듯 하다.) Next.js 가 SSR 을 지원하는 프레임워크이기 때문에 공식 사이트도 대부분의 페이지가 SSR 또는 SSG 기반으로 만들어져 있다. 개발자 모드로 들어가 Network 에서 확인해보면 초기 로딩시 HTML에 텍스트가 이미 들어 있고, 이후에 JS가 붙는 구조이다. 이미지를 참고하면 실제로 처음에 document 를 받아오고 이후에 JS 를 받아오는 것을 확인 할 수 있다. 따라서 JS 옵션을 제거한 후 새로고침 하여도 빈 페이지가 아닌 초기 페이지 화면을 받아볼 수 있다.
5.2 CSR 확인 방법
네이버, 지금 글을 작성하고 있는 티스토리에서의 관리 페이지 또한 CSR 기반으로 구성된 사이트이다. 개발자 모드에서 Elements 에서 새로고침을 하게 되면 다음과 같이 div가 짠 하고 생기는 것을 확인할 수 있다. 새로고침 후에 아주 짧은 순간 동안 빈 <div> 였다가 화면이 "짜잔" 하고 뜨는 걸 확인 할 수 있다.