Core Web Vitals는 ‘프론트 성능’으로만 보이지만, 실제로는 캐시/CDN과 보안 설정(헤더/쿠키/압축/프로토콜)까지 함께 움직입니다. 그래서 LCP가 갑자기 튀거나 INP가 불규칙해질 때는 “코드만” 보다가 시간을 쓰기 쉽습니다.

방패와 속도계로 표현한 웹 성능과 보안 균형

아래는 성능(Core Web Vitals) 중심으로, 캐시/CDN 포함 성능 개선 루트를 실전 점검 순서로 정리한 가이드입니다.

1) 먼저 재현 환경 고정: Chrome에서 원인 분리하기

지표가 흔들릴 때는 “측정 조건”이 바뀌었을 가능성이 큽니다. 코드/인프라를 바꾸기 전에, Chrome에서 재현을 최대한 고정해 주세요.

  • Chrome Incognito로 확장프로그램 영향 제거
  • Network 탭에서 캐시 비활성화(DevTools 열려 있을 때만 적용)로 캐시 영향 분리
  • Throttle은 고정값(예: Fast 4G)으로 통일해 비교
  • 동일 URL을 새로고침 vs 새 탭으로 각각 측정(서비스 워커/캐시 동작이 다를 수 있음)
  • Disable JavaScript는 원인 확인용으로만 잠깐(실사용 성능과 다름)

이 단계의 목표는 “지표가 나쁜 게 진짜 서버/캐시/CDN 때문인지”를 빠르게 가르는 것입니다. 특히 LCP는 네트워크/캐시/우선순위에 민감하고, INP는 스크립트/서드파티/메인 스레드 점유 영향을 크게 받습니다.

2) LCP부터 잡기: 캐시 히트/미스와 HTML 응답을 먼저 확인

LCP가 나빠졌다면 가장 먼저 HTML 문서(TTFB)와 캐시 상태부터 보세요. 대개 여기서 1차 원인이 갈립니다.

체크 포인트는 단순합니다.

  • CDN을 쓴다면 응답 헤더에서 cache hit/miss 상태 확인
  • TTFB가 늘었으면 원인은 대체로 원본 서버(Origin) 처리 지연, 동적 렌더링, DB, 또는 캐시 미적용
  • HTML에 Cache-Control이 너무 보수적이면(예: no-store) CDN이 사실상 못 돕는 경우가 많음

보안 때문에 no-store/no-cache를 무조건 쓰는 경우가 있는데, 로그인/개인정보가 포함된 페이지와 공개 페이지를 분리해서 캐시 전략을 다르게 가져가면 LCP가 크게 안정됩니다. “모든 페이지를 동일한 보안 정책으로 묶는 것”이 성능 흔들림의 시작인 경우가 꽤 있습니다.

CDN 캐시 히트와 미스 흐름을 보여주는 도식

3) CDN 구성에서 자주 터지는 포인트: 변형(Variations)과 압축/프로토콜

CDN을 켰는데도 LCP가 개선되지 않거나 오히려 악화되면, CDN이 “다르게” 캐시하고 있을 가능성을 봐야 합니다. 특히 다음 두 가지가 잦습니다.

  • Vary가 많아 캐시가 쪼개짐 (예: Accept-Encoding, User-Agent, Cookie 등)
  • 압축/프로토콜 협상 문제로 리소스 전송이 비효율적임 (Brotli, HTTP/2, HTTP/3)

실전에서는 이렇게 접근하면 빠릅니다.

  • HTML/핵심 리소스가 Brotli(br)로 내려오는지 확인(가능하면 CDN에서)
  • HTTP/2 연결에서 동일 도메인으로 필요한 리소스를 묶을 수 있는지(도메인 분산이 오히려 손해)
  • 서드파티(태그/광고/위젯) 도메인 때문에 연결이 늘어나면 LCP/INP 모두 악화

보안 설정과도 맞물립니다. 예를 들어 CSP를 강하게 잡아놓고 리소스 도메인이 자주 바뀌면, 문제 해결 과정에서 임시로 허용 리스트가 늘어나고(=제어가 느슨해지고) 그 사이 서드파티가 늘어 성능이 더 나빠지는 식의 부작용이 생길 수 있습니다. 성능/보안은 같이 설계해야 안정적입니다.

