Core Web Vitals는 프론트 코드만 건드려서는 한계가 있습니다. 사용자가 화면을 보기까지는 DNS, TLS, 라우팅, 캐시, 이미지 파이프라인과 같은 인프라 단계가 겹겹이 쌓여 있고, 이 구간에서의 작은 개선이 LCP·CLS·INP 전체를 동시에 끌어내립니다. 아래 내용은 이미 운영 중인 서비스를 전제로, 설정 몇 가지와 서빙 전략만 바꿔도 숫자가 안정적으로 좋아지는 방법을 흐름대로 정리한 것입니다.
1) LCP 낮추기: 네트워크와 리소스 배달 최적화
LCP는 결국 “첫 화면의 큰 콘텐츠가 언제 보이느냐”의 문제이므로, TTFB를 줄이고 해당 리소스를 가장 먼저, 가장 가깝게 보내면 빨라집니다. 권위 DNS를 Anycast로 두고, 초기에 반드시 접근하는 외부 도메인에는 preconnect를 걸어 DNS·TLS 왕복을 선제 제거하세요. 오리진에는 HTTP/3와 TLS 1.3을 기본화하고, LCP 후보 이미지는 AVIF/WebP 협상을 켠 뒤 정해진 폭 그리드로만 리사이즈해 캐시 파편화를 막습니다. 파일명 해시와 immutable 캐시 정책을 적용하면 CDN에서 장기 히트가 유지되고, 프리로드와 fetchpriority=high로 네트워크 큐의 맨 위에 올려 실제 다운로드 시작 시점을 앞당길 수 있습니다. 백엔드가 병목이라면 LCP에 필요한 데이터만 별도의 캐시 레이어나 머티리얼라이즈드 뷰로 미리 계산해 두는 편이 체감에 훨씬 큽니다.
2) CLS 낮추기: 레이아웃 이동의 인프라적 원인 제거
CLS는 디자인 문제가 아니라 “예측 가능한 크기를 미리 약속했는가”의 문제입니다. 이미지와 비디오, 광고 슬롯과 임베드는 모두 폭·높이나 aspect-ratio를 명시해 자리부터 확보해야 합니다. 폰트는 woff2와 preload를 쓰더라도 표시 전략을 swap이나 optional로 두어 플래시를 최소화하고, 서브셋으로 용량을 줄여 로딩 변동을 낮추면 이동이 훨씬 줄어듭니다. 에지 리사이즈가 있다면 cover/contain 같은 fit 정책을 고정해 종횡비가 흔들리지 않도록 하고, 프리로드는 꼭 필요한 리소스만 선별해 순서를 안정화하세요. 결국 “갑자기 나타나서 밀어내는 요소”를 인프라 단계에서 원천 차단하는 것이 핵심입니다.
3) INP 낮추기: 입력→응답 경로의 서버·네트워크 지연 깎기
INP는 사용자가 클릭한 직후부터 응답 UI가 그려질 때까지의 총 지연입니다. 여기선 API 왕복을 짧게 유지하는 것이 결정적입니다. 상호작용 직후 호출되는 엔드포인트는 가능한 한 엣지 캐시로 끌어오고, 지역별로 지연이 큰 통신사는 Geo/Latency 라우팅으로 가까운 리전에 붙입니다. JSON 전송은 Brotli 중간 레벨이나 Gzip 스윗스팟을 쓰되 헤더와 쿠키를 다이어트해 바이트 자체를 줄이세요. 서버 측에서는 인기 키에 요청 합치기를 적용해 폭주 시 오리진을 보호하고, 비정상 구간에는 서킷브레이커와 stale-while-revalidate로 사용자에게는 즉시 응답을, 백그라운드에선 복구를 진행하는 형태가 안정적입니다. 프론트에서는 낙관적 업데이트로 반응을 먼저 그려 주면 꼬리 구간의 체감이 크게 완화됩니다.
4) CDN·캐시 레이어 공통 전략
여러 계층이 섞일수록 규칙은 단순해야 합니다. 캐시키는 경로와 의미 있는 파라미터만 포함하고, 추적성 쿼리와 불필요한 쿠키는 제외해 히트를 한곳으로 모으세요. 이미지·폰트 같은 정적 리소스는 전용 서브도메인으로 분리하면 보안과 캐시 정책을 과감하게 적용하기 쉽습니다. 오리진 부담을 낮추려면 Tiered Caching 또는 Shield를 활성화해 상위 캐시에서 재사용률을 높이되, Vary 헤더는 Accept·DPR·Width 등 꼭 필요한 항목만 남겨 캐시 폭발을 방지하는 것이 좋습니다.
5) 배포 전후 검증 루틴(필수)
릴리스 전에 TTL을 단계적으로 줄여 롤백 창구를 확보하고, 변경 사항은 카나리로 일부 트래픽에만 반영해 RUM과 Synthetic을 동시에 관측하세요. RUM에서는 국가·ISP·디바이스별 LCP·CLS·INP의 p75/p95를 확인하고, Synthetic에서는 DNS·연결·다운로드 단계로 분해해 어디서 병목이 생겼는지 즉시 짚어냅니다. LCP가 오르면 TTFB와 LCP 이미지의 TTFB/전송량을, CLS가 튀면 예약 슬롯과 크기 메타 누락을, INP가 나빠지면 첫 입력 이후 API 지연과 서버 작업 시간, 락 충돌 여부를 우선 확인하면 대부분의 원인이 드러납니다.
6) 바로 쓰는 체크리스트
핵심은 단순한 원칙을 꾸준히 지키는 것입니다. 핵심 외부 도메인 두세 곳만 preconnect로 워밍업하고, LCP 이미지는 AVIF/WebP 협상과 프리로드를 묶어 최상단 큐에 올립니다. 폰트는 woff2와 preload를 소수로 제한하고 swap 전략을 기본으로, 이미지·광고·임베드에는 크기 메타를 반드시 포함하세요. API는 엣지 캐시와 요청 합치기로 안정화하고, 전송은 HTTP/3와 Brotli 사전압축을 기본으로 둡니다. 캐시키와 Vary를 최소화한 뒤, RUM 대시보드에서 세 지표와 TTFB·오류율을 한 화면에서 보이도록 고정하면 운영이 쉬워집니다.
7) FAQ로 정리하는 오해
프리로드를 많이 쓰면 항상 더 빨라지는 것은 아닙니다. 초기 큐가 혼잡해져 오히려 LCP가 늦어질 수 있으므로 “정말 필요한 것만” 올려야 합니다. INP는 프론트 최적화만으로 해결하기 어렵습니다. 상호작용 직후의 API 지연, 캐시 미스, 라우팅 품질이 같은 비중으로 작용합니다. CLS 또한 디자이너만의 과제가 아닙니다. 크기 메타 제공과 예약 슬롯, 일관된 리사이즈 정책 같은 서빙 규칙이 갖춰져야 비로소 숫자가 안정됩니다.
마무리
Core Web Vitals는 화면을 “빨리, 안정적으로, 즉각 반응”하게 만드는 전 과정의 결과입니다. 인프라 관점에서 전송 경로를 짧게, 캐시를 두텁게, 변수를 예측 가능하게 만들면 LCP·CLS·INP는 동시에 내려갑니다. 오늘은 LCP 이미지의 프리로드와 캐시 정책부터, 내일은 캐시키와 요청 합치기, 그다음은 Geo 라우팅과 서킷브레이커처럼 단계적으로 적용해 보세요. 평균뿐 아니라 p95/p99 꼬리까지 함께 정돈되는 순간, 사용자는 진짜로 “빠르다”고 느낍니다.