CLS란 무엇인가

CLS(Cumulative Layout Shift, 누적 레이아웃 이동)는 웹페이지가 표시되는 동안 이미 보이던 요소가 사용자 조작 없이 위치를 옮긴 정도를 점수로 재는 구글의 시각적 안정성 지표다. 시간이 아니라 비율의 곱이라 단위가 없다.

구글은 페이지 전체 수명 주기에서 일어난 예기치 않은 레이아웃 이동 가운데 가장 큰 묶음(세션 창)의 점수를 CLS로 삼는다. 이동 사이 간격이 1초 미만이고 전체 길이가 5초 이하인 연속 이동을 한 묶음으로 본다 (web.dev, 레이아웃 변경 횟수(CLS)).

코어 웹 바이탈 세 지표 중 로딩은 LCP, 반응성은 INP, 시각적 안정성은 CLS가 맡는다.

같은 약자가 다른 뜻으로 더 많이 쓰인다. 구글 “CLS” 1페이지는 메르세데스 벤츠 CLS, 쿠팡 로지스틱스 서비스, 셀레스티카 주식 티커가 채우고 웹 지표는 web.dev 한 건뿐이다.

이 문서는 웹 성능 지표 CLS만 다룬다.

CLS는 몇 점을 넘으면 나쁨인가?

0.1 이하면 좋음, 0.25를 넘으면 나쁨이고, 판정은 페이지 조회의 75번째 백분위수로 한다 (web.dev, CLS, 위 인용).

판정CLS기준
좋음0.1 이하75번째 백분위수
개선 필요0.1 초과 0.25 이하75번째 백분위수
나쁨0.25 초과75번째 백분위수

0.1이라는 숫자는 사람이 느끼는 정도에서 나왔다. 구글 내부 테스트에서 0.15 이상 이동은 일관되게 방해로 인식됐고 0.1 이하는 눈에 띄지만 지나치게 방해되지는 않았으며, CrUX 데이터에서 출처의 거의 50%가 0.05 이하였다 (web.dev, Core Web Vitals 측정항목 기준 정의).

LCP보다 통과율이 높다. HTTP Archive 2024년 웹 연감 기준 데스크톱 사이트의 72%, 모바일 사이트의 79%가 좋음 판정을 받았고, 모바일이 데스크톱보다 안정적이라는 점이 다른 지표와 다르다 (HTTP Archive, Web Almanac 2024 Performance).

검색 순위에는 코어 웹 바이탈의 일부로 쓰인다. 다만 구글은 좋은 점수가 상위 노출을 보장하지 않으며 완벽한 점수를 위한 최적화는 시간 낭비일 수 있다고 안내한다 (Google 검색 센터, 페이지 경험 이해하기).

CLS 점수는 어떻게 계산되는가?

개별 레이아웃 이동 점수는 영향 분수와 거리 분수의 곱이다. 영향 분수는 이동 전후 요소가 차지한 영역의 합집합이 뷰포트에서 차지하는 비율이고, 거리 분수는 요소가 움직인 최대 거리를 뷰포트의 긴 변으로 나눈 값이다 (web.dev, CLS, 위 인용).

구글의 예를 그대로 옮기면 이렇다. 뷰포트 절반을 차지하던 요소가 뷰포트 높이의 25%만큼 아래로 밀리면 합집합은 75%라 영향 분수 0.75, 거리 분수 0.25, 점수는 0.1875다.

모든 이동이 점수에 들어가지는 않는다. 클릭이나 탭, 키 입력 뒤 500밀리초 안에 일어난 이동에는 hadRecentInput 플래그가 붙어 제외되고, 스크롤이나 드래그 같은 연속 동작은 최근 입력으로 치지 않는다.

CLS는 페이지가 열려 있는 내내 잰다. 그래서 로드 직후만 보는 실험실 도구보다 실제 사용자 데이터가 높게 나오는 경우가 많다.

CLS는 무엇 때문에 생기는가?

