애드센스 심사 전 PSI | Lighthouse 10 배점과 진단

PSI 화면

PSI는 공개 URL을 받아 랩 데이터와 필드 데이터를 나란히 보여 준다. 랩은 Lighthouse가 그 순간 그 환경에서 한 번 측정한 값이다. 필드는 Chrome User Experience Report(CrUX)가 실제 사용자에게서 모은 값이다. 신규나 저트래픽이면 필드가 「데이터 없음」인 경우가 많다. 필드가 없다고 점검을 미룰 필요는 없다. 랩으로 병목을 자른다.

화면 상단에서 URL 단위인지 오리진 단위인지를 본다. 오리진은 도메인 전체의 표본이다. 대표 글만 고쳤는데 필드가 안 움직이면, 보고 있는 숫자가 URL이 아니라 오리진일 수 있다. 모바일과 데스크톱은 전략이 다르다. 애드센스 심사 전 점검은 모바일 랩을 기준으로 두는 편이 본문에 맞다. 폰의 뷰포트와 느린 CPU에서 TBT와 CLS가 더 크게 드러난다.

「개선할 항목」과 「진단」은 점수 그 자체가 아니다. 구글 문서가 말하듯 점수를 만드는 것은 다섯 지표다. 진단은 그 지표를 움직이기 위한 힌트다. 「미사용 JS 제거 0.8초」를 고쳤는데 점수가 그대로인 이유가 여기 있다. 이미 90점을 넘긴 뒤에는 숫자 100보다 진단 원문이 사라졌는지를 본다.

측정은 PSI 모바일로 대표 URL 한 번, 성능 점수와 FCP LCP TBT CLS 화면 저장, CrUX가 URL 단위인지 오리진 단위인지, LCP 요소가 무엇인지다. 고치기는 LCP 4구간 지연, TBT 상위 롱태스크, 광고 슬롯 min-height, 폰트 렌더 차단 순이다. 재측정은 같은 URL, 같은 전략(모바일)이다.

Lighthouse 10 배점

TBT와 CLS를 합치면 55%다. 둘 다 자바스크립트와 광고가 원인인 경우가 많다. 최적화 글 대부분은 이미지와 폰트, 즉 FCP와 LCP 쪽으로만 간다. FCP 10%와 Speed Index 10%는 첫 픽셀과 화면이 채워지는 속도다. 여기만 만지면 점수의 절반 이상이 그대로다.

PSI 점수 몇 점이면 심사에 안전하다는 공식 기준선은 없다. 핵심은 가치 있는 콘텐츠와 정책 준수다. 빈 목록 200, 느린 첫 화면, 과도한 서드파티는 심사와 색인, 이탈을 같이 나쁘게 만들 수 있다. 애드센스 심사에는 90대를 100으로 올리는 시간이 글 한 편보다 가치가 낮을 수 있다.

핵심 포인트: 점수 입력은 다섯 지표이고, 진단 목록은 힌트다. TBT 30%를 건너뛰고 이미지만 만지면 점수가 안 움직이는 이유가 된다.

TBT

배점 30%로 가장 큰데 폰트 글에서는 거의 다루지 않는다. TBT는 메인 스레드를 50ms 넘게 막은 작업의 초과분 합계다. 50ms짜리 작업은 TBT에 안 들어간다. 80ms짜리 작업은 30ms가 합계에 더해진다. 콘텐츠 블로그에서는 광고 스크립트, 애널리틱스, 댓글 위젯, 소셜 임베드, 무거운 테마 JS가 원인인 경우가 많다.

PSI 진단의 「메인 스레드 작업 최소화」와 「긴 작업 피하기」에 파일 이름이 드러난다. 해당 스크립트를 제거하는지, 늦추는지, 조건부로만 로드하는지 순서로 본다. 댓글 위젯이 본문 아래에만 있으면 첫 화면 뒤에 불러도 된다. 광고와 분석은 심사와 정산에 묶여 있어 제거가 답이 아닐 때가 많다. 그때는 슬롯 예약과 로드 순서가 TBT와 CLS를 같이 움직인다.

