본 글은 <모던 리액트 DEEP DIVE>도서의 내용을 바탕으로 작성되었습니다.
싱글 페이지 애플리케이션(SPA)
SPA란 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식을 의미한다. SPA는 첫 페이지에서 데이터를 모두 불러온 후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리한다. 이러한 작동 방식은 최초에 로딩해야 할 자바스크립트 리소스가 커지는 단점이 있지만 한번 로딩된 이후에는 서버를 거쳐 리소스를 받아올 일이 적어져 훌륭한 UI/UX를 제공할 수 있다는 장점이있다.
페이지 전환을 시도하면 서버로 HTML을 요청하는 것이 아닌 다음 페이지 렌더링에 필요한 정보만 HTTP요청으로 가져온다음, 그 결과를 바탕으로 <body /> 내부에 DOM을 추가, 수정, 삭제하는 방법으로 페이지 전환이 이루어진다.
자바스크립트가 점차 많은 작업을 담당하게되고, 자바스크립 코드가 점차 비대해지면서 이에 대한 우려의 목소리가 나왔지만, 폭발적인 기술 발전으로 자연스럽게 해결되리라 여겨져 왔다.
그러나 인터넷 속도, 프로세서나 메모리 등 하드웨어 성능 향상에 비하여 유저의 로딩 속도가 크게 개선되지 못했다. 물론 이 모든 것이 SPA때문이라는 것은 아니다. 과거에 비해 현재의 웹 어플리케이션은 정말 다양한 작업을 처리하기 때문이다. 그럼에도 웹 사이트 방문자들은 참을성이 없기에 개발자들은 늘 웹 서비스 환경에 대해 고민해야한다.
서버 사이드 렌더링이란?(SSR)
SPA가 자바스크립트를 활용해 하나의 페이지에서만 렌더링을 수행한다면, 서버 사이드 렌더링은 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 유저에게 화면을 제공하는 방식을 의미한다.
서버 사이드 렌더링의 장점
1. 최초 페이지 진입이 비교적 빠르다
: 사용자가 최초 사이트에 진입해 유의미한 정보가 그려지는 시간(First Contentful Paint)이 더 빨라질 수 있다. 일반적으로 서버에서 HTTP요청을 수행하는 것이 빠르고, HTML을 그리는 작업또한 서버에서 그려서 문자열로 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 빠르다. 항상 그런 것은 아니지만, 화면 렌더링이 HTTP요청에 의존적이거나 렌더링 할 HTML크기가 커진다면 상대적으로 서버사이드 렌더링이 빠를 수 있다. 물론 서버가 사용자를 감당하지 못하고 리소스 확보가 어렵다면 오히려 SPA보다 느릴 수 있다.
SSR의 FCP는 CSR보다 빠를 수 있지만 TTFB(Time To First Byte)는 더 느리다. 서버가 빈 HTML을 응답하는 CSR과 달리 SSR은 페이지 컨텐츠를 포함한 HTML을 생성할 시간이 필요하기 때문이다.
2. 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다
: 검색엔진과 사용자가 브라우저에 접속할 때의 가장 큰 차이는 JS 실행 여부이다. SPA가 앱 작동의 대부분을 JS에 의존하는데, 메타데이터 또한 마찬가지다. 검색엔진이 페이지에 최초 진입할 때 이러한 메타 정보를 제공할 수 있도록 별도의 조치를 취하지 않으면 SEO에 불이익이 있을 수 있다. 반면 SSR은 최초의 렌더리잉 서버에서 일어나는데, 검색엔진이 필요로하는 정보를 서버에서 가공해서 HTML응답으로 제공할 수 있으므로 SEO에 대응하기 용이하다.
검색엔진이 사이트에서 필요한 정보를 가져가는 과정
1. 검색 엔진 머신이 페이지에 진입한다.
2. 페이지가 HTML정보를 제공해 로봇이 이 HTML을 다운로드한다. 단, 이때 JS코드를 실행하지 않는다.
3. 다운로드한 HTML 페이지 내부의 오픈 그래프나 메타 태그 정보를 기반으로 페이지의 검색정보를 가져오고 이를 바탕으로 검색엔진에 저장한다.
3. 누적 레이아웃 이동이 적다
: 누적 레이아웃 이동(Cumulative Layout Shift)이란 사용자에게 페이지를 보여준 후 뒤늦게 어떤 HTML정보가 추가되거나 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 UX를 말한다. SPA에서는 페이지 콘텐츠가 API요청에 의존하고, API요청 속도가 제각각이며, 이걸 적절히 처리하지 않으면 누적 레이아웃 이동문제가 발생한다. 반면 SSR은 요청이 완전히 완료된 후 완성된 페이지를 제공하므로 이런 문제에서 비교적 자유롭다. 그렇다해도 useEffect로 인한 문제가 남아있다. 또한 모든 API요청을 기다려야하므로 최초 페이지 다운로드가 느려질 수 있다. 그러나 이러한 문제는 리액트18에서 나온 스트림에 의해 해결될 수도 있을 것으로 보인다.
4. 사용자의 디바이스 성능에 비교적 자유롭다
: JS 리소스 실행은 전적으로 사용자 디바이스에서만 실행되므로 절대적으로 사용자 디바이스에 의존적이다. 그러나 SSR은 이러한 부담을 서버와 함께 분담할 수 있다. 물론 사용자 방문 폭증 등으로 인한 서버 부담에 대한 적절한 조치가 되어있지 않다면 SSR도 충분히 느려질 수 있다.
5. 보안에 좀 더 안전하다
: JAM(Javascript, API, Markup)스택을 채택한 프로젝트의 공통된 문제점은 앱의 모든 활동이 브라우저에 노출된다는 것이다. 반면 SSR의 경우 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공하기 때문에 보안 위협에 비교적 안전하다.
서버 사이드 렌더링의 단점
1. 소스코드를 작성할 때 항상 서버를 고려해야한다
: 서버에서는 window, sesstionStorage와 같은 브라우저 전역객체를 사용할 수 없다. 따라서 서버에서 돌아갈 가능성이 있는 코드라면 브라우저 전역객체 접근을 최소화해야하고, 불가피할 경우 해당코드가 서버사이드에서 실행되지 않도록 처리해주어야한다. 이러한 서버에 대한 고려는 직접 작성한 코드 뿐만아니라 외부 라이브러리에도 동일하게 적용되므로 서버 처리가 안되어있다면 따로 처리해주거나 다른 대안을 찾아야한다.
2. 적절한 서버가 구축되어 있어야한다
: SPA에서 서버는 정적인 데이터인 자바스크립트와 HTML만 제공하면 되지만, SSR은 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다. 그러나 서버를 제대로 구축해 운영하는 것은 쉬운 일이 아니다.
3. 서비스 지연에 따른 문제
: 서비스 지연 시 SPA의 경우 로딩 중과 같은 안내를 통해 유저의 불편을 조금이라도 덜 수 있으나, SSR의 경우 그럴 수 없다. 앱 규모가 커지고, 작업이 복잡해짐에 따라 병목현상이 심해진다면 때로는 SSR이 더 안좋은 UX를 제공할 수도 있다.
SPA와 SSR을 모두 알아야하는 이유
위에서도 살펴보았지만, SSR이 만능이 아니다. 잘못된 웹사이트 설계는 오히려 성능을 해치고 오히려 서버와 클라이언트 두 군데로 관리포인트만 늘어날 수 있다.
SPA vs SSR
1. 가장 뛰어난 싱글페이지 애플리케이션(SPA)은 가장 뛰어난 멀티페이지 애플리케이션(MPA)보다 낫다. MPA에 엄청난 최적화를 가미하더라도 SPA가 가진 브라우저 API와 자바스크립트를 활용한 라우팅을 기반으로 한 매끄러운 라우팅보다 뛰어난 성능을 보여줄 수는 없을 것이다.
2. 평균적인 SPA는 평균적인 MPA보다 느리다. MPA는 매번 서버에 렌더링을 요청하고, 서버는 안정적인 리소스를 기반으로 매 요청마다 비슷한 성능의 렌더링을 수행할 것이다. 그러나 SPA는 렌더링과 라우팅에 최적화가 돼 있지 않다면 사용자 기기에 따라 성능이 들쑥날쑥하고, 성능 최적화는 어렵기때문에 적절한 최적화가 되어있지 않을 가능성이 높다. 최근에는 MPA에서 발생하는 라우팅 문제를 해결하기 위한 다양한 API가 브라우저에 추가되고 있다.
- 페인트홀딩: 같은 origin에서 라우팅이 일어날 경우 화면을 하얗게 띄우는 대신 이전 페이지를 잠깐 보여주는 기법
- back forword cache(bfcache): 브라우저 앞으로 가기, 뒤로가기 실행 시 캐시된 페이지를 보여주는 기법
- Shared element Transitions: 페이지 라우팅이 일어났을 때 두 페이지에 동일 요소가 있다면 해당 콘텍스트를 유지해 부드럽게 전환되게 하는 기법
이러한 기법들 모두 SPA에서 구현 가능한 것들이지만 상당한 노력을 기울여야한다.
결론적으로 SPA와 MPA에는 모두 상황에 따라 유효하다. 최근에는 두 방법론의 장점을 취하는 방식으로 작동한다. 최초 웹사이트 진입 시에는 서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 JS를 바탕으로 마치 SPA처럼 작동한다. 요즘 각광받는 NEXT.js, Remix 등은 모두 이런 식으로 작동한다. 따라서 더 나은 유저경험을 제공하는 웹사이트 구축을 위해서는 두 가지 방식에 대해 잘 이해하고 있어야할 것이다.
References
- 도서 <모던 리액트 DEEP DEVE>
- The Benefits of Server Side Rendering Over Client Side Rendering
'FE > react' 카테고리의 다른 글
| [React] useState, useEffect, useRef (0) | 2024.01.28 |
|---|---|
| [React] 리액트 렌더링 과정 (1) | 2024.01.14 |
| [React] 언제 어떻게 state와 useEffect를 사용해야할까? (0) | 2023.10.13 |
| [React] 스크롤 특정 요소로 이동하기 (0) | 2023.06.01 |
| [React] 토스트팝업/스낵바(toast popup/snack bar)직접 구현하기 (0) | 2023.05.24 |
댓글