서버 사이드 렌더링 (1)
모던 리액트 Deep Dive: 리액트의 핵심 개념과 동작 원리부터 Next.js까지, 리액트의 모든 것 - 04장 서버 사이드 렌더링 (1)
1. 서버 사이드 렌더링이란?
싱글 페이지 애플리케이션의 세상
싱글 페이지 애플리케이션이란?
싱글 페이지 애플리케이션(Single Page Application: SPA)이란 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식을 의미한다.
최초에 첫 페이지에서 데이터를 모두 불러온 이후에는 페이지 전환을 위한 모든 작업이 자바스크립트와 브라우저의 history.pushState와 history.replaceState로 이뤄지기 때문에 페이지를 불러온 이후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리한다.
최초에 서버에서 최소한의 데이터를 불러온 이후부터는 이미 가지고 있는 자바스크립트 리소스와 브라우저 API를 기반으로 모든 작동이 이뤄진다.
전통적인 방식의 애플리케이션 과 싱글 페이지 애플리케이션의 작동 비교
서버 사이드에서 작동하던 전통적인 방식의 애플리케이션은 페이지 전환이 발생할 때마다 새롭게 페이지를 요청하고, HTML 페이지를 다운로드해 파싱하는 작업을 거친다.
- 브라우저 환경이 충분히 빠르지 못하다면 흰 화면이 잠시 노출될 수 있다.
페이지 전환을 모두 자바스크립트로 한다면 최초에 한번 모든 리소스를 다운로드하고 나면 이 후 페이지를 전환할 때 추가로 리소스를 다운로드하는 시간이 필요 없어진다. (매끄러운 UI)
싱글 페이지 렌더링 방식의 유행과 JAM 스택의 등장
PHP나 JSP를 기반으로 웹 애플리케이션이 만들어졌을 때는 렌더링이 서버 사이드에서 이뤄졌다. 페이지를 요청하면 서버에서 완성된 HTML을 내려받고, 페이지 이동이 있으면 새로운 페이지를 서버에서 내려받는 방식이었다. (자바스크립트는 보조적인 수단)
자바스크립트 모듈화하는 방안이 점차 논의되기 시작됐고 등장한 것이 CommonJS와 AMD(Asynchoronous Module Definition)다.
사용자 기기의 성능 향상 및 인터넷 속도의 발전 등으로 자바스크립트에서 할 수 있는 일이 다양해진다.
2010년경 Backbone.js와 AngularJS, Knockout.js 등 MVx 프레임워크를 구현하기 시작했다.
자바스크립트에서도 복잡한 작업을 할 수 있다는 것을 의미했고, 규모가 커져갔다.
React, Vue, Angular의 시대
웹 페이지의 모든 영역 페이지의 렌더링에서부터 사용자의 인터랙션 까지을 담당하는 방식인 싱글 페이지 렌더링이 인기를 얻게 됐다.
기존의 웹 개발은 LAMP(Linux(운영체제), Apache(서버), MySQL(데이터베이스), PHP/Python 등 (프레임워크)) 스택으로 구성돼 있었다.
과거에는 자바스크립트에서 할 수 있는 일이 제한적이었기 때문에 대부분의 처리를 서버에서 해야만 했다.
웹 애플리케이션의 기능이 다양해지거나 사용자가 늘어나면 이와 동시에 서버도 확장해야 했지만 이 당시에는 서버를 확장하는 것이 매우 번거로웠다.
그래서 프레임워크의 등장으로 등장한 것이 바로 JAM(JavaScript, API, Markup) 스택이다.
대부분의 작업을 자바스크립트에서 수행할 수 있었기 때문에 프런트엔드는 자바스크립트와 마크업(HTML, CSS)을 미리 빌드해 두고 정적으로 사용자에게 제공하면 이후 작동은 모두 사용자의 클라이언트에서 실행되므로 서버 확장성 문제에서 자유로워질 수 있다.
JAM 스택의 인기에 Node.js의 고도화에 MEAN(MongoDB, Express.js, AngularJS, Node.js)이나 MERN(MongoDB, EXpress.js, React, Node.js) 스택처럼 아예 API 자체도 자바스크립트로 구현하는 구조가 인기를 끌기 시작했다.
싱글 페이지 렌더링 방식의 유행과 JAM 스택의 등장
사용자의 기기나 인터넷 환경이 더 빠르게 발전할 것이기 때문에 웹 애플리케이션에서 제공하는 자바스크립트 리소스의 크기와 수가 모두 증가하기 시작했다.
- 웹페이지의 속도는 얼마나 개선이 되었나?
- 모바일 환경에서의 웹페이지 로딩과 인터랙션은 여전히 오래걸린다.
- 자바스크립트 파싱을 위해 CPU를 소비하는 시간이 눈에 띄게 증가했다.
사용자의 기기와 인터넷 속도 등 웹 전반을 이루는 환경이 크게 개선됐음에도 실제 사용자들이 느끼게 웹 애플리케이션의 로딩 크게 차이가 없거나 오히려 더 느리다는 것이다.
서버 사이드 렌더링이란?
서버 사이드 렌더링은 최초의 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식을 의미한다.
싱글 페이지 애플리케이션과 서버에서 페이지를 빌드하는 서버 사이드 렌더링의 차이는 웹페이지 렌더링의 책임을 어디에 두는냐다.
싱글 페이지 애플리케이션은 사용자에게 제공되는 자바스크립트 번들에서 렌더링을 담당하지만
- 서버 사이드 방식을 채택하면 렌더링에 필요한 작업을 모두 서버에서 수행한다.
- 클라이언트의 렌더링은 사용자 기기의 성능에 영향을 받지만 서버 사이드 렌더링은 서버에서 제공하기 때문에 비교적 안정적인 렌더링이 가능하다.
서버 사이드 렌더링의 장점
최초 페이지 진입이 비교적 빠르다.
사용자가 최초 페이지에 진입했을 때 페이지에 유의미한 정보가 그려지는 시간(First Contentful Paint)이 더 빨라질 수 있다.
일반적으로 서버에서 HTTP 요청을 수행하는 것이 더 빠르고, 또 HTML에 그리는 작업도 서버에서 해당 HTML을 문자열로 미리 그려서 내려주는 것이 클라이언트에서 기존 HTML에 삽입하는 것보다 더 빠르다.
화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 서버 사이드 렌더링이 더 빠를 수 있다.
검색 엔진과 SNS 공유 등 메타데이터 제공이 쉽다.
서버 사이드 렌더링은 검색 엔진 최적화에 유용하다
- 검색 엔진 로봇(머신)이 페이지에 진입한다.
- 페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드한다. 단, 다운로드만 하고 자바스크립트 코드는 실행하지 않는다.
- 다운로드한 HTML 페이지 내부의 오픈 그래프(Open Graph)나 메타(meta) 태그 정보를 기반으로 페이지의 검색(공유) 정보를 가져오고 이를 바탕으로 검색 엔진에 저장한다.
싱글 페이지 애플리케이션은 자바스크립트의 작동에 의존하기 때문에, 페이지 진입시 메타 정보를 제공할 수 있게 조치를 해줘야 한다.
서버 사이드 렌더링은 검색 엔진에 필요한 정보를 서버에서 가공해서 HTML 응답으로 제공이 가능해서 검색 엔진 최적화에 대응하기 용이하다.
누적 레이아웃 이동이 적다.
서버 사이드 렌더링은 누적 레이아웃 이동(Cumulative Layout Shift)을 줄일 수 있다.
누적 레이아웃 이동이란 사용자에게 페이지를 보여준 이후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥 거리는 것과 같은 부정적인 사용자 경험을 말한다.
- 서버 사이드 렌더링의 경우에는 이러한 요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 이러한 문제에서 비교적 자유롭다.
서버 사이드 렌더링에서는 모든 요청이 완료되기 전까지 페이지가 렌더링되지 않을 것이므로 최초 페이지 다운로드가 괸장히 느려질 수도 있지만 리액트 18에서 등장한 해결 될 수도 있다.
사용자의 디바이스 성능에 비교적 자유롭다.
서버 사이드 렌더링은 비교적 사용자 디바이스의 성능으로부터 자유롭다.
자바스크립트 리소스 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적이다.
- 서버 사이드 렌더링을 수행하면 이러한 부담을 서버에 나눌 수 있으므로 사용자의 디바이스 성능으로부터 더 자유로워질 수 있다.
사용자 방문의 폭증으로 서버에 부담이 가중되고, 이를 위한 처리가 수반되지않으면, 서버 사이드 렌더링도 느려질 것이다
보안에 좀 더 안전하다.
JAM 스택을 채택한 프로젝트의 공통된 문제점은 애플리케이션의 모든 활동이 브라우저에 노출된다는 것이다.
브라우저의 개발자 도구를 사용하면 웹사이트에서 일어나는 저의 대부분의 작업을 파악할 수 있다.
- 서버 사이드 렌더링의 경우 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 이러한 보안 위협을 피할 수 있다는 장점이 있다.
서버 사이드 렌더링의 단점
소스코드를 작성할 때 항상 서버를 고여해야 한다.
서버 사이드 렌더링을 적용하기로 결정했다면 소스코드 전반에 걸쳐 서버 환경에 대한 교려가 필요하다.
브라우저느 전역 객체인 window 또는 sessionStorage와 같이 브라우저에만 있는 전역 객체 등이다. 이 코드가 실행된다면 ‘window is not defined’라는 에러를 마주하게 된다. 그러므로 서버에서는 최소화하고, 사용이 불가피하다면 해당 코드가 서버 사이드 렌더링에서 실행되지 않도록 하고 클라이언트에서만 실행되는 코드가 많아질수록 서버 사이드 렌더링의 장점이 줄어든다.
적절한 서버가 구축돼 있어야 한다.
서버 사이드 렌더링은 사용자의 요청을 받아 렌더링을 수행할 서버가 필요하다.
사용자의 요청에 따라 적절하게 대응할 수 있는 물리적인 가용량을 확보해야 하고, 때로는 예기치 않은 장애 상황에 대응할 수 있도록 복구 전략도 필요하다. 또한 요청을 분산시키고, 프로세스가 예기치 못하게 다운될 때를 대비해 PM2와 같은 프로세스 매니저의 도움도 필요하다.
서비스 지연에 따른 문제
🍪 서버 사이드 렌더링에서 지연이 일어나면?
이 지연 작업이 최초 렌더링에 발생한다면 큰 문제가 된다. 서버 사이드 렌더링은 서버에서 사용자에게 보여줄 페이지에 대한 렌더링 작업이 끝나기까지는 사용자에게 그 어떤 정보도 제공할 수 없다.
애플리케이션의 규모가 커지고 작업이 복잡해지고, 이에 따라 다양한 요청에 얽혀있어 병목 현상이 심해진다면 때로는 서버 사이드 렌더링이 더 안 좋은 사용자 경험을 제공할 수도 있다.
SPA와 SSR을 모두 알아야 하는 이유
서버 사이드 렌더링 역시 만능이 아니다.
웹페이지에서 사용자에게 제공하고 싶은 내용이 무엇이고, 또 어떤 우선순위에 따라 페이지의 내용을 보여줄지를 잘 설계하는 것이 중요하다.
잘못된 설계는 서버와 클라이언트 두 군데로 관리 포인트만 늘어나게 한다.
싱글 페이지 애플리케이션과 서버 사이드 렌더링 애플리케이션
가장 뛰어난 싱글 페이지 애플리케이션은 가장 뛰어난 멀티 페이지 애플리케이션보다 낮다.
ex)Gamil- 최초 페이지 진입 시에 보여줘야 할 정보만 최적화해 요청해서 렌더링
- 이미지와 같은 중요성이 떨어지는 리소스는 게으른 로딩으로 렌더링에 방해되지 않게 처리
- 코드 분할 또한 칼같이 지켜서 불필요한 자바스크립트 리소스의 다운로드 및 실행을 방지
평균적인 싱글 페이지 애플리케이션은 평균적인 멀티 페이지 애플리케이션보다 느리다.
평균적인 노력을 기율여서 동일한서비스를 만든다면 서버에 렌더링되는 멀티 페이지 애플리케이션이 더 우위에 있을 수 있다.
멀티 페이지 애플리케이션에서 발생하는 라우팅으로 인한 문제를 해결하기 위한 API 브라우저에 추가되고 있다.
페인팅 홀당(Paint Holding): 같은 출저(origin)에서 라우팅이 일어날 경우 화면을 잠깐 하얗게 띄우는 대신 이전 페이지의 모습을 잠깐 보여주는 기법
back forward cache(bfcache): 브라우저 앞으로 가기, 뒤로가기 실행 시 캐시된 페이지를 보여주는 방법
Shared Element Transitions: 페이지 라우팅이 일어났을 때 두 페이지에 동일 요소가 있다면 해당 콘텐스트를 유지해 부드럽게 전환되게 하는 기법
두 가지 모두 장단점이 있으며 어느 하나가 완벽하다고 볼 수 없다.
현재의 서버 사이드 렌더링
LAMP 에서는 모든 페이지를 서버에서 랜더링 함으로 라우팅이 느렸다.
Next.js 와 Remix와 같은 요즘 서버 사이드 렌더링 방식은 최초 웹사이트 진입 시에는 서버 사이드 렌더링 방식으로 서버에서 완성된 HTML을 제공받고, 이후 라우팅에서는 서버에서 내려받은 자바스크립트를 바탕으로 마치 싱글 페이지 애플리케이션처럼 작동한다.