TBT 합계는 작업마다 따로 난다. 40ms 작업 열 개는 50ms를 넘지 않으므로 합계에 0이다. 80ms 작업 하나는 30ms가 합계에 더해진다. 200ms 작업 하나는 150ms가 더해진다. 광고 스크립트와 애널리틱스와 테마 JS가 각각 80ms를 넘기면, 파일이 세 개여도 TBT는 세 초과분의 합이다. 이미지를 압축해도 이 합은 안 줄어든다. 배점 30%가 그 합에 실려 있다. 진단에서 파일 이름을 고른 뒤에만 제거, 지연, 조건부 로드 순서를 고른다.

필드 지표로는 INP(Interaction to Next Paint) 가 중요하다. 출처 문서 기준으로 2024년 3월부터 FID를 대신하는 Core Web Vital이다. 랩에서는 TBT, 실제 사용자에서는 INP를 같이 본다. 상호작용 이후에만 무거워지는 위젯은 TBT보다 INP에서 더 크게 드러날 수 있다. 클릭한 뒤에 메인 스레드가 막히면 다음 페인트가 늦다. 랩의 TBT가 괜찮아 보여도 필드 INP가 나쁘면, 첫 로드가 아니라 클릭 뒤 스크립트가 병목이다.

LCP 네 구간

LCP가 느릴 때 「이미지를 압축한다」가 첫 반응이면 헛수고인 경우가 많다. 구글 공식 가이드는 LCP를 네 구간으로 분해하고, 네 구간을 더하면 LCP가 된다.

delay가 붙은 두 구간은 0에 가까울수록 좋다. 여기가 크면 문제는 압축이 아니라 늦게 시작하거나, 다 받았는데 못 그리는 구조다. 이미지를 WebP나 AVIF로 바꿔 load duration을 줄여도, 그 시간이 render delay로 옮겨가면 LCP는 그대로일 수 있다.

TTFB가 크면 서버와 CDN, 리다이렉트, HTML 생성이다. Resource load delay가 크면 LCP 리소스를 늦게 발견한 것이다. LCP 리소스가 JS로 동적으로 추가되거나 data-src 뒤에 있거나 CSS background-image에만 있으면 preload scanner가 늦게 발견한다. 뷰포트 안 LCP 이미지에는 loading="lazy"를 걸지 않고, 필요한 경우 fetchpriority="high"를 제한적으로 쓴다. Element render delay가 크면 폰트나 긴 자바스크립트가 그리기를 막는다. 파일을 줄여도 메인 스레드가 바쁘면 그림이 안 나온다.

네 구간을 더하면 LCP다. 구글 가이드의 이상적 비율은 TTFB 약 40%, load duration 약 40%, delay 두 구간은 각 10% 미만이다. delay가 붙은 두 구간은 0에 가까울수록 좋다. WebP로 load duration을 줄여도, 그 시간이 render delay로 옮겨가면 LCP 숫자는 그대로일 수 있다. PSI가 가리킨 LCP 요소가 히어로 이미지가 아니라 큰 제목 텍스트이면, 이미지 압축은 그 지표를 거의 안 움직인다. 화면에서 LCP 요소를 먼저 읽고 네 구간 중 어디가 큰지를 본다. delay가 크면 압축이 아니라 발견 시점이나 메인 스레드다.

PSI가 가리킨 LCP 요소가 히어로 이미지가 아니라 큰 제목 텍스트이면, 이미지 압축은 그 지표를 거의 안 움직인다. 화면에서 LCP 요소를 먼저 읽고 네 구간 중 어디가 큰지를 본다.

preload scanner와 LCP 발견

브라우저는 HTML을 읽는 동안 preload scanner가 이미지와 스크립트 주소를 미리 찾는다. LCP 리소스가 JS로 동적으로 추가되거나 data-src 뒤에 있으면, 그 스캐너가 주소를 늦게 본다. CSS background-image에만 있어도 HTML 태그로 안 보여 발견이 늦다. Resource load delay가 크면 압축이 아니라 이 발견 시점이 병목이다. <img src>로 뷰포트 안에 두면 스캐너가 일찍 받는다.

lazy는 뷰포트 밖 이미지를 늦게 받기 위한 속성이다. 첫 화면의 가장 큰 그림에 loading="lazy"를 걸면 Resource load delay가 커진다. fetchpriority="high"는 브라우저에게 그 리소스를 앞에 두라는 힌트다. 모든 이미지에 붙이면 힌트가 희석된다. 필요한 경우에 제한적으로 쓴다.

INP가 가리키는 시점

