워드프레스 CLS 수치가 계속 높게 나오는 이유

새로고침을 몇 번을 해도 CLS 점수는 그대로일 때가 있습니다

PageSpeed Insights 화면을 새로고침해 보지만 숫자가 꼼짝하지 않는다면

현장 데이터가 최근 28일치 방문을 모은 값이기 때문일 수 있습니다

제목의 질문에 먼저 답을 드리면, 이유는 크게 두 갈래입니다. 하나는 28일 집계 때문에 고친 결과가 아직 숫자에 안 들어와서 계속 높아 보이는 경우입니다. 다른 하나는 실제로 화면을 밀어내는 요소가 아직 남아 있는 경우로, 치수 없는 이미지, 웹폰트 교체, 광고·임베드, 뒤늦게 끼어드는 영역, 테마 CSS로 그린 배너가 대표적입니다. 기준값과 원인 분류는 web.dev의 CLS 문서를 따랐습니다.

글을 읽기 전에 알아 둘 점이 하나 있습니다. 이 글의 코드와 표에 적힌 수치는 형식을 보여 주려는 예시이고, 실제 값은 사이트와 폰트, 기기마다 다릅니다. 개발자 도구, PageSpeed Insights, 플러그인 화면의 메뉴 이름도 버전에 따라 조금씩 다를 수 있습니다. 이 말은 아래에서 다시 반복하지 않겠습니다.

훑어보실 때는 아래 순서로 읽으시면 됩니다.

1. 원인: 숫자가 안 바뀌는 이유와 대표 원인 다섯 가지
2. 방법: 밀린 요소를 찾고, 이미지·웹폰트·쿠키 안내·배너를 고치는 법
3. 검증: 현장 데이터와 Lighthouse를 나눠 확인하고 기록하는 법

몇 번을 눌러도 안 바뀌는 그 숫자의 정체

사이트를 손본 날 저는 PageSpeed Insights를 열어 같은 페이지를 다섯 번 넘게 새로고침해 봤습니다

그런데 CLS 점수는 매번 똑같았습니다

화면 위쪽 현장 데이터 항목을 다시 보니 이유가 있었습니다

이 값은 제가 방금 새로고침한 결과가 아니라 최근 28일 동안 실제 방문자들에게서 모은 데이터입니다

그것도 개별 방문 하나하나가 아니라 75번째 백분위, 즉 방문의 75%가 겪은 값을 기준으로 잡습니다

매일 갱신되기는 하지만 하루 안에 크게 움직이는 값은 아닙니다

그래서 오늘 이미지 크기를 고쳤다고 해도 오늘 오후에 새로고침한 화면에는 아직 반영되지 않을 수 있습니다

이 설명은 Google의 PageSpeed Insights 문서에 나와 있습니다. 현장 데이터는 Chrome 사용자 경험 보고서(CrUX)를 바탕으로 최근 28일을 집계하고, 75백분위 값으로 좋음·개선 필요·나쁨을 가른다고 안내합니다. 페이지 단위 데이터가 부족하면 사이트 전체(오리진) 값이 대신 표시될 수 있다는 점도 알아 두면 좋습니다. 내가 고친 페이지 하나보다 사이트 전체의 다른 페이지가 숫자를 끌어올리고 있을 수 있기 때문입니다.

화면에 뜬 저 숫자, 좋음인가 나쁨인가

CLS 항목 옆에 색으로 구간이 나뉘어 있는데 이 구간을 기준으로 보면 됩니다

0.1 이하면 좋음, 0.1에서 0.25 사이면 개선 필요, 0.25를 넘으면 나쁨으로 분류됩니다

이 구간은 web.dev의 CLS 문서에서 확인할 수 있고, 모바일과 데스크톱을 나누어 평가한다는 점도 같이 적혀 있습니다

제 사이트는 개선 필요 구간에 걸려 있었는데 워드프레스 코어가 이미지에 자동으로 width와 height를 붙여 주는 버전을 쓰고 있었는데도 그랬습니다

테마가 배너 영역을 CSS로 직접 그리고 있어서 그 영역은 코어의 자동 처리 대상이 아니었습니다

그 배너가 로드되는 타이밍에 아래 콘텐츠가 밀려 내려가는 게 화면에서 보였습니다

CLS가 높게 나오는 대표 원인 다섯 가지

제 경우는 배너였지만, 내 사이트가 같은 이유일 거라고 단정할 수는 없습니다. 자기 사이트의 원인을 짚으려면 어떤 후보가 있는지부터 알아야 해서 web.dev의 CLS와 CLS 최적화 문서를 기준으로 정리했습니다.

코어가 채워 주는 이미지, 못 채우는 이미지

