Cumulative Layout Shift (CLS)란 무엇이며 어떻게 해결하는가

Cumulative Layout Shift (CLS)란 무엇인가?

Cumulative Layout Shift (CLS)는 Core Web Vitals에서 '시각적 안정성'을 나타내는 지표입니다. 콘텐츠가 렌더링되거나 새로운 콘텐츠가 나타날 때 페이지가 얼마나 흔들리는지 측정합니다. 읽고 있던 글의 줄을 놓치거나, 누르려던 버튼이 손가락 밑에서 움직여 엉뚱한 곳을 클릭했을 때 이 문제를 체감하게 됩니다. 간혹 이를 "content layout shift"라고 부르기도 하지만, 이 지표의 공식 명칭은 Cumulative Layout Shift입니다.

좋은 Cumulative Layout Shift (CLS) 점수 기준은?

좋은 CLS 점수는 0에서 0.1 사이입니다. 0.1에서 0.25 사이는 개선이 필요하며, 0.25를 초과하는 점수는 나쁨으로 분류됩니다. Cumulative Layout Shift 항목에서 Core Web Vitals를 통과하려면 전체 페이지 방문의 최소 75%에서 '좋음' 점수를 기록해야 합니다. 이는 field data의 p75 기준이며, 모바일과 데스크톱을 각각 분리하여 측정합니다. LCP와 INP가 시간 단위인 것과 달리, CLS는 단위가 없는 점수입니다.

Google Search Console의 Core Web Vitals 보고서는 기준에 미달한 URL을 문제 유형별로 분류합니다. "CLS issue: more than 0.1 (mobile)"은 개선 필요를, "CLS issue: more than 0.25 (desktop)"은 나쁨을 의미하며, 두 기준치 모두 기기별로 각각 존재합니다. Search Console은 이동 기간(rolling window) 동안의 field data를 평균하여 집계합니다. 따라서 문제를 수정하여 배포한 당일에 바로 보고서가 녹색으로 바뀌지는 않습니다. 몇 주 동안은 이전 사이트의 데이터가 여전히 일부 반영되기 때문입니다.

레이아웃 이동이 초래하는 대가

화면이 이리저리 튀면 모든 기능이 정상 작동하더라도 페이지가 망가진 것처럼 느껴집니다.

• 방문자와 브랜드: 레이아웃 이동은 방문자가 하려던 동작을 방해합니다. 읽고 있던 줄을 놓치거나 잘못된 링크를 탭하게 되며, 일부 방문자는 결국 사이트를 떠납니다. 화면이 끊임없이 흔들리는 사이트는 조잡하게 만들어졌다는 인상을 주며, 이는 사이트를 운영하는 기업의 신뢰도 하락으로 이어집니다.
• 접근성: 화면을 확대하거나 화면 돋보기를 사용할 때처럼 페이지의 일부만 보고 있을 때 레이아웃 이동의 악영향이 가장 큽니다. 단 한 번의 이동으로도 읽고 있던 텍스트가 화면 밖으로 밀려날 수 있습니다.
• SEO 및 검색 순위: Google의 순위 산정 시스템은 Core Web Vitals를 활용하며, CLS도 그중 하나입니다. 순위에 미치는 비중은 작은 편입니다. Google에 따르면 가장 관련성 높은 콘텐츠가 항상 우선 노출되며, 여러 페이지의 관련성이 대등할 때 좋은 페이지 경험이 순위에 도움이 됩니다.

CLS는 어떻게 측정하는가?

브라우저는 Layout Instability API를 통해 레이아웃 이동을 보고합니다. 콘솔에 다음 코드를 붙여넣으면 발생하는 모든 레이아웃 이동이 기록됩니다:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

각 항목(entry)에는 해당 이동의 점수인 value와 움직인 요소 목록인 sources가 포함됩니다. 클릭 직후 발생한 레이아웃 이동은 hadRecentInput 플래그가 true로 설정됩니다. 이러한 이동은 여기에 기록은 되지만 CLS 점수에는 반영되지 않습니다.

CLS 계산 방법

모든 레이아웃 이동은 개별 점수를 갖습니다:

layout shift score = impact fraction * distance fraction

영향 분율(impact fraction)은 움직인 요소가 이동 전후에 차지하는 영역이 viewport의 얼마나 많은 비중에 걸쳐 있는지를 나타냅니다. 거리 분율(distance fraction)은 viewport의 가장 큰 치수(스마트폰의 경우 높이) 대비 요소가 얼마나 멀리 이동했는지를 나타냅니다.