필드 지표 INP는 클릭이나 탭 뒤에 다음 페인트까지다. 출처 문서 기준으로 2024년 3월부터 FID를 대신하는 Core Web Vital이다. 랩의 TBT는 첫 로드에서 메인 스레드가 50ms를 넘는 초과분의 합이다. 50ms짜리 작업은 TBT에 안 들어간다. 80ms짜리 작업은 30ms가 합계에 더해진다. 상호작용 이후에만 무거워지는 위젯은 TBT보다 INP에서 더 크게 드러날 수 있다. 댓글 위젯을 본문 아래에 두고 첫 로드에서는 안 불러도, 사용자가 댓글 칸을 여는 순간 INP가 나빠질 수 있다. 랩 TBT가 괜찮아 보여도 필드 INP가 나쁘면, 첫 로드가 아니라 클릭 뒤 스크립트가 병목이다. 둘을 같은 숫자로 취급하지 않는다.

CLS

CLS 배점은 25%다. 레이아웃이 밀린 정도를 면적과 거리로 곱해 합친 값이다. 위 문장이 아래로 밀리면 손가락이 누르려던 곳이 광고가 된다. 애드센스를 붙인 사이트에서 CLS를 망치는 주범은 거의 항상 광고 슬롯이다. 웹폰트가 뒤늦게 바뀌며 줄 높이가 달라지는 경우도 있다. font-display: swap은 FCP를 살리는 대신, 폴백과 본 글꼴의 폭이 다르면 CLS를 키울 수 있다.

해법은 공간 예약이다. 예상되는 가장 큰 크기 기준으로 min-height 또는 aspect-ratio를 잡는다. 작은 광고 기준이 아니다. 예약 값의 예는 다음 블록이다.

.ad-slot {
  min-height: 280px;
  min-width: 300px;
}

280px와 300px는 예약의 예이지, 모든 슬롯의 공식 크기는 아니다. 실제로 내려오는 가장 큰 유닛을 기준으로 잡는다. 빈 칸이 커 보여도, 밀리는 본문보다 심사와 점수에 덜 해롭다.

광고 슬롯

「광고 스크립트를 window load 이후로 미룬다」는 조언은 주의가 필요하다. Auto ads를 쓰거나 반응형 유닛 크기를 예약하지 않은 상태라면, 늦게 들어온 광고가 이미 그린 레이아웃을 밀어 CLS를 더 악화시킬 수 있다. 수익이 흔들릴 수도 있다. 무조건 지연이 아니라 공간 예약 먼저, 그다음 실제 CLS 재측정이다.

Effectively loading ads without impacting page speed와 Minimize Layout Shift가 이 구간의 1차 출처다. 슬롯을 본문 한가운데에 넣으면 광고가 도착하는 순간 아래 문장 전체가 밀린다. 사이드나 문단 사이라도 min-height가 없으면 같다. Auto ads는 삽입 위치를 페이지가 고르므로, 예약 없는 지연과 겹치면 CLS가 더 커질 수 있다.

광고가 붙은 페이지는 서빙되는 광고에 따라 점수가 흔들린다. 같은 URL을 두세 번 돌려 중앙값을 본다. 점수가 떨어지면 되돌린다. 속도 점수를 위해 광고를 숨기는 편법은 정책 리스크다.

ExtraBold 폰트

실무에서 반복되는 실패는 여기다. ExtraBold를 없애려고 CSS의 font-weight: 800과 900을 전부 700으로 바꿨는데, 네트워크 탭에는 ExtraBold 파일이 그대로 내려온다.

원인은 어딘가에 850, 950 같은 값이 남은 것이다. font-weight는 100부터 900까지 임의 정수를 받는다. 브라우저는 850을 만나면 가장 가까운 무게의 페이스를 다시 가져온다. 숫자 치환만으로 끝나지 않는 이유가 여기 있다. 쓰지 않는 weight의 @font-face 선언 자체를 지우고, 네트워크 워터폴에서 실제 다운로드가 사라졌는지 본다.

800과 900만 700으로 바꿔도, 테마 변수에 850이 남아 있으면 ExtraBold 파일이 다시 받는다. @font-face 선언이 글로벌 CSS에 남아 있으면 본문이 700만 써도 브라우저가 그 페이스를 받을 수 있다. rg "font-weight:\\s*[0-9]{3}" ./src가 세 자리 숫자를 전수 찾는다. rg "@font-face" ./src -n이 선언 위치를 줄 번호와 같이 보여 준다. 네트워크 워터폴에서 ExtraBold 파일이 사라진 뒤에만 이 절을 끝낸다. 요청문의 font-weight 전수 검색 줄이 그 실패를 계약으로 고정한다.

