Core Web Vitals 통과를 위한 최적의 Cloudflare 설정

Cloudflare로 Core Web Vitals 최적화하기: 활성화할 설정과 피해야 할 설정

Cloudflare에는 Core Web Vitals에 긍정적이거나 부정적인 영향을 미치는 다양한 설정이 있습니다. 성능을 개선하는 설정이 있는 반면, 지연을 유발하거나 페이지 렌더링을 방해하는 설정도 있습니다. 가장 자주 쓰이는 Cloudflare 옵션들을 살펴보고, 각 설정을 어떤 조건에서 활성화해야 하는지 정리해 보겠습니다.

최종 검토: Arjen Karel (2026년 2월)

자주 묻는 Cloudflare 설정 질문: 고객사의 Cloudflare 설정을 자주 검토합니다. Cloudflare 같은 CDN 설정에 대해서는 책 한 권을 쓸 수도 있지만, 질문은 대부분 '이 설정을 켜야 할까요?'라는 단순한 내용입니다. 이 글에서는 Core Web Vitals와 관련된 가장 핵심적인 Cloudflare 설정을 살펴보고, 각 설정을 판단하는 데 필요한 고려 사항과 답을 제시합니다.

Free vs. Pro: 업그레이드할 가치가 있을까요?

Speed > Optimization

Polish

Polish는 Cloudflare 도메인에서 호스팅하는 이미지를 압축하고 메타데이터를 제거하며, 선택에 따라 WebP로 변환하여 최적화합니다. 이미지 최적화에 대한 전체 가이드는 Core Web Vitals를 위한 이미지 최적화를 참고하세요.

이미지 크기가 줄어들면 이미지 리소스 로드 시간이 단축되어 대개 Largest Contentful Paint가 개선됩니다. 하지만 LCP는 이미지 리소스 로드 시간 외에도 여러 요인의 영향을 받으므로 극적인 개선을 기대하기는 어렵습니다.

권장 사항: 활성화하고 최상의 결과를 위해 'Lossy WebP'를 선택하세요. Polish는 AVIF 변환을 지원하지 않는다는 점에 유의해야 합니다. AVIF가 필요하다면 별도의 유료 서비스인 Cloudflare Image Resizing을 사용해야 합니다.

Mirage (지원 중단)

Mirage는 2025년 9월 15일 Cloudflare에서 지원을 중단했으며 모든 도메인에서 자동 비활성화되었습니다. 최신 브라우저는 loading="lazy" 속성을 통해 lazy loading을 자체 지원하므로, Mirage의 JavaScript 기반 접근 방식은 더 이상 필요하지 않습니다.

Mirage는 네트워크 상태에 맞춰 이미지를 최적화하던 기능이었습니다. 하지만 그 구현 방식은 '설계부터 느린(slow by design)' 구조였습니다. 네트워크 속도가 측정될 때까지 이미지를 차단했기 때문입니다. 이러한 차단은 Layout Shift를 유발할 수 있었고, 아이러니하게도 Largest Contentful Paint를 오히려 더 느리게 만들었습니다.

권장 사항: 더 이상 존재하지 않는 설정입니다. 예전 가이드에서 보더라도 무시하세요.

Speed Brain

Speed Brain은 향후 내비게이션을 프리페치하여 Time to First Byte를 단축하는 데 Speculation Rules API를 활용합니다. Speculation Rules는 Largest Contentful Paint를 비롯한 모든 Core Web Vitals를 개선하는 데 대단히 효과적입니다. Speed Brain은 무료 플랜을 포함한 모든 요금제에서 사용할 수 있으며, 현재는 사용자가 링크를 클릭하기 직전에만 프리페치하는 conservative eagerness 단계를 사용합니다.

Speed Brain에만 의존하는 것은 권장하지 않습니다. speculation rules를 직접 구성하는 방법이 간단할 뿐만 아니라, Cloudflare의 획일적인 방식보다 훨씬 효과적이기 때문입니다. 직접 구성하면 원하는 eagerness 단계를 선택하고, 특정 URL을 지정할 수 있으며, 단순 프리페치를 넘어 사전 렌더링(prerendering)까지 활용할 수 있습니다.

