홈페이지 이미지가 늦게 뜨며 화면이 밀릴 때, 흔들림 줄이는 설계

이미지 공간 예약으로 CLS를 낮추는 방법 — 홈페이지를 운영하거나 개발 중이라면

글을 읽던 중에 이미지가 뒤늦게 나타나 문단이 아래로 밀려 내려간 경험은 누구에게나 있습니다. 버튼을 누르려는 순간 화면이 움직여 엉뚱한 곳을 누르게 되는 경우도 흔합니다. 이런 홈페이지 화면 흔들림은 대부분 이미지 파일이 늦게 도착해서 생긴다고 생각하기 쉽지만, 실제 원인은 조금 다릅니다. 브라우저가 이미지가 들어올 자리를 미리 알지 못한 채 글과 버튼을 먼저 배치했기 때문에, 이미지가 도착하는 순간 주변 요소를 밀어내는 것입니다.

그래서 이 문제의 해법은 이미지를 더 빨리 내려받는 데서만 나오지 않습니다. 파일이 도착하기 전부터 실제 비율에 맞는 자리를 레이아웃에 마련해 두는 설계가 핵심입니다. 이 글에서는 레이아웃 이동을 수치로 나타내는 CLS의 개념, width·height와 aspect-ratio를 이용한 공간 예약, 지연 로딩과의 관계, 첫 화면 이미지와 아래쪽 이미지를 구분하는 로딩 정책, 그리고 화면 밀림을 재현해 원인을 찾는 점검 방법까지 순서대로 설명합니다.

화면이 밀리는 현상을 수치로 보는 CLS의 원리

CLS(누적 레이아웃 이동)는 화면에 보이는 요소가 예기치 않게 이동한 정도를 합산한 점수입니다. 단위가 없는 숫자이며, 클수록 화면이 많이 흔들렸다는 뜻입니다. 이미지가 늦게 나타나 글이나 버튼을 밀어내는 현상도 측정 대상에 포함됩니다. 여기서 CLS는 Core Web Vitals를 이루는 지표 가운데 웹페이지 시각적 안정성을 담당합니다.

점수를 읽는 기준은 다음과 같습니다.

① 0.1 이하는 양호입니다. web.dev는 0.1 이하로 표기하고, Google Search Central은 같은 기준을 0.1 미만으로 표현합니다. 표기만 조금 다를 뿐 같은 기준선을 가리킵니다.
② 0.1과 0.25 사이는 개선이 필요한 구간입니다.
③ 0.25를 초과하면 나쁨으로 분류됩니다.

점수 하나만 맞추면 끝나는 것은 아닙니다. 방문의 75% 이상에서 양호 기준을 달성하는 것이 권고 목표입니다. 내 컴퓨터에서 한 번 측정해 0.05가 나왔다고 해서 모든 방문자가 그 경험을 하는 것은 아닙니다. 네트워크 속도, 화면 크기, 스크롤 습관이 다른 방문자 전체의 분포를 기준으로 삼는다는 뜻입니다.

이미지가 화면을 미는 과정

이미지가 화면을 미는 과정은 다음 순서로 일어납니다.

1. 브라우저가 HTML을 읽으면서 <​img alt="이미지 로딩 전후 레이아웃 변화를 보여주는 다이어그램"> 태그를 만납니다.

2. 이미지 크기 정보가 없으면, 브라우저는 파일을 받기 전까지 이미지가 얼마나 큰지 알 수 없습니다. 그래서 높이 0에 가까운 상태로 다음 글을 먼저 배치합니다.

3. 파일이 도착하면 이미지의 실제 크기가 확정됩니다.

4. 브라우저는 이미지 높이만큼 아래 요소를 밀어내며 레이아웃을 다시 계산합니다.

5. 사용자 눈에는 글과 버튼이 갑자기 움직인 것으로 보입니다.

이 과정에서 중요한 점은 문제의 본질이 속도가 아니라 정보 부족이라는 것입니다. 이미지가 아주 빨리 도착해도 도착 시점에 이미 글이 배치된 뒤라면 이동은 일어납니다. 반대로 이미지가 느리게 도착하더라도 자리가 미리 잡혀 있으면 이동은 일어나지 않습니다. 느린 이미지는 빈 공간이 잠시 보이는 불편은 만들 수 있지만, 레이아웃 이동은 만들지 않습니다.