viewport의 절반을 차지하는 요소가 viewport 높이의 25%만큼 아래로 이동하는 경우를 가정해 보겠습니다. 이동 전후의 영역을 합치면 viewport의 75%에 달합니다. 즉 영향 분율은 0.75, 거리 분율은 0.25가 되므로 해당 이동의 점수는 0.75 * 0.25 = 0.1875입니다. 이러한 이동이 단 한 번만 발생해도 그 자체로 0.1을 넘습니다. 페이지의 최종 CLS는 아래에서 설명할 세션 윈도우(session window) 단위로 이 이동 점수들을 합산하여 구합니다.

예상된 레이아웃 이동과 예상치 못한 레이아웃 이동

'더 보기' 링크를 클릭할 때는 새 항목이 나타나며 페이지가 움직일 것을 예상하기 마련입니다. 그렇기 때문에 CLS에는 예상치 못한 레이아웃 이동만 계산에 포함됩니다. 클릭, 탭, 키 입력 후 500밀리초 이내에 발생한 레이아웃 이동은 모두 계산에서 제외되므로, 클릭 시 열리는 드롭다운 메뉴는 점수에 아무런 영향을 주지 않습니다. 스크롤은 사용자 입력으로 인정되지 않으며, 이에 대해서는 아래에서 자세히 설명합니다.

레이아웃 이동 세션

CLS가 처음 도입되었을 때는 페이지 수명 전체에 걸쳐 발생한 모든 이동을 합산했습니다. 그 결과 무한 스크롤 사이트나 단일 페이지 애플리케이션처럼 페이지를 오래 열어두는 환경에서는 점수가 계속해서 누적되었습니다. 2021년 6월부터는 CLS를 세션 단위로 계산합니다. 각 세션은 최대 5초 동안 지속되며, 레이아웃 이동 간격이 1초 이상 벌어지면 종료됩니다. 이 중 가장 큰 CLS 점수를 기록한 세션의 점수가 최종 CLS 점수가 됩니다.

예를 들어 첫 번째 세션의 합계가 0.095, 다음 세션이 0.15, 마지막 세션이 0이라고 하면, 최종 CLS 점수는 세 값 중 가장 높은 0.15가 됩니다.

주요 CLS 원인

모든 레이아웃 이동의 동작 원리는 동일합니다. 페이지가 렌더링된 후 특정 요소의 크기가 변하거나 위치가 바뀌면, 레이아웃상 그 뒤에 오는 모든 요소가 함께 밀려납니다. 주요 원인은 다음과 같습니다:

크기가 지정되지 않은 이미지, 비디오, iframe

크기가 지정되지 않은 미디어는 CLS를 유발하는 가장 대표적인 원인입니다. 브라우저는 파일의 첫 번째 바이트가 도착해야만 이미지의 크기를 알 수 있습니다. 그전까지는 width와 height(또는 CSS aspect-ratio)가 없으면 공간을 미리 확보하지 않아 이미지 높이가 0이 됩니다. 이미지가 로드되는 순간 그 아래에 있는 모든 요소가 아래로 밀려납니다.

이미지와 미디어가 레이아웃 이동을 유발하는 이유에서는 크기가 지정되지 않은 이미지, 비디오, iframe, width: auto CSS 함정, 아트 디렉션, 반응형 이미지 불일치, lazy loading 및 플레이스홀더 이미지를 다룹니다.

웹 폰트 교체

웹 폰트가 다운로드되는 동안 페이지는 fallback 폰트로 텍스트를 렌더링합니다. 웹 폰트가 로드되면 텍스트의 reflow가 발생합니다. 글자 폭과 줄 높이가 달라지면서 줄 바꿈 위치가 바뀌고, 해당 문단 아래에 있는 모든 블록이 밀려납니다.

Lighthouse의 "Ensure text remains visible during webfont load" 감사는 font-display: swap 사용을 유도합니다. 하지만 이 설정만으로는 CLS 문제를 전혀 해결하지 못합니다. fallback 폰트로 텍스트가 더 일찍 표시될 뿐, 폰트가 교체될 때 화면이 밀리는 현상은 여전히 발생하기 때문입니다. 이를 해결하려면 size-adjust, ascent-override 같은 @font-face 메트릭 오버라이드를 적용하여 fallback 폰트가 동일한 공간을 차지하도록 맞춰야 합니다. 그런 다음 핵심 폰트를 자체 호스팅(self-hosting)하고 사전 로드(preload)하여 폰트를 더 빠르게 전달하십시오. 관련 코드는 원인 분석 및 해결 가이드에서 확인할 수 있습니다.

