이 글의 링크는 추후 제휴 링크로 바뀔 수 있으며, 그 경우 구매 시 수수료를 받을 수 있습니다.
이 글에서 다루는 것
코어 웹 바이탈 세 지표가 애드센스 수익의 어느 지점에 닿는지, 구글이 공개한 기준값과 사례로 정리합니다.
속도 점수는 챙기는데 그게 수익과 무슨 상관인지 모르겠는 분을 위한 글입니다.
다 읽고 나면 LCP·CLS·서버 응답 시간 중 어디가 새고 있는지, 무엇부터 손볼지 정할 수 있습니다.
결론부터: 점수가 단가를 올려 주지는 않습니다
먼저 오해를 걷어내겠습니다.
점수가 좋아진다고 애드센스가 단가를 더 쳐 주지는 않습니다.
애드센스 수익은 노출 수 × 조회가능 비율 × 단가로 쪼갤 수 있는데, 코어 웹 바이탈은 앞의 두 항목을 흔듭니다.
늦게 뜨면 광고가 그려지기 전에 독자가 나가고, 화면이 덜컹거리면 오클릭과 이탈이 늘어납니다.
1. 먼저 세 숫자의 기준값을 외웁니다
구글 web.dev 공식 문서 화면 - 코어 웹 바이탈 세 지표와 각각의 기준값
구글 공식 문서가 제시하는 합격선은 셋입니다.
LCP는 2.5초 이내, INP는 200밀리초 이하, CLS는 0.1 이하입니다.
판정은 평균이 아니라 페이지 로드의 75번째 백분위수로 하고 모바일과 데스크톱을 나눠 봅니다.
방문자 4명 중 3명이 기준 안에 들어와야 통과입니다.
| 지표 | 보는 것 | 좋음 기준 | 애드센스에 미치는 영향 |
|---|---|---|---|
| LCP | 주요 콘텐츠가 뜨는 시간 | 2.5초 이내 | 광고가 그려지기 전 이탈, 노출 손실 |
| INP | 클릭·입력에 대한 반응 | 200밀리초 이하 | 체류와 페이지뷰 감소 |
| CLS | 화면이 밀리는 정도 | 0.1 이하 | 오클릭과 이탈, 광고가 주요 원인 |
| TTFB | 서버 첫 응답까지 | 0.8초 이하 권장 | 위 세 지표의 출발선 |
2. LCP가 늦으면 광고는 보이기 전에 사라집니다
광고는 화면에 실제로 그려져야 노출로 잡힙니다.
LCP가 3~4초대면 단가와 무관하게 셀 물건 자체가 줄어듭니다.
흔한 실수는 첫 화면 맨 위에 큰 광고를 넣는 배치입니다.
광고 스크립트가 본문 이미지·폰트와 대역을 두고 경쟁하기 때문입니다.
구글 사례 연구에서도 상단의 큰 사각 광고를 걷어내고 이미지와 폰트를 먼저 불러오게 한 것이 LCP 개선의 핵심이었습니다.
3. CLS는 대부분 광고가 만든 문제입니다
구글 퍼블리셔 태그 공식 문서 화면 - 광고 때문에 생기는 레이아웃 변경을 줄이는 방법
광고는 늦게 도착합니다.
자리를 비워 두지 않으면 도착하는 순간 본문을 아래로 밀어냅니다.
이것이 CLS입니다.
구글 문서의 표현은 단호합니다.
레이아웃 변경을 막는 유일한 방법은 CSS로 광고 슬롯에 충분한 공간을 미리 예약하는 것이라고 적혀 있습니다.
실무로는 네 가지입니다.
첫째, 광고 슬롯에 고정 높이와 너비를 직접 줍니다.
최소치만 잡으려면 min-width와 min-height를 씁니다.
둘째, 여러 크기가 나가는 슬롯은 최대·최소·가장 많이 게재되는 크기 중 하나를 기준으로 자리를 잡습니다.
셋째, 크기가 유동적인 슬롯은 첫 화면에 두지 않고 스크롤 아래로 내립니다.
넷째, 자바스크립트로 자리를 잡지 않습니다.
스크립트가 실행되는 그 시점에 화면이 한 번 밀립니다.
4. 서버 응답 시간은 나머지 전부의 출발선입니다
구글 web.dev 공식 문서 화면 - 대부분의 사이트는 TTFB가 0.8초 이하가 되도록 권장
TTFB는 주소를 누른 순간부터 응답의 첫 바이트가 도착할 때까지의 시간입니다.
구글 문서는 대부분의 사이트가 0.8초 이하를 목표로 하라고 안내합니다.
TTFB는 코어 웹 바이탈 지표가 아닙니다.
다만 LCP보다 먼저 일어나는 일이라, 여기서 1.5초를 까먹으면 이미지를 줄여도 LCP 2.5초는 불가능합니다.
그래서 TTFB가 0.8초를 넘으면 플러그인 정리나 이미지 압축보다 서버 쪽을 먼저 봐야 합니다.
사양 부족, 캐시 없음, 서버와의 물리적 거리 셋 중 하나입니다.
5. 개선하면 얼마나 달라지나
구글 web.dev 사례 연구 화면 - 코어 웹 바이탈 개선 뒤 광고 수익이 18% 늘어난 독일 매체
독일 매체 Netzwelt는 코어 웹 바이탈에 맞춰 사이트를 다시 만든 뒤 페이지 조회수가 27%, 광고 수익이 18% 늘었습니다.
같이 나온 숫자가 더 중요합니다.
광고 조회가능성이 75%를 넘겼고 이탈률은 절반으로 줄었습니다.
단가가 아니라 더 많이, 더 오래 보게 된 것이 원인이라는 뜻입니다.
다만 한 매체의 사례입니다.
같은 폭을 기대할 일은 아니고 방향만 가져가는 편이 맞습니다.
6. 서버가 원인으로 좁혀졌을 때의 선택지
여기까지 짚었는데도 TTFB가 줄지 않는다면 그때가 호스팅을 볼 지점입니다.
공유 호스팅은 한 서버를 여럿이 나눠 쓰는 구조라, 옆집 트래픽이 내 응답 시간을 끌어내립니다.
클라우드웨이즈 요금 페이지 - 2026년 9월 24일 확인한 가장 싼 요금제
관리형 클라우드 호스팅인 클라우드웨이즈를 예로 들면, 2026년 9월 24일 기준 가장 싼 요금제는 월 14달러짜리 Micro입니다.
1GB RAM, 1 vCPU, 25GB NVMe, 1TB 전송량입니다.
시작은 이 최저 요금제로 충분합니다.
메모리 경고가 뜨거나 동시 접속에 응답이 밀릴 때 Small(월 28달러)로 올리면 되고, 처음부터 상위 요금제를 살 이유는 없습니다.
카드 없이 3일 무료 체험이 되니 옮기기 전에 응답 속도만 먼저 재 보는 방법도 있습니다.
클라우드웨이즈 요금제와 사양을 공식 페이지에서 직접 확인해 보기
다만 이런 분에게는 권하지 않습니다.
요금은 달러 결제이고 표시가에 세금이 빠져 있어 실제 청구액이 달라집니다.
외부 백업은 GB당 0.033달러가 따로 붙습니다.
한국어 고객지원이 없고 관리 화면도 영어입니다.
메일 호스팅은 별도 애드온이고, 도메인도 등록기관에서 따로 사야 합니다.
무엇보다 월 1만 원 이하 공유 호스팅에서 TTFB가 이미 0.8초 안쪽이라면 옮길 이유가 없습니다.
자주 묻는 질문
페이지스피드 점수는 90인데 왜 코어 웹 바이탈은 미달인가요
점수는 실험실 측정이고 코어 웹 바이탈 판정은 실사용자 데이터의 75번째 백분위수입니다.
느린 기기로 들어오는 방문자가 많으면 둘이 갈립니다.
광고를 줄이면 CLS는 해결되나요
개수보다 자리 예약이 먼저입니다.
두 개라도 슬롯 크기를 지정하지 않으면 밀리고, 여섯 개라도 CSS로 자리를 잡아 두면 밀리지 않습니다.
무엇부터 손대야 하나요
TTFB, CLS, LCP 순서를 권합니다.
서버 응답이 느리면 나머지 작업의 효과가 묻히고, CLS는 CSS 몇 줄로 가장 빨리 잡힙니다.
관리형 클라우드 호스팅이 어떤 구조인지 공식 소개 페이지에서 보기
마무리
코어 웹 바이탈은 애드센스 단가가 아니라 노출 수와 조회가능 비율을 통해 수익에 닿습니다.
기준값은 LCP 2.5초, INP 200밀리초, CLS 0.1이고, 그 앞에 서버 응답 시간 0.8초라는 출발선이 있습니다.
손대는 순서는 서버 응답, 광고 자리 예약, 상단 콘텐츠 우선순위입니다.
이미지와 플러그인은 그다음입니다.
지금 블로그의 LCP와 CLS는 얼마로 나오시나요.
두 숫자와 쓰고 계신 호스팅을 댓글로 남겨 주시면 어느 항목부터 손대면 좋을지 같이 짚어 보겠습니다.
다음 글에서는 「애드센스 광고 위치와 개수, 수익과 이탈 사이」에 대해 알아보겠습니다.