이미지가 오기 전에 자리를 확보하는 세 가지 방법

이미지 공간 예약의 기본은 브라우저에 이미지의 비율을 미리 알려주는 것입니다. 방법은 크게 세 가지입니다. HTML의 width·height 속성, srcset·<​picture>와 함께 쓰는 비율 지정, 그리고 CSS의 aspect-ratio입니다.

HTML width·height 속성

가장 기본이 되는 방법은 <​img alt="picture 태그로 화면 크기별 다른 이미지를 제공하는 마크업 예시">에 width와 height를 적는 것입니다.

<​img src="product.jpg" width="800" height="600" alt="제품 사진">

이렇게 하면 브라우저는 파일을 받기 전에도 두 값의 비율을 바탕으로 이미지가 차지할 자리를 계산할 수 있습니다. 여기서 오해하기 쉬운 점이 있습니다. 이 값은 반드시 화면에 표시되는 크기와 같아야 하는 것이 아닙니다. 800과 600은 가로세로 비율(4:3)을 알려주는 역할을 합니다. 화면에서 실제로 얼마나 크게 보일지는 CSS가 따로 정할 수 있습니다. 즉 표시 크기를 고정하지 않고도 이미지가 들어올 공간을 미리 확보할 수 있다는 것이 이 방식의 장점입니다.

반응형 페이지에서는 보통 다음 CSS를 함께 씁니다.

img {
max-width: 100%;
height: auto;
}

max-width: 100%는 이미지가 컨테이너보다 커지지 않게 하고, height: auto는 너비가 줄어들 때 높이를 비율에 맞게 따라가게 합니다. 이 조합은 화면 폭에 따라 이미지가 유연하게 줄어들면서도 비율을 유지하게 해줍니다.

다만 주의할 점이 있습니다. CSS 크기 조절만으로 HTML의 크기 정보가 빠진 문제를 대신 해결한다고 단정하면 안 됩니다. height: auto만 있고 HTML에 width·height가 없으면, 브라우저는 여전히 파일이 도착하기 전까지 비율을 알 수 없습니다. HTML의 크기 속성과 CSS의 유연한 크기 조절은 서로 대체재가 아니라 함께 쓰는 짝입니다.

srcset과 picture를 쓸 때의 비율 지정

해상도별로 여러 파일을 제공하는 srcset을 쓰더라도 방식은 같습니다. srcset으로 고르는 파일들이 모두 같은 화면 비율이라면, <​img alt="width, height, loading lazy 속성이 모두 포함된 img 태그 코드">에 그 비율에 맞는 width·height를 두면 됩니다. 파일은 작은 것과 큰 것이 있어도 비율이 같으면 하나의 크기 정보로 충분합니다.

src="banner-800.jpg"
srcset="banner-400.jpg 400w, banner-800.jpg 800w, banner-1600.jpg 1600w"
sizes="(max-width: 600px) 100vw, 800px"
width="1600" height="900"
alt="배너 이미지">

비율이 달라지는 경우도 있습니다. 모바일에서는 정사각형에 가깝게 자르고 데스크톱에서는 가로로 넓게 보여주는 <​picture> 아트 디렉션이 대표적입니다. 이때는 선택될 <​source>에도 width·height를 둘 수 있습니다. HTML 표준(WHATWG)은 선택된 <​source>의 크기를 이미지 비율 결정에 사용할 수 있다고 명시합니다.

<​picture>
<​source media="(max-width: 600px)" srcset="hero-square.jpg" width="800" height="800">
<​source media="(min-width: 601px)" srcset="hero-wide.jpg" width="1600" height="700">
<​img src="hero-wide.jpg" width="1600" height="700" alt="대표 이미지">
<​/picture>

비율이 다른 파일을 하나의 <​img alt="이미지 로딩 정책을 요약한 체크리스트 이미지"> 크기 정보로만 처리하면, 선택된 파일의 비율과 예약된 비율이 어긋나 이미지가 도착할 때 이동이 생길 수 있습니다. 아트 디렉션을 쓴다면 각 <​source>의 비율을 파일과 맞춰 두는 것이 안전합니다.