CSS 애니메이션과 트랜지션

top, left, width, height 속성에 애니메이션을 적용하면 브라우저는 매 프레임마다 레이아웃을 다시 계산합니다. 이 프레임 하나하나가 모두 레이아웃 이동이 될 수 있습니다. transform과 opacity는 레이아웃을 전혀 유발하지 않으므로, 요소를 이동할 때는 항상 이 속성들을 사용하십시오. CSS 트랜지션으로 인한 레이아웃 이동 해결 방법에서 구체적인 해결 과정을 확인할 수 있습니다.

광고, 임베드 및 동적으로 삽입되는 콘텐츠

광고는 늦게 로드되면서 콘텐츠를 아래로 밀어냅니다. 화면 위에 오버레이로 뜨는 쿠키 배너는 레이아웃을 이동시키지 않지만, 상단에 삽입되는 배너는 페이지 전체를 아래로 밀어버립니다. 공간을 미리 확보하지 않은 상태에서 AJAX 요청으로 콘텐츠를 삽입할 때도 마찬가지입니다. 모두 브라우저가 페이지 레이아웃을 잡을 당시에는 알지 못했던 요소가 뒤늦게 페이지에 추가되기 때문에 발생합니다. 컨테이너에 min-height를 지정하는 등의 방식으로 사전에 공간을 미리 확보하십시오. YouTube나 Google Maps 같은 서드파티 임베드의 경우 파사드(facade) 패턴을 적용하면 CLS를 완전히 없앨 수 있습니다.

스크롤로 인해 발생하는 레이아웃 이동

Lighthouse의 페이지 로드 테스트는 스크롤 동작을 하지 않으므로 이러한 CLS 원인을 발견하지 못합니다. 스크롤할 때 숨겨지는 헤더, 패럴랙스 효과, 크기가 줄어드는 내비게이션 바 등은 top이나 height 속성에 애니메이션을 적용하는 경우가 많습니다. Layout Instability 명세상 스크롤은 예외 처리되는 사용자 입력에 해당하지 않으므로, 스크롤로 인해 발생하는 모든 레이아웃 이동이 CLS 점수에 그대로 반영됩니다. 스크롤에 따라 움직이는 요소에는 transform: translateY()를 사용하십시오. 자세한 내용은 스크롤 트리거 애니메이션이 CLS를 유발하는 이유에서 확인할 수 있습니다.

CLS 문제 진단 및 해결

먼저 field data부터 확인하십시오. lab 테스트는 페이지 로드 초반의 몇 초만 관찰하지만, 실제 방문자는 스크롤을 내리고 광고가 로드되길 기다리며 계속해서 콘텐츠를 읽습니다. 모바일과 데스크톱의 p75 CLS를 각각 분리하여 점검하십시오. CLS의 경우 데스크톱 환경이 더 나쁜 경우가 많습니다. Google Search Console을 보면 어떤 페이지 그룹이 기준에 미달했는지 확인할 수 있습니다. CoreDash 같은 RUM 툴은 어떤 요소가 이동했는지도 함께 기록하므로, 특정 템플릿의 상품 이미지 문제인지 다른 템플릿의 광고 슬롯 문제인지 파악할 수 있습니다. 변화 추이도 함께 살펴보십시오. 수치가 갑자기 급증했다면 대개 새로운 배너나 광고 슬롯이 추가된 배포가 원인입니다.

그런 다음 Chrome DevTools나 Core Web Vitals Visualizer 확장 프로그램을 사용해 문제를 재현하고, 어떤 요소가 레이아웃을 움직이게 만드는지 확인하십시오. 단계별 진단 방법, 도구 활용법, 원인별 코드 수정 방법, 빠른 점검 체크리스트는 Cumulative Layout Shift (CLS) 문제 진단 및 해결 가이드에서 확인할 수 있습니다.

사례 연구: Rakuten 24의 Core Web Vitals A/B 테스트

일본의 온라인 쇼핑몰 Rakuten 24는 트래픽이 많은 랜딩 페이지 하나를 대상으로 Core Web Vitals 최적화를 진행했습니다. 각 버전에 트래픽을 50%씩 배분하여 기존 페이지와 최적화 페이지를 한 달 동안 비교 테스트했습니다. CLS의 경우 CSS aspect-ratio로 이미지 공간을 확보하고, lazy loading되는 요소에는 min-height로 영역을 미리 확보했습니다. 그 결과 최적화된 페이지의 CLS가 92.72% 감소했습니다. 또한 모바일 로딩 테스트에서 로딩 완료 시간이 0.4초 단축되었으며, FCP와 TTFB도 함께 개선되었습니다. 기존 페이지와 비교했을 때 최적화된 페이지는 다음과 같은 성과를 거두었습니다:

