최근 리액트를 하면서 왜 리액트를 써야하는지 그리고 리액트는 무엇인지 알아보던 와중 CSR이라는 단어를 접했고 CSR 뿐만아니라 다른 렌더링이 존재한다 해서 각각의 특징 및 장단점을 알아보려고 한다.
🥦 CSR
Client Side Rendering
→ 요청을 받으면 구동에 필요한 모든것을 다운로드 받은 후, User에게 뷰를 보여줌
리액트를 해본사람이라면 다들 뭔지는 모르지만 들어는 보았을 CSR은 우선 Client Side Rendering의 약자이다.
말 그대로 클라이언트 (브라우저) 에서 웹페이지를 렌더링하는 것이다. 이말은 즉, 어플리케이션 구동에 필요한 HTML JS CSS 파일을 모두 다운로드 한 후에 뷰가 구성된다.
자세한 흐름
- 사용자가 웹 페이지를 방문하면(request), 브라우저는 최소한의 HTML 파일을 다운로드(response) 한다.
- 이 HTML 파일은 script, meta, link 등의 태그를 포함하며, 빈 컨텐츠의 index.html 파일이라고 보면 된다.
- 브라우저는 index.html에 있는 자바스크립트 번들 파일을 다운로드한 다음 AJAX를 통해 API 요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링한다.
- 사용자가 페이지를 이동할 경우, 서버에 추가 HTML파일을 요청하지 않고 이미 받은 자바스크립트를 이용하여 렌더링 한다.
장점 👍
- 후속 페이지 로드 시간이 더 빠르다.
- CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문에 CSR의 로드 시간이 줄어든다.
- 별도의 API를 호출할 필요가 없는 페이지이거나 지연 로딩 모듈이 필요하지 않다, 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.
- CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.
단점 👎
- 초기 페이지 로드 시간이 SSR에 비해 느리다.
- CSR을 사용하면 브라우저는 브라우저에서 사용 가능한 컨텐츠로 HTML을 컴파일하기 전에 기본 HTML, CSS 및 모든 필수 스크립트를 로드하기 때문이다.
- SEO에 친화적이지 않다.
- Javascript 파일을 전부 로드해야, 페이지 정보를 구성할 수 있기 때문이다.
- 브라우저가 페이지를 표시하기 전에 HTML 및 JavaScript 파일을 다운로드하고 프레임 워크를 실행하는 동안 사용자는 빈페이지를 보게 되므로 UX가 좋지 않다.
SEO 란
검색 엔진 최적화
🥕 SSR
Server Side Rendering
→ 요청 받은 즉시 화면을 생성하여 User에게 보여줌
서버에서 뷰 구성에 필요한 전체 HTML을 요청을 받은 즉시 생성해서 반환합니다. 이렇게 하면 클라이언트 브라우저에서 응답을 받은 후, 이미 완성된 뷰를 그대로 보여지게 됩니다.
자세한 흐름
- 사용자가 웹 페이지를 방문하면(request), 서버는 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행 후 HTML 컨텐츠를 컴파일 및 준비한다.
- 컴파일된 HTML은 추가 렌더링 및 표시를 위해 클라이언트 브라우저로 전송된다(response).
- 브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.
- 브라우저는 자바스크립트를 다운로드하고 실행하면서 페이지를 대화형(interactive)으로 만든다.
- 사용자가 페이지를 이동할 경우, 위 동작을 반복한다.
장점 👍
- 초기 페이지 로드시간이 빠르다.
- 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠르다.
- SEO에 친화적이다.
- 이미 다 만들어진 페이지를 검색엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.
단점 👎
- 페이지 이동시마다 서버에서 페이지를 생성하는데 시간이 걸리기 때문에 TTFB(Time to First Byte)가 느리다.
- 페이지 로드가 너무 무겁다면, 오히리 사용자 경험을 개선하는게 아니라 해칠 수 있다. 초기 페이지 로드시 데이터가 많이 필요한 대시 보드가 예가 될 수 있다.
- 페이지 전환 간에 깜빡임 현상이 존재합니다.
- 페이지를 이동할 때마다, 서버에서 렌더링해주는 새로운 파일을 받기 때문이다.
- CSR에 비해 더 많은 개발 노력이 필요하며, SSR 프레임워크를 사용한다면 추가적인 러닝 커브에 대한 비용이 발생한다.
🥕 SSG
Static Site Generation
→ 요청 받은 즉시 화면을 생성하여 User에게 보여줌
클라이언트에서 필요한 페이지들을 사전에 미리 준비해뒀다가, 요청을 받으면 이미 완성된 파일을 단순히 반환하여 브라우저에서 뷰를 보여지게 된다.
자세한 흐름
- 사용자가 웹 페이지를 방문하면(request), 엣지 캐싱(edge caching)된 HTML 클라이언트로 반환해 준다.
- 브라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.
엣지 캐싱(edge caching)이란?
최종 사용자에게 더 가까운 컨텐츠를 저장하기 위해 캐싱 서버를 사용하는 것이다. 대표적으로 CDN을 많이 사용한다.
장점 👍
- 빌드 타임에 HTML 파일이 생성되기 때문에 빠른 FP, FCP, TTI를 제공한다.
- 매 요청마다 생성하는 것이 아니므로, SSR과 달리 일관성있게 빠른 TFB를 달성할 수 있다.
- 이미 생성된 HTML 파일을 받기 때문에 SEO 친화적이다.
- build 명령은 실제로 사이트를 방문하는 사람의 워크플로를 벗어나므로 시간이 좀 걸리더라도 문제되지 않는다.
단점 👎
- 모든 URL에 대해 개별 HTML 파일을 생성해야 한다. 따라서 URL을 미리 예측할 수 없거나 URL을 예측할 수 없으면 적용이 어렵다.
출처
이왕하는거미루지말고하자.