검색 명령의 예는 다음 블록이다.

rg "font-weight:\\s*[0-9]{3}" ./src
rg "@font-face" ./src -n

첫 줄은 세 자리 무게 숫자를 전수 찾는다. 800과 900만 바꾸면 850이 남는다. 둘째 줄은 @font-face 선언 위치를 줄 번호와 같이 보여 준다. 선언이 CSS에 남아 있으면, 본문이 700만 써도 브라우저가 ExtraBold 파일을 받을 수 있다.

글로벌 CSS가 렌더를 막는 동안 @font-face가 그 안에 있으면 폰트까지 크리티컬 체인에 묶인다. fonts.css로 분리해 비동기로 로드하는 방식이 실제로 효과를 낸 사례가 있다. font-display: swap이나 optional을 의도적으로 고르고, 한글 폰트는 서브셋이나 weight 축소를 같이 본다. Google Fonts best practices가 이 구간의 1차 출처다.

swap은 폴백 글꼴로 먼저 그린 뒤 본 글꼴로 바꾼다. FCP는 살아도, 폴백과 본 글꼴의 폭이 다르면 CLS가 커질 수 있다. optional은 그 바꾸기를 제한한다. 한글 웹폰트는 라틴보다 파일이 크다. weight를 700 하나로 줄이고 서브셋하면 ExtraBold 다운로드와 렌더 차단이 같이 줄어든다. 네트워크 워터폴에서 ExtraBold 파일이 사라진 뒤에만 이 절을 끝낸다.

재측정

하루에 진단 하나만 고친다. 두 개를 동시에 바꾸고 점수가 떨어지면 어느 쪽이 원인인지 구분하기 어렵다. 재측정은 같은 URL, 같은 전략으로 한다. 성공 기준은 점수가 아니라 진단 원문이 사라졌는지다. 이미 90대라면 점수 차이는 작게 보일 수 있다.

AI에게 숫자만 던지면 캐시 헤더나 이미지 압축부터 만지기 쉽다. 진단 원문이 계약서다. 요청문에 넣을 측정값과 제약의 뼈대는 다음 블록이다.

목표: PSI 모바일 랩에서 [진단 원문 그대로]를 제거한다.
제약: 관련 없는 대규모 리팩터 금지. 광고 슬롯 min-height는 제거하지 말 것. 변경 파일 3개 이하.
작업: 원인 특정 후 확인받은 뒤 수정. font-weight는 800/900뿐 아니라 850/950 등 세 자리 숫자 전수 검색.
검증: 동일 URL, 동일 전략(모바일)으로 재실행. 진단 원문이 사라졌는지 확인.

대괄호 안은 PSI 화면에 적힌 문장을 그대로 붙이는 자리다. 의역하면 에이전트가 다른 진단을 고친다. min-height를 빼지 말라는 줄은 CLS 예약을 속도 점수를 위해 지우는 실패를 막는다. 변경 파일 3개 이하는 점수 하나를 위해 테마 전체를 갈아엎는 확장을 막는다. font-weight 전수 검색 줄은 800과 900만 바꾸고 850을 남기는 실패를 막는다.

광고가 붙은 페이지는 서빙되는 광고에 따라 점수가 흔들린다. 같은 URL을 두세 번 돌려 중앙값을 본다. 점수가 떨어지면 되돌린다. 필드가 데이터 없음이면 신규나 저트래픽에서 흔하다. 필드가 없다고 점검을 미룰 필요는 없다. 모바일과 데스크톱은 전략이 다르다. 애드센스 심사 전 점검은 모바일 랩을 기준으로 두는 편이 본문에 맞다. 폰의 뷰포트와 느린 CPU에서 TBT와 CLS가 더 크게 드러난다.

저가치 콘텐츠 반려는 속도 점수로 덮이지 않는다. 빈 목록 200, 주제 분산, 서술 없는 표만 있는 본문이 심사와 색인을 같이 나쁘게 만든다. 공개 URL 세 종(홈, 대표 글, 목록)이 빈 본문 200이 아닌지, 문서 0건 카테고리가 내비와 사이트맵에 없는지, 개인정보처리방침과 쿠키 광고 고지, ads.txt, HTTPS가 있는지가 속도 측정 앞에 온다. 속도 점수를 위해 콘텐츠를 지우거나 광고를 숨기는 편법은 정책 리스크다.

