Next.js - SSR, CSR? SEO최적화?
이 블로그도 Next.js의 SSR로 노출페이지가 작성되어 배포돼요.
- •Pre-rendering: 서버에서 HTML을 미리 생성하여 전달
- •FCP 속도: 첫 페이지 로딩 시 빈 화면 없이 즉시 노출
- •Data Fetch: 서버 사이드에서 보안성 높은 API 통신
- •성능: 클라이언트 기기의 리소스 소모가 상대적으로 적음
- •Hydration: 브라우저에서 JS가 실행되며 화면 렌더링
- •UX/Interaction: 페이지 전환 시 새로고침 없는 부드러움
- •Server Load: 렌더링 부하를 클라이언트가 분담하여 감소
- •State: 컴포넌트 간 상태 공유 및 복잡한 UI 유지 유리
• 검색 엔진 가독성: SSR은 완성된 HTML을 제공하므로, JS를 실행하지 못하는 검색 로봇도 콘텐츠를 완벽히 수집하여 상위 노출에 매우 유리합니다.
• 메타 태그 동적 생성: 각 페이지별로 고유한 Title, OpenGraph(OG) 태그를 서버에서 주입할 수 있어 SNS 공유 시 최적의 미리보기를 제공합니다.
• 인덱싱 속도: CSR은 크롤러가 JS 렌더링을 기다려야 하지만, SSR은 즉시 인덱싱이 가능하여 콘텐츠 색인 시간을 대폭 단축시킵니다.
SSR, CSR 개념 및 Next.js의 구조적 특징
웹 개발에서 화면을 그리는 방식인 SSR과 CSR은 성능과 SEO(검색 엔진 최적화)에 결정적인 역할을 해요. 특히 Next.js는 이 두 방식의 장점을 결합한 구조를 제공하고 가장 인기가 많아요. 성능도 이 정도면 저는 충분하다고 생각합니다. ~~약간의 불편을 제외하면
결국 SSR, CSR은 서버가 내용을 작성해서 보내느냐(SSR), 사용자 브라우저에서 내용을 작성(CSR)하느냐 차이.
여기서 똑똑 하신 분들은 바로 캐치하실거에요. 사용자 브라우저에서 내용을 전부다 보는게아니라 사용자 브라우저에서 내용을 완성한다면, 검색엔진들은? 크롤링 봇들은?
크롤링 봇들은 전통적인 웹에 더 친숙함 (이미 다 그려진,SSR방식)
구글은 최근 스크립트마저 알아서 실행해서 검색에 노출시킨다고 해요, 그런데 검색봇 입장에서 수집이 편한 사이트를 먼저 수집하는것은 당연한 논리일 거에요(여전히 php로 배포하는사이트도 엄청많아요 특히 wordpress). 빠른노출과 검색엔진 최적화(Search Engine Optimization)을 원한다면 당연히 Next.js로 빌드한 웹은 반드시 모든 노출페이지가 SSR로 작성되는 것이 좋아요.
다만 SSR은 서버에서 모든 렌더링을 끝낸 내용을
접속자(검색봇, 사용자)에게 제공한다는 점에서
'조금이라도 더 서버자원(램or 캐시)을 사용한다'는 단점은 있어요.
(이마저도 사실 빌드과정에서 페이지별로 최적화합니다. stateless한 php대비 램을 상시 먹는다는 단점이 있을 뿐)
그러면 검색노출이 생명인 홈페이지를 왜 node.js로 빌드하고
php와 같이 퍼블리시된 형태(프로덕션) 바로적용이 안되는건가?
라는 생각을 하실텐데요.
결국 성능차이 때문이라고 설명드리게 될 것 같은데.
일반 사용자나 대규모 사용자 접속환경에서 진가를 발휘합니다.
때문에..
일반적인 서비스 환경에서는 php도 전혀 느리지 않긴 해요.
php가 검색 노출에도 완전히 최강이구요
(html자체가 php를 포함한다고 생각하셔도 괜찮아요)
PHP vs Next.js 핵심 아키텍처 비교
요청 처리 방식부터 SEO 최적화 전략까지
PHP (전통적 방식)
- • 빌드 불필요: 서버 수정 즉시 반영
- • Stateless: 요청 시마다 프로세스 실행
- • 동작 원리: 요청 → 소스 코드 읽기 → HTML 생성 → 종료
- • 특징: 단순한 배포 구조, 직관적인 개발
Next.js (현대적 방식)
- • 빌드 필수: 최적화 및 코드 번들링 과정
- • Persistent: 서버 프로세스 상시 대기
- • 동작 원리: 빌드 → 서버 상주 → 이벤트 기반 즉시 응답
- • 특징: 강력한 성능 최적화, 뛰어난 UX
1. 검색 엔진 가독성 (SSR)
두 방식 모두 서버에서 HTML을 완성하여 전달하므로 검색 로봇 인덱싱에 유리합니다.
2. 빌드 타임 최적화
Next.js는 빌드 시점에 이미지를 최적화하고 코드 분할로 로딩 속도를 극대화합니다.
3. 동적 메타 데이터
페이지별 제목과 설명을 즉시 주입하여 SNS 공유 및 검색 클릭률을 높입니다.
4. 사용자 경험(UX)
Next.js는 필요한 데이터만 불러와 새로고침 없이 앱처럼 부드럽게 전환됩니다.
Next.js와 SSR, CSR
1. SSR vs CSR 핵심 비교
| 구분 | SSR (Server-Side Rendering) | CSR (Client-Side Rendering) |
|---|---|---|
| 렌더링 주체 | 서버 (HTML 완성 후 전달) | 브라우저 (자바스크립트 실행 후 생성) |
| 초기 로딩 | 빠름 (완성된 화면을 즉시 표시) | 느림 (JS 다운로드 및 실행 대기 필요) |
| SEO | 매우 유리 (완성된 콘텐츠 제공) | 불리 (검색 로봇이 빈 페이지를 볼 수 있음) |
| 사용자 경험 | 페이지 이동 시 화면 깜빡임 발생 가능 | 초기 로드 후 앱처럼 매끄러운 이동 |
2. Next.js의 구조적 특징: 하이브리드 렌더링
Next.js는 단순히 라이브러리(React)를 넘어선 프레임워크로, 상황에 맞는 최적의 렌더링 전략을 선택합니다.
- Pre-rendering: 모든 페이지를 서버에서 미리 렌더링하여 정적 HTML을 생성합니다.
- Hydration: 서버에서 받은 HTML에 React의 상호작용성(Event Listeners 등)을 결합하는 과정입니다.
- Server Components: App Router 기반의 Next.js는 컴포넌트 단위로 서버에서 실행할지 클라이언트에서 실행할지 결정하여, 브라우저로 전송되는 자바스크립트 양을 획기적으로 줄입니다.
3. 일반 HTML/PHP vs Next.js 빌드 방식의 차이
Next.js는 소스 코드를 서버에 올리기만 하면 작동하는 PHP나 단순 HTML 파일과 달리 **'컴파일 및 최적화'**라는 복잡한 빌드 과정을 거칩니다.
💡 전통적인 방식 (PHP, ASP 등)
- 런타임 중심: 요청이 들어올 때마다 서버가 소스 코드를 읽어 실시간으로 HTML을 찍어냅니다. 별도의 최적화 빌드 단계가 약하며, 서버 사양에 성능이 크게 의존합니다.
🚀 Next.js 빌드 방식
- Build-time Optimization:
next build시점에 전체 애플리케이션 코드를 분석합니다. - Tree Shaking & Bundling: 사용하지 않는 코드를 제거하고, 수많은 JS 파일을 몇 개의 최적화된 번들로 합칩니다.
- Static Generation (SSG): 빌드 시점에 가능한 모든 페이지를 미리 HTML 파일로 구워내어, 실제 서비스 시에는 서버 연산 없이 초고속으로 응답합니다.
- Image Optimization: 이미지 파일을 WebP 등 최신 포맷으로 변환하고 사이즈를 조절하는 최적화가 빌드 및 런타임에 포함됩니다.
4. SEO(검색 엔진 최적화)의 결정적 차이
검색 엔진 로봇은 웹사이트를 방문하여 HTML 코드를 수집합니다.
- 초기 콘텐츠 노출: CSR은 로봇이 접속했을 때 콘텐츠가 없는
<div id="root"></div>만 보게 되어 인덱싱에 실패할 확률이 높습니다. Next.js의 SSR은 의미 있는 텍스트와 구조가 담긴 HTML을 즉시 제공합니다. - TBT(Total Blocking Time) 최적화: 구글 검색 순위에 영향을 주는 'Core Web Vitals' 지표를 개선합니다. 브라우저가 자바스크립트를 해석하느라 화면을 멈추는 시간을 최소화합니다.
- 동적 메타데이터: Next.js는 서버 측에서 페이지별
title,description,OG tag를 생성하므로, 소셜 미디어 공유(카톡, 페이스북 등) 시에도 정확한 정보가 노출됩니다.
요약: Next.js는 PHP처럼 서버에서 HTML을 생성하여 SEO를 잡으면서도, React처럼 클라이언트에서 부드럽게 작동하는 현대 웹의 정수를 담은 빌드 시스템을 갖추고 있습니다.
