목차
나는 nextjs를 공부하기 전 이 기술을 배우는 이유에 대해 정확히 알아야 한다고 생각하여
이번 기회에 정리하고자 한다.
CSR의 정의
CSR은 "Client-Side Rendering"의 약어로, 클라이언트 측에서 페이지를 렌더링하는 방식을 말한다. CSR은 서버로부터 받아온 데이터를 클라이언트에서 JavaScript를 통해 동적으로 조작하여 렌더링한다.
클라이언트에서 데이터를 받아오고 렌더링하기 때문에 초기 로딩 속도는 느리지만, 이후에는 페이지 이동이 빠르고 사용자 경험을 향상시키는 등의 이점이 있다.
CSR의 단점
1. CSR은 SEO측에서 불리하다.
초기 html의 빈 상태
검색 엔진 크롤러는 JavaScript를 실행하지 않고 HTML만 분석하는 경우가 많음
<!-- CSR 방식의 초기 HTML -->
<html>
<head>
<title>My Website</title>
</head>
<body>
<div id="root"></div> <!-- 콘텐츠가 없음 -->
<script src="bundle.js"></script> <!-- JS 실행 후 콘텐츠 추가 -->
</body>
</html>
그렇다면 검색 엔진 크롤러가 js실행을 기다려 주면 되는거 아닌가?
일부 검색 엔진(특히 구글 외의 검색 엔진)은 JavaScript를 실행하는 능력이 제한적이다.
여기서 그러면 모든 검색 엔진 크롤러가 js실행을 안하냐고 오해를 할 수 있다.
구글 검색 엔진은 다른 것을 볼 수 있다.
ex) 구글 검색엔진
문서에 따르면 다음과 같다.
- nextjs.org에서 분석한 10만 건 이상의 구글봇 요청 중, 상태 코드 오류와 색인 불가능한 페이지를 제외하고, 복잡한 자바스크립트 상호작용이 있는 페이지를 포함하여 100%의 HTML 페이지가 전체 페이지 렌더링으로 이어졌습니다.
따라서 구글 검색엔진 이외의 크롤링 봇들 때문에 seo가 약하다.
2. CSR은 첫 로딩이 느리다.
csr의 랜더링 과정을 살펴보면 다음과 같다.
CSR의 과정
1. User가 Website 요청을 보냄.
2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
CDN : aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 '물리적'으로 가까운 서버에서 요청에 응답하는 방식
3. 클라이언트는 HTML과 JS를 다운로드 받는다. (이때 SSR과 달리 유저는 아무것도 볼 수 없다)
4. 다운이 완료된 JS가 실행된다. 데이터를 위한 API가 호출된다.
(이때 유저들은 placeholder(빈 화면)를 보게된다)
5. 서버가 API로부터의 요청에 응답한다.
6. API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용이 가능해진다.
따라서 CSR은 react나 vue등을 통해 가상돔을 생성하여 js가 실행될 때 채워지기 때문에 늦다.
CSR의 장점
- 첫 로딩만 기다린다면 이후부터는 좋은 사용자 경험(UX)를 제공한다.
- 연속된 렌더링으로 인한 과부하를 줄일 수 있다. (전체를 렌더링하는 Vanila JS보다 성능 향상 가능)
- 초기 로드만 완료된다면 이후 렌더링이 빠르다.
- 서버에 요청할 것이 거의 없어서 서버 부담이 적다. (data가 필요할 때만 서버에 요청)
- Web Application에 좋다.
SSR의 정의
SSR은 "Server-Side Rendering"의 약어로, 서버 측에서 페이지를 렌더링하는 방식이다. 서버에서 페이지를 렌더링한 후에, 클라이언트에게 전달되며, 클라이언트에서는 추가적인 JavaScript 로딩이 필요하지 않다. SSR은 초기 로딩 속도가 빠르고, SEO에 유리하며, 서버에서 데이터를 처리하므로 보안성이 높다. 그러나 페이지 이동이 느리고, 서버에서 처리하기 때문에 서버의 부하가 증가할 수 있다.
위에 구문을 통해서 서버 측에서 화면을 보여준다고 오해를 할 수 있다.
정확히 말하면 다음과 같다.
SSR은 서버에서 HTML을 미리 생성하여 클라이언트로 전달하는 방식이다.
그러나 최종적으로 화면을 그리는 것은 브라우저이며, JavaScript가 추가로 실행될 수도 있다.
ssr의 과정
1. User가 Website 요청을 보냄.
2. Server는 'Ready to Render'. 즉, 즉시 렌더링 가능한 html파일을 만든다.
(리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다. 그러나 사이트 자체는 조작 불가능하다. (Javascript가 읽히기 전이다.)
4. 클라이언트가 자바스크립트를 다운받는다.
5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작 할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 Javascript 프레임워크를 실행한다.
7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용 가능해진다.
SSR의 단점
- 서버에서 전체 앱을 미리 렌더링하기 때문에 컴포넌트 로딩이 오래 걸리면 유저는 빈 화면을 볼 수도 있다.
- 간단한 데이터 수정에도 서버에 매번 요청하기 때문에 서버 부하가 크다. (view 변경 시 요청)
- 매번 페이지를 요청할 때마다 새로고침되어 UX가 다소 떨어진다.
SSR의 장점
- 초기 렌더링 속도가 빠르다.
- JS를 이용한 렌더링이 아니므로 SEO에 좋다. (HTML 파일에 모든 콘텐츠 정보가 포함되어 제공되기 때문에 봇이 데이터 수집이 가능하다)
- 초기 로딩 속도가 빠르다.
- Static Sites(동적)에 좋다.
'코딩 정보' 카테고리의 다른 글
| [vite] esm, rollup.. 알고 쓰자 (0) | 2025.03.09 |
|---|---|
| 깃허브 브랜치 전략에 대해 알아보자 (2) | 2024.11.21 |
| NodeJs 코딩 테스트 준비 핵심 요약 (0) | 2024.10.19 |
| 백엔드와 함께 프론트 개발 시 유용한 패키지들 (0) | 2024.08.22 |
| 깃허브 브랜치를 잘못 merge했을 때 해결방안.. (2) | 2024.05.12 |