Search Console의 CLS 문제를 해결하는 최고의 팁

Table of contents

CLS: 배경 지식

Cumulative Layout Shift는 예상치 못한 레이아웃 이동을 측정합니다. 페이지가 로딩되거나 상호작용이 이루어지는 동안 눈에 보이는 요소가 위치를 바꿀 때마다 레이아웃 이동 점수가 계산됩니다. 이 누적 점수가 CLS입니다.

주요 원인:

• 명시적인 width 및 height 속성이 없는 이미지 또는 iframe
• 주변 콘텐츠가 이미 렌더링된 후 확장되는 광고
• 기존 콘텐츠 위에 삽입되는 동적으로 주입된 콘텐츠(배너, 쿠키 안내, 채팅 위젯)
• 로딩 시 플래시와 리플로우를 일으키는 웹 폰트(FOUT/FOIT)
• 초기 렌더링 후 UI 요소를 추가하는 서드파티 JavaScript

관련 글: Search Console에서 LCP 문제를 해결하는 방법

CLS 측정하기

Google Search Console

Search Console의 Core Web Vitals 보고서가 출발점입니다. 문제 유형별로 그룹화된 「나쁨」(CLS ≥ 0.25) 또는 「개선 필요」(0.1–0.25)로 플래그된 페이지를 보여줍니다. 이 보고서를 사용해 영향을 받는 URL 목록을 확인하세요.

PageSpeed Insights

PageSpeed Insights(PSI)는 실험실 데이터(Lighthouse 시뮬레이션)와 Chrome UX Report(CrUX)를 통한 실제 사용자의 현장 데이터를 모두 보여줍니다. 현장 데이터가 순위 목적으로 더 중요합니다—단순 합성 테스트가 아닌 실제 사용자 경험을 반영합니다.

PSI는 로딩 시 초기 뷰포트만 시뮬레이션하므로 스크롤이나 사용자 상호작용에 의해 발생하는 CLS를 놓칠 수 있습니다. 그런 경우에는 Chrome DevTools를 사용하세요.

Chrome DevTools와 Web Vitals 확장 프로그램

Web Vitals Chrome 확장 프로그램(Google이 유지 관리)은 페이지를 스크롤하고 상호작용하면서 실시간 CLS 점수를 표시합니다. 레이아웃 이동을 수동으로 재현하는 가장 빠른 방법입니다. Chrome DevTools의 Performance 패널도 어떤 요소가 얼마나 이동했는지를 보여주는 주석과 함께 레이아웃 이동 기록을 강조 표시합니다.

CLS 문제 해결

모든 이미지와 iframe에 width와 height 추가하기

대부분의 사이트에서 가장 효과가 큰 수정 방법입니다. 명시적인 크기가 없으면 브라우저는 이미지가 로딩되는 동안 얼마나 많은 공간을 확보해야 하는지 알 수 없어, 이미지가 나타날 때 아래 콘텐츠가 아래로 밀려납니다.

<!-- 나쁜 예: 크기 없음 -->
<img src="photo.jpg" alt="…">

<!-- 좋은 예: 명시적인 크기로 브라우저가 공간을 확보할 수 있음 -->
<img src="photo.jpg" alt="…" width="800" height="450">

현대 CSS(aspect-ratio)는 반응형 이미지에 동일한 효과를 제공하지만, HTML에서 width와 height 속성을 명시적으로 설정하는 것이 가장 신뢰할 수 있는 방법이며 대부분의 현대 프레임워크와 CMS 이미지 파이프라인이 자동으로 처리합니다.

광고 공간 예약하기

광고는 수익화된 사이트에서 높은 CLS의 가장 흔한 원인입니다. 광고 네트워크는 동적인 크기를 제공하며, 공간이 예약되지 않으면 광고가 로딩될 때 페이지가 리플로우됩니다.