4) 이미지/폰트 우선순위: LCP 리소스를 “확실히” 빠르게

LCP가 이미지(대표 이미지/히어로 이미지)인 사이트는 “용량 줄이기”만으로는 부족한 경우가 많고, 우선순위가 결정적입니다.

  • LCP 후보 이미지가 lazy-load로 잡혀 있지 않은지 확인
  • 이미지 포맷은 가능하면 AVIF/WebP + 적절한 사이즈(서버/빌드에서 생성)
  • 폰트는 preload를 남발하지 말고, 실제 렌더 차단을 만드는 파일만 선별
  • CDN 이미지 리사이징을 쓰면 캐시 키(쿼리스트링/헤더)로 캐시가 너무 쪼개지지 않게 설계

추가로, 보안 관점에서 폰트/이미지 도메인을 분리할 때는 CORS 헤더가 꼬이면 폰트 재시도가 발생해 성능이 악화될 수 있습니다. “폰트가 느려졌다”가 아니라 “폰트가 실패 후 재시도한다” 같은 케이스도 있으니 Network에서 실패 요청이 있는지 꼭 같이 봐주세요.

5) INP 개선 루트: 서드파티 스크립트 + 메인 스레드 점유 줄이기

INP는 “사용자 입력 후 화면 반응”이라, CDN/캐시보다 스크립트 실행 영향이 훨씬 큽니다. 하지만 캐시 전략이 나쁘면 JS 번들이 자주 바뀌어 재다운로드/재파싱이 늘어나 INP에도 간접적으로 타격이 납니다.

  • 서드파티 태그(Analytics/Ads/Chat) 로딩 순서 재점검: 정말 초기 렌더 전에 필요하나요?
  • 긴 작업(Long Task)이 많은지 Performance에서 확인 후, 번들 분리/지연 로딩 적용
  • 캐시 정책: 빌드 산출물(JS/CSS)은 content hash 기반 파일명 + 장기 캐시가 기본
  • 보안 헤더(예: CSP)를 적용했다면, inline script 차단으로 우회 로직이 생기며 오히려 실행량이 늘지 않았는지 확인

스크립트 최적화와 보안 헤더를 함께 나타낸 일러스트

포인트는 “보안을 강화하면서도 성능이 떨어지지 않게”입니다. 예를 들어 CSP를 도입할 때 nonce/sha 기반으로 정리해두면, 무의미한 예외 도메인 추가를 줄여 보안과 성능(서드파티 절제)을 같이 챙길 수 있습니다.

6) CLS 흔들림 방지: 캐시/CDN보다 ‘레이아웃 안정’ 기본기

CLS는 캐시/CDN 이슈보다는 화면 구성 이슈가 대부분이지만, 운영 중에는 “광고/위젯이 특정 지역에서만 늦게 로딩” 같은 형태로 지표가 들쭉날쭉해집니다.

  • 이미지/광고 영역에 고정 높이(또는 aspect-ratio)가 잡혀 있는지
  • 폰트 로딩으로 텍스트 폭이 바뀌는지(FOIT/FOUT) 확인
  • CDN 지연으로 특정 리소스가 늦게 와서 레이아웃이 밀리는지(특히 서드파티)

CLS는 “나중에 오는 것”이 원인이라, 리소스가 늦게 오는 이유(네트워크/지역/캐시 미스)와 “늦게 와도 밀리지 않게 만드는 설계”를 같이 봐야 안정됩니다.

마무리

Core Web Vitals를 성능 중심으로 개선하려면, 프론트 최적화만이 아니라 캐시/CDN과 보안 설정을 같은 흐름에서 점검하는 게 가장 빠릅니다. 특히 LCP는 HTML/캐시/우선순위, INP는 스크립트/캐시 전략, CLS는 레이아웃 안정성으로 나눠 잡으면 효율적입니다.

지표가 “갑자기” 변했다면 변경 이력(배포, CDN 규칙, 헤더, 서드파티 추가)을 먼저 좁혀 보고, Chrome에서 재현 조건을 고정한 뒤 한 단계씩 원인을 분리해 보세요.