[2026 최신] -Core Web Vitals를 고려한 웹사이트 속도 최적화 방법 완벽 가이드 | 테라그로스

구글 애즈 계정을 오래 굴리다 보면 이상한 순간을 자주 만난다. 광고 소재도 좋고, 키워드 매칭도 깔끔하고, 입찰가도 적정한데 전환율이 계속 바닥을 기는 계정. 십중팔구 랜딩페이지 열어보면 답이 나온다. 모바일에서 4초 넘게 걸리는 페이지에 클릭당 몇천 원씩 태우고 있었던 거다. 우리가 인수받은 계정 중에 페이지 로딩만 개선했는데 전환당 비용이 30% 넘게 떨어진 사례가 있다. 광고 세팅은 손도 안 댔는데 말이다.

2026년 현재 Core Web Vitals는 단순한 SEO 체크리스트가 아니다. 구글 검색 순위 시그널이면서 동시에 광고 방문 페이지 만족도, 그러니까 품질평가점수에 직결되는 요소다. 오늘은 우리가 실무에서 실제로 손대는 순서 그대로, 속도 최적화를 어떻게 하는지 풀어보겠다.

2026년 기준 Core Web Vitals – 뭐가 바뀌었나

과거에는 FID(First Input Delay)라는 지표가 있었지만 지금은 완전히 퇴역했다. 2024년 3월부터 INP(Interaction to Next Paint)가 그 자리를 대체했고, 2026년 현재 Core Web Vitals 3대 지표는 이렇게 정리된다.

여기서 실무자들이 자주 놓치는 포인트 하나. 이 기준은 ’75번째 백분위수’ 기준이다. 방문자 100명 중 75등의 경험이 기준을 통과해야 한다는 뜻이다. 사무실 와이파이에 최신 아이폰으로 테스트해서 빠르다고 안심하면 안 되는 이유다. 실제 유저 상당수는 지하철에서 LTE 잡히다 말다 하는 환경으로 들어온다.

그리고 FID가 왜 사라졌는지 이해하면 INP 대응이 쉬워진다. FID는 ‘첫 입력’의 지연만 쟀는데, INP는 페이지에 머무는 동안 발생하는 모든 인터랙션을 본다. 첫 화면만 반짝 빠르게 만들어놓고 뒤에서 무거운 스크립트 돌리는 꼼수가 더 이상 안 통한다는 얘기다.

LCP 최적화 – 대부분의 사이트가 여기서 무너진다

우리가 진단하는 사이트의 체감 8할은 LCP가 문제다. 그리고 그 LCP 문제의 대부분은 히어로 이미지, 그러니까 첫 화면 큰 이미지 하나 때문이다.

이미지부터 잡아라

솔직히 여기까지만 해도 절반은 해결된다. 순서대로 적어보면 이렇다.

첫째, 포맷 전환. JPG나 PNG를 아직도 쓰고 있다면 WebP나 AVIF로 바꾸는 것만으로 용량이 30~50% 줄어든다. 2026년 시점에서 AVIF는 모든 주요 브라우저가 지원하니 호환성 걱정은 접어둬도 된다. 워드프레스라면 이미지 최적화 플러그인이 자동 변환해주고, 요즘은 CDN 레벨에서 브라우저 보고 알아서 포맷 골라주는 서비스도 흔하다.

둘째, LCP 이미지에는 절대 lazy loading을 걸지 마라. 이거 정말 자주 보는 실수인데, 플러그인이 전체 이미지에 일괄로 loading=”lazy”를 박아버리면서 첫 화면 이미지까지 늦게 뜨는 경우가 많다. 반대로 LCP 후보 이미지에는 fetchpriority=”high”를 명시해서 브라우저가 최우선으로 받게 해야 한다. 우리가 관리하는 한 이커머스 사이트는 이 속성 하나 추가하고 모바일 LCP가 3.8초에서 2.4초로 내려왔다.

셋째, 이미지 크기 자체를 화면에 맞게 서빙해라. 모바일 360px 화면에 2000px짜리 원본을 내려보내는 사이트가 아직도 널렸다. srcset으로 해상도별 분기만 해줘도 전송량이 확 준다.