애드센스 콘텐츠가 속도보다 앞서는 이유

PSI 점수 99를 만들어도 콘텐츠가 부족하면 반려된다. 반대는 성립하지 않는다. 흔한 반려 사유인 low value content의 실제 원인은 서술형 텍스트 부족, 주제 분산, 빈 목록 200(soft-404)인 경우가 많다. 표와 데이터만 많고 서술이 없으면 크롤러가 본문을 약하게 본다. 원예, 금융, 여행, 개발을 한 블로그에서 다루면 깊이가 얕아진다. 문서 0건 카테고리가 헤더와 푸터만 달고 200으로 열리면 심사와 색인이 같이 나빠진다.

공개 URL 세 종(홈, 대표 글, 목록)이 빈 본문 200이 아닌지, 문서 0건 카테고리가 내비와 사이트맵에 없는지, 개인정보처리방침과 쿠키 광고 고지, ads.txt, HTTPS가 있는지가 속도 측정 앞에 온다. 자격 요건과 필수 콘텐츠 고지는 AdSense Help가 기준이다.

CrUX와 랩

랩은 Lighthouse가 그 순간 그 환경에서 한 번 측정한 값이다. CPU와 네트워크를 제한한 실험실에 가깝다. 필드는 Chrome User Experience Report가 실제 사용자에게서 모은 값이다. 신규나 저트래픽이면 필드가 비어 있는 상태가 흔하다. 필드가 없다고 점검을 미룰 필요는 없다. CrUX 표본이 쌓이기 전에는 랩으로 병목을 자른다.

화면 상단의 URL과 Origin 토글이 이 차이를 가른다. 오리진은 도메인 전체의 표본이다. 대표 글만 고쳤는데 필드가 안 움직이면, 보고 있는 숫자가 URL이 아니라 오리진일 수 있다. 모바일과 데스크톱은 전략이 다르다. 애드센스 심사 전 점검은 모바일 랩을 기준으로 두는 편이 본문에 맞다. 폰의 뷰포트와 느린 CPU에서 TBT와 CLS가 더 크게 드러난다.

INP는 필드 지표다. 2024년 3월부터 FID를 대신하는 Core Web Vital이다. 랩에서는 TBT, 실제 사용자에서는 INP를 같이 본다. 상호작용 이후에만 무거워지는 위젯은 TBT보다 INP에서 더 크게 드러날 수 있다. 클릭한 뒤에 메인 스레드가 막히면 다음 페인트가 늦다. 랩의 TBT가 괜찮아 보여도 필드 INP가 나쁘면, 첫 로드가 아니라 클릭 뒤 스크립트가 병목이다.

광고가 붙은 페이지는 서빙되는 광고에 따라 점수가 흔들린다. 같은 URL을 두세 번 돌려 중앙값을 본다. 점수가 떨어지면 되돌린다. 하루에 진단 하나만 고치는 이유는, 두 개를 동시에 바꾸고 점수가 떨어지면 어느 쪽이 원인인지 구분하기 어려워서다. 재측정은 같은 URL, 같은 전략이다.

랩은 광고 슬롯에 어떤 크리에이티브가 들어왔는지와 무관하게, 그 순간의 스크립트와 레이아웃을 잰다. 필드는 실제 폰에서 실제 광고가 들어온 뒤의 INP와 LCP다. 둘을 같은 점수로 맞추려 하면 랩만 쫓게 된다. 심사 전 점검은 랩의 진단 원문을 지우는 일이고, 필드 INP는 표본이 쌓인 뒤에 같이 본다. About PageSpeed Insights 문서가 랩과 필드를 나란히 보여 주는 이유를 설명한다.

진단 원문을 계약으로 두는 이유

「개선할 항목」에 적힌 초는 점수 입력이 아니다. 구글 문서가 말하듯 점수를 만드는 것은 다섯 지표다. 진단은 그 지표를 움직이기 위한 힌트다. 「미사용 JS 제거 0.8초」를 고쳤는데 점수가 그대로인 이유가 여기 있다. 그 스크립트가 메인 스레드 50ms를 넘는 롱태스크가 아니면 TBT 30%는 안 움직인다. 이미지만 압축하면 LCP의 load duration은 줄어도, render delay로 옮겨가면 LCP 25%는 그대로일 수 있다.