크기가 지정되지 않은 이미지, 크기가 없는 광고와 삽입 콘텐츠, 레이아웃을 건드리는 애니메이션, 웹 글꼴 교체 네 가지가 대표 원인이다 (web.dev, 레이아웃 변경 누적 최적화).

원인왜 밀리는가규모
크기 없는 이미지브라우저가 공간을 예약하지 못해 로드 뒤 아래 내용이 밀린다모바일 페이지의 66%에 크기 미지정 이미지가 1개 이상
광고, 삽입, iframe나중에 들어오는 콘텐츠가 자리를 차지한다게재되는 광고 크기가 여러 가지라 예약이 어렵다
애니메이션width, margin처럼 레이아웃을 바꾸는 속성을 움직이면 주변이 밀린다transform 애니메이션은 CLS에 들어가지 않는다
웹 글꼴대체 글꼴과 웹 글꼴의 크기 차이로 텍스트가 재배치된다모바일 페이지의 85%가 웹 글꼴 사용

크기 미지정 이미지 66%와 웹 글꼴 85%는 2024년 웹 연감 수치이고, 66%는 2022년 72%에서 개선된 값이다 (HTTP Archive, 위 인용).

광고는 원인 중 가장 다루기 까다롭다. 구글 게시자 태그 가이드는 한 슬롯에 300x250이 70%, 320x50이 30% 게재된다면 세로 250px을 예약하는 식으로, 실제 노출 비율을 보고 min-height를 정하라고 안내한다 (Google Publisher Tag, 레이아웃 변경 최소화).

CLS는 어떻게 측정하는가?

실제 사용자 데이터인 필드 값과 통제된 환경의 랩 값을 나눠 본다. 판정에 쓰이는 것은 필드 값이다.

  1. 서치 콘솔 Core Web Vitals 보고서. CrUX 데이터를 URL 그룹 단위로 보여 주며, 그룹 안에서 가장 나쁜 지표가 그 그룹의 상태가 된다 (Search Console 고객센터, Core Web Vitals 보고서).
  2. PageSpeed Insights. 필드 값과 Lighthouse 랩 값을 함께 보여준다.
  3. Chrome DevTools의 성능 패널. 어떤 요소가 언제 얼마나 움직였는지 개별 이동을 짚어 준다 (web.dev, 레이아웃 변경 디버그).
  4. 자바스크립트 Layout Instability API. PerformanceObserver로 layout-shift 항목을 구독하면 값과 원인 요소를 페이지 안에서 직접 받는다.

랩 값과 필드 값이 다르다고 측정이 틀린 것은 아니다. 구글은 실험실 도구가 페이지 로드 동안만 재는 반면 필드는 스크롤과 상호작용 뒤에 생긴 이동까지 포함한다고 설명한다 (web.dev, CLS 최적화, 위 인용).

직접 재 보면 무엇이 보이는가?

서치폴라리스 페이지 두 개를 Layout Instability API로 재 봤다. 2026년 9월 19일 데스크톱 크로미움에서 각 1회 측정한 랩 값이다.

측정한 주소CLS이동 횟수이동 시점이동 원인 요소이미지 수크기 미지정 이미지
/wiki/lcp/00없음없음00
/blog/rag/0.05912,123ms텍스트 span1310

두 페이지 모두 0.1 안에 들었다. 위키 페이지는 이미지가 없고 텍스트만 있어 이동이 한 번도 없었다.

블로그 페이지의 이동 한 번은 이미지가 아니라 텍스트 요소에서 나왔다. 두 페이지 모두 웹 글꼴을 font-display: swap으로 쓰는데, 대체 글꼴이 먼저 보이고 웹 글꼴로 바뀌는 시점에 문단이 재배치된 것으로 보인다.

이미지 13개 중 10개에 width와 height가 없는 점은 이번 측정에서 점수로 드러나지 않았다. 이미지가 뷰포트 아래에 있으면 로드 시 이동이 잡히지 않지만, 사용자가 스크롤해 내려가면 필드에서 잡힐 수 있다.

위 표는 1회 랩 측정이라 순위 판정과 무관하고, 원인이 어느 요소인지 찾는 용도로만 쓴다.