CSS aspect-ratio

HTML 속성을 바꾸기 어려운 상황이라면 CSS aspect-ratio가 대안이 됩니다. 이미지나 동영상이 들어갈 영역의 비율을 CSS로 선언하는 방법입니다.

.thumb {
aspect-ratio: 16 / 9;
width: 100%;
}

MDN은 이 속성을 미디어 로딩 후 재배치(jank)를 줄이는 방법으로 설명합니다. 콘텐츠 관리 화면에서 템플릿의 마크업은 건드리기 어렵지만 스타일시트는 수정할 수 있을 때, 또는 이미지를 감싸는 카드 영역 자체에 비율을 주고 싶을 때 유용합니다. 동영상이나 iframe처럼 width·height 외의 방식으로 공간을 잡아야 하는 요소에도 적용할 수 있습니다.

어떤 방법을 고를까

세 방법은 경쟁 관계가 아니라 상황에 따른 선택지입니다.

① 일반 콘텐츠 이미지는 width·height 속성을 기본으로 둡니다. 마크업 자체가 비율 정보를 담고 있어 가장 직접적입니다.
② 비율이 다른 이미지를 화면 크기별로 바꿔 보여준다면 <​picture>의 <​source>에 크기 속성을 둡니다.
③ 마크업을 바꾸기 어렵거나 동영상·임베드 영역에 공간을 잡을 때는 aspect-ratio를 씁니다.

한 가지 원칙은 같습니다. 파일이 도착하기 전에 브라우저가 비율을 알 수 있어야 합니다.

지연 로딩과 공간 예약은 함께 설계해야 합니다

지연 로딩은 공간 예약 없이 쓰면 오히려 화면 밀림을 키울 수 있습니다. loading="lazy"는 화면 아래쪽 이미지를 사용자가 가까이 갈 때까지 내려받지 않게 해서 초기 로딩의 부담을 줄이는 속성입니다. 아래쪽 이미지에는 적용할 수 있고, 불필요한 데이터 사용을 줄이는 효과가 있습니다.

그러나 크기 정보가 없는 상태에서 지연 로딩을 쓰면 문제가 생깁니다. 사용자가 스크롤을 내려 해당 이미지에 가까워진 시점에야 파일을 받기 시작하고, 도착하는 순간 공간이 확보되어 있지 않으므로 이미 화면에 보이고 있는 글과 버튼이 밀려납니다. 사용자는 글을 읽는 도중에 내용이 위아래로 흔들리는 경험을 하게 됩니다.

지연 로딩이 CLS에 반영되는 경우

CLS는 최초 로딩 순간만 보는 지표가 아닙니다. 페이지 전체 생애 동안 측정될 수 있습니다. 사용자가 입력한 직후 500밀리초 안에 일어난 예상 가능한 이동은 CLS에서 제외될 수 있습니다. 클릭하자마자 메뉴가 펼쳐지는 것 같은 동작이 여기에 해당합니다. 하지만 스크롤한 뒤 공간 예약 없이 로드되는 지연 이미지의 이동은 사용자가 직접 입력한 결과로 보기 어렵기 때문에 CLS에 반영될 수 있습니다.

측정 방식에도 특징이 있습니다. web.dev는 2021년 6월부터 최대 세션 윈도 방식을 적용했다고 기록합니다. 이동이 연속해서 일어날 때, 이동 간격이 1초 미만이고 전체 길이가 최대 5초인 묶음을 하나의 세션 윈도로 보고, 그중 가장 큰 윈도의 점수를 사용하는 방식입니다. 그래서 오래 열어 둔 긴 페이지에서 작은 이동이 아주 드문드문 쌓이는 경우와, 짧은 시간에 몰려서 일어나는 이동을 같은 기준으로 다루지 않습니다.

이 구조를 이해하면 점검 방향도 달라집니다. 페이지 위쪽만 확인해서는 부족하고, 끝까지 스크롤하면서 이동이 생기는지 확인해야 합니다.

올바른 조합

정리하면 지연 로딩은 단독 최적화가 아니라 공간 예약과 한 쌍으로 설계해야 합니다.