AI에게 숫자만 던지면 캐시 헤더나 이미지 압축부터 만지기 쉽다. 요청문의 목표 줄에 PSI 모바일 랩에서 진단 원문 그대로를 제거한다고 적는 이유가 여기 있다. 대괄호 안을 의역하면 에이전트가 다른 진단을 고친다. 제약 줄의 관련 없는 대규모 리팩터 금지와 변경 파일 3개 이하는, 점수 하나를 위해 테마 전체를 갈아엎는 확장을 막는다. 광고 슬롯 min-height를 제거하지 말라는 줄은, CLS 예약을 속도 점수를 위해 지우는 실패를 막는다.

font-weight는 800과 900뿐 아니라 850과 950 등 세 자리 숫자를 전수 검색한다. 브라우저는 850을 만나면 가장 가까운 무게의 페이스를 다시 가져온다. @font-face 선언이 CSS에 남아 있으면, 본문이 700만 써도 ExtraBold 파일이 내려온다. rg "font-weight:\\s*[0-9]{3}" ./src가 그 전수의 검색이다. rg "@font-face" ./src -n은 선언 위치를 줄 번호와 같이 보여 준다.

검증 줄은 동일 URL, 동일 전략(모바일)으로 재실행하고, 진단 원문이 사라졌는지를 본다. 이미 90대라면 점수 차이는 작게 보일 수 있다. 성공 기준은 숫자 100이 아니라 그 문장이 화면에서 빠졌는지다. PSI 점수 몇 점이면 심사에 안전하다는 공식 기준선은 없다. 핵심은 가치 있는 콘텐츠와 정책 준수다.

공개 URL 세 종(홈, 대표 글, 목록)이 빈 본문 200이 아닌지, 문서 0건 카테고리가 내비와 사이트맵에 없는지, 개인정보처리방침과 쿠키 광고 고지, ads.txt, HTTPS가 있는지가 속도 측정 앞에 온다. 표와 데이터만 많고 서술이 없으면 크롤러가 본문을 약하게 본다. 원예, 금융, 여행, 개발을 한 블로그에서 다루면 깊이가 얕아진다. PSI 점수 99를 만들어도 콘텐츠가 부족하면 반려된다. 반대는 성립하지 않는다.

FCP 10%는 첫 픽셀이 그려진 시점이다. Speed Index 10%는 화면이 채워지는 속도다. 여기만 만지면 점수의 절반 이상이 그대로다. TBT 30%와 CLS 25%를 합치면 55%다. 둘 다 자바스크립트와 광고가 원인인 경우가 많다. 콘텐츠 블로그에서는 광고 스크립트, 애널리틱스, 댓글 위젯, 소셜 임베드, 무거운 테마 JS가 TBT의 롱태스크로 잡힌다. 댓글 위젯이 본문 아래에만 있으면 첫 화면 뒤에 불러도 된다. 광고와 분석은 심사와 정산에 묶여 있어 제거가 답이 아닐 때가 많다. 그때는 슬롯 예약과 로드 순서가 TBT와 CLS를 같이 움직인다.

LCP 요소가 히어로 이미지가 아니라 큰 제목 텍스트이면, 이미지 압축은 그 지표를 거의 안 움직인다. TTFB가 크면 서버와 CDN, 리다이렉트, HTML 생성이다. Resource load delay가 크면 LCP 리소스를 늦게 발견한 것이다. data-src 뒤나 CSS background-image에만 있으면 preload scanner가 늦게 발견한다. 뷰포트 안 LCP 이미지에는 loading="lazy"를 걸지 않는다. fetchpriority="high"는 필요한 경우에 제한적으로 쓴다.

모바일 랩에서 고치는 순서

준비물은 홈, 대표 글, 목록 URL 하나씩과 PSI 모바일 랩 결과다. 측정은 대표 URL 한 번, 성능 점수와 FCP LCP TBT CLS 화면 저장, CrUX가 URL 단위인지 오리진 단위인지, LCP 요소가 무엇인지다. 고치기는 LCP 4구간 지연, TBT 상위 롱태스크, 광고 슬롯 min-height, 폰트 렌더 차단 순이다. 이 순서는 배점이 큰 쪽부터다. TBT 30%를 건너뛰고 이미지만 만지면 점수가 안 움직이는 이유가 된다.

