0️⃣ Rendering 이란?
Rendering은 Application의 데이터와 UI를 결합해서 화면에 표시하는 과정입니다.
React와 같은 Application은 컴포넌트의 상태와 데이터를 기반으로 UI를 생성하고, 이러한 UI를 브라우저나 애플리케이션 화면에 출력합니다.
1️⃣ Client Side Rendering
CSR은 Application의 Rendering 작업이 브라우저에서 실행되는 방식입니다.
서버는 요청 받으면, 빈 div 구조를 가진 최소한의 HTML과, JavaScript 번들 파일을 클라이언트에 전달합니다.
클라이언트는 서버로부터 받은 JavaScript 번들 파일을 다운로드 하고 실행하여, React Component를 기반으로 UI를 동적으로 생성합니다.
서버는 단순히 HTML과 JavaScript 번들 파일을 전달하면 되기 때문에 서버의 처리 부담이 적고, 처음 자바스크리트가 실행된 이후에는 클라이언트에서 모든 작업이 처리되기 때문에 페이지 전환 속도가 빠르다는 장점이 있습니다.
🚫 Client Side Rendering의 한계점
1. 초기 로딩 속도 느림
CSR은 서버에서 HTML이 아닌 JavaScript 번들 파일을 전달 받아 브라우저에서 실행해서 콘텐츠를 표시합니다.
처음 화면을 로딩할 때, 브라우저는 JavaScript 번들 파일을 다운로드, 파싱, 실행한 뒤에야 콘텐츠를 표시할 수 있기 때문에 네트워크가 많이 느리거나 JavaScript 번들 파일의 크기가 큰 경우, 초기 화면 로딩 속도가 느려집니다.
2. 자바스크립트 의존하기 때문에 검색 엔진 최적화 어려움
CSR에선 JavaScript가 실행된 이후에 콘텐츠가 렌더링됩니다.
JavaScript를 실행하지 않는 크롤러를 사용하는 검색 엔진의 경우, 페이지의 콘텐츠를 제대로 크롤링을 못하기 때문에 검색엔진 최적화 SEO 에 부정적인 영향을 미치게 됩니다.
또한 오프라인의 브라우저 환경이나 장애나 보안 설정 등으로 JavaScript가 비활성화 혹은 차단되면서 동작하지 못하는 경우, 콘텐츠가 정상적으로 렌더링을 할 수 없어 유저 경험이 나빠질 수 있습니다.
💡 검색 엔진 최적화 SEO
웹사이트나 웹페이지가 검색엔진 결과페이지에서 더 높은 순위를 얻도록 최적화하는 과정입니다.
검색 엔진 알고리즘이 해당 사이트를 크롤링, 색인, 순위 매기기 방식에 따라, 사이트를 상위 검색 결과에 노출시키고 사용자에게 노출이 더 잘되도록 합니다.
3. 클라이언트 성능에 의존하고 대규모 애플리케이션에서 복잡해짐
CSR에선 클라이언트에서 모든 상태 관리와 데이터 패칭, 그리고 컴포넌트 렌더링 작업 모두를 수행해야 합니다.
이는 유저의 디바이스 성능에 크게 의존하게 되어, 저사양의 디바이스에서는 JavaScript가 느리게 실행되고 그에 따라 콘텐츠의 렌더링 속도도 느려지게 됩니다.
뿐만 아니라, 대규모 Application에서는 클라이언트 측의 로직이 복잡해지고, 그에 따라 디버깅과 유지보수가 어려워질 수 있어 개발자 경험에도 좋지 않을 수 있습니다.
2️⃣ Server Side Rendering
SSR은 React Application의 HTML을 서버에서 생성해서 브라우저에 전달하는 렌더링 방식입니다.
브라우저는 서버에서 전달받은 HTML을 그대로 렌더링해서 화면을 즉시 표시할 수 있습니다.
CSR와 달리, 초기 화면을 브라우저가 즉시 표시할 수 있기 때문에 UX와 SEO에 유리합니다.
react-dom/server 라이브러리를 활용한 SSR은 React Application 전체를 서버에서 실행해서 생성한 HTML, Hydration 작업을 위한 JS 번들 파일, 그리고 필요한 경우 React의 초기 상태 데이터를 포함하여 클라이언트에 전달합니다.
이후 클라이언트는 전달받은 HTML을 즉시 브라우저에 렌더링한 뒤, JS 번들 파일을 실행하여 이벤트 핸들러와 React 상태 관리 로직을 활성화하는 Hydration 작업을 수행합니다.
이 과정에서 서버로부터 전달받은 초기 상태 데이터가 있는 경우, 해당 초기 상태 데이터를 React Application의 State로 설정해서 서버에서 생성된 HTML과 HTML을 생성할 때 사용된 상태를 일치시켜서, 불필요한 추가 렌더링을 방지합니다.
💡 Hydration
서버에서 미리 만든 HTML 페이지를 브라우저가 받아온 뒤, JS를 추가로 연결하여 페이지를 활성화시키는 작업입니다.
예를 들면, 서버가 HTML을 만들어 브라우저에 보내서 화면이 표시됩니다.
그런 다음, 브라우저가 JS를 실행하고 HTML에 이벤트 처리나 애니메이션 같은 동적인 기능을 추가합니다.
즉, HTML이 껍데기라면, Hydration은 그 껍데기에 생명을 불어넣는 작업입니다.
🚫 Server Side Rendering의 한계점
1. 불필요한 JS 번들 실행 및 Hydration 작업
서버에서 HTML을 생성해서 클라이언트로 전달한 뒤, 클라이언트는 컴포넌트 트리 전체에 대해 JS 번들 파일을 실행하고 Hydration 작업을 통해 상호작용을 활성화 합니다.
이 과정에서 상호작용이 필요 없는 정적인 콘텐츠조차 JS 번들 파일을 실행하고 Hydration 작업을 수행해야 하기 때문에 불필요한 작업과 리소스 낭비가 발생합니다.
2. 서버와 클라이언트의 중복된 데이터 처리
서버에서 HTML을 생성할 때 데이터를 처리한 뒤, 클라이언트에서 추가적으로 API 호출하고 데이터를 동기화해야 하는 경우가 있습니다.
이로 인해 클라이언트에서 중복된 데이터 처리 로직이 발생하며, 데이터 동기화로 인한 비효율성이 발생합니다.
예를 들면, 사용자가 게시글 목록을 요청하면, 서버에서 HTML과 게시글 데이터를 렌더링합니다.
하지만, 클라이언트가 Hydration한 이후 최신 게시글을 표시하기 위해 API를 다시 호출하여 동일한 데이터를 가져오는 경우가 있습니다.
3️⃣ React Server Component
RSC는 React에서 제안한 새로운 렌더링 방식으로, 서버에서만 컴포넌트를 실행하여 정적인 HTML을 생성합니다.
상호작용이 필요없는 정적인 콘텐츠를 처리할 때 설계되었으며, 서버에서 처리한 데이터를 컴포넌트 트리에 전달하고, 컴포넌트는 이 데이터를 기반으로 HTML을 생성합니다.
이렇게 생성된 HTML은 JS 번들 파일 없이 클라이언트에서 즉시 렌더링이 가능하기 때문에, 브라우저의 초기 로딩 속도가 빠르고, 별도의 Hydration 작업이 요구되지 않습니다.
⭐️ React Server Component 도입한 이후의 Server Side Rendering
앞서 말했던, 기존 SSR의 문제점을 아래와 같이 해결합니다.
1. 불필요한 JavaScript 번들 파일 실행 및 Hydration 작업 해결
상호작용이 필요없는 정적인 콘텐츠를 서버에서만 실행하고 HTML로 생성하여 클라이언트로 전달하고, 클라이언트에서는 전달받은 HTML을 그대로 렌더링하며 추가적인 JS 번들 파일을 실행하거나 Hydration 작업이 필요하지 않습니다.
그래서 검색 엔진이 콘텐츠를 크롤링하기 편해지기 때문에 SEO에 유리하고, 초기 로딩 속도가 빨라집니다. 또한, 클라이언트 측의 Hydration 비용이 줄어들어 성능 최적화에 도움이 됩니다.
정적인 콘텐츠는 서버에서 처리하고, 상호작용이 필요한 동적인 콘텐츠는 클라이언트에서 처리하도록 역할을 나누어, 서버와 클라이언트에서의 중복작업이 줄고 개발의 효율성을 높일 수 있습니다.
2. 서버와 클라이언트의 중복된 데이터 처리 해결
데이터 처리가 서버 내부에서만 이루어지며, 서버에서 직접 DB를 호출하거나 비동기작업을 수행해서 획득한 데이터를 HTML에 포함합니다.
이 방식은 클라이언트의 불필요한 API 호출을 제거하고, 민감한 데이터가 클라이언트에 전달되지 않기 때문에 보안성이 강화되고 데이터 처리 로직 또한 비교적 단순화되어 개발 속도가 향상될 수 있습니다.
✅ 기존 SSR vs RSC 도입한 이후의 SSR의 차이점
1. JavaScript 번들 파일의 의존성 및 Hydration 필수 여부
- 기존 SSR: 요청된 경로와 관련된 컴포넌트 트리 전체에 대해, JS 번들 파일과 Hydration 작업이 필수적입니다.
- RSC 도입 이후의 SSR: 상호작용이 필요한 동적인 콘텐츠에 대해서만, JS 번들 파일 및 Hydration 작업을 수행합니다.
2. 서버에서의 HTML 생성 범위
- 기존 SSR: 요청된 경로와 관련된 컴포넌트 트리 전체에 대해, 서버에서 모두 실행해서 HTML을 생성합니다.
- RSC 도입 이후의 SSR: 상호작용이 필요없는 정적인 콘텐츠에 대해서만, 서버에서 실행해서 HTML을 생성합니다.
3. 데이터 처리 위치에 따른 보안성
- 기존 SSR: 서버와 클라이언트 모두 데이터 처리가 가능하기 때문에, 클라이언트 측에서 데이터 노출의 위험이 있습니다.
- RSC 도입 이후의 SSR: 서버에서만 데이터 처리를 수행하기 때문에, 클라이언트에서 별도로 API 호출을 하지 않아도 되고 민감한 데이터에 대해서 노출될 우려가 줄어듭니다.
