[모던 리액트 딥다이브] 4.1장 서버 사이드 렌더링

싱글 페이지 애플리케이션(SPA, Single Page Application)

• 렌더링과 라우팅에 필요한 대부분의 기능을 서버가 아닌 브라우저의 자바스크립트에 의존하는 방식
• 최초에 첫 페이지에서 데이터를 모두 불러온 이후에는 페이지 전환을 위한 모든 작업이 자바스크립트와 브라우저의 history.pushState, history.replaceState로 이뤄지기 때문에 페이지를 불러온 이후에는 서버에서 HTML을 내려받지 않고 하나의 페이지에서 모든 작업을 처리함
• 사이트 렌더링에 필요한 <body/> 내부의 내용을 모두 자바스크립트 코드로 삽입한 이후에 렌더링함
• 페이지 전환 시에는 새로운 HTML을 요청하는 것이 아니라 자바스크립트에서 다음 페이지 렌더링에 필요한 정보만 HTTP 요청 등으로 가져온 다음, 그 결과를 바탕으로 <body/> 내부에 DOM을 추가, 수정, 삭제하는 방법으로 페이지가 전환됨
• 최초에 로딩해야 할 자바스크립트 리소스가 커지는 단점이 있지만 한번 로딩된 이후에는 서버를 거쳐 필요한 리소스를 받아올 일이 적어 사용자에게 훌륭한 UI/UX를 제공한다는 장점이 있음

 

 

전통적인 방식의 애플리케이션 vs 싱글 페이지 애플리케이션

• 전통방식 애플리케이션
  • 페이지 전환이 발생할 때마다 새롭게 페이지 요청, HTML 페이지를 다운로드해 파싱하는 작업 => 부자연스러운 모습 발생 
• SPA
  • 페이지 전환을 js로 하기 때문에 페이지 전체를 새로 렌더링하는 것이 아니라 페이지 전환에 필요한 일부 영역만 다시 그림 => 훨씬 매끄러운 UI

 

 

JAM 스택

• Javascript, API, Markup 스택
• 대부분의 작업을 자바스크립트에서 수행할 수 있었기 때문에 프런트엔드는 자바스크립트와 마크업을 미리 빌드해 두고 정적으로 사용자에게 제공해 이후 작동은 모두 사용자의 클라이언트에서 실행되므로 서버 확장성 문제에서 더 자유로워 질 수 있게 됨

 

SPA 문제점

• 점차 발전되는 기술과 서비스로 js 의 규모가 방대해짐
• js 파싱을 위해 CPU 소비 시간이 증가함
• 사용자가 상호작용할 수 있을 때까지 대기하는 평균 시간이 12초로 오래 걸림

 

서버 사이드 렌더링 (SSR, Server-Side Rendering)

• 최초에 사용자에게 보여줄 페이지를 서버에서 렌더링해 빠르게 사용자에게 화면을 제공하는 방식
• SPA는 사용자에게 제공하는 js 번들에서 렌더링을 담당하지만 SSR은 렌더링에 필요한 작업을 모두 서버에서 수행
• 따라서, 사용자 기기의 성능에 구애없이 안정적인 렌더링이 가능함

 

 

서버 사이드 렌더링 장점

1. 최초 페이지 진입이 비교적 빠름
   • 화면 렌더링이 HTTP 요청에 의존적이거나 렌더링해야 할 HTML의 크기가 커진다면 상대적으로 빠름
2. 검색 엔진과 SNS 공유 등 메타데이터 제공이 쉬움
   • SPA 방식은 대부분의 작동이 js에 의존하기 때문에 검색 엔진이 최초에 방문했을 때 메타 정보를 제공할 수 없다면 검색 엔진 최적화에 불이익이 있을 수 있음
   • SSR 방식은 검색 엔진에 제공할 정보를 서버에서 가공해서 HTML응답으로 제공할 수 있으므로 검색 엔진 최적화에 대응하기가 매우 용이함
3. 누적 레이아웃 이동이 적음
   • 누적 레이아웃 이동 : 사용자에게 페이지를 보여준 이후에 뒤늦게 어떤 HTML 정보가 추가되거나 삭제되어 마치 화면이 덜컥거리는 것과 같은 부정적인 사용자 경험
   • SPA 방식의 경우 페이지 콘텐츠가 API 요청에 의존하고, API 요청의 응답 속도가 제각각이기 때문에 이를 적절히 처리해두지 않으면 누적 레이아웃 이동 문제가 발생할 수 있음
   • SSR 방식은 요청이 완전히 완료된 이후에 완성된 페이지를 제공하므로 이러한 문제에서 비교적 자유로움
4. 사용자의 디바이스 성능에 비교적 자유로움
   • 자바스크립트 리소스 실행은 사용자의 디바이스에서만 실행되므로 절대적으로 사용자 디바이스 성능에 의존적임
   • SSR방식은 이러한 부담을 서버에 나눌 수 있으므로 비교적 디바이스 성능에 자유로움
5. 보안에 좀 더 안전함
   • 인증 혹은 민감한 작업을 서버에서 수행하고 그 결과만 브라우저에 제공해 보안 위협을 피할 수 있음

검색 엔진이 사이트에서 필요한 정보를 가져가는 과정
1. 검색 엔진 로봇이 페이지 진입
2. 페이지가 HTML 정보를 제공해 로봇이 이 HTML을 다운로드 함. 단, 다운로드만 하고 자바스크립트 코드는 실행하지 않음
3. 다운로드한 HTML 페이지 내부의 오픈 그래프나 메타 태그 정보를 기반으로 페이지의 검색(공유)정보를 가져오고 이를 바탕으로 검색 엔진에 저장함

 

 

 

서버 사이드 렌더링의 단점

1. 소스코드를 작성할 때 항상 서버를 고려해야 함
   • 브라우저의 전역 객체인 window, sessionStorage에 대한 접근을 최소화해야 하고, 사용이 불가피하다면 해당 코드가 서버 사이드에서 실행되지 않도록 처리해야 함
2. 적절한 서버가 구축돼 있어야 한다
   • 사용자의 요청에 따라 적절하게 대응할 수 있는 물리적인 가용량 확보 필요
   • 장애 상황 복구 전략 필요
   • 요청 분산, 프로세스 다운될 대 대비 필요
3. 서비스 지연에 따른 문제
   • 지연 작업이 최초 렌더링에 발생한다면 큰 분제
   • 병목 현상이 심해져 더 안 좋은 사용자 경험 제공

 

 

SPA, SSR 모두 알아야 하는 이유

• 서버 사이드 렌더링은 만능이 아님
  
  • 작업이 모두 서버에서 이뤄진다고 해서 모든 성능 문제가 해결되는 것은 아님
  • 잘못된 웹페이지 설계는 오히려 성능을 해치고 서버와 클라이언트 두 군데로 관리 포인트만 늘어날 수 있음