서버 응답 시간 – TTFB를 의심해라

이미지를 다 잡았는데도 LCP가 안 내려온다면 서버 응답 시간(TTFB)을 봐야 한다. 구글은 TTFB 800ms 이내를 권장하는데, 국내 저가형 공유 호스팅에서는 이거 하나 못 지켜서 모든 지표가 밀리는 경우가 흔하다.

페이지 캐싱이 첫 번째 답이다. 워드프레스 기준으로 서버 사이드 캐시 플러그인 하나만 제대로 세팅해도 TTFB가 수백 ms 단위로 떨어진다. 근데 캐시 플러그인 두세 개 겹쳐 깔아서 오히려 충돌 나는 사이트도 봤다. 하나만, 제대로 쓰는 게 낫다.

INP 최적화 – 2026년의 진짜 난제

LCP는 그래도 원인이 눈에 보이는데, INP는 좀 다르다. 페이지 어딘가에서 자바스크립트가 메인 스레드를 붙잡고 있으면 버튼 하나 누르는 데도 화면이 버벅인다. 사용자 입장에서는 “눌렀는데 반응이 없네?” 하고 한 번 더 누르게 되는 그 경험이 전부 INP 악화로 기록된다.

서드파티 스크립트 다이어트

진단해보면 INP 범인은 대부분 서드파티다. 채팅 위젯, 히트맵 툴, 마케팅 자동화 픽셀, 예전 담당자가 심어놓고 퇴사한 정체불명의 태그까지. 한 클라이언트 사이트에서는 태그매니저 안에 이미 서비스 해지한 툴의 스크립트가 세 개나 살아서 돌고 있었다. 이런 것부터 정리하는 게 코드 최적화보다 먼저다.

남겨야 하는 스크립트는 로딩 시점을 조절한다. 사용자 인터랙션 이후로 미루거나, 화면에 해당 요소가 보일 때 로드하는 식으로. 채팅 위젯 같은 건 첫 스크롤 발생 시점에 불러와도 사용 경험에 아무 지장이 없다.

긴 작업 쪼개기

자체 스크립트가 문제라면 긴 작업(Long Task)을 쪼개야 한다. 50ms 넘게 메인 스레드를 점유하는 작업이 있으면 그 사이 들어온 클릭이 전부 대기열에 밀린다. 2026년 현재는 scheduler.yield() API가 안정화돼서 무거운 작업 중간중간 브라우저에게 제어권을 돌려주는 패턴을 표준적으로 쓸 수 있다. 개발자가 있는 조직이라면 이 부분을 요청하면 되고, 없다면 최소한 서드파티 정리라도 확실히 해두자.

CLS 최적화 – 사용자를 배신하는 화면 밀림 없애기

CLS는 셋 중에 제일 잡기 쉬운데 제일 짜증나는 지표다. 기사 읽다가 갑자기 광고가 끼어들어서 엉뚱한 링크를 누른 경험, 다들 있지 않나. 그게 CLS다.

해결 원칙은 하나다. 나중에 로드되는 모든 요소에 미리 자리를 확보해두는 것. 구체적으로는 이렇게 한다.

이미지와 동영상에는 width, height 속성을 반드시 명시한다. 요즘 브라우저는 이 값으로 aspect-ratio를 계산해서 로드 전에 공간을 예약한다. 광고 슬롯도 마찬가지로 min-height를 잡아둔다. 광고가 안 뜨는 경우까지 감안하면 고정 높이 컨테이너가 안전하다.

웹폰트도 CLS 유발자다. 폰트가 늦게 로드되면서 텍스트가 재배치되는 현상인데, font-display 설정과 함께 대체 폰트의 자간, 크기를 웹폰트와 비슷하게 맞추는 size-adjust 기법으로 잡는다. 한글 폰트는 용량이 커서 이 문제가 영문 사이트보다 심하다. 서브셋 폰트 쓰는 것만으로도 체감이 다르다.

측정이 먼저다 – 랩 데이터와 필드 데이터는 다르다

최적화 작업 전에 측정 체계부터 잡아야 한다. 여기서 많이들 헷갈리는 게 랩 데이터와 필드 데이터의 차이다.