① 화면 아래쪽 이미지에는 loading="lazy"를 적용합니다.
② 같은 이미지에 width·height 또는 aspect-ratio로 공간을 예약합니다.
③ 두 가지 중 하나라도 빠지면 이미지가 나타나는 순간 화면이 밀릴 위험이 남습니다.

<​img src="detail-1.jpg" width="1200" height="800" loading="lazy" alt="상세 이미지">

이 한 줄에는 비율 정보(공간 예약)와 로딩 시점(지연 로딩)이 함께 들어 있습니다. 두 속성이 서로 다른 문제를 푼다는 점을 구분해 두면 설계가 흔들리지 않습니다. 하나는 다운로드 시점에 관한 것이고, 다른 하나는 레이아웃에서 차지하는 자리에 관한 것입니다.

첫 화면 이미지와 아래쪽 이미지의 로딩 정책은 다릅니다

모든 이미지에 같은 규칙을 적용하면 안 됩니다. 화면에 처음 보이는 이미지와 스크롤해야 보이는 이미지는 로딩 정책이 달라야 합니다. 첫 화면 이미지에 아래쪽 이미지용 규칙을 그대로 쓰면 CLS는 안정되더라도 LCP가 나빠질 수 있습니다.

LCP 요소가 되는 첫 화면 이미지

LCP(Largest Contentful Paint)는 화면에서 가장 큰 콘텐츠가 표시되는 시점을 재는 지표입니다. Google Search Central은 양호 기준을 로드 시작 후 2.5초 이내로 제시하며, CLS와 마찬가지로 방문의 75% 이상에서 달성하도록 권고합니다. 첫 화면의 대표 이미지나 배너가 화면에서 가장 큰 요소라면 그 이미지가 곧 LCP 요소입니다.

이 이미지에 loading="lazy"를 적용하면 문제가 생깁니다. 지연 로딩은 이미지 요청 시작을 늦출 수 있으므로, 가장 먼저 보여야 할 이미지가 오히려 늦게 요청됩니다. web.dev는 LCP 이미지를 지연 로딩하지 말라고 안내합니다. 따라서 첫 화면 대표 이미지는 지연 로딩 없이 즉시 요청되게 두고, 대신 width·height로 공간을 확보합니다.

fetchpriority의 사용 범위

LCP일 가능성이 높은 이미지에는 fetchpriority="high"를 고려할 수 있습니다. 브라우저에 이 이미지의 요청 우선순위를 높여달라는 힌트를 주는 속성입니다.

<​img src="hero.jpg" width="1600" height="700" fetchpriority="high" alt="대표 이미지">

여기에는 절제가 필요합니다. web.dev는 한두 개를 넘는 이미지에 높은 우선순위를 주면 효과가 희석될 수 있다고 설명합니다. 모든 이미지가 중요하다고 표시하면 결국 어떤 것도 특별하지 않게 됩니다. 우선순위 힌트는 첫 화면의 실제 LCP 후보 한두 개에만 쓰는 것이 기본입니다.

두 가지 효과를 구분하기

여기서 구별해야 할 것이 있습니다. 아래쪽 이미지에 지연 로딩을 적용하면 초기에 받아야 할 데이터가 줄어드는 절감 효과가 생깁니다. 반면 첫 화면 이미지를 지연 로딩하면 첫 화면 표시 지연이 생깁니다. 두 효과는 같은 속성에서 나오지만 방향이 정반대입니다. 이미지 목록을 점검할 때 "이 이미지는 사용자가 페이지를 열자마자 보는가"라는 질문 하나로 정책이 갈립니다.

로딩 정책은 다음과 같이 정리할 수 있습니다.

① 첫 화면에서 보이는 대표 이미지: loading="lazy"를 쓰지 않습니다. width·height로 공간을 예약합니다. LCP 후보라면 fetchpriority="high"를 고려하되 한두 개 이내로 제한합니다.
② 첫 화면에서 보이지만 LCP는 아닌 보조 이미지: 지연 로딩은 쓰지 않는 쪽이 안전합니다. 이미 화면에 보이는 위치에 있다면 늦게 요청할 이유가 없습니다. 공간 예약은 반드시 합니다.
③ 스크롤해야 보이는 아래쪽 이미지: loading="lazy"를 적용하고 width·height 또는 aspect-ratio를 반드시 함께 둡니다.

