오늘은 렌더링에 대해서 알아서보려고한다.
먼저 렌더링(Rendering)이란 무엇인가!??
렌더링은 화면에 표시할 웹 페이지를 만드는 과정을 의미한다.
렌더링 과정은 다음과 같이 이루어진다.
1. Loader가 서버로부터 HTML을 불러온다.
2. HTML을 분류(Phasing)하여 DOM트리를 만든다.
3. css파일과, 스타일 요소를 분류하여 CSSOM트리를 만든다.
4. DOM트리와 CSSOM을 결합하여 렌더링트리를 만든다.
5. 렌더링트리의 요소들의 크기와 위치를 계산한다.
6. 계산된 크기와 위치에 맞게 화면에 출력한다.
렌더링은 Client와 Server중 어느쪽에서 렌더링이 준비되느냐에 따라
CSR(Client Side Rendering) , SSR(Server Side Rendering) 으로 나뉜다.
각 CSR과 SSR은 대척관계에 있기 때문에 장단점이 각각 있다.
따라서 각각의 장단점을 파악하고, 적재적소에 필요한 방식을 사용해야한다.
그럼 본격적으로 CSR과 SSR에 대해 알아보자!!
👉🏻 CSR(Client Side Rendering)
CSR은 렌더링이 클라이언트쪽에서 일어난다.
즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내줌.
클라이언트는 그것을 받아 렌더링시작.
CSR의 단계는 아래와 같다.
- User가 Website 요청을 보냄.
- CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보냄.
여기서 CDN은, 엔드 유저의 요청에 '물리적'으로
가까운 서버에서 요청에 응답하는 방식 - 클라이언트는 HTML과 JS를 다운받는다.
(이때 SSR과는 달리 뼈대만있는 HTML이다.) - 다운이 완료된 JS가 실행된다. 데이터를 위한 API호출
- 서버가 API로부터의 요청에 응답
- API로부터 받아온 data를 placeholder 자리에 넣어줌.
⭐️ 이제서야 페이지가 상호작용가능!!
즉, CSR은 서버에서 처리없이 클라이언트로 보내주기 때문에
자바스크립트가 모두 다운로드 되고 실행이 끝나기전까지 사용자는 볼수 있는게 없음.
따라서, 자바스크립트 파일을 서버로부터 다운로드받아 동적으로 페이지를 생성해서
브라우저에 띄우는 과정을 CSR의 경우 기다려야하기 때문에 초기 로딩속도가 느린 단점이 있음.
단, 초기 로딩 이후에 페이지 일부를 변경할 때는
서버에 일부 데이터만 요청하면되므로 이후의 로딩속도는 SSR보다 빠름.
클라이언트측에서 연산 및 라우팅을 직접처리하기 때문에
반응속도가 빠르며 서버가 빈 뼈대만 있는 HTML을 브라우저에 넘겨주는
역할만을 수행하기 때문에 서버 부하를 줄일 수 있음.
하지만 빈뼈대의 HTML안엔 검색 엔진이 색인을 할만한 컨텐츠가 없기 때문에,
CSR은 검색엔진최적화 (SEO)에 불리.
👉🏻 SSR (Server Side Rendering)
서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달.
SSR의 단계는 다음과 같음
- User가 Website 요청을 보냄
- Server는 'Ready to Render',
즉, 즉시 렌더링 가능한 html파일을 만듬. - 클라이언트에 전달되는 순간,
이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다.
그러나 사이트 자체는 조작 불가능(Javascript 읽히기 전) - 클라이언트가 자바스크립트를 다운받는다.
- 다운 받아지고 있는 사이에 유저는 컨텐츠를 볼 수 있지만
사이트를 조작할 순 없다. - 브라우저가 Javascript 프레임워크를 실행한다.
- JS까지 성공적으로 컴파일 되면, 사용자 조작이 실행되고
⭐️ 이제 웹페이지는 상호작용이 가능해진다
즉, SSR은 서버에서 이미 '렌더 가능한'상태로
클라이언트에 전달되기 때문에,
JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있음.
모든 데이터가 이미 HTML에 담긴 채로 브라우저에 전달되기 때문에
검색엔진 최적화에 유리함.
브라우저측의 자바스크립트 다운로드를 기다려야했던 CSR보다
초기 구동속도가 빠르다.
하지만 초기 로딩시 사용자가 버튼을 클릭해도
아무 반응이 없는 현상이 발생한다.
이유는 JS로직이 아직 연결이 안되었기 때문이다.
위의 이유때문에 TTV와 TTI 의 개념이 생겨난 것이다.
TTV(Time To View), TTI(Time To Interact)의 시간차이가 존재한다는 것이다.
📌 SSR 과 CSR의 차이
1) 웹페이지를 로딩하는 시간
웹페이지 로딩의 종류는 두가지로 나눌 수 있다.
가장 첫페이지 로딩, 나머지를 로딩
- 가장 첫페이지 로딩시간
CSR은 HTML, CSS 모든 JS를 한번에 불러옴.
하지만 SSR은 필요한 부분의 HTML과 JS만 불러옴.
따라서 SSR이 더 빠르다.
- 나머지 로딩시간
첫 페이지를 로딩하고, 사이트의 다른 곳으로 이동할 때
CSR은 이미 첫페이지 로딩때 나머지 부분을 구성하는
코드를 받아왔기 때문에 빠르다.
하지만 SSR은 첫페이지를 로딩한 과정을 그대로
다시 실행한다. 따라서 SSR이 더 느리다.
2) SEO 대응
검색 엔진은 '크롤러'로 웹 사이트들을 읽는다.
CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에
자바스크립트가 실행되어야만 meatadata가 바뀌었음.
하지만 SSR은 애초에 서버 사이드에서 컴파일되어
클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이.
📂 CSR 과 SSR의 장단점들을 정리해보면
CSR
장점
- 페이지 전환시 화면 깜빡임이 없음.
- 초기 로딩 이후 구동속도가 빠름
- TTV와 TTI의 시간차이가 없음
- 서버의 부하가 client로 분산됨.
단점
- 초기 로딩 속도가 느림
- 검색엔진에 불리
SSR
장점
- 초기 구동속도가 빠름
- 검색엔진에 최적화되어 있음
단점
- 페이지 전환시 화면 깜빡임이 있음
- TTV와 TTI사이 시간차가 있음
- 서버 부하가 존재
🔆 그럼 어떨때 CSR을 쓰고, 어떨때 SSR을 써야할까!?
SSR을 추천할 때
- 네트워크가 느릴때
(CSR은 한번에 모든것을 불러오지만, SSR은 각 페이지마다 나눠불러오기 때문) - SEO(검색엔진 최적화)가 필요할 때
- 최초 로딩이 빨라야하는 사이트를 개발 할 때
- 메인스크립트가 크고 로딩이 매우 느릴때
- 웹 사이트가 상호작용이 별로 없을 때
CSR을 추천할 때
- 네트워크가 빠를때
- 서버의 성능이 좋지 않을때
- 사용자에게 보여줘야하는 데이터의 양이 많을 때
- 메인 스크립트가 가벼울 때
- SEO(검색엔진 최적화)는 상관없을 때
- 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때
