서버 사이드 렌더링이란? | with Next.js

전통적인 사이드 렌더링과 SPA 비교

싱글 페이지 애플리케이션과 멀티 페이지 애플리케이션의 차이

위의 이미지를 보면, 최초 요청 이외에도 계속 서버에서 HTML을 받아올지 아닌지의 차이를 볼 수 있다. 쉽게 말하면 웹페이지 랜더링의 책임을 어디에 두느냐에 따라 SPA냐 아니냐가 구분된다. 

 

여기서 Ajax란 브라우저가 갖고있는 XMLHttpRequest 객체를 이용해서 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기법으로, ES6의 fetch().then()문법과 비슷하다고 생각하면 된다. 

 

서버 사이드 렌더링의 장점

✓ 최초 페이지 진입이 비교적 빠르다.

- 서버에서 HTTP 요청을 수행하고 서버에서 HTML을 그려서 내려주는 것이 클라이언트 단에서 수행하는 것보다 빠름

 

✓ 검색 엔진 최적화에 유용하다.

- 검색 엔진 작동 과정

  1. 검색 엔진 로봇이 페이지에 진입

  2. 페이지가 HTML 정보를 제공해 로봇이 그것을 다운로드한다. 단 자바스크립트 코드는 실행x

  3. 다운로드한 HTML 페이지에서 og태그나 메타 태그 정보를 기반으로 페이지의 검색(공유) 정보를 가져오고 검색 엔진에 저장

 

- 브라우저는 자바스크립트를 실행하지만 로봇은 페이지의 정적인 정보를 가져오는 것이 목적

 

✓ 누적 레이아웃 이동이 적다.

- 사용자에게 페이지를 보여준 이후, 뒤늦게 어떤 HTML 정보가 추가, 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 사용자 경험을 의미

 

✓ 사용자의 디바이스 성능에 비교적 자유롭다.

✓ 보안에 좀 더 안전하다.

 

 

서버 사이드 렌더링의 단점

✓ 소스코드를 작성할 때 항상 서버를 고려해야 한다.

- 브라우저 전역 객체인 window 혹은 sessionStorage 에 접근하면 ‘window is not defined’라는 에러 발생

✓ 적절한 서버가 구축돼 있어야 한다.

- 물리적인 가용량 확보, 복구 전략 등 대비 필요

✓ 서비스 지연에 따른 문제를 사용자에게 안내할 수 없다.

 

 

결론

서버 사이드 렌더링이 만능 해결책은 아니다. 웹페이지의 설계와 목적, 그리고 우선순위에 따라 SPA와 SSR중에 선택해야 한다. 요즘은 이 둘의 장점을 모두 취한 프레임워크인 Next.js, Remix가 각광받고 있다. 이 프레임워크에서 SSR은 최초 웹사이트 진입 시에 SSR 방법을 취하고 그 이후에는 마치 SPA처럼 작동한다.