Core Web Vitals 통과를 위한 최고의 Cloudflare 구성
최대 페이지 속도를 위해 Cloudflare를 구성하고 활용해야 할 설정 이해하기
Cloudflare로 Core Web Vitals 최적화하기: 활성화해야 할 항목과 피해야 할 항목
Cloudflare는 Core Web Vitals에 긍정적 또는 부정적 영향을 미칠 수 있는 다양한 설정을 제공합니다. 일부 설정은 성능을 향상시키지만 다른 설정은 지연을 유발하거나 페이지 렌더링을 방해합니다. 가장 일반적인 Cloudflare 옵션과 이를 활성화해야 하는 조건을 분석해 보겠습니다!
2026년 2월 Arjen Karel이 마지막으로 검토함
일반적인 Cloudflare 설정 질문: 저는 종종 클라이언트를 위해 Cloudflare 설정을 검토합니다. Cloudflare와 같은 CDN 설정에 대해 책을 쓸 수도 있지만, 대부분의 질문은 단순한 '이 설정을 활성화해야 합니까?'에 집중됩니다. 이 기사는 Core Web Vitals와 관련된 가장 일반적인 Cloudflare 설정에 대한 적절한 고려 사항과 함께 해당 질문에 답합니다.
Free 대 Pro: 업그레이드할 가치가 있습니까?
속도 > 최적화
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" 속성을 통해 기본적으로 지연 로딩을 지원하므로 Mirage의 JavaScript 기반 접근 방식이 필요하지 않습니다.
Mirage는 네트워크 상태에 따라 이미지를 최적화하곤 했습니다. 구현은 '의도적으로 느리게' 설계되었습니다. 네트워크 속도가 측정될 때까지 이미지를 차단했습니다. 이 차단은 Cumulative Layout Shift를 유발할 수 있으며 아이러니하게도 Largest Contentful Paint를 느려지게 할 수 있습니다.
권장 사항: 이 설정은 더 이상 존재하지 않습니다. 오래된 가이드에서 보게 된다면 무시하세요.
Speed Brain
Speed Brain은 Speculation Rules API를 사용하여 향후 탐색을 미리 가져옴으로써 Time to First Byte 속도를 높입니다. Speculation Rules는 Largest Contentful Paint를 포함한 모든 Core Web Vitals를 개선하는 데 매우 효과적입니다. Speed Brain은 모든 요금제(무료 포함)에서 사용할 수 있으며 현재 사용자가 링크를 클릭하려고 할 때만 미리 가져오는 conservative 열성도를 사용합니다.
Speculation Rules를 수동으로 구성하는 것이 쉽고 Cloudflare의 일률적인 접근 방식보다 훨씬 효과적이므로 Speed Brain에 의존하는 것을 권장하지 않습니다. 수동 구성을 사용하면 자체 열성도를 선택하고, 특정 URL을 타겟팅하고, 단순한 prefetching 대신 prerendering을 사용할 수 있습니다.
권장 사항: 비활성화하고 Speculation Rules를 수동으로 구성하세요. 직접 구성하지 않을 경우 Speed Brain을 활성화된 상태로 두는 것이 Speculation Rules가 아예 없는 것보다 낫습니다.
Cloudflare Fonts
Cloudflare Fonts는 폰트 셀프 호스팅을 자동화합니다. 중요한 리소스를 셀프 호스팅하면 기본적으로 Cloudflare 프록시 사이트에 이미 열려 있는 연결을 재사용하는 것보다 느린 새로운 외부 연결이 제거되므로 이는 훌륭한 아이디어입니다.
15분을 투자하여 수동으로 셀프 호스팅 폰트 파일을 구성하는 것이 더 효과적입니다. 불행히도 많은 CMS 시스템은 이를 허용하지 않습니다. 그럴 경우 Cloudflare Fonts를 활성화하는 것은 완벽하게 유효한 옵션입니다. Cloudflare Fonts는 여전히 베타 버전(2023년부터)이며 APO가 활성화되어 있으면 작동하지 않습니다.
권장 사항: 기본적으로 비활성화하고, 수동 셀프 호스팅이 불가능한 경우에만 활성화하세요.
Early Hints
Early Hints는 실제 HTML 콘텐츠가 브라우저로 전송되기 전에 힌트를 제공하여 중요한 리소스(스타일, 폰트 또는 이미지 등) 전달 속도를 높입니다. Cloudflare를 통해 리소스 힌트를 보내기 위해 Cloudflare는 응답 헤더를 읽고 거기서 리소스 힌트를 추출합니다.
HTTP 응답 헤더에 리소스 힌트를 보내는 것이 편하다면 이 기능을 활성화하는 것을 강력히 제안합니다. 그러나 헤더의 리소스 힌트는 페이지의 <head>에 있는 리소스 힌트보다 개발 팀에게 훨씬 더 숨겨져 있을 수 있다는 점에 유의하세요. 잘못 구성되면 속도를 높이는 대신 오히려 느리게 만들 수 있습니다. 따라서 주의해서 사용하십시오. 수년 동안 사용 가능했음에도 불구하고 2025 Web Almanac에 따르면 Early Hints 채택률은 여전히 3% 미만입니다.
권장 사항: 리소스 힌트 헤더를 올바르게 보내는 경우에만 활성화하세요.
Auto Minify
Cloudflare는 HTML, CSS 및 JavaScript를 즉시 축소할 수 있습니다. HTML 축소는 공백과 주석을 제거하여 전송 크기를 약간 줄입니다. CSS 및 JavaScript 축소는 해당 파일 형식에 대해 동일한 작업을 수행합니다.
권장 사항: HTML 축소를 활성화하세요. CSS 및 JavaScript의 경우 배포 프로세스 중의 빌드 타임 축소가 Cloudflare의 즉각적인 접근 방식보다 더 나은 결과를 생성합니다. 빌드 프로세스가 없는 경우 3가지 모두 활성화해도 좋습니다.
Rocket Loader
Rocket Loader는 스크립트를 일시적으로 보류한 다음 잠시 후 페이지에 주입하여 웹 페이지의 모든 JavaScript를 '지연'시킵니다. 이는 모든 브라우저에서 제대로 작동하는지 확인하기 위해 많은 검사와 핵이 필요한 까다로운(또는 관점에 따라 깔끔한) 트릭입니다. 또한 중요한 리소스 로딩 속도를 높이도록 설계된 메커니즘인 프리로드 스캐너에서 스크립트를 숨깁니다.
위의 이유 때문에 저는 맹목적으로 Rocket Loader를 활성화하는 것을 선호하지 않습니다. 스크립트는 중요도에 따라 예약되어야 합니다. 중요한 스크립트는 일찍 로드하고 실행해야 하는 반면, 중요하지 않은 스크립트는 브라우저가 유휴 상태가 될 때까지 기다릴 수 있습니다.
Cloudflare의 Rocket Loader는 그렇게 하지 않습니다. 모든 스크립트를 보류하고 중요도를 고려하지 않은 채 특정 시점에 주입합니다. Rocket Loader는 스크립트보다 LCP 요소, 폰트 및 스타일과 같은 다른 리소스에만 우선순위를 둡니다. 게다가 Rocket Loader는 브라우저의 Back-Forward Cache(bfcache)가 작동하는 것을 방지하는 지원 중단된 API인 unload 이벤트 핸들러를 사용합니다. 즉, 앞뒤로 탐색하면 즉각적인 복원 대신 전체 페이지 새로고침이 트리거됩니다.
CMS가 스크립트 지연이나 더 세밀한 스크립트 타이밍을 허용하지 않는다면 Rocket Loader가 최선의 선택일 수 있습니다. 하지만 대부분의 사이트에서는 수동으로 스크립트를 예약하는 것이 훨씬 더 효과적입니다.
권장 사항: 비활성화하고 스크립트를 수동으로 예약하세요. 스크립트 실행을 지연시키거나 제어할 다른 방법이 없는 경우에만 활성화하세요.
WordPress를 위한 Automatic Platform Optimization
Cloudflare의 APO는 전체 페이지 엣지 캐싱이라고 하는 기술인 엣지 서버에 전체 페이지를 캐시합니다. 올바르게 구현되면 특정 유형의 방문자를 위한 Time to First Byte(결과적으로 LCP 및 FCP)를 개선합니다!
하지만 함정이 있습니다. 전체 페이지 엣지 캐싱은 종종 자동으로 우회되어야 합니다. 예를 들어 사용자가 로그인하거나 장바구니에 항목을 추가하면 페이지 콘텐츠가 개인화되므로 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 프로토콜에 비해 크게 개선된 버전입니다. HTTP/2는 많은 기능을 수행하지만 가장 중요한 것은 동일한 연결을 통해 여러 파일을 병렬로 보낼 수 있도록 하여 기존의 계단식 효과를 제거한다는 것입니다. HTTP/2는 나온 지 10년이 되었으며 브라우저와 서버에서 널리 지원됩니다!
권장 사항: 3개 모두 활성화하세요.
HTTP/3(QUIC 사용)
QUIC를 사용하는 HTTP/3는 연결 설정 및 지연 시간 개선으로 인해 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 Search가 콘텐츠를 미리 가져올 수 있도록 허용하는 데 사용되었습니다. SXG는 Google Search 결과에서 유입되는 방문자를 위해 LCP를 대략 450ms 정도 개선할 수 있었습니다.
하지만 Cloudflare는 2025년 10월에 SXG를 지원 중단했습니다. 해당 기능은 제거되었으며 더 이상 사용할 수 없습니다. 활성화되어 있었다면 자동으로 비활성화되었습니다. Speed Brain(Speculation Rules)이 프리페치를 위한 가장 근접한 대체제이지만, SXG처럼 Google Search에서의 교차 출처 프리페치에는 작동하지 않고 동일 사이트 탐색에만 작동합니다.
권장 사항: 이 설정은 더 이상 존재하지 않습니다.
Scrape Shield
Scrape Shield는 웹사이트의 콘텐츠를 보호합니다. 이것이 좋은 아이디어처럼 보일 수 있지만 저는 Scrape Shield 옵션을 활성화하는 것에 극렬히 반대합니다. Scrape Shield는 이전에 난독화된 콘텐츠를 디코딩하기 위해 페이지에 JavaScript를 주입하는 방식으로 작동합니다. 속도를 희생하여 콘텐츠를 숨기는 이러한 절충안은 제게 이해가 되지 않습니다. 실제 스패머는 속지 않는 반면 실제 사용자는 페이지 속도를 늦추는 추가 스크립트를 받게 됩니다.
권장 사항: Email Address Obfuscation을 비활성화하고 Hotlink Protection을 비활성화하세요.
Bot Fight Mode 및 Super Bot Fight Mode
이것은 Core Web Vitals에 가장 치명적인 단일 Cloudflare 설정입니다. 활성화되면 Bot Fight Mode는 모든 페이지에 invisible.js라는 스크립트를 주입합니다. 이 스크립트는 모든 페이지 로드에 2,000밀리초 이상의 CPU 실행 시간을 추가하는 브라우저 챌린지를 실행합니다. 즉, 페이지가 상호 작용할 수 있게 되기 전까지 메인 스레드가 2초 동안 완전히 차단됩니다.
실제로 Bot Fight Mode를 활성화하면 PageSpeed 점수가 20점 이상 떨어질 수 있습니다. Super Bot Fight Mode에도 동일한 문제가 있습니다. 아이러니하게도 이러한 모드는 봇을 차단하도록 설계되었지만 사이트를 방문하는 모든 실제 사용자에게 페널티를 줍니다.
권장 사항: Bot Fight Mode와 Super Bot Fight Mode를 모두 비활성화하세요. 봇 보호가 필요한 경우 대신 Cloudflare의 WAF 규칙이나 속도 제한을 사용하십시오. 이들은 클라이언트 측 JavaScript를 주입하지 않습니다.
캐싱 > 구성
Purge Cache
캐시를 제거하면 스타일시트, JavaScript, 이미지 및 전체 페이지 캐시를 포함하여 Cloudflare에 캐시된 모든 파일이 무효화됩니다. 그리고 캐시 제거가 엄밀히 말해 설정은 아니지만 캐시 지우기에 대해 경고해야 합니다. 캐시를 지우면 캐시가 다시 빌드될 때까지 사이트가 느려집니다!
권장 사항: 가능하면 전체 캐시를 제거하지 마십시오. 영향을 받는 파일만 제거하세요!
Caching Level
캐시 수준은 Cloudflare가 쿼리 문자열을 처리하는 방식을 결정합니다. 이 설정을 주의 깊게 살펴보고 싶으실 것입니다.
가장 '빠른' 옵션은 'Ignore query string'입니다. 이는 쿼리 문자열에 관계없이 동일한 리소스를 제공합니다. 사이트에서 쿼리 문자열이 사용되지 않는다고 100% 확신하는 경우에만 좋은 옵션입니다. 이 경우 다른 사람이 추가한 쿼리 문자열은 무시됩니다.
'Standard'는 서로 다른 쿼리 문자열마다 다른 캐시된 파일을 제공합니다. 이것은 Cloudflare의 기본 설정이지만 전체 페이지 엣지 캐싱 및 utm 파라미터와 같은 추적 파라미터와 결합될 경우 이 설정은 캐시 불일치와 캐시 적중률 저하를 유발할 수 있습니다! 이를 해결하려면 Cloudflare Workers로 추적 파라미터 제거를 고려해 보세요.
권장 사항: 가능하면 Ignore query string으로 설정하거나 Standard로 설정하세요. 'No query string' 옵션은 피하십시오.
Browser Cache TTL
브라우저 캐시 TTL은 브라우저에 정적 리소스를 캐시할 수 있는 기간을 알려줍니다. 캐시된 리소스는 브라우저에서 직접 제공될 수 있으며 원격 네트워크 리소스보다 훨씬 빠르게 사용할 수 있습니다. 즉, 브라우저 캐시 TTL이 짧으면 브라우저 캐시가 자주 무효화되어 캐시 적중률이 낮아집니다. 따라서 정적 파일이 자주 변경되지 않는 한 이 설정을 최대로 설정하십시오.
권장 사항: 가능하면 1년으로 설정하세요.
Development Mode
개발 모드가 활성화되어 있으면 모든 Cloudflare 캐싱을 우회합니다. 개발 중에 개발 모드를 활성화하고 싶은 유혹이 들 수 있습니다. 개발 모드를 활성화하지 마십시오. 이는 다른 모든 방문자에 대한 캐싱도 비활성화합니다. 대신 개발할 수 있는 개발 도메인을 설정하거나 캐시 규칙을 설정하여 Cloudflare 캐싱에서 자신을 제외하십시오.
권장 사항: 활성화하지 마세요!
캐싱 > Tiered Cache
Tiered Cache는 Cloudflare가 자체 서버에서 캐시되지 않은 파일을 먼저 찾도록 지시하여 오리진 서버에 대한 요청 수를 줄이고 캐시 적중률을 높입니다. 이는 백엔드 서버의 부하를 더욱 줄이고 추가 리소스를 확보합니다.
권장 사항: Smart Tiered Caching Topology를 활성화하세요.
CoreDash에서 모니터링하는 사이트 전체에서 적절히 구성된 CDN을 사용하는 사이트는 CDN이 없는 사이트에 비해 p75에서 55% 더 빠른 TTFB를 보여줍니다. Cloudflare의 HTTP/3, Brotli 및 Tiered Cache의 조합은 현장에서 측정 가능한 차이를 만들어냅니다. Real User Monitoring을 사용하여 Cloudflare 구성이 사용자에게 실제로 작동하는지 확인하세요.
