우선 정의부터 알아보자.
CSR(Client-Side-Rendering)
클라이언트 브라우저에서 어플리케이션을 렌더링을 진행합니다. 즉 어플리케이션 구동에 필요한 HTML, JS, CSS 파일 등을 모두 다운로드 한 뒤에 뷰가 구성되게 됩니다.
SSR(Server-Side-Rendering)
서버에서 뷰 구성에 필요한 전체 HTML을 요청을 받은 즉시 생성해서 반환합니다. 이렇게 하면 클라이언트 브라우저에서 응답을 받은 후, 이미 완성된 뷰를 그대로 보여지게 됩니다.
SSG(Static-Site-Generation)
다른 말로, Static-Rendering 이라고도 하는 해당 방식은 클라이언트에서 필요한 페이지들을 사전에 미리 준비해뒀다가, 요청을 받으면 이미 완성된 파일을 단순히 반환하여 브라우저에서 뷰를 보여지게 됩니다.
각각의 장단점
CSR의 장점
- 후속 페이지 로드 시간이 더 빠르다. CSR을 위해 이미 모든 지원 스크립트가 사전에 로드되었기 때문에 CSR의 로드 시간이 줄어든다.
- 별도의 API를 호출할 필요가 없는 페이지이거나 지연 로딩 모듈이 필요하지 않다, 이미 스크립트가 캐싱된 경우 인터넷 없이도 해당 CSR 웹 애플리케이션을 실행할 수 있다.
- CSR은 서버를 호출할 때마다 전체 UI를 다시 로드할 필요가 없다.
CSR의 단점
- 초기 Javascript 파일을 전부 로드한 후, 뷰를 구성해야하기 때문에 어플리케이션이 커질수록 구동시간이 점점 느려집니다.
- 마찬가지로 Javascript 파일을 전부 로드해야, 페이지 정보를 구성할 수 있으므로 SEO(Search-Engine-Optimization)에도 취약한 문제가 있습니다.
SSR의 장점
- 초기 페이지 로드시간이 빠르다(FP 및 FCP가 빠르다). 렌더링이 준비된 HTML 파일을 브라우저에서 로드하기 때문에 CSR에 비해 더 빠르다.
- 서버에서 페이지 로직 및 렌더링을 실행하면 많은 자바스크립트를 클라이언트에 보내지 않아도 되므로 TTI(Time to Interactive)를 빠르게 수행할 수 있다.
- SEO에 친화적이다. 이미 다 만들어진 페이지를 검색엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.
- 클라이언트 하드웨어 및 소프트웨어 성능에 영향을 덜 받는다. 일반적으로 서버는 더 높은 컴퓨팅 성능과 훨씬 더 높은 네트워킹 속도를 가진 시스템이다. 클라이언트에서는 서버에서 완성된 페이지만 렌더링해 주면 된다. 즉 클라이언트의 부담이 CSR에 비해 덜하다.
SSR의 단점
- 페이지 전환 간에 깜빡임 현상이 존재합니다. 페이지를 이동할 때마다, 서버에서 렌더링해주는 새로운 파일을 받기 때문이죠.
- 새로운 파일을 받아서 다시 필요한 파일을 로드하는 것이기 때문에, 클라이언트단에서 메모리에 데이터를 유지할 수가 없습니다. 이는 SSG 방식도 마찬가지입니다.
SSG의 장점
- 빌드 타임에 HTML 파일이 생성되기 때문에 빠른 FP, FCP, TTI를 제공한다. 또한 매 요청마다 생성하는 것이 아니므로, SSR과 달리 일관성있게 빠른 TFB를 달성할 수 있다.
- 이미 생성된 HTML 파일을 받기 때문에 SEO 친화적이다.
build 명령은 실제로 사이트를 방문하는 사람의 워크플로를 벗어나므로 시간이 좀 걸리더라도 문제되지 않는다.
SSG의 단점
- 이미 Pre-rendering된 정적 파일이 있으므로, 서버에서는 단지 그 파일을 클라이언트로 전달해줄 뿐이어서 정말 빠릅니다. 그렇지만, 웹 서비스에 존재하는 수많은 페이지들을 전부 정적 파일로 만들어주기에는 현실적으로 무리가 있어 보입니다.
말많은 개발자의 111강