치수 없는 이미지는 이미지 요소 자체의 문제라 코어가 어느 정도 막아 주지만, 나머지 넷은 테마나 외부 스크립트가 만드는 영역이라 직접 찾아야 합니다. 코어가 width와 height를 자동으로 채워 주는 기능은 워드프레스 5.5부터 들어갔습니다. 그 이전 버전을 쓰고 있다면 이미지 문제부터 의심해 볼 만합니다.

5.5 이상이라고 해서 모든 이미지가 해결되는 것은 아닙니다. 워드프레스 개발자 문서의 wp_img_tag_add_width_and_height_attr 함수 설명과 Make WordPress Core의 5.5 지연 로딩 안내 글을 보면, 코어는 미디어 라이브러리에 올린 이미지를 기준으로 크기를 찾아 채웁니다. 그래서 어떤 이미지가 대상인지 먼저 갈라 두면 내 사이트에서 어디를 봐야 할지 좁혀집니다.

함수 문서에서 확인되는 내용은 이렇습니다. 이 함수는 img 태그의 src와 첨부파일 ID로 미디어 라이브러리의 메타데이터에서 가로·세로 값을 구하고, 둘 다 구해질 때만 속성을 붙입니다. 즉 라이브러리에 첨부파일로 등록되지 않은 외부 주소 이미지는 구할 값이 없습니다. 다만 기존 속성이 있으면 건너뛰는지, wp-image-숫자 클래스를 어떻게 쓰는지는 이 함수 페이지에는 적혀 있지 않습니다. 아래 표의 해당 줄은 위 안내 글과 함께 읽어 주세요.

내 사이트가 어디에 해당하는지는 두 곳에서 확인합니다. 먼저 관리자 화면 오른쪽 아래의 버전 표기로 5.5 이상인지 봅니다. 그다음 문제 페이지에서 오른쪽 클릭으로 페이지 소스 보기를 열거나 개발자 도구 Elements 패널에서 이미지 태그를 찾아, width와 height가 둘 다 들어 있는지 확인합니다. 하나라도 비어 있는 이미지가 있다면 그 이미지는 코어가 못 채운 쪽이니 직접 넣어야 합니다. 참고로 같은 문서에 따르면 loading=”lazy”도 두 속성이 모두 있는 이미지에만 붙기 때문에, 속성이 빠진 이미지는 지연 로딩에서도 빠집니다.

웹폰트는 이렇게 맞춥니다

표에서 가장 설명이 짧았던 곳이 웹폰트라서 한 번 풀어 둡니다. 웹폰트가 늦게 도착하면 대체 글꼴로 먼저 그린 글자가 웹폰트로 바뀌면서 줄바꿈과 높이가 달라지고, 그 아래 콘텐츠가 같이 움직입니다. web.dev의 CLS 최적화 문서는 두 방향을 제시합니다. 하나는 font-display: optional로 처음부터 폰트가 준비되지 않았으면 웹폰트를 쓰지 않는 것이고, 다른 하나는 대체 글꼴을 웹폰트와 비슷한 크기로 맞춰 두는 것입니다.

font-display: optional에는 대가가 있습니다. 첫 방문에서 폰트가 늦으면 그 페이지에서는 웹폰트가 아예 안 보일 수 있습니다. 디자인보다 점수 안정이 우선인지는 사이트마다 다르니 선택은 운영자 몫입니다.

/* 예시: 폰트 이름, 파일 경로, 퍼센트 값은 모두 사이트마다 다릅니다 */
@font-face {
  font-family: "MyWebFont";
  src: url("/wp-content/uploads/fonts/mywebfont.woff2") format("woff2");
  font-display: optional;
}

/* 웹폰트 대신 먼저 보일 대체 글꼴을 웹폰트 크기에 맞춘 것 */
@font-face {
  font-family: "MyWebFont Fallback";
  src: local("Arial");
  size-adjust: 105%;
  ascent-override: 92%;
  descent-override: 24%;
  line-gap-override: 0%;
}

body {
  font-family: "MyWebFont", "MyWebFont Fallback", sans-serif;
}

/* 예시: 폰트 파일 경로는 사이트마다 다릅니다 */
add_action( 'wp_head', function () {
  echo '<link rel="preload" href="' . esc_url( content_url( '/uploads/fonts/mywebfont.woff2' ) ) . '" as="font" type="font/woff2" crossorigin>' . "\n";
}, 1 );

쿠키 안내와 공지 바는 이렇게 고칩니다