권장 사항: 비활성화하고 speculation rules를 직접 구성하세요. 직접 구성하지 않을 생각이라면, speculation rules를 아예 쓰지 않는 것보다는 Speed Brain을 켜두는 편이 낫습니다.

Cloudflare Fonts

Cloudflare Fonts는 폰트 자체 호스팅(self-hosting)을 자동화합니다. 중요한 리소스를 직접 호스팅하면 외부 신규 연결을 제거할 수 있어 매우 유용합니다. 외부 연결은 Cloudflare 프록시를 통해 이미 열려 있는 연결을 재사용하는 것보다 기본적으로 느리기 때문입니다.

15분만 투자해 폰트 파일을 직접 호스팅하도록 설정하는 편이 훨씬 효과적입니다. 하지만 이를 지원하지 않는 CMS도 많습니다. 그런 환경이라면 Cloudflare Fonts를 활성화하는 것도 충분히 좋은 대안입니다. 다만 Cloudflare Fonts는 (2023년부터) 여전히 베타 상태이며, APO가 활성화되어 있으면 작동하지 않는다는 점에 유의하세요.

권장 사항: 기본적으로 비활성화하세요. 직접 자체 호스팅할 수 없는 경우에만 활성화하세요.

Early Hints

Early Hints는 실제 HTML 콘텐츠가 브라우저에 전송되기 전에 미리 힌트를 제공하여 핵심 리소스(스타일, 폰트, 이미지 등)의 전달 속도를 높입니다. Cloudflare를 통해 리소스 힌트(resource hint)를 전송하려면, Cloudflare가 원본 응답 헤더를 읽어 그곳에서 리소스 힌트를 추출해야 합니다.

HTTP 응답 헤더로 리소스 힌트를 능숙하게 전송할 수 있다면 이 기능을 활성화하는 것을 강력히 추천합니다. 하지만 헤더에 포함된 리소스 힌트는 페이지의 <head>에 있는 리소스 힌트보다 개발팀 눈에 훨씬 덜 띌 수 있다는 점을 알아두어야 합니다. 잘못 설정하면 속도가 빨라지기는커녕 오히려 느려질 수 있으므로 주의해서 사용하세요. 2025 Web Almanac에 따르면, 출시된 지 수년이 지났음에도 Early Hints 도입률은 여전히 3% 미만입니다.

권장 사항: 리소스 힌트 헤더를 올바르게 전송하고 있을 때만 활성화하세요.

Auto Minify

Cloudflare는 HTML, CSS, JavaScript를 실시간으로 경량화(minify)할 수 있습니다. HTML 경량화는 공백과 주석을 제거하여 전송 크기를 약간 줄여줍니다. CSS와 JavaScript 경량화도 해당 파일에 대해 동일하게 작동합니다.

권장 사항: HTML 경량화는 활성화하세요. CSS와 JavaScript의 경우, 배포 과정에서 빌드 타임에 경량화하는 것이 Cloudflare의 실시간 방식보다 더 나은 결과를 냅니다. 별도의 빌드 과정이 없다면 세 가지 모두 활성화해도 무방합니다.

Rocket Loader

Rocket Loader는 스크립트를 일시적으로 보류한 뒤 잠시 후 페이지에 주입하는 방식으로 웹페이지의 모든 JavaScript를 '지연(defer)'시킵니다. 보는 시각에 따라 영리해 보일 수도, 고약해 보일 수도 있는 트릭입니다. 모든 브라우저에서 제대로 작동하도록 보장하려면 수많은 검사와 편법(hack)이 필요하기 때문입니다. 또한 핵심 리소스의 로딩 속도를 높이도록 설계된 프리로드 스캐너(preload scanner)로부터 스크립트를 숨겨버리기도 합니다.

