CSR vs SSR
- 화면에 보일 페이지의 컨텐츠를 어디서 그리느냐의 차이
- 한가지의 아키텍처만 고집하는게 아니라 각각 필요한 부분에 병행하면서 사용 하는것이 Point
컨텐츠를 그린다?
HTML(최종 결과물 === 화면에 그려낼 컨텐츠)을 완성하는 것
브라우저 렌더링 과정
CSR과 SSR 모두 브라우저 렌더링 과정이 일어난다.
CSR은 서버에서 미완성된 HTML을 던져주고 클라이언트에서 JS로 동적으로 완성
SSR은 서버에서 HTML를 완성시켜서 던져준다.
- 서버에 요청하여 HTML 파일을 다운로드
- HTML 코드를 위에서 아래로 코드를 읽어나간다.
- 읽는 과정에서 다음의 요소들을 만나면 파일 다운로드
link(외부 리소스 연동): 주로 CSS 불러 올때 사용, CSS 파일을 다운로드하고 파싱script: 렌더링을 멈추고 자바스크립트 파일 다운로드 및 해석그외 외부 리소스 파일들: 외부 리소스를 다운로드
- HTML과 CSS 파싱이 완료되면 브라우저에서 사용할수 있는 구조인
DOM과CSSOM으로 변환 DOM과CSSOM을 결합하여Render tree를 구축- Layout 단계: 각 요소의 크기와 위치를 계산한다.
- Paint 단계: 요소를 픽셀로 변환하여 화면에 그린다.
- Compositiong 단계: 픽셀로 그려낸 여러 레이러를 합성한다.
Why JS is parser blocking?
- 브라우저는 스크립트가 페이지에서 무엇을 수행할지 모르기 때문에, 브라우저는 최악의 시나리오를 가정하고 파서를 차단합니다 [자세히]
Re-Rendering
- DOM을 조금이라도 변경하면
Render tree를 다시 만들고 렌더링 과정 진행 - 렌더링은 사용자 경험을 해치지 않는 마지노선인
60fps를 보장해야 한다.- 1frame당 0.0166초로 0.0166초 내에 레이아웃 단계와 페인트 단계가 진행되어야 자연스럽다는 뜻
Layout 단계
- 배치 관련 변경되지 않았을 때 Layout 단계는 생략된다.
- ex:) width, height, position 등, Layout을 발생시키는 속성을 사용하면 60fps 보장이 어렵다. [CSS Trigger 자세히]
- Layout 단계는 줄이면 줄일수록 성능 UP
- CPU 사용
Paint 단계
- Paint 단계는 필수로 진행된다.
- Paint 단계는 필수로 일어나기 때문에 최적화할수 있는 부분이 없다.
- GPU 사용
Client Side Rendering
- 브라우저에서 JS로 동적으로 컨텐츠를 만든다.
실시간성이 중요한 페이지에 적합하다.- ex:) SNS,Youtube, Gmail, Google Docs
- HTML을 최소화하고 JS로 DOM을 직접 생성
- HTML 용량 ↓, JS 용량 ↑
- 필요한 DOM만 그때 그때 만들어서 사용
- 페이지 이동이 일어날때 HTML을 서버로부터 다시 불러오는게 아니라 JS로 DOM을 다시 만듦
History API를 사용하여 라우팅 처리- DOM을 이용하여 렌더링 수행
- React는 JSX문법을 이용하여 DOM(Virtual DOM)을 만든다.
SPA (Single Page Application)
- 서버에서 브라우저로 하나의 빈 HTML을 전달
- HTML 태그 자체를 자바스크립트가 동적으로 생성
CSR이 나오게된 배경
- 사이트 이동이 일어날 때 흰색배경이 나타남
- 데이터 갱신이 필요할 때마다 새로고침이 필요
- 사용자 경험이 너무나도 안좋았다 😭
CSR의 장점
- 서버의 통신없이 브라우저(클라이언트)에서 JS로 DOM을 생성하기 때문에 빠른 화면 전환과 인터렉션이 가능하다.
- 한번 렌더링이 된 이후에 필요한 부분만 렌더링하면 되기에 성능상 이점 있음
CSR의 단점
- JS 번들 사이즈가 커짐
- DOM을 브라우저에서 직접 만들기 때문에 컴퓨팅 파워에 영향이 큼
- JS를 해석하고 DOM을 만드는 과정 때문에 렌더링 퍼포먼스가
SSR에 비해 낮다. - 첫 index.html에는 단순히 뼈대만 있고 텅 비어있기 때문에 검색 엔진봇이 크롤링 할때 아무 내용이 없어
SEO에 취약 - html파일이 하나이기 때문에 별도의 추가 작업이 없을 경우 페이지별로 검색엔진에 도움을 주는 메타 태그들을 활용할 수 없다.
요즘은 검색 엔진 봇이 JS 해석을 잘하고 크롬 기반이기 때문에 SEO와 크롤링은 문제없다.
JavaScript SEO
Server Side Rendering
- 서버에서 페이지를 그려 클라이언트로 보낸 후 화면에 표시하는 기법
- DB -> API -> Data -> HTML의 flow가 Server 내에서 이루어짐
- 컨텐츠가 많은 서비스인 경우
SSR을 이용하는게 합리적
SSR의 장점
- 서버의 컴퓨팅파워가 더 좋기 때문에
CSR보다 빠르다. - 서버에서 미리 HTML을 완성해서 내려주기 때문에 초기 구동 속도가 빠름
- SSR이 검색엔진 최적화에 이로운 이유
- HTML에 이미 내용이 다 차있기 때문에 검색 엔진들이 정보를 수집할때 정확한 정보를 가져갈 수 있어서 SEO에 좋다.
- 검색엔진은 컨텐츠가 빠르게 뜨는 사이트가 우선순위가 높다.
- 페이지 별로 메타태그를 활용할수 있기 때문에
OG태그활용과 검색엔진 최적화 가능
OG(Open Graph) Tag란?
- 링크를 공유했을 때 해당 웹 사이트의 정보를 이미지와 설명으로 표시해주는 메타 태그
SSR의 단점
- 서버에 데이터를 요청할때 서버에서 HTML을 생성해서 내려주는 시간이 필요
- 이 과정이 느려질수록 UX 저하
Front-End 😲