FID는 사라졌습니다! 코어 웹 바이탈(LCP·INP·CLS) 자가진단과 인프라로 개선할 부분

같은 사이트인데 누구는 빠르고 누구는 느리다

같은 페이지인데도 사용자마다 체감 속도가 다릅니다. 그 차이를 주관이 아니라 숫자로 잡기 위한 것이 구글의 코어 웹 바이탈(Core Web Vitals)입니다. 검색 경험과도 연결돼 있어, 마케팅·개발·인프라가 같은 언어로 성능을 이야기하려면 이 지표부터 맞춰야 합니다.

그런데 현장에서 자주 어긋나는 지점이 있습니다. "사이트가 느리다 → CDN 붙이자"처럼 모든 성능 문제를 한 가지 처방으로 뭉뚱그리는 것이죠. 코어 웹 바이탈은 서로 다른 것을 재는 세 지표이고, 고치는 주체도 다릅니다. 먼저 무엇을 재는지부터 봅니다.

2024년 3월, FID가 INP로 바뀌었다

응답성 지표가 한 번 교체됐다는 점을 짚어둘 필요가 있습니다. web.dev 공지에 따르면 INP는 2024년 3월 12일 코어 웹 바이탈이 되며 FID를 대체했고, FID는 이 전환에서 폐기됐습니다.

폐기에는 시차가 있었습니다. FID는 그날 Google Search Console에서 즉시 제거됐지만, PageSpeed Insights와 CrUX 같은 나머지 도구에서는 6개월의 폐기 유예 기간이 주어졌습니다. 그래서 지금 기준으로 보고 관리해야 할 응답성 지표는 INP입니다.

코어 웹 바이탈 3가지와 좋음 기준

세 지표의 "좋음" 기준은 다음과 같고, 모두 모바일·데스크톱으로 나눈 페이지 로드의 75퍼센타일로 판단합니다.

참고로 TTFB(Time To First Byte)는 코어 웹 바이탈 자체는 아니지만, 서버가 첫 바이트를 응답하기까지의 시간으로 대략 0.8초 이하가 권장됩니다. 뒤에서 보겠지만 이 TTFB가 인프라와 LCP를 잇는 연결 고리입니다.

어디는 코드로, 어디는 인프라로

같은 "느림"이라도 원인이 다르면 고치는 사람도 다릅니다. web.dev의 설명을 따라 지표별로 나눠 봅니다.

INP는 클릭·탭·키보드 상호작용의 지연을 재는데, 이 지연은 입력 지연 + 처리 시간 + 표시 지연으로 나뉩니다. web.dev는 "상호작용성의 주된 동인은 자바스크립트인 경우가 많다"고 설명하고, 최적화 가이드도 긴 작업 분할, 웹 워커로 메인스레드 분리, 렌더링 최적화 같은 프런트엔드 항목 중심입니다. 그래서 INP는 CDN보다 프런트엔드 코드의 영역으로 보는 것이 맞습니다. CLS도 이미지 크기 지정·폰트·삽입 요소 같은 레이아웃 쪽이죠.

반면 LCP는 결이 다릅니다. web.dev의 LCP 분해를 보면 LCP 시간은 TTFB + 리소스 로드 지연 + 리소스 로드 시간 + 요소 렌더 지연 네 단계로 구성되고, 이들이 더해져 전체 LCP가 됩니다. 즉 LCP의 첫 단계가 서버 응답 시간(TTFB)입니다. 여기가 인프라가 직접 손댈 수 있는 지점입니다.

인프라가 직접 닿는 곳 — TTFB와 LCP

TTFB는 서버가 첫 바이트를 보내기까지의 시간이고, 이걸 줄이는 대표적 수단이 CDN입니다. web.dev의 TTFB 최적화 문서는 이렇게 권합니다.

CDN은 사용자와 오리진 서버 사이의 물리적 거리 문제를, 사용자에게 더 가까운 서버에 리소스를 캐시하는 분산 서버 네트워크로 해결한다. (web.dev — Optimize TTFB)

그래서 자가진단에서 LCP가 느리고 그 안에서 TTFB가 큰 비중을 차지한다면, 그건 프런트엔드 코드만으로는 한계가 있고 서버 위치·캐싱·전달 같은 인프라로 개선되는 영역입니다. 적절한 Cache-Control 설정과 엣지 캐싱으로 오리진까지의 왕복을 줄이면 TTFB가 내려가고, 그 위에 쌓이는 LCP도 함께 좋아집니다.

정리하면 진단의 순서는 이렇습니다. 코어 웹 바이탈을 측정해 약한 지표를 찾고, 그 지표가 INP·CLS(코드)인지 LCP·TTFB(인프라·CDN)인지 가른 뒤, 각 영역의 담당이 맞는 처방을 적용하는 것입니다. 캐싱·가용성 관점은 CDN 가용성 설계와도 이어집니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)