위와 같은 이유로 Rocket Loader를 무작정 활성화하는 것은 전혀 권장하지 않습니다. 스크립트는 중요도에 따라 실행 일정이 정해져야 합니다. 핵심 스크립트는 일찍 로드되어 실행되어야 하고, 필수적이지 않은 스크립트는 브라우저가 유휴 상태(idle)가 될 때까지 기다릴 수 있어야 합니다.

Cloudflare의 Rocket Loader는 그렇게 작동하지 않습니다. 모든 스크립트를 보류했다가 특정 시점에 중요도와 무관하게 한꺼번에 주입합니다. Rocket Loader는 LCP 요소, 폰트, 스타일 등 다른 리소스를 스크립트보다 먼저 처리할 뿐입니다. 게다가 Rocket Loader는 브라우저의 Back-Forward Cache(bfcache) 작동을 가로막는 지원 중단 API인 unload 이벤트 핸들러를 사용합니다. 이로 인해 뒤로 가기나 앞으로 가기를 할 때 즉각 복원되지 않고 전체 페이지를 다시 로드하게 됩니다.

사용 중인 CMS에서 스크립트 지연이나 세밀한 스크립트 타이밍 조절을 지원하지 않는다면 Rocket Loader가 최선의 선택일 수 있습니다. 하지만 대부분의 사이트에서는 스크립트 실행 일정을 직접 제어하는 것이 훨씬 더 효과적입니다.

권장 사항: 비활성화하고 스크립트 실행을 직접 제어하세요. 스크립트 실행을 지연하거나 제어할 다른 방법이 전혀 없을 때만 활성화하세요.

Automatic Platform Optimization for WordPress

Cloudflare의 APO는 전체 페이지를 엣지 서버에 캐싱하며, 이를 전체 페이지 엣지 캐싱(full-page edge caching)이라고 부릅니다. 올바르게 구현하면 특정 방문자층의 Time to First Byte(그리고 이에 따른 LCP 및 FCP)를 개선해 줍니다!

하지만 맹점이 있습니다. 전체 페이지 엣지 캐싱은 자동으로 우회(bypass)되어야 하는 경우가 많습니다. 예를 들어 사용자가 로그인하거나 장바구니에 상품을 담으면 페이지 콘텐츠가 개인화되므로 APO가 자동 비활성화됩니다. 그 시점부터는 일반적인 캐시 페이지를 제공할 수 없기 때문입니다. APO는 모든 유형의 웹사이트를 수용해야 하므로, 개별 사이트에 실제로 필요한 수준보다 훨씬 자주 캐시를 우회합니다. 그렇기 때문에 수동으로 캐시를 구성하는 편이 Cloudflare의 APO보다 거의 항상 더 효과적입니다.

권장 사항: APO를 활성화하거나, 더 좋은 방법으로 전체 페이지 엣지 캐싱 규칙을 직접 구성하여 캐시 우회 시점을 더 정밀하게 제어하세요.

HTTP/2, HTTP/2 to Origin 및 Enhanced HTTP/2 Prioritization

HTTP/2, HTTP/2 to Origin, Enhanced HTTP/2 Prioritization을 활성화하는 것은 고민할 필요도 없는 당연한 선택입니다. HTTP/2는 구형 HTTP/1.1 프로토콜에 비해 크게 향상되었습니다. 여러 개선점이 있지만, 가장 중요한 점은 단일 연결을 통해 여러 파일을 병렬로 전송하여 과거의 계단식 로딩 현상(staircase effect)을 없앴다는 것입니다. HTTP/2가 도입된 지 10년이 흘렀으며 현재 브라우저와 서버 전반에서 폭넓게 지원됩니다!

권장 사항: 세 가지 모두 활성화하세요.

HTTP/3 (with QUIC)

QUIC을 지원하는 HTTP/3는 연결 설정과 지연 시간(latency)이 개선되어 HTTP/2보다 훨씬 더 빠릅니다. HTTP/3는 한 스트림이 지연되더라도 여러 스트림을 독립적으로 전송할 수 있습니다. QUIC은 전송 핸드셰이크와 암호화 핸드셰이크를 결합하여 연결 시간을 단축합니다. 그 결과 TTFB가 최대 10% 단축됩니다! 2025 Web Almanac에 따르면 웹사이트의 38%가 현재 HTTP/3를 지원합니다.