• 방문자당 수익 53.37% 증가
• 전환율 33.13% 증가
• 평균 주문액 15.20% 증가
• 이탈률 35.12% 감소

이 테스트에서 가장 크게 개선된 지표는 CLS였지만, 로딩 시간, FCP, TTFB 역시 함께 향상되었습니다. 따라서 이러한 결과는 최적화 작업 전체의 성과로 보아야 합니다. CLS 하나만의 효과로 인용해서는 안 됩니다.

실제 환경의 CLS 데이터가 보여주는 현황

2026년 8월 Chrome UX Report 기준, 양호한 CLS를 기록한 출처(origin) 비율은 81.5%로, 2025년 8월의 80.1%에서 증가했습니다.

corewebvitals.io 사이트 자체의 경우, CoreDash 측정 결과 CLS가 Core Web Vitals 중 가장 우수한 성능을 기록하고 있습니다. 전체 페이지 로드의 92.8%가 '좋음' 점수를 얻었으며, 데스크톱(92.8% 좋음)과 모바일(92.7% 좋음) 간의 격차도 거의 없습니다. 두 환경 모두 p75 수치가 0으로, 전체 페이지 로드의 4분의 3 이상에서 레이아웃 이동이 전혀 발생하지 않았습니다.

웹 전반적으로 CLS는 데스크톱보다 모바일에서 더 좋은 성적을 보입니다. 이는 LCP나 INP와는 정반대 현상입니다. 2025 Web Almanac에는 이러한 통계와 함께 앞서 언급한 원인들이 얼마나 자주 발생하는지가 정리되어 있습니다:

• 모바일 사이트의 81%, 데스크톱 사이트의 72%가 '좋음' CLS를 기록하고 있습니다. 모바일의 약 9%, 데스크톱의 약 10%는 '나쁨' 수준입니다.
• 모바일 페이지의 62%에 명시적인 크기가 지정되지 않은 이미지가 최소 하나 이상 포함되어 있으며, 이는 2024년의 66%에서 감소한 수치입니다.
• 모바일 페이지의 40%(데스크톱의 44%)가 합성(composite)되지 않은 애니메이션을 사용하고 있습니다.
• 모바일 페이지의 87%가 최소 하나 이상의 웹 폰트를 사용하며, 사전 로드(preload)를 적용한 비율은 약 12%입니다(Fonts 챕터).

관련 가이드

CLS 문제 진단과 해결에 대해 더 자세히 다루는 가이드입니다:

• CLS 문제 진단 및 해결: 도구 활용법을 포함한 단계별 진단, 원인별 코드 수정 방법, 빠른 점검 체크리스트.
• 이미지와 미디어가 레이아웃 이동을 유발하는 이유: 크기가 지정되지 않은 이미지, 비디오, iframe, 아트 디렉션, 반응형 이미지, lazy loading, 플레이스홀더로 인한 CLS.
• 이미지 자동 크기 조정으로 인한 레이아웃 이동 해결 방법: 이미지 및 반응형 컨테이너에 적절한 크기 지정하기.
• CSS 트랜지션으로 인한 레이아웃 이동 해결 방법: 레이아웃을 유발하는 CSS 애니메이션을 찾고 합성(composited) 대안으로 대체하기.
• 스크롤 트리거 애니메이션과 CLS: Lighthouse 페이지 로드 테스트가 놓치는 CLS 원인 및 해결 방법.
• Google Fonts 자체 호스팅하기: 올바른 font-display 설정과 사전 로드(preloading)로 폰트를 자체 호스팅하여 폰트 로딩 CLS 줄이기.
• 웹 폰트 로드 중 텍스트가 계속 표시되도록 설정하기: 폰트 교체로 인한 레이아웃 이동을 방지하는 font-display 및 폰트 메트릭 오버라이드.
• 완벽한 Core Web Vitals를 유지하는 채팅 위젯 구축하기: CLS, INP, LCP 저하 없이 서드파티 위젯을 추가한 사례 연구.

Core Web Vitals 개요에서는 세 가지 지표를 모두 다루며, Core Web Vitals 체크리스트를 활용해 사이트를 직접 점검할 수 있습니다.