서버 사이드 렌더링(SSR)은 페이지 요청에 맞춰 서버에서 콘텐츠의 HTML을 생성해 보내는 렌더링 방식입니다. 제목과 본문, 링크를 초기 응답에 담을 수 있어 브라우저나 크롤러가 JavaScript를 실행하기 전에도 주요 내용을 받을 수 있습니다.
서버에서 HTML을 만드는 과정
클라이언트 사이드 렌더링(CSR)에서는 서버가 앱의 기본 틀을 보낸 뒤, 브라우저가 JavaScript를 실행해 데이터를 가져오고 콘텐츠를 채우는 구성이 일반적입니다. SSR은 이 중 HTML을 만드는 작업을 서버에서 수행합니다. 서버가 데이터와 템플릿으로 콘텐츠의 HTML을 만들어 보내면 브라우저는 이를 받아 표시합니다.
React나 Vue 기반 앱은 HTML을 받은 뒤에도 JavaScript로 버튼 클릭이나 화면 전환을 처리할 수 있습니다. 첫 페이지는 서버에서 렌더링하고, 이후 페이지 이동과 데이터 요청은 브라우저에서 처리하는 구성도 가능합니다. SSR을 쓴다고 앱의 모든 처리가 서버에서 끝나는 것은 아닙니다.
CSR과 비교할 때 볼 성능 지표
| 구분 | CSR 중심 구성 | SSR 구성 |
|---|---|---|
| 초기 응답 | 앱의 기본 틀 중심일 수 있음 | 서버에서 생성한 콘텐츠 HTML 포함 |
| 콘텐츠를 표시하는 과정 | JavaScript가 HTML 요소와 내용을 생성 | 서버에서 받은 콘텐츠 HTML을 브라우저가 해석 |
| FCP에 영향을 주는 작업 | 스크립트 다운로드, 실행, 데이터 요청 | 서버 응답과 HTML, 스타일 등 자원 처리 |
| TTFB에 영향을 주는 작업 | 서버 처리와 네트워크, 캐시 등 | 서버의 데이터 조회와 렌더링 비용이 추가될 수 있음 |
SSR에서는 브라우저가 본문을 만들기 위해 스크립트를 내려받고 데이터를 요청하는 시간을 줄일 수 있어 첫 콘텐츠 표시(FCP)가 빨라질 수 있습니다. 반면 서버의 데이터 조회나 HTML 생성에 시간이 걸리면 첫 바이트를 받기까지의 시간(TTFB)이 길어집니다. 서버에서 기다리는 시간이 늘어 초기 콘텐츠 표시의 이점이 줄어들 수도 있습니다.
생성한 HTML을 캐시하면 재요청에 저장한 응답을 보내 서버의 반복 작업을 줄일 수 있습니다. 다만 화면을 빨리 표시해도 브라우저에 무거운 JavaScript 작업이 남으면 버튼이나 입력창의 반응은 늦을 수 있습니다. 초기 표시 속도와 사용자의 조작에 반응하는 속도는 따로 측정해야 합니다.
정적 생성, 하이드레이션과의 관계
정적 생성(SSG)은 일반적으로 빌드할 때 페이지의 HTML을 미리 만듭니다. 사용자가 요청하면 만들어 둔 파일을 보내므로 요청마다 HTML을 생성할 필요가 없습니다. 파일 전송과 캐시 운영에는 여전히 자원이 들지만, 요청 시점의 렌더링 부담은 줄일 수 있습니다.
하이드레이션은 서버에서 생성한 HTML에 브라우저의 JavaScript가 앱의 상태와 이벤트 처리를 연결하는 과정입니다. SSR이나 SSG와 함께 적용할 수 있습니다. HTML로 버튼이 먼저 보여도 클릭을 처리할 코드가 아직 연결되지 않았다면 바로 반응하지 않을 수 있습니다.
검색엔진이 초기 HTML을 읽을 수 있을 때의 이점
Google은 JavaScript를 실행해 CSR 페이지의 콘텐츠를 읽을 수 있습니다. 그래도 본문과 링크가 초기 HTML에 있으면 이를 읽기 위해 JavaScript 실행을 기다릴 필요가 줄어듭니다. Google은 JavaScript를 실행하지 못하는 크롤러도 있다는 점을 들어 서버 렌더링이나 사전 렌더링을 권장합니다. 네이버 역시 주요 본문을 서버에서 렌더링해 제공하도록 안내합니다.
크롤러에게만 서버에서 렌더링한 버전을 보내는 다이내믹 렌더링은 다른 방식입니다. Google은 구현이 복잡하고 추가 자원이 드는 임시 대응책으로 보며, 서버 렌더링이나 정적 렌더링 등의 대안을 권장합니다. 사용자와 크롤러에게 유사한 내용을 제공한다면 다이내믹 렌더링 자체를 클로킹으로 보지 않습니다. 서로 전혀 다른 내용을 제공하면 클로킹에 해당할 수 있습니다.
AI 크롤러 조사에서 확인된 범위
Vercel과 MERJ는 2024년 12월 공개한 조사에서 nextjs.org와 Vercel 네트워크의 트래픽을 수개월 관찰했습니다. 서로 다른 기술로 만든 두 채용 사이트에서도 동작을 대조했습니다. 이 표본에서 GPTBot, ClaudeBot, PerplexityBot 등은 JavaScript를 렌더링하지 않았다고 보고했습니다.
보고서가 ChatGPT와 Claude 크롤러로 분류한 요청 중 JavaScript 파일 요청의 비율은 각각 11.5%, 23.84%였습니다. 이는 파일을 가져간 요청의 비중이며, JavaScript를 실행한 페이지의 비율이 아닙니다. 파일 요청 기록만으로 코드를 실행해 콘텐츠까지 읽었다고 판단할 수는 없습니다.
이 결과는 2024년 조사에서 관찰한 동작으로, 현재 모든 AI 서비스에 그대로 적용할 수는 없습니다. 여러 검색엔진과 AI 크롤러가 읽어야 하는 공개 페이지라면 핵심 제목, 본문, 링크를 SSR이나 SSG로 초기 HTML에 넣어 브라우저의 JavaScript 실행에만 의존하지 않도록 구성할 수 있습니다.
실제 페이지를 점검하는 방법
브라우저의 페이지 소스나 초기 HTTP 응답에 제목, 본문, 링크가 들어 있는지 봅니다. 스크립트 안의 데이터로만 들어 있고 본문 HTML 요소에는 없다면, 화면의 본문은 여전히 클라이언트 렌더링에 의존할 수 있습니다. 반대로 초기 HTML에 본문이 있다고 SSR인지 SSG인지까지 알 수 있는 것은 아닙니다. HTML을 만드는 시점은 서버 설정과 배포 방식을 확인해야 합니다.
TTFB가 길다면 서버의 데이터 조회와 렌더링에 걸린 시간, 네트워크 지연, 캐시 적중 여부를 나눠 살펴봅니다. 페이지를 한 번 열어 본 결과만으로는 캐시가 없을 때의 지연을 놓칠 수 있습니다. 초기 HTML, JavaScript 실행 후의 DOM, 검색엔진이 렌더링한 결과를 대조하는 작업은 JavaScript SEO에 해당합니다.
자주 묻는 질문
WordPress도 SSR인가요?
일반적인 WordPress 사이트도 서버에서 HTML을 만들어 보냅니다. React나 Vue 앱의 SSR과 같은 용어로 부를 수 있지만, 전통적인 WordPress 테마와 JavaScript 앱은 이후 화면을 처리하는 방식이 다를 수 있습니다. 페이지 캐시를 쓰면 WordPress도 매 요청마다 HTML을 새로 만들지 않고 저장한 응답을 보낼 수 있습니다.
SSR을 쓰면 검색순위가 오르나요?
SSR을 적용했다는 이유만으로 순위가 오르지는 않습니다. 본문을 읽지 못하던 크롤러가 내용을 수집할 수 있게 만드는 데는 도움이 될 수 있습니다. 이미 본문을 정상적으로 읽고 있었다면 렌더링 방식만 바꾼 효과는 다를 수 있으며, 검색어와 콘텐츠의 관련성이나 품질 문제는 별도로 해결해야 합니다.
CSR 사이트는 전부 바꿔야 하나요?
아니요. 먼저 검색 대상인 공개 페이지의 본문과 링크가 크롤러에게 보이는지 점검합니다. CSR로도 정상적으로 읽힌다면 전면 교체를 서두를 이유는 없습니다. 특정 크롤러가 본문을 읽지 못한다면 해당 공개 페이지에 SSR이나 SSG를 적용하는 방법을 검토할 수 있습니다.
함께 알아두면 좋은 용어
- JavaScript SEO: 렌더링을 포함해 JavaScript 페이지 전반의 검색 노출을 점검하고 고치는 작업
- 크롤링: 검색로봇이 URL과 자원을 가져오는 과정
- AI 크롤러: AI 모델 학습과 검색, 실시간 응답을 위해 웹페이지에 접근하는 봇
- 페이지 속도: 서버 응답과 렌더링을 포함해 페이지가 보이고 반응하기까지의 전반적인 성능
- 클로킹: 검색엔진이나 사용자를 속일 목적으로 서로 다른 콘텐츠를 보여 주는 행위
- CDN: 여러 지역의 서버에서 콘텐츠를 전달해 지연과 원본 서버의 부하를 줄이는 네트워크