저관여웹 정적 생성과 HTML 캐시 기준
저관여웹의 기술 설계에서는 초기 HTML에 담긴 본문과 CDN의 HTML 캐시를 함께 확인해야 합니다. TTFB 0.8초는 성능 개선의 참고값이며, 캐시 적용 범위와 수정 후 갱신도 설계 대상입니다.
초기 HTML에 핵심 본문을 담으면 JavaScript 실행에 대한 의존을 줄일 수 있습니다.
Google은 JavaScript를 실행하므로 React 사용만으로 검색 수집 실패를 판단할 수 없습니다.
TTFB 0.8초 이하는 성능 개선의 참고값이며 페이지 전체 로딩 시간을 뜻하지 않습니다.
Cloudflare CDN은 기본적으로 HTML을 캐시하지 않으므로 공개 페이지의 캐시 규칙을 확인해야 합니다.
HTML 캐시에는 로그인 페이지 제외와 콘텐츠 수정 후 갱신 정책이 필요합니다.
저관여웹의 검색 수집을 돕으려면 초기 HTML에 핵심 본문을 담아야 합니다. 공개 콘텐츠에는 정적 생성과 CDN의 HTML 캐시가 유용합니다. 다만 TTFB 0.8초 달성만으로 검색 노출을 보장할 수는 없습니다.
TTFB 수치의 근거는 2025년 11월 18일 갱신된 web.dev 문서입니다.
저관여웹에서 먼저 확인할 기술 조건
이 글에서 저관여웹은 필요한 정보를 짧게 확인하는 웹사이트를 뜻합니다. 렌더링과 전송 속도는 이런 사이트의 기술 점검 항목입니다. 다만 두 항목만으로 검색 노출의 차이를 모두 설명할 수는 없습니다.
검색 수집은 로봇이 페이지를 가져오는 과정입니다. 색인 생성은 가져온 내용을 검색 대상으로 처리하는 과정입니다. Google은 수집된 모든 페이지가 색인에 포함되지는 않는다고 설명합니다. Google 크롤링 예산 안내
점검 항목 | 확인할 내용 | 해결하려는 문제
초기 HTML | 제목과 핵심 본문이 응답에 포함되는지 | 본문을 읽기 위한 추가 실행 의존
렌더링 | JavaScript 실행 후 내용이 정상적으로 나타나는지 | 실행 오류나 차단으로 인한 누락
TTFB | 첫 응답이 도착하기까지 걸리는 시간 | 연결과 서버 응답의 지연
HTML 캐시 | 공개 문서를 CDN에서 재사용하는지 | 원본 서버까지 반복해서 요청하는 비용
색인 상태 | Google이 해당 URL을 어떻게 처리했는지 | 수집 성공과 검색 등록을 혼동하는 문제
React 페이지가 빈 HTML로 보이는 이유
React 페이지의 초기 HTML은 구현 방식에 따라 달라집니다. 브라우저에서 본문을 만드는 방식은 CSR이라고 부릅니다. 이 방식에서는 첫 응답에 본문 없이 실행용 코드만 담길 수 있습니다.
Google은 Chromium을 이용해 JavaScript를 실행합니다. 페이지는 수집 이후 렌더링을 기다릴 수 있습니다. 차단된 페이지나 파일은 렌더링 대상에서 제외될 수 있습니다. 모든 로봇이 JavaScript를 실행하는 것도 아닙니다. Google JavaScript SEO 기본 안내
따라서 화면이 정상이라는 사실만으로 수집 상태를 판단하지 마세요. 초기 응답에 본문이 있는지부터 확인하세요. Google이 렌더링한 결과는 Search Console의 URL 검사로 확인할 수 있습니다.
정적 생성과 서버 렌더링 비교
공개 본문의 갱신 방식에 따라 HTML 생성 방법을 선택할 수 있습니다. 정적 생성은 요청 전에 HTML을 만드는 방식입니다. 서버 렌더링은 요청을 받았을 때 서버에서 HTML을 만듭니다. React에서도 이런 방식을 사용할 수 있습니다. web.dev 렌더링 방식 안내
방식 | HTML을 만드는 시점 | 검토하기 좋은 상황 | 운영상 확인할 점
클라이언트 렌더링 CSR | 브라우저에서 JavaScript를 실행할 때 | 사용자 조작이 많은 화면 | 본문 표시까지 필요한 실행과 요청
정적 생성 SSG | 빌드나 콘텐츠 생성 시점 | 방문자에게 같은 내용을 보여주는 공개 문서 | 수정 후 재생성과 배포
서버 렌더링 SSR | 페이지 요청을 처리할 때 | 요청마다 최신 내용을 구성하는 화면 | 데이터 조회와 HTML 생성 시간
사전 렌더링 | 배포 전에 앱을 실행해 HTML을 확보할 때 | 기존 앱의 초기 본문을 미리 제공할 때 | 이후 기능에 필요한 JavaScript
정적 생성과 CDN은 서로 다른 역할을 합니다. 정적 생성은 HTML을 만드는 시점에 관한 선택입니다. CDN은 콘텐츠를 전달하고 재사용하는 구조입니다. 서버에서 만든 HTML도 조건에 맞으면 CDN에 캐시할 수 있습니다.
TTFB 0.8초는 무엇을 뜻하나요?
TTFB는 페이지 이동 시작부터 첫 응답 바이트까지의 시간입니다. web.dev는 대부분의 사이트에 0.8초 이하를 대략적인 목표로 제시합니다. 이는 페이지 전체가 표시되는 시간과 다릅니다. TTFB 자체는 Core Web Vitals 항목도 아닙니다. web.dev TTFB 설명
TTFB에는 서버 내부 처리 외의 지연도 포함됩니다. DNS 조회는 도메인의 접속 주소를 찾는 과정입니다. TCP와 TLS 연결에도 시간이 걸릴 수 있습니다. 주소를 다른 곳으로 보내는 리디렉션도 영향을 줍니다.
· DNS 조회와 연결 준비 시간
· 네트워크를 통한 요청과 응답의 이동 시간
· 원본 서버의 데이터 조회와 HTML 생성 시간
· 첫 응답 전까지 발생하는 리디렉션 시간
서버가 서울에 있다는 사실만으로 0.8초 초과를 단정할 수는 없습니다. 접속 위치와 연결 재사용 여부에 따라 결과가 달라집니다. Google의 크롤러는 주로 미국 IP 주소를 사용합니다. 다만 다른 국가의 IP 주소에서도 접속할 수 있습니다. Google 크롤러 기술 특성
지속적인 응답 지연은 Google의 수집 용량에 영향을 줍니다. 서버 오류도 수집량 감소의 원인이 됩니다. 그렇다고 0.8초를 한 번 넘으면 수집이 중단되는 규칙은 아닙니다. 수집 수요에는 페이지 품질과 갱신 빈도도 관여합니다. Google 크롤링 예산 안내
CDN에서 HTML 캐시를 확인해야 하는 이유
Cloudflare CDN은 기본적으로 HTML을 캐시하지 않습니다. 이미지나 CSS가 캐시되어도 본문 문서는 별도로 확인해야 합니다. 다른 CDN의 기본 동작은 해당 서비스 문서에서 확인하세요.
The Cloudflare CDN does not cache HTML or JSON by default. Cloudflare, Default cache behavior
이 문장은 HTML과 JSON이 기본 캐시 대상이 아니라는 뜻입니다. 공개 HTML은 Cache Rules로 캐시 대상에 포함할 수 있습니다. 실제 저장 여부에는 응답 헤더와 쿠키 등의 조건도 작용합니다. Cloudflare 기본 캐시 동작
캐시는 저장해 둔 응답을 다시 사용하는 기능입니다. CDN에 연결했다고 모든 문서가 전 세계에 즉시 복제되지는 않습니다. Cloudflare는 요청을 처리하는 데이터센터에 콘텐츠를 캐시합니다. 캐시에 없는 요청은 원본 서버 조회가 필요할 수 있습니다. Cloudflare 캐시 시작 안내
공개 HTML에 캐시 규칙을 적용할 때는 개인화 페이지를 제외하세요. Cloudflare는 동적 HTML 캐시로 다른 사람의 정보가 전달될 수 있다고 경고합니다. 로그인이나 계정 페이지는 캐시하지 마세요. Cloudflare Cache Everything 주의사항
페이지 조건별 캐시 적용 기준
방문자에게 같은 내용을 보여주는지가 캐시 범위의 출발점입니다. 공개 설명문은 공동으로 재사용하기 좋은 대상입니다. 로그인 상태에 따라 내용이 달라지는 응답은 별도로 처리해야 합니다.
페이지 조건 | 검토할 구성 | 함께 확인할 사항
방문자에게 동일한 설명문 제공 | 정적 생성과 공개 HTML 캐시 | 수정 후 재생성·캐시 갱신
공개 본문에 자주 바뀌는 수치 포함 | 본문과 변동 데이터의 갱신 방식 분리 | 수치의 기준 시점과 실패 시 표시
요청 시점의 최신 공개 정보 필요 | 서버 렌더링과 조건부 캐시 검토 | 허용 가능한 정보 지연
로그인·계정·결제 화면 | 공용 HTML 캐시에서 제외 | 인증 쿠키와 사용자별 응답
언어별 공개 문서 제공 | 언어별 URL과 각 문서의 캐시 | 번역문 연결과 언어별 갱신
실시간 데이터를 나중에 불러오면 정적 본문을 유지하기 쉽습니다. 그러나 검색에 필요한 핵심 내용을 전부 나중으로 미루지는 마세요. 초기 HTML을 제공하는 목적과 충돌할 수 있기 때문입니다.
흔한 실수와 확인 기준
기술 이름이나 설정 화면만으로 결과를 판단하면 오류를 놓치기 쉽습니다. 실제 HTML과 응답 헤더를 함께 확인하세요. 다음은 서로 구분해야 할 상태입니다.
흔한 판단 | 확인해야 할 기준
React 사이트는 검색 로봇이 읽지 못함 | 초기 HTML과 Google의 렌더링 결과
TTFB 0.8초면 화면도 모두 표시됨 | 첫 응답 이후 본문 표시까지 걸리는 시간
CDN을 연결했으니 HTML도 캐시됨 | HTML 요청의 캐시 상태
정적 파일이면 항상 최신 내용임 | 마지막 생성 시점과 배포된 내용
빠르게 응답하면 검색 등록도 완료됨 | Search Console의 색인 처리 상태
캐시 적중 결과 하나로 글로벌 속도를 판단함 | 접속 지역과 캐시 적중 여부별 측정 결과
Cloudflare의 CF-Cache-Status는 캐시 상태를 보여주는 헤더입니다. HIT는 캐시에서 응답을 찾았다는 뜻입니다. MISS는 요청 당시 캐시에 없어 원본에서 가져왔다는 뜻입니다. DYNAMIC은 캐시 대상으로 처리되지 않은 상태입니다. Cloudflare 캐시 응답 설명
콘텐츠 수정 후 캐시 갱신
정적 파일과 CDN 캐시는 수정 내용을 반영하는 경로까지 설계해야 합니다. 원본을 고쳐도 이전 캐시가 남으면 옛 내용이 전달됩니다. HTML과 JSON을 함께 발행한다면 두 형식의 내용도 맞춰야 합니다.
다음은 문서와 데이터 파일을 함께 운영할 때의 점검 순서입니다.
· 원문 데이터에서 변경 내용을 확정하세요.
· 같은 변경본으로 HTML과 데이터 파일을 다시 생성하세요.
· 새 파일을 배포한 뒤 변경된 URL의 캐시를 갱신하세요.
· 각 URL을 다시 요청해 수정 내용이 일치하는지 확인하세요.
Cloudflare는 URL별 캐시 삭제를 권장합니다. 캐시 삭제는 저장된 응답을 제거하는 작업입니다. 정적 HTML을 새로 만드는 작업은 별도로 필요합니다. 따라서 파일 생성과 캐시 갱신을 같은 배포 절차에 연결하세요. Cloudflare 캐시 삭제 안내
갱신 간격은 콘텐츠가 허용하는 정보 지연에 맞춰 정하세요. 설명문과 실시간 수치에 같은 주기를 적용할 필요는 없습니다. 짧은 캐시 유효기간만으로 모든 갱신 문제를 해결할 수는 없습니다.
다국어 사이트의 hreflang 기준
hreflang은 같은 콘텐츠의 언어·지역별 주소를 연결하는 정보입니다. 번역문을 만들어 주는 기능은 아닙니다. Google이 방문자에게 적절한 언어 버전을 찾도록 돕습니다.
구현 위치 | 표시 방법 | 선택할 때 확인할 점
HTML | 문서의 head에 대체 언어 링크 표시 | 각 페이지 템플릿에서 관리 가능한지
HTTP 헤더 | 응답의 Link 헤더에 표시 | 서버에서 헤더를 관리 가능한지
사이트맵 | 언어별 URL 관계를 사이트맵에 표시 | 문서 목록을 일괄 관리 가능한지
Google은 이 방법들을 동등하게 취급합니다. 따라서 HTML 안에만 넣어야 하는 것은 아닙니다. 각 언어 문서는 자기 자신을 포함해 대체 언어 문서를 표시해야 합니다. 서로 대응하는 페이지 사이의 연결도 확인하세요. Google 다국어 페이지 안내
배포 결과 확인 순서
배포 후에는 본문 전달과 캐시 동작을 따로 검증하세요. 속도 측정값에는 측정 지역과 캐시 상태를 함께 남기세요. 다음 순서로 확인하면 문제 지점을 구분하기 쉽습니다.
· 브라우저 개발자 도구에서 HTML 문서 응답을 확인하세요. 핵심 본문이 응답에 포함되는지 살펴보세요.
· Search Console의 URL 검사에서 렌더링된 HTML을 확인하세요. 실제 색인 처리 상태도 별도로 점검하세요.
· HTML 응답의 캐시 헤더를 확인하세요. Cloudflare에서는 CF-Cache-Status를 읽으세요.
· 주요 접속 지역에서 같은 문서를 측정하세요. 캐시에 없는 요청과 적중한 요청을 구분하세요.
· 콘텐츠를 수정한 뒤 갱신 결과를 확인하세요. 로그인 페이지가 캐시에서 제외되는지도 점검하세요.
Cloudflare는 과도한 동적 HTML 캐시가 로그인을 깨뜨릴 수 있다고 경고합니다. 로그인 폼과 인증된 페이지는 캐시하지 마세요. 수정 후에는 인증 쿠키가 유지되는지도 확인하세요. Cloudflare 로그인 문제 안내
AI 코딩에 전달할 구현 조건
AI에게는 기술 이름과 함께 검증 가능한 결과를 요청하세요. 초기 HTML의 내용과 캐시 제외 범위를 명시하는 방식이 유용합니다. 아래 문구는 공개 지식 페이지를 만드는 경우의 요청 예시입니다.
공개 지식 페이지의 핵심 본문을 초기 HTML에 포함하세요.
공개 문서는 정적 생성을 우선 검토하세요.
변동 데이터의 갱신 방식을 별도로 설명하세요.
CDN의 HTML 캐시 적용 여부를 확인하세요.
로그인·계정·결제 페이지는 공용 캐시에서 제외하세요.
콘텐츠 수정 시 정적 파일 재생성과 캐시 갱신을 연결하세요.
다국어 페이지가 있으면 hreflang 연결을 구성하세요.
초기 HTML, 캐시 상태, 수정 반영 여부의 확인 방법을 제시하세요.