동적으로 끼어드는 영역은 워드프레스 안에서 어디서 만들어지는지부터 알아야 합니다. 보통은 쿠키 안내 플러그인, 테마의 상단 공지 기능, 광고·알림 스크립트 중 하나입니다. 플러그인이라면 설정 화면에서 표시 위치(상단 바, 하단 바, 떠 있는 팝업)를 고르는 옵션이 있는지 먼저 봅니다. 옵션 이름은 플러그인마다 다르고, 저는 특정 플러그인의 메뉴를 확인하지 못했으니 이름은 적지 않습니다.

web.dev의 CLS 최적화 문서는 해결 방법을 두 가지로 안내합니다. 나타날 자리를 미리 잡아 두거나, 다른 콘텐츠를 밀지 않도록 문서 흐름 밖에 띄우는 것입니다. 두 방법 중에는 상단 바라면 자리 확보, 쿠키 안내처럼 사라질 수 있는 요소라면 겹쳐 띄우기가 낫다고 봅니다. 사라지는 요소가 흐름 안에 있으면 닫을 때 또 한 번 밀리기 때문입니다.

/* 방법 1: 공지 바 자리를 미리 확보 (클래스명과 높이는 예시) */
.notice-bar {
  min-height: 48px;
}

/* 방법 2: 쿠키 안내를 화면 아래에 겹쳐 띄움 (본문을 밀지 않음) */
.cookie-notice {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
}

밀린 요소는 어디서 찾나

원인 후보를 알았다면 이제 어느 요소가 실제로 움직였는지 눈으로 확인해야 합니다. 화면에서 밀리는 게 보였다는 느낌만으로는 어떤 요소가 점수를 깎는지 알 수 없기 때문입니다. web.dev의 CLS 최적화 문서가 안내하는 흐름은 이렇습니다.

1. Chrome에서 문제의 페이지를 열고 F12로 개발자 도구를 엽니다. Performance 패널에서 페이지를 새로 로드하며 기록합니다.
2. 기록 결과의 Layout Shifts 트랙에 보라색 덩어리가 보이면 그 안의 다이아몬드가 이동 한 번입니다. 클수록 많이 움직인 것입니다.
3. 다이아몬드를 누르면 움직인 요소가 화면에서 강조되고, Summary에서 발생 시각과 점수를 볼 수 있습니다. 점수가 가장 큰 이동부터 보면 됩니다.
4. Lighthouse 결과에서도 이동한 요소 목록을 볼 수 있습니다. 다만 여기 나오는 요소는 원인이 아니라 밀려난 쪽일 수 있어서, 그 위에 있는 요소가 무엇인지까지 함께 봐야 합니다.

이 순서가 중요한 이유는 밀려난 요소와 밀어낸 요소가 다르기 때문입니다. 본문 첫 문단이 내려갔다고 해서 문단을 고치면 소용이 없고, 그 위에서 높이가 늦게 정해진 배너나 광고 칸을 고쳐야 합니다.

한 번 재서 0.1을 넘었다고 탈락은 아닙니다

기준을 충족한다는 말은 한 번 잰 값이 0.1 이하라는 뜻이 아닙니다

방문의 75%에서 0.1 이하가 나와야 충족으로 봅니다

그래서 제 눈앞의 화면 하나가 0.12로 나왔다고 그 순간 기준 미달이 확정되는 건 아닙니다

같은 페이지를 다른 시간대, 다른 기기로 열어 보면 값이 다르게 잡히는 경우도 있었습니다

현장 데이터 항목 자체가 이미 여러 방문을 모아 놓은 결과라서 오늘 제가 연 한 번의 화면과는 계산 방식이 다릅니다

Lighthouse 값도 실행할 때마다 네트워크와 기기 자원에 따라 조금씩 달라질 수 있습니다. 그래서 단일 측정값 하나로 고쳤다, 안 고쳐졌다를 판단하기보다 여러 번 재서 흐름을 보는 쪽이 안전합니다.

현장 데이터랑 Lighthouse 값이 따로 놉니다

같은 페이지인데 위쪽 현장 데이터 CLS와 아래쪽 Lighthouse 점수가 다르게 나오는 걸 보고 처음엔 오류인 줄 알았습니다

현장 데이터는 실제 사용자들이 각자의 기기와 회선으로 방문한 값을 모은 것이고 Lighthouse는 구글 서버가 정해진 조건으로 한 번 시뮬레이션한 결과입니다

제 경우는 현장 데이터 쪽 CLS가 더 높게 나왔는데 이럴 때는 실제 방문자의 기기 환경이나 광고 노출 여부처럼 시뮬레이션에 안 잡히는 요소를 들여다봐야 할 수 있습니다

반대로 Lighthouse 쪽이 더 높다면 그 페이지를 처음 여는 순간의 렌더링 과정 자체를 봐야 할 수 있습니다

개인적으로 두 값 중 어느 쪽이 높은지부터 먼저 확인하는 게 다음에 뭘 볼지를 정하는 데 더 맞다고 봅니다