CLS는 어떻게 줄이는가?

공간을 미리 잡아 두는 것이 원칙이다. 나중에 들어올 것의 자리를 먼저 비워 두면 밀릴 것이 없다 (web.dev, CLS 최적화, 위 인용).

  1. 이미지와 동영상에 width와 height를 적는다. 반응형이면 CSS aspect-ratio로 비율을 지정한다. 브라우저가 로드 전에 공간을 계산할 수 있어 가장 쉽고 효과가 큰 조치다.
  2. 광고와 삽입 콘텐츠 슬롯에 min-height를 준다. 실제 게재 비율이 높은 크기로 예약하고, 광고가 안 나와도 슬롯을 접지 않는다.
  3. 동적 콘텐츠는 뷰포트 아래에 넣거나 사용자 행동에 반응해서만 띄운다. 위에서 끼어드는 배너가 본문을 밀어내는 패턴을 피한다.
  4. 애니메이션은 transform으로 한다. width, height, margin, top처럼 레이아웃을 바꾸는 속성 대신 translate와 scale을 쓰면 주변 요소가 움직이지 않는다.
  5. 웹 글꼴은 미리 로드하고 대체 글꼴 크기를 맞춘다. 중요한 글꼴은 preload로 먼저 받고, font-display: optional을 쓰거나 size-adjust로 대체 글꼴과의 크기 차이를 줄인다.
  6. 페이지가 뒤로 앞으로 캐시(bfcache)를 쓸 수 있게 한다. 되돌아온 페이지는 떠났을 때 상태로 복원돼 로드 중 이동이 반복되지 않는다.

효과는 두 사례가 보여 준다. Yahoo! JAPAN 뉴스는 히어로 이미지에 가로세로 비율 상자를 적용해 실험실 CLS를 약 0.2에서 0으로 낮췄고, 세션당 페이지 조회수 15.1%, 세션 시간 13.3% 증가와 이탈률 1.72% 감소를 기록했다 (web.dev, CLS 최적화를 통해 Yahoo! JAPAN 뉴스의 세션당 페이지 조회수 15% 증가).

Rakuten 24는 코어 웹 바이탈에 최적화한 버전이 A/B 테스트에서 CLS를 92.72% 개선했고, 방문자당 수익 53.37%, 전환율 33.13% 상승을 확인했다 (web.dev, How Rakuten 24’s investment in Core Web Vitals increased revenue per visitor by 53.37%).

자주 묻는 질문

CLS 뜻은 무엇인가?

웹 성능에서는 누적 레이아웃 이동(Cumulative Layout Shift)이고, 자동차에서는 메르세데스 벤츠 CLS, 물류에서는 쿠팡 로지스틱스 서비스, 명령줄에서는 화면을 지우는 cls 명령이다. 구글 검색량 기준 “CLS”는 월 3,600회, “CLS 뜻”은 170회다 (2026-09-19 서치폴라리스 실측, 구글 키워드 플래너).

CLS의 단위는 무엇인가?

없다. 뷰포트 대비 영역 비율과 거리 비율을 곱한 값이라 0에서 시작하는 소수로 표현되고, 0.1 이하가 좋음이다 (web.dev, CLS, 위 인용).

CLS는 첫 로드에서만 측정되는가?

아니다. 페이지가 열려 있는 전체 수명 주기에서 재고 그중 가장 큰 세션 창의 점수를 쓰므로, 로드 뒤 스크롤이나 클릭으로 생긴 이동도 필드 데이터에 들어간다.

웹 성능에서 CLS는 얼마나 중요한가?

구글 순위 시스템이 쓰는 코어 웹 바이탈 세 지표 중 하나이고, Yahoo! JAPAN 뉴스와 Rakuten 24 사례처럼 이탈률과 수익에 직접 이어진다. LCP보다 통과율이 높고, 이미지 크기 지정처럼 손쉬운 조치의 비중이 크다.

참고 자료

우리 브랜드는 AI 답변에 나오고 있을까?

서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.

GEO 최적화 서비스 보기