권장 사항: 활성화하세요.

Brotli Compression

Brotli는 Gzip보다 파일 크기를 더 작게 만들어주는 압축 알고리즘입니다. Cloudflare는 모든 요금제에서 Brotli를 기본적으로 활성화합니다. 계속 활성화되어 있는지 확인하세요. 2025 Web Almanac에 따르면 CDN을 거치는 요청의 46%가 현재 Brotli 압축을 사용하고 있습니다.

권장 사항: 활성화 상태를 유지하세요(기본적으로 켜져 있습니다).

0-RTT Connection Resumption

0-RTT Connection Resumption은 사용자가 사이트를 다시 방문할 때 초기 핸드셰이크를 건너뛰어 보안 연결 속도를 높입니다. 이전에 저장된 암호화 키를 활용해 데이터를 즉시 전송할 수 있으므로, 지연 시간을 줄이고 페이지 로드 시간을 단축합니다.

권장 사항: 활성화하세요.

Automatic Signed Exchanges (지원 중단)

Signed Exchanges(SXG)는 사용자 개인정보를 보호하면서 Google 검색이 콘텐츠를 프리페치할 수 있도록 지원하던 기능이었습니다. SXG는 Google 검색 결과에서 유입되는 방문자의 LCP를 약 450ms 개선할 수 있었습니다.

하지만 Cloudflare는 2025년 10월 SXG 지원을 중단했습니다. 해당 기능은 제거되어 더 이상 사용할 수 없습니다. 활성화해 두었더라도 자동으로 비활성화되었습니다. 프리페치 관점에서는 Speed Brain(Speculation Rules)이 가장 근접한 대안이지만, 기존 SXG처럼 Google 검색을 통한 교차 출처(cross-origin) 프리페치는 불가능하며 동일 사이트(same-site) 내비게이션에서만 작동합니다.

권장 사항: 더 이상 존재하지 않는 설정입니다.

Scrape Shield

Scrape Shield는 웹사이트의 콘텐츠를 보호하는 기능입니다. 언뜻 좋은 아이디어처럼 보일 수 있지만, 저는 Scrape Shield의 어떤 옵션도 켜는 것에 단호히 반대합니다. Scrape Shield는 이전에 난독화해 둔 콘텐츠를 복호화하기 위해 페이지에 JavaScript를 주입하는 방식으로 작동합니다. 콘텐츠 숨김을 위해 속도를 희생하는 이런 맞바꿈은 전혀 타당하지 않습니다. 실제 스패머는 여기에 속지 않는 반면, 실제 사용자는 페이지를 느려지게 만드는 추가 스크립트만 떠안게 됩니다.

권장 사항: Email Address Obfuscation을 비활성화하고 Hotlink Protection도 비활성화하세요.

Bot Fight Mode and Super Bot Fight Mode

Core Web Vitals에 가장 치명적인 단 하나의 Cloudflare 설정을 꼽자면 바로 이것입니다. Bot Fight Mode를 활성화하면 모든 페이지에 invisible.js라는 스크립트가 주입됩니다. 이 스크립트는 브라우저 챌린지를 실행하며, 페이지가 로드될 때마다 2,000밀리초 이상의 CPU 실행 시간을 가중시킵니다. 페이지와 상호작용하기 전에 main thread가 2초 동안이나 차단되는 셈입니다.

실제로 Bot Fight Mode를 활성화하면 PageSpeed 점수가 20점 이상 떨어질 수 있습니다. Super Bot Fight Mode 역시 같은 문제를 안고 있습니다. 봇을 막기 위해 고안된 기능이 정작 사이트를 방문하는 모든 실제 사용자에게 페널티를 주는 아이러니가 발생합니다.

권장 사항: Bot Fight Mode와 Super Bot Fight Mode를 둘 다 비활성화하세요. 봇 차단이 필요하다면 클라이언트 측 JavaScript를 주입하지 않는 Cloudflare의 WAF 규칙이나 rate limiting을 대신 사용하세요.