1. 광고 태그가 로딩되기 전에 고정 컨테이너(가장 일반적인 광고 크기에 맞는 min-height)를 예약하세요.
2. 광고가 게재되지 않더라도 컨테이너를 접지 마세요—빈 플레이스홀더로 두 번째 리플로우를 방지합니다.
3. 뷰포트 상단 근처에 배치된 광고에 특히 주의하세요. 폴드 위에 삽입된 비고정 광고는 최악의 CLS 점수를 유발합니다.
4. 광고 네트워크의 과거 노출 데이터를 사용해 각 슬롯에서 가장 일반적인 광고 크기를 파악하고, 그에 맞게 컨테이너 크기를 설정하세요.

기존 콘텐츠 위에 콘텐츠 삽입 피하기

비동기적으로 로딩되어 기존 콘텐츠 위에 나타나는 쿠키 동의 배너, 알림 프롬프트, 채팅 위젯은 빈번한 CLS 원인입니다. 해결 방법:

• 고정 위치 오버레이에서 로딩하세요(문서 흐름에 영향을 주지 않습니다).
• 인라인으로 나타나야 한다면 레이아웃에서 미리 공간을 할당하세요.
• 쿠키 배너의 경우 특히 화면 하단 배치를 고려하세요—CLS를 완전히 방지하며 규정 준수에도 동일하게 유효합니다.

웹 폰트 로딩 수정하기 (FOIT와 FOUT)

FOIT(Flash of Invisible Text)는 커스텀 폰트가 로딩될 때까지 브라우저가 텍스트를 숨길 때 발생합니다. FOUT(Flash of Unstyled Text)는 폴백 폰트가 먼저 표시된 후 교체될 때 발생합니다—폰트 메트릭 차이가 레이아웃 이동을 유발합니다.

해결책은 중요한 폰트에 <link rel="preload">와 결합한 font-display: swap입니다:

<link rel="preload" href="/fonts/my-font.woff2" as="font" type="font/woff2" crossorigin>

@font-face {
  font-family: 'MyFont';
  src: url('/fonts/my-font.woff2') format('woff2');
  font-display: swap;
}

font-display: swap은 FOIT(보이지 않는 텍스트) 대신 FOUT(보이지만 스타일이 없는 텍스트)를 발생시킵니다. 텍스트가 즉시 보이기 때문에 CLS에 더 유리합니다. 교체의 지표 영향을 더욱 줄이려면 CSS 속성 size-adjust를 사용해 폴백 폰트 메트릭을 커스텀 폰트와 일치시키세요—커스텀 폰트가 적용될 때의 리플로우를 최소화합니다.

서드파티 JavaScript

서드파티 스크립트(공유 버튼, 댓글 위젯, 라이브 채팅, 분석 팝업)는 비동기적으로 로딩되며 페이지가 이미 렌더링된 후에 UI 요소를 주입하는 경우가 많습니다. CLS 영향을 최소화하려면:

• 가능한 한 서드파티 시각적 요소를 초기 뷰포트 아래로 배치하세요—페이지 하단의 콘텐츠는 사용자가 도달하기 전에 로딩할 시간이 더 많습니다.
• 스크립트가 실행되기 전에 컨테이너 크기를 미리 정의해 브라우저가 이미 얼마나 많은 공간을 확보해야 하는지 알 수 있도록 하세요.
• 서드파티 출처로 필터링된 Chrome DevTools의 Network 탭을 사용해 레이아웃 이동에 기여하는 스크립트를 파악하세요.

레이지 로딩과 플레이스홀더

레이지 로딩은 이미지가 뷰포트에 가까워질 때까지 로딩을 지연시켜 대역폭을 절약합니다. 그러나 플레이스홀더가 설정되지 않으면 이미지 컨테이너가 높이 0으로 접혔다가 이미지가 로딩될 때 갑자기 열립니다.