광고 슬롯 예약의 min-height: 280px와 min-width: 300px는 예상되는 가장 큰 크기 기준의 예다. 작은 광고 기준이 아니다. 빈 칸이 커 보여도, 밀리는 본문보다 심사와 점수에 덜 해롭다. Auto ads를 쓰거나 반응형 유닛 크기를 예약하지 않은 상태에서 스크립트를 window load 이후로 미루면, 늦게 들어온 광고가 이미 그린 레이아웃을 민다. CLS와 수익이 같이 흔들릴 수 있다. Effectively loading ads without impacting page speed와 Minimize Layout Shift가 이 구간의 1차 출처다.

글로벌 CSS가 렌더를 막는 동안 @font-face가 그 안에 있으면 폰트까지 크리티컬 체인에 묶인다. fonts.css로 분리해 비동기로 로드하는 방식이 실제로 효과를 낸 사례가 있다. font-display: swap은 FCP를 살리는 대신, 폴백과 본 글꼴의 폭이 다르면 CLS를 키울 수 있다. optional을 의도적으로 고르고, 한글 폰트는 서브셋이나 weight 축소를 같이 본다. Google Fonts best practices가 이 구간의 1차 출처다.

증상 표의 다섯 행이 재측정의 분기이다. 800을 700으로 바꿨는데 ExtraBold가 내려오면 850/950 잔존 또는 선언 미삭제다. 이미지 압축했는데 LCP가 그대로면 줄어든 시간이 render delay로 이동한 것이다. 미사용 JS를 줄였는데 점수가 그대로면 메인 스레드 차단이 아니었던 것이다. 광고 지연 후 CLS가 악화되면 공간 예약 없이 지연한 것이다. 필드 데이터가 URL과 다르면 오리진 단위 표시 중이다. PSI 상단에서 URL과 Origin을 확인한다.

이미 90점을 넘긴 뒤에는 숫자 100보다 진단 원문이 사라졌는지를 본다. 애드센스 심사에는 그 시간이 글 한 편보다 가치가 낮을 수 있다. 속도 점수를 위해 콘텐츠를 지우거나 광고를 숨기는 편법은 정책 리스크다. 자격 요건과 필수 콘텐츠 고지는 AdSense Help가 기준이다. 빈 목록 200, 느린 첫 화면, 과도한 서드파티는 심사와 색인, 이탈을 같이 나쁘게 만들 수 있다.

마무리

앞에서 다룬 애드센스 심사 전 PSI 점검의 핵심만 짧게 정리한다.

• Lighthouse 10 성능 점수는 TBT 30%, LCP 25%, CLS 25%, FCP 10%, SI 10%다.
• 진단 목록은 힌트이고, 성공 기준은 진단 원문이 사라졌는지다.
• 콘텐츠와 정책 고지가 속도 측정보다 앞에 있다.
• LCP는 네 구간의 합이며 delay가 크면 압축이 답이 아니다.
• 광고 CLS는 공간 예약이 지연보다 앞선다.
• 폰트는 800만 바꾼 상태로는 부족하고, 세 자리 숫자와 @font-face를 같이 본다.
• 하루에 진단 하나, 같은 URL과 같은 전략으로 재측정한다.

「점수를 쫓기 전에 배점과 진단 원문을 계약으로 둔다」 필드 데이터가 없어도 랩으로 병목을 자를 수 있다.

출처와 링크

• PageSpeed Insights: https://pagespeed.web.dev/
• About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Lighthouse performance scoring: https://developer.chrome.com/docs/lighthouse/performance/performance-scoring/
• Optimize Largest Contentful Paint: https://web.dev/articles/optimize-lcp
• Interaction to Next Paint: https://web.dev/inp/
• Minimize Layout Shift: https://developers.google.com/publisher-tag/guides/minimize-layout-shift
• Effectively loading ads without impacting page speed: https://web.dev/articles/loading-ads-page-speed
• Google Fonts best practices: https://web.dev/articles/font-best-practices
• AdSense 자격 요건: https://support.google.com/adsense/answer/9724
• 필수 콘텐츠 및 고지: https://support.google.com/adsense/answer/1348695?hl=ko

조사 기준: 2026년 8월. 랩 점수는 흔들리므로 진단 원문 제거 여부를 성공 기준으로 둔다. Lighthouse 버전이 바뀌면 배점부터 공식 문서를 다시 연다.