Caching > Configuration

Purge Cache

캐시를 삭제(Purge Cache)하면 스타일시트, JavaScript, 이미지는 물론 전체 페이지 캐시까지 Cloudflare가 캐싱한 모든 파일이 무효화됩니다. 엄밀히 말해 캐시 삭제가 '설정'은 아니지만, 캐시 비우기에 대한 경고는 반드시 짚고 넘어가야 합니다. 캐시가 다시 생성될 때까지 사이트가 느려지기 때문입니다!

권장 사항: 가능한 한 전체 캐시 삭제는 피하세요. 변경된 파일만 선별하여 삭제하세요!

Caching Level

Caching Level은 Cloudflare가 쿼리 문자열을 처리하는 방식을 결정합니다. 꼼꼼히 살펴봐야 할 설정입니다.

가장 '빠른' 옵션은 'Ignore query string'입니다. 쿼리 문자열과 상관없이 동일한 리소스를 제공합니다. 사이트에서 쿼리 문자열을 전혀 사용하지 않는다고 100% 확신할 때만 적합한 선택지입니다. 이 경우 타인이 덧붙인 쿼리 문자열은 무시됩니다.

'Standard'는 서로 다른 쿼리 문자열마다 다른 캐시 파일을 제공합니다. Cloudflare의 기본 설정이지만, 전체 페이지 엣지 캐싱 및 utm 파라미터 같은 추적 파라미터와 결합될 경우 캐시 불일치와 캐시 히트율 저하를 유발할 수 있습니다! 이를 해결하려면 Cloudflare Workers로 추적 파라미터를 제거하는 방법을 고려해 보세요.

권장 사항: 가능하면 'Ignore query string'을 사용하고, 그렇지 않다면 'Standard'를 쓰세요. 'No query string' 옵션은 피해야 합니다.

Browser Cache TTL

Browser Cache TTL은 브라우저에 정적 리소스를 얼마 동안 캐싱할 수 있는지를 지정합니다. 캐시된 리소스는 브라우저에서 직접 제공되므로 원격 네트워크 리소스보다 훨씬 빠르게 사용할 수 있습니다. 즉 Browser Cache TTL이 짧으면 브라우저 캐시가 빈번하게 무효화되어 캐시 히트율이 떨어집니다. 따라서 정적 파일이 자주 변경되지 않는다면 이 설정을 최댓값으로 지정하세요.

권장 사항: 가능하면 1년으로 설정하세요.

Development Mode

Development Mode가 활성화되어 있는 동안에는 Cloudflare의 모든 캐시가 우회됩니다. 개발 중에는 이 모드를 켜고 싶을 수 있습니다. 하지만 Development Mode는 켜지 마세요. 다른 모든 방문자의 캐시까지 함께 비활성화되기 때문입니다. 개발을 진행할 별도의 개발용 도메인을 구축하거나, 캐시 규칙을 설정하여 본인의 접속만 Cloudflare 캐시에서 제외하세요.

권장 사항: 활성화하지 마세요!

Caching > Tiered Cache

Tiered Cache는 캐시되지 않은 파일을 찾을 때 Cloudflare 자체 서버망을 먼저 조회하도록 하여, 원본 서버(origin server)로 향하는 요청 수를 줄이고 캐시 히트율을 높입니다. 이는 백엔드 서버의 부하를 한층 더 줄이고 추가 리소스를 확보해 줍니다.

권장 사항: Smart Tiered Caching Topology를 활성화하세요.

CoreDash가 모니터링하는 사이트 전체를 보면, CDN을 올바르게 구성한 사이트는 CDN을 쓰지 않는 사이트에 비해 p75 기준 TTFB가 55% 더 빠릅니다. HTTP/3, Brotli, Tiered Cache의 조합은 필드에서도 측정 가능한 분명한 차이를 만들어냅니다. Real User Monitoring을 활용하여 Cloudflare 설정이 실제 사용자에게 제대로 효과를 내고 있는지 직접 검증해 보세요.