첫 화면 이미지의 로딩 정책은 CLS와 LCP를 함께 고려해 정해야 합니다. CLS만 보고 정하면 LCP가 놓치고, LCP만 보고 정하면 CLS가 놓칩니다.

이미지 밖의 요소도 화면을 밉니다

화면을 미는 것은 이미지만이 아닙니다. 광고, 임베드, iframe처럼 외부에서 뒤늦게 들어오는 요소도 주변 콘텐츠를 밀어낼 수 있습니다. 지도, 동영상 플레이어, 소셜 게시물, 광고 슬롯이 대표적입니다. 이런 요소는 이미지와 달리 크기를 정확히 알기 어려운 경우가 많습니다.

이럴 때 제시되는 방법은 초기 공간을 예약하는 것입니다.

① min-height로 최소 높이를 확보합니다. 크기가 가변적일 때 최소한의 자리를 보장합니다.
② aspect-ratio로 비율을 선언합니다. 동영상처럼 비율이 정해진 임베드에 적합합니다.
③ 자리표시 영역을 둡니다. 실제 콘텐츠가 들어오기 전까지 같은 크기의 빈 영역을 보여줍니다.

.ad-slot {
min-height: 250px;
}
.video-embed {
aspect-ratio: 16 / 9;
width: 100%;
}

위 값은 설명을 위한 예시입니다. 모든 페이지에 통용되는 정답 크기가 있는 것이 아니라, 실제로 들어오는 광고나 임베드의 크기를 확인해서 정해야 합니다.

iframe 측정의 한계

한 가지 알아 둘 점이 있습니다. web.dev는 CrUX에 포함될 수 있는 iframe 내부의 이동이 Web API 기반 현장 측정에서는 포착되지 않을 수 있다고 설명합니다. 즉 iframe 안에서 일어나는 이동은 실제 사용자 데이터(CrUX)에는 반영되지만, 페이지에 직접 넣은 스크립트로 현장 측정할 때는 잡히지 않을 수 있습니다. 두 측정 결과가 어긋나는 이유를 찾을 때 이 점이 단서가 됩니다.

화면 밀림을 재현하고 원인을 찾는 점검 절차

측정 도구마다 보는 범위가 다르므로, 한 도구의 점수만 믿으면 원인을 놓칠 수 있습니다. 이 차이를 이해하는 것이 점검의 출발점입니다.

Lighthouse와 실제 사용자 데이터의 차이

Lighthouse의 기본 로드 검사는 페이지를 열어 초기 로딩 구간을 측정합니다. 이 방식은 페이지 생애 중 모든 이동을 포착하지 못할 수 있습니다. 스크롤해서 나타나는 지연 이미지나 상호작용 뒤 들어오는 요소는 기본 로드 검사에 잡히지 않을 수 있습니다. 반면 Chrome UX Report(CrUX)는 실제 방문자의 페이지 생애 동안의 CLS를 측정합니다.

그래서 Lighthouse에서는 양호하게 나왔는데 실제 사용자 데이터에서는 점수가 나쁜 상황이 생길 수 있습니다. 이는 어느 한쪽이 틀렸다는 뜻이 아니라 측정 범위가 다르다는 뜻입니다. 이럴 때는 CrUX 같은 현장 데이터에서 문제가 보인다면, 초기 로딩 이후의 이동을 의심하고 스크롤과 상호작용을 재현해 봐야 합니다.

단계별 점검 방법

다음 순서로 점검하면 원인을 좁히기 쉽습니다.

Step 1. 현장 데이터로 문제 여부 확인
CrUX 같은 현장 데이터에서 CLS가 0.1을 넘는지, 0.25를 넘는지 확인합니다. 방문의 75% 이상에서 양호 기준을 달성하고 있는지가 판단 기준입니다.

Step 2. 초기 로드 검사로 1차 점검
Lighthouse로 초기 로딩 구간의 이동을 확인합니다. 첫 화면에서 크기 정보가 없는 이미지나 늦게 들어오는 요소가 드러납니다.