PageSpeed Insights 돌리면 위쪽에 ‘실제 사용자 환경 평가’가 나오고 아래에 Lighthouse 점수가 나온다. 구글이 순위와 판정에 쓰는 건 위쪽, 그러니까 CrUX(Chrome UX Report) 기반 필드 데이터다. Lighthouse 점수 95점 받고 좋아했는데 정작 필드 데이터는 ‘개선 필요’인 사이트가 수두룩하다. 반대 경우도 있고.

우리 실무 루틴은 이렇다. 서치콘솔의 Core Web Vitals 보고서로 문제 URL 그룹을 먼저 파악하고, PageSpeed Insights로 해당 페이지의 필드 데이터를 확인한 다음, Lighthouse와 크롬 개발자 도구 성능 탭으로 원인을 파고든다. 진단은 랩 데이터로, 판정은 필드 데이터로. 이 순서만 지켜도 헛수고를 크게 줄인다.

한 가지 팁을 더 하자면, 필드 데이터는 28일 이동 평균이라 오늘 고쳐도 점수에 온전히 반영되기까지 한 달 가까이 걸린다. 클라이언트에게 보고할 때 이 시차를 미리 설명 안 하면 “고쳤다면서 왜 그대로예요?”라는 질문을 반드시 받게 된다. 경험담이다.

속도와 광고 성과 – 대행사가 속도에 집착하는 이유

사실 우리가 SEO 업체도 아닌데 왜 이렇게 속도 얘기를 하냐면, 구글 애즈 성과와 직결되기 때문이다.

구글 애즈의 품질평가점수는 예상 클릭률, 광고 관련성, 그리고 방문 페이지 만족도로 구성된다. 이 방문 페이지 만족도에 로딩 속도와 모바일 사용성이 들어간다. 품질평가점수가 오르면 같은 순위를 더 낮은 CPC로 가져올 수 있으니, 속도 개선은 사실상 입찰가 할인과 같은 효과를 낸다.

더 직접적인 건 전환율이다. 구글 리서치에서 오래전부터 반복 검증된 사실인데, 모바일 로딩이 1초에서 3초로 늘어나면 이탈 확률이 32% 증가한다. 클릭당 2,000원 주고 데려온 방문자가 페이지 뜨기도 전에 나가버리면 그 돈은 그냥 증발이다. 우리가 랜딩페이지 LCP를 1초대로 끌어내린 한 B2B 계정은 동일 예산에서 상담 신청이 월 40건대에서 60건대로 올라왔다. 광고 최적화로는 몇 달 걸렸을 개선 폭이다.

2026년에 추가로 챙길 것들 – 한 발 앞서가는 기법

기본기를 다 잡았다면 요즘 우리가 적극적으로 쓰는 기법들이 있다.

먼저 Speculation Rules API. 사용자가 다음에 클릭할 가능성이 높은 페이지를 브라우저가 미리 렌더링해두는 기술인데, 잘 적용하면 다음 페이지 이동이 사실상 0초에 가깝게 체감된다. 과거의 prefetch가 리소스만 미리 받았다면 지금은 페이지 전체를 미리 그려놓는 수준까지 왔다. 목록에서 상세로 넘어가는 동선이 뚜렷한 커머스, 콘텐츠 사이트에서 효과가 크다.

bfcache(뒤로-앞으로 캐시)도 점검 대상이다. 사용자가 뒤로가기를 눌렀을 때 페이지를 새로 로드하지 않고 메모리에서 즉시 복원하는 기능인데, 특정 스크립트나 헤더 설정이 이걸 막고 있는 사이트가 의외로 많다. 크롬 개발자 도구에서 bfcache 적용 여부를 바로 테스트할 수 있으니 꼭 확인해보길.

마지막으로 우선순위 정리. 예산과 시간이 한정돼 있다면 이 순서를 권한다. 광고 랜딩페이지와 메인 페이지의 LCP부터, 그다음 전환 동선(폼, 결제)의 INP, 마지막으로 사이트 전반의 CLS. 트래픽과 돈이 흐르는 페이지부터 잡는 게 투자 대비 회수가 가장 빠르다.