어렴풋이 알고만 있던 SSR과 CSR, 그리고 SPA 알고는 있지만, 이걸 정의해보라고 시키면 말하기는 어려운 친구들...
하나 둘씩 정리해보자
SSR (Server Side Rendering) 란?
이름 그대로 서버에서 페이지를 모두 렌더링해서 브라우저에 전달하는 방식이다. 브라우저는 렌더링이 거의 끝난 HTML 문서를 전달받기 때문에, 초기 화면을 매우 빠르게 표시할 수 있다는 장점이 있다.
SSR의 동작 과정
SSR의 동작 순서를 간단히 나타내면 이렇다.
- 사용자가 브라우저를 통해 웹사이트에 접속을 요청한다.
- 서버는 요청을 받고, 페이지를 렌더링할 준비를 마친 완전한 형태의 HTML 파일을 생성한다.
- 브라우저는 서버로부터 이 HTML 파일을 받아 즉시 화면에 표시한다. 사용자는 콘텐츠를 바로 볼 수 있지만, 아직 상호작용에 필요한 JavaScript가 적용되지 않아 버튼 클릭 등은 동작하지 않는다. (이 시점을 TTV, Time To View라고 부른다)
- 브라우저는 이어서 페이지 상호작용에 필요한 JavaScript 파일을 다운로드한다.
- 다운로드한 JavaScript를 HTML 문서(DOM)에 적용하는 'Hydration(하이드레이션)' 과정을 거친다.
- Hydration이 완료되면 비로소 페이지의 모든 기능이 활성화되고, 사용자는 정상적으로 상호작용할 수 있다. (이 시점이 바로 TTI, Time To Interact이다)
조금 더 간소화 해서 보면
- 서버가 렌더링된 HTML 파일을 보내고 브라우저가 받음
- 브라우저가 페이지를 화면에 띄워주고 JS 파일을 다운 받는다
- 브라우저가 프레임워크 (React)를 실행한다.
- 페이지 작동!
정리하자면, 서버 사이드 렌더링은 사용자의 요청이 있을 때마다 서버에서 페이지를 새로 만들어 제공하는 방식이다. 즉, 화면을 그리는(렌더링) 주체가 서버! 과거의 웹은 대부분 이 방식을 사용했지만, 웹에서 제공되는 정보의 양이 많아지면서 문제가 발생했는데, 페이지를 이동할 때마다 전체 페이지를 새로고침하므로 화면 깜빡임(flicker)이 발생하고, 서버에 계속해서 부담을 주는 성능 저하의 원인이 되었다.
SSR의 장점과 단점
- 장점
- 빠른 초기 로딩 속도: 사용자가 첫 화면을 보기까지의 시간이 짧다.
- 검색엔진 최적화(SEO) 유리: 서버가 콘텐츠가 모두 채워진 HTML을 전달하므로 검색엔진 크롤러가 사이트 정보를 수집하기 용이하다.
- 단점
- 느린 페이지 전환: 다른 페이지로 이동할 때마다 서버에 새로운 페이지를 요청하고 받아오는 과정을 반복하므로 화면 전체가 새로고침되어 깜빡인다.
- 서버 부하: 사용자의 요청이 있을 때마다 서버가 페이지를 새로 렌더링해야 하므로, 트래픽이 많은 서비스의 경우 서버에 부하가 갈 수 있다.
- TTV와 TTI의 간극: 사용자가 화면을 보고 나서 실제로 조작할 수 있을 때까지 지연 시간이 존재한다.
SPA (Single Page Application) 란?
SPA는 Single Page Application의 약자로, 하나의 HTML 페이지만으로 전체 서비스를 운영하는 애플리케이션을 뜻한다. 최초 접속 시에만 전체 페이지를 로드하고, 그 이후에는 사용자의 행동에 따라 필요한 데이터만 서버에서 받아와 화면의 일부만 동적으로 교체한다.
이 방식 덕분에 페이지 이동 시 SSR처럼 화면 전체가 깜빡이며 새로고침되지 않고, 마치 데스크톱 앱처럼 부드러운 사용자 경험을 제공할 수 있다. 이 SPA를 구현하는 대표적인 렌더링 방식이 바로 다음에 설명할 CSR이다.
CSR (Client Side Rendering)
SSR과 반대로 렌더링의 책임이 클라이언트(브라우저)에게 있다. 서버는 거의 텅 빈 HTML 뼈대와 렌더링에 필요한 JavaScript 파일만 보내주고, 브라우저가 이를 받아 동적으로 페이지를 그려나간다.
CSR의 동작 과정
- 사용자가 웹사이트 접속을 요청한다.
- 서버는 내용이 거의 없는 최소한의 HTML 파일과 화면 구성에 필요한 JavaScript 파일 링크를 전달한다.
- 브라우저는 이 파일들을 다운로드한다. 이 시간 동안 사용자는 빈 화면 혹은 로딩 스피너를 보게 된다.
- 다운로드가 완료된 JavaScript 파일이 실행되며 화면을 동적으로 구성한다.
- 페이지에 필요한 데이터가 있다면, JavaScript가 서버에 API를 호출해 데이터를 요청한다.
- 서버로부터 데이터를 수신하면, 그제야 빈 페이지의 적절한 위치에 데이터를 채워 넣어 사용자에게 완전한 화면을 보여준다
SSR 과 달리 CSR은 화면이 띄워지는 타이밍이 확실히 늦다. 브라우저가 HTML 파일, JS 파일 까지 모두 다 읽은 뒤 프레임워크까지 실행하고 난 뒤에 페이지가 노출되고, 상호작용이 가능해진다.
정리하자면 클라이언트 사이드 렌더링은 클라이언트인 브라우저가 렌더링을 도맡아 처리하는 방식이다. 서버에서 필요한 데이터를 한 번에 받아오고 받은 데이터를 브라우저가 주체가 되어 그린다.
CSR은 SPA 트랜드와 CPU 성능 상승 +JS 표준화(리액트, 뷰, 앵귤러 등 프레임워크의 발전)와 함께 본격적으로 시작되었다.
클라이언트사이드렌더링은 서버에서 데이터를 받아 모두 읽고 다시 화면에 전체 페이지를 바꿔서 보여주는 것보다 훨씬 빠르게 화면을 그릴 수 있는 것이다. 이는 성능적으로도 페이지를 새로 렌더링하지 않아 서버자원을 덜 사용하고, 새로고침이 발생하지 않기 때문에 화면이 바뀔때 화면 깜빡임도 없어 우수한 사용자 경험을 제공한다.
CSR의 장점과 단점
- 장점
- 뛰어난 사용자 경험(UX): 초기 로딩 이후에는 페이지 전체를 새로고침할 필요 없이 필요한 부분만 빠르게 업데이트하므로, 매우 부드러운 화면 전환이 가능하다.
- 서버 부하 감소: 렌더링은 대부분 브라우저가 처리하므로 서버는 데이터 제공 역할에 집중할 수 있다.
- 단점
- 느린 초기 로딩 속도: 모든 스크립트 파일이 다운로드되고 실행될 때까지 사용자는 기다려야 한다.
- 검색엔진 최적화(SEO) 불리: 대부분의 검색엔진 크롤러는 텅 빈 HTML 문서를 보고 내용을 수집하지 못하는 경우가 많다. (최근 구글 등은 JS를 실행시켜주기도 하지만, 여전히 SEO에는 보완이 필요하다)
그래서 뭐가 다른데? SSR VS CSR 한눈에 보기
| 구분 | SSR | CSR |
| 초기 로딩 속도 | 빠름 | 느림 |
| 페이지 전환 속도 | 느림 (전체 새로고침) | 빠름 (부분 업데이트) |
| SEO | 유리 | 불리 |
| 서버 부하 | 높음 | 낮음 |
| 사용자 경험 | 페이지 이동 시 깜빡임 발생 | 부드럽고 쾌적함 |
결론
SSR과 CSR은 어느 하나가 무조건 좋은 '은 탄환(Silver Bullet)'이 아니다. 각자 명확한 장단점을 가지고 있어, 서비스의 성격에 따라 적절한 방식을 선택해야 한다.
- SSR이 유리한 경우: SEO가 매우 중요하거나, 콘텐츠 중심의 정적인 페이지(뉴스 기사, 블로그 등), 혹은 사용자와의 상호작용이 적은 웹사이트에 적합하다.
- CSR이 유리한 경우: 복잡한 상호작용과 빠른 인터랙션이 중요한 서비스(대시보드, 관리자 페이지 등), 혹은 SEO의 중요도가 낮은 서비스에 적합하다.
최근에는 Next.js(React 기반)나 Nuxt.js(Vue 기반) 같은 프레임워크가 등장하며 이 문제를 해결하고 있다. 이런 프레임워크들은 첫 페이지 로딩은 SSR 방식으로 처리해 SEO와 초기 로딩 속도를 잡고, 이후의 상호작용은 CSR 방식으로 처리해 부드러운 사용자 경험을 제공하는 하이브리드 방식을 채택했다.
더 나아가 빌드 시점에 페이지를 미리 만들어두는 SSG(정적 사이트 생성)나, 필요할 때만 페이지를 다시 렌더링하는 ISR(점진적 정적 재생성) 같은 고급 전략도 등장했다. (공부할게 왜이렇게 많은건지,, 이것도 정리한번 하는게 좋을거같다)
결국 중요한 것은 각 렌더링 방식의 원리를 정확히 이해하고, 만들고자 하는 서비스의 성격에 맞는 최적의 방식을 선택하고 조합하는 능력이다.