레이지 로딩된 요소에는 항상 명시적인 크기나 CSS로 설정된 aspect-ratio가 있는지 확인하세요—이미지가 로딩되기 전에도 브라우저가 올바른 공간을 확보할 수 있게 합니다. 이는 네이티브 loading="lazy"와 JavaScript 기반 레이지 로더 모두에 적용됩니다.

CLS — 2026년 FAQ

2026년에도 FID가 순위 신호인가요?

아닙니다. Google은 2024년 3월 FID(First Input Delay)를 Core Web Vital에서 공식 폐지하고 INP(Interaction to Next Paint)로 대체했습니다. 현재 CWV 트리오는 LCP, INP, CLS입니다. 아직 FID를 참조하는 내부 문서나 도구를 업데이트하세요.

목표해야 할 좋은 CLS 점수는?

Google의 임계값: 0.1 미만은 「좋음」, 0.1–0.25는 「개선 필요」, 0.25 초과는 「나쁨」입니다. 0.1 미만을 목표로 하세요. 점수는 CrUX 현장 데이터의 페이지 로드 75번째 백분위수에서 측정됩니다.

CLS가 순위에 영향을 미치나요?

네, 하지만 많은 신호 중 하나입니다. Core Web Vitals는 2021년 중반부터 페이지 경험 순위 요인이었습니다. 나쁜 CLS가 강력한 페이지를 무너뜨리지는 않겠지만, 동점 상황에서 결정적 요인이 될 수 있으며 사용자 참여 지표(이탈률, 세션 깊이)에도 직접 악영향을 줄 수 있습니다.

PSI 점수에서는 좋은 CLS를 보여주는데 Search Console이 페이지를 나쁨으로 표시한다면—어느 것이 맞나요?

충돌이 있을 때는 PSI 실험실 데이터보다 Search Console(현장 데이터)을 신뢰하세요. PSI 실험실 테스트는 초기 뷰포트 로딩만 시뮬레이션합니다—사용자 스크롤, 느린 연결에서의 폰트 교체, 상호작용 후 로딩되는 광고로 발생하는 CLS는 놓칩니다. Search Console의 CrUX 현장 데이터는 실제 조건에서 실제 사용자를 반영합니다.

관련 읽을거리:

• Search Console에서 LCP 문제를 해결하는 방법
• 웹사이트 속도를 최적화하는 방법
• 기술적 SEO 감사

짧은 버전

여기서 설명하는 워크플로가 한 주를 통째로 잡아먹고 있어서 이 글을 읽고 있다면, 바로 그런 루프를 위해 저는 AI 에이전트를 구축합니다. 동시에 두 개의 개발 슬롯이 열려 있습니다.

2026년 5월 업데이트

2026년 Google의 이야기는 AI Overviews가 모든 곳에: 2023년의 SGE 실험이 2024년 5월 기본 기능으로 졸업했으며 이제 **미국 정보성 검색의 약 60%**에 표시됩니다. SEO 및 광고 운영자의 경우:

• AI Overviews가 있는 쿼리의 자연 검색 CTR이 평균 15–30% 하락했습니다(Ahrefs, Authoritas 등의 2024–25년 데이터 기반 발표 연구).
• Google Ads는 여러 PMax 기능을 AI-powered Search로 리브랜딩했습니다. 캠페인 관리 UI는 이제 기본적으로 AI 입찰 제안을 표시합니다.
• Search Console은 2025년 말에 「AI Overview 노출수」 필터를 추가했습니다—이 사이트의 글 중 GSC 보고를 언급하는 것은 플레이북 업데이트가 필요합니다.
• Google의 광고 수익은 2024년 ~2,650억 달러를 돌파했습니다. Search는 여전히 Alphabet 총 수익의 약 57%를 차지합니다.

2026년 「Google이 돈을 버는 방법」의 답변: 여전히 검색 광고(지배적)지만, YouTube 광고, Cloud, 구독(YouTube Premium + Google One)도 이제 중요한 수익 라인입니다.