Step 3. 이미지 목록 점검
페이지의 모든 <​img>를 훑으며 다음을 확인합니다.
① width·height 속성 또는 aspect-ratio가 있는가
② 화면 아래쪽 이미지에 loading="lazy"가 있는가
③ 첫 화면의 LCP 후보 이미지에 loading="lazy"가 잘못 붙어 있지 않은가
④ fetchpriority="high"가 한두 개를 넘지 않는가
⑤ <​picture>로 비율이 달라지는 이미지의 <​source>에 크기 속성이 있는가

Step 4. 스크롤과 상호작용 재현
페이지를 위에서 아래까지 천천히 스크롤하며 눈으로 흔들림을 확인합니다. 메뉴, 탭, 슬라이더를 조작해 보고 이동이 생기는지 봅니다. 이 단계가 기본 로드 검사의 빈틈을 메웁니다.

Step 5. DevTools에서 이동 요소 확인
Chrome DevTools의 Performance 패널에서 페이지 로딩과 스크롤을 기록하고, Layout shifts 기록에서 어떤 요소가 얼마나 움직였는지 확인합니다. 이동 지점이 특정 이미지나 임베드로 좁혀지면 원인이 보입니다.

Step 6. 화면 크기별 재현
모바일과 데스크톱 폭에서 각각 반복합니다. 반응형 레이아웃에서는 화면 폭에 따라 이미지 비율이나 배치가 달라지므로, 한쪽에서만 이동이 생기는 경우가 흔합니다. 느린 네트워크를 흉내 내어 이미지 도착을 늦추면 평소에 가려진 이동이 드러납니다.

원인 유형별 해결 방향

점검에서 찾은 원인은 대체로 다음 중 하나입니다.

① width·height·aspect-ratio가 모두 없는 이미지 → 크기 속성을 추가합니다.
② 아래쪽 이미지에 지연 로딩은 있으나 공간 예약이 없음 → 공간 예약을 추가합니다.
③ <​picture>에서 비율이 바뀌는데 <​source>에 크기 속성이 없음 → 각 <​source>에 비율을 맞춥니다.
④ 광고·임베드·iframe이 크기 없이 들어옴 → min-height, aspect-ratio, 자리표시 영역으로 초기 공간을 예약합니다.

적용할 때의 판단 기준과 흔한 실수

설계의 우선순위는 "이 이미지의 비율을 브라우저가 미리 아는가"입니다. 적용 과정에서 판단이 갈리는 지점과, 자주 반복되는 실수를 정리합니다.

판단 기준

① 모든 이미지에 비율 정보가 있어야 합니다. 이미지의 위치, 크기, 중요도와 관계없이 기본 조건입니다. 지연 로딩 여부와도 상관없이 공간 예약은 모든 이미지에 필요합니다.
② 로딩 시점은 이미지의 위치로 정합니다. 첫 화면에서 바로 보이면 즉시 로딩, 아래쪽이면 지연 로딩을 고려합니다.
③ 우선순위 힌트는 아껴 씁니다. fetchpriority="high"는 실제 LCP 후보 한두 개 이내로 제한합니다.
④ 이미지 외 요소도 같은 시각으로 봅니다. 늦게 들어오는 요소라면 자리를 먼저 잡아 둡니다.
⑤ 측정은 초기 로딩과 페이지 생애 양쪽에서 합니다. 한쪽 결과만으로 결론을 내리지 않습니다.

흔한 실수

실수 1. 이미지 파일만 줄이면 해결된다고 생각한다.
파일을 줄이면 도착이 빨라져 체감이 나아질 수는 있지만, 자리를 예약하지 않았다면 도착 시점의 이동은 그대로 남습니다. 속도 개선과 공간 예약은 별개의 작업입니다.

실수 2. height: auto만 쓰고 HTML 크기 속성은 생략한다.
CSS가 비율을 유지해 주는 것은 이미지가 도착한 뒤의 일입니다. 도착 전의 자리 확보는 HTML의 width·height 같은 크기 정보에서 나옵니다. 두 가지를 함께 두는 것이 안전합니다.

실수 3. 페이지 전체 이미지에 loading="lazy"를 일괄 적용한다.
첫 화면의 LCP 이미지까지 지연 로딩되면 요청 시작이 늦어져 LCP가 나빠질 수 있습니다. 일괄 적용 대신 위치별로 구분합니다.