어느 쪽을 어떻게 확인하는지 표로 덧붙입니다. 공식 문서가 두 값이 다를 수 있다고만 설명하는 부분이 있어서, 표의 해석은 web.dev와 PSI 문서를 바탕으로 한 가능성 위주의 정리로 봐 주세요.

고친 뒤 뭘 적어 둬야 나중에 비교가 됩니다

배너 영역에 최소 높이를 지정해 두고 다음 날 같은 페이지를 다시 열었습니다

현장 데이터 CLS 값과 그날 날짜를 함께 적어 두고 Lighthouse 점수는 따로 구분해서 적었습니다

두 값을 한 줄에 섞어 적으면 나중에 어느 쪽이 좋아졌는지 헷갈리기 쉽습니다

오늘 날짜로 적어 둔 현장 데이터 CLS 값 옆에는 일주일 뒤 날짜를 하나 더 비워 뒀습니다

배너에 최소 높이 넣기

최소 높이를 넣는 방법도 보충해 둡니다. 개발자 도구의 Elements 패널에서 배너 요소를 골라 실제로 그려진 높이를 먼저 재고, 그 값을 기준으로 정하면 됩니다. 모바일과 데스크톱에서 높이가 다르게 그려지므로 화면 폭을 바꿔 가며 각각 재야 합니다. 클래스명과 높이는 자기 사이트의 값으로 바꿔 쓰세요.

/* 예시: 클래스명(.banner)과 높이는 사이트마다 다릅니다 */
.banner {
  min-height: 320px;
}

@media (max-width: 768px) {
  .banner {
    min-height: 180px;
  }
}

이 CSS는 테마가 제공하는 추가 CSS 입력란이나 자식 테마의 style.css에 넣습니다. 높이를 실제보다 작게 잡으면 남는 만큼 여전히 밀리고, 너무 크게 잡으면 빈 공간이 생깁니다. 비율이 일정한 배너라면 min-height 대신 aspect-ratio를 쓰는 방법도 있습니다.

테마 배너에 이미지 치수 처리 같은 일반 해결책이 통하지 않는 이유를 정리해 둡니다. 위의 코어 처리 대상표에서 보았듯 CSS 배경으로 그린 영역에는 붙일 width와 height 속성이 애초에 없고, 높이는 CSS나 안에 든 내용이 정해질 때까지 0에 가까울 수 있습니다. 그래서 “이미지에 속성을 붙인다”는 해법 대신 영역 자체에 자리를 지정해야 합니다. 어느 방법을 고를지는 배너가 어떻게 생겼는지에 달려 있습니다.

이 표는 앞서 인용한 web.dev의 해결 방향을 배너 형태별로 나눈 정리이고, 제가 형태별로 측정해 비교한 결과는 아닙니다. 내 배너가 어느 줄에 해당하는지는 Layout Shifts 트랙에서 이동한 요소를 눌러 확인하는 것이 먼저입니다.

고친 뒤 확인은 두 단계로

고친 뒤 확인은 두 단계로 나누면 헷갈리지 않습니다. 현장 데이터는 28일 집계라서, 고친 직후에는 Lighthouse로 먼저 확인하고 현장 데이터는 시간을 두고 봐야 합니다.

1. 수정 직후: 개발자 도구의 Lighthouse나 PageSpeed Insights에서 같은 페이지를 같은 조건(모바일/데스크톱)으로 서너 번 재고, 값이 흔들리는 범위를 함께 적어 둡니다. Performance 패널의 Layout Shifts 트랙에서 배너 이동이 사라졌는지도 봅니다.
2. 28일 뒤: PageSpeed Insights의 현장 데이터 CLS가 0.1 이하로 내려왔는지 확인합니다. 일주일 뒤에는 오래된 방문 기록이 일부만 빠진 상태라 중간 점검 정도로 보는 게 맞습니다. 사이트 전체의 상태는 Search Console의 핵심 웹 지표 보고서에서도 볼 수 있지만, 방문 데이터가 충분해야 표시됩니다.

기록표 예시

기록은 아래처럼 현장 데이터와 Lighthouse를 나눠서 적어 두면 됩니다.

이 글의 기준값과 확인 절차는 2026년 10월 10일에 열어 본 web.dev와 Google 문서를 따랐습니다. 워드프레스 5.5의 이미지 처리 기준과 웹폰트 속성 설명은 개발자 문서, Make WordPress Core, MDN을 2026년 10월 25일에 다시 열어 확인했습니다. 대체 글꼴 보정값 계산식과 CookieYes 설정 경로는 2026년 10월 26일에 Chrome 개발자 블로그와 CookieYes 문서로 확인했습니다.

• 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법
• 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유