Rendering
- 요청받은 내용을 브라우저 화면에 표시하는/그리는 작업.
과정
-
서버로부터 데이터를 응답받아 파싱하여 DOM트리를 생성한다.
-
DOM 트리가 구축되는 동안 브라우저는 Render 트리를 구축한다.
-
CSS 설정 및 위치 지정
-
Render 트리가 그려진다.
1. SSR (Server Side Rendering)
-
전통적인 웹 어플리케이션 방식으로, 요청시 마다 서버에서 처리하여 새로고침으로 페이지 응답한다.
-
웹에서 기능과 데이터가 많아지면서 SPA(Single Page Application)가 생김, 더 향상됨 UX를 위함
1-1) MPA (Multi Page Application)
- page = html
2. CSR (Client Side Rendering)
-
클라이언트에서 Javascript를 통해 렌더링 하는 방식이다.
-
SPA (Single Page Application) 형식의 대부분 프론트엔드 라이브러리(Vue, React 등)가 CSR 방식으로 시작되었다. 그리고 초기 렌더링 시간 비용 문제, SEO 문제, 메타 데이터 동적 생성의 한계를 극복하기 위해 SSR 프레임워크(Nuxt.js, Next.js)를 모두 보유하고 있다.
2-1) SPA (Single Page Application)
-
최초 한번 전체 페이지를 다 불러오고 HTML에 번들링된 js가 실행되며 페이지를 렌더링한다.
-
클라이언트 요청에 따라 응답 데이터만 다시 페이지의 특정부분에 렌더링하는 Web Application 개념이다.
3. SPA의 장/단점
장점
-
필요한 부분만 중복없이 요청하므로 퍼포먼스가 향상된다.
-
페이지 이동이 자연스럽고 빠르다. (UX)
-
서버의 렌더링 연산을 클라이언트로 분산
-
개발 생산성 개선 (컴포넌트 별 개발)
-
다른 플랫폼과 공통으로 사용하는 Backend API 개발 가능
단점
-
JS번들링 파일을 한번에 받기 때문에 초기 로딩 비용 있다. (=> code spliting으로 최적화 가능)
-
렌더링의 부하를 클라이언트가 담당하기에 구형 단말기/성능이 낮은 단말기에서의 초기 로딩 비용이 클 수 있다.
-
SEO의 한계 (pre-rendering, SSR)
-
동적 metat data 생성 불가능 ex) open graph
-
보안 이슈
4. SSR의 장/단점
- 위의 SPA가 가지는 단점을 보완하기 위해 SSR(universal)의 개념을 도입
장점
- 초기 페이지의 컨텐츠는 서버사이드에서 생성하므로 SEO, 크롤링의 문제 해결 가능
단점
-
페이지 이동시 새로고침 및 중복된 로딩
-
서버 렌더링 부하 (CPU)
-
다른 플랫폼과 공유하는 Backend API 한계
-
개발/배포 환경이 기존 CSR 방식보다는 까다로울 수 있다