실수 4. 여러 이미지에 fetchpriority="high"를 붙인다.
한두 개를 넘으면 효과가 희석됩니다. 정말 LCP 후보인 이미지로 한정합니다.

실수 5. 속성 값을 모든 화면에 통용되는 정답 크기로 생각한다.
width="800" height="600" 같은 값은 해당 이미지의 비율을 알려주는 수단이지, 모든 사이트에 맞는 표준 크기가 아닙니다. 실제 파일의 가로세로 비율을 기준으로 정해야 합니다.

실수 6. Lighthouse 한 번의 점수로 끝낸다.
초기 로드 검사는 스크롤 뒤 이동을 놓칠 수 있습니다. 스크롤과 상호작용을 재현하고 DevTools와 현장 데이터를 함께 봐야 합니다.

실수 7. CLS 개선이 곧 검색 순위 상승이라고 기대한다.
Google은 Core Web Vitals가 순위에 쓰인다고 하면서도 좋은 점수가 상위 노출을 보장하지는 않는다고 밝힙니다. 화면 안정성은 순위 하나를 위한 작업이 아니라, 읽다가 밀리거나 잘못 눌리는 경험을 줄이는 사용성 작업으로 보는 편이 정확합니다.

자주 묻는 질문

Q. 이미지 크기를 반응형으로 바꾸면 width·height를 적어도 의미가 없지 않나요?
의미가 있습니다. 두 속성은 화면 표시 크기를 고정하기 위한 것이 아니라 비율 정보를 브라우저에 미리 전달하기 위한 것입니다. 반응형 CSS로 폭이 바뀌어도, 브라우저는 그 비율을 바탕으로 높이를 계산해 자리를 확보할 수 있습니다.

Q. 이미지가 도착하기 전의 빈 공간이 보이는 것은 문제가 아닌가요?
빈 공간이 잠시 보이는 것은 레이아웃 이동이 아니므로 CLS 관점에서는 문제가 되지 않습니다. 빈 자리가 어색하다면 배경색이나 자리표시 영역으로 시각적으로 완화할 수 있고, 그 경우에도 자리는 그대로 유지하는 것이 핵심입니다.

Q. 사용자가 버튼을 누른 뒤 화면이 바뀌는 것도 CLS에 포함되나요?
사용자 입력 후 500밀리초 안에 일어난 예상 가능한 이동은 CLS에서 제외될 수 있습니다. 다만 그 시간이 지난 뒤에 지연되어 나타나는 이동은 반영될 수 있으므로, 입력 후 내용이 늦게 들어오는 영역에도 공간을 예약해 두는 편이 안전합니다.

마무리

화면이 밀리는 문제의 핵심은 이미지가 느리게 오는 것이 아니라, 오기 전에 자리가 없었다는 점입니다. 이를 바로잡는 설계는 다음 순서로 요약할 수 있습니다.

첫째, 모든 이미지에 width·height를 두거나 aspect-ratio로 비율을 선언해, 파일이 도착하기 전부터 브라우저가 자리를 계산하게 합니다.
둘째, 화면 아래쪽 이미지는 지연 로딩하되 반드시 공간 예약과 함께 적용합니다.
셋째, 첫 화면의 LCP 후보 이미지는 지연 로딩하지 않고, fetchpriority="high"는 한두 개 이내로 제한합니다.
넷째, 광고·임베드·iframe도 min-height나 aspect-ratio로 초기 공간을 예약합니다.
다섯째, 측정은 Lighthouse 한 번에 그치지 않고, 스크롤·상호작용 재현, DevTools의 Layout shifts, 현장 데이터를 함께 봅니다.

CLS 0.1 이하와 방문의 75% 이상이라는 기준은 목표선일 뿐, 그 자체가 순위나 성과를 보장하는 것은 아닙니다. 그래도 읽는 도중 글이 밀리지 않고 누르려는 버튼이 제자리에 있는 페이지는 방문자에게 분명히 더 편한 경험을 줍니다. 오늘 운영 중인 페이지의 이미지 목록을 한 번 훑으며 크기 정보가 빠진 곳부터 채워 보시길 권합니다.