갑작스러운 레이아웃 변경을 피하여 사용자 환경을 개선하는 방법 알아보기
누적 레이아웃 변경 (CLS)은 세 가지 Core Web Vitals 측정항목 중 하나입니다. 표시 영역에서 보이는 콘텐츠의 변화 정도와 영향을 받는 요소가 이동한 거리를 결합하여 콘텐츠의 불안정성을 측정합니다.
레이아웃 변경으로 인해 사용자의 주의가 산만해질 수 있습니다. 기사를 읽기 시작했는데 페이지 주위에 갑작스러운 요소가 전부 이동하면서 흥미를 잃고 원하는 장소를 다시 찾아야 하는 상황이 발생했다고 상상해 보세요. 뉴스를 읽거나 '검색'을 클릭하려고 할 때 등 웹에서 많이 나타나는 현상은 또는 '장바구니에 추가' 버튼을 클릭합니다. 이러한 경험은 시각적으로 거슬리고 짜증이 납니다. 이러한 현상은 다른 요소가 갑자기 페이지에 추가되거나 크기가 조절되어 보이는 요소가 강제로 이동되는 경우에 발생합니다.
우수한 사용자 환경을 제공하기 위해 사이트는 페이지 방문의 최소 75% 에 대해 CLS를 0.1 이하로 유지해야 합니다.
<ph type="x-smartling-placeholder">초 또는 밀리초 단위로 측정되는 시간 기반 값인 다른 Core Web Vitals와 달리 CLS 점수는 콘텐츠가 얼마나 많이, 얼마나 이동하는지를 계산한 값을 기반으로 한 단위 없는 값입니다.
이 가이드에서는 레이아웃 변경의 일반적인 원인을 최적화하는 방법을 설명합니다.
낮은 CLS의 가장 일반적인 원인은 다음과 같습니다.
- 크기가 없는 이미지입니다.
- 크기가 없는 광고, 삽입 및 iframe
- 크기 없이 광고, 삽입, iframe과 같이 동적으로 삽입된 콘텐츠
- 웹 글꼴
레이아웃 변경 원인 이해
일반적인 CLS 문제의 해결책을 살펴보기 전에 CLS 점수와 변화가 발생한 위치를 이해하는 것이 중요합니다.
실습 도구와 현장에서의 CLS 비교
Chrome UX 보고서 (CrUX)에서 측정한 CLS가 Chrome DevTools 또는 다른 실험실 도구로 측정하는 CLS와 일치하지 않기 때문에 잘못되었다고 생각하는 개발자들을 많이 듣습니다. Lighthouse와 같은 웹 성능 실험실 도구는 일반적으로 페이지를 간단히 로드하여 일부 웹 성능 측정항목을 측정하고 안내를 제공하기 때문에 페이지의 전체 CLS를 표시하지 않을 수 있습니다. 하지만 Lighthouse 사용자 플로우를 사용하면 기본 페이지 로드 감사 이상의 측정을 할 수 있습니다.
CrUX는 Web Vitals 프로그램의 공식 데이터 세트입니다. 이를 위해 CLS는 실험실 도구에서 일반적으로 측정하는 초기 페이지 로드 중에뿐만 아니라 페이지의 전체 수명 동안 측정됩니다.
레이아웃 변경은 페이지 로드 중에 매우 흔하게 발생합니다. 초기에 페이지를 렌더링하는 데 필요한 모든 리소스를 가져오므로 초기 로드 이후에 레이아웃 변경이 발생할 수도 있습니다. 로드 후 변화 중 상당수는 사용자 상호작용의 결과로 발생할 수 있으며, 해당 상호작용으로부터 500밀리초 이내에 발생하는 경우 예상되는 변화이므로 CLS 점수에서 제외됩니다.
그러나 요건을 충족하는 상호작용이 없는 경우 사용자가 예상치 못한 다른 로드 후 변화(예: 페이지를 따라 더 스크롤할 때 지연 로드 콘텐츠가 로드되어 이동을 유발하는 경우)가 포함될 수 있습니다. 로드 후 CLS가 발생하는 다른 일반적인 원인은 전환 상호작용(예: 500밀리초의 유예 기간보다 오래 걸리는 단일 페이지 앱)에서 비롯됩니다.
PageSpeed Insights를 보면 사용자 인식 비정상 종료 발생률과 '실제 사용자가 경험하는 문제 파악' URL의 CLS 섹션으로 이동합니다. 'Diagnose performance issues(성능 문제 진단)'의 실습 기반 로드 CLS를 섹션으로 이동합니다. 이러한 값 간의 차이는 로드 후 CLS로 인한 결과일 수 있습니다.
<ph type="x-smartling-placeholder">![Lighthouse CLS보다 훨씬 큰 실제 사용자 CLS를 강조하는 URL 수준 데이터를 보여주는 PageSpeed Insights 스크린샷](https://web.developers.google.cn/static/articles/optimize-cls/image/screenshot-pagespeed-ins-1b9715cccc402.png?authuser=19&hl=ko)
로드 CLS 문제 식별
PageSpeed Insights의 CrUX 및 Lighthouse CLS 점수가 서로 일치한다면 일반적으로 Lighthouse에서 감지한 로드 CLS 문제가 있음을 나타냅니다. 이 경우 Lighthouse는 두 가지 감사를 통해 너비와 높이 누락으로 인해 CLS를 일으킨 이미지에 대한 자세한 정보를 제공하고 페이지 로드를 위해 변경된 모든 요소를 CLS 기여도와 함께 나열합니다. CLS 감사를 필터링하여 이러한 감사를 확인할 수 있습니다.
<ph type="x-smartling-placeholder">![CLS 문제를 식별하고 해결하는 데 도움이 되는 추가 정보를 제공하는 CLS 감사를 보여주는 Lighthouse 스크린샷](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-screenshot-sho-1c6eeefdc4b1b.png?authuser=19&hl=ko)
DevTools의 Performance 패널은 환경 섹션의 레이아웃 변경도 강조 표시합니다. Layout Shift
레코드의 Summary 뷰에는 누적 레이아웃 변경 점수와 영향을 받은 지역을 보여주는 직사각형 오버레이가 포함되어 있습니다. 이는 로드 CLS 문제에 대한 자세한 내용을 파악하는 데 특히 유용합니다. 이는 새로고침 성능 프로필로 쉽게 복제되기 때문입니다.
![환경 섹션을 펼칠 때 Chrome DevTools 성능 패널에 표시되는 레이아웃 변경 기록](https://web.developers.google.cn/static/articles/optimize-cls/image/layout-shift-records-bein-90d4c6c924a25.jpg?authuser=19&hl=ko)
Layout Shift
레코드를 표시하는 빨간색 색조의 막대로 채워집니다. 레코드를 클릭하면 '다음에서 이동됨'과 같은 세부정보를 표시하여 영향을 받은 요소를 상세히 살펴볼 수 있습니다. 및 '이동함' 입력되어야 합니다.
로드 후 CLS 문제 파악
CrUX와 Lighthouse CLS 점수 간 불일치는 로드 후 CLS를 나타내는 경우가 많습니다. 이러한 변화는 현장 데이터가 없으면 추적하기가 까다로울 수 있습니다. 필드 데이터 수집에 관한 자세한 내용은 필드에서 CLS 요소 측정을 참고하세요.
Web Vitals Chrome 확장 프로그램을 사용하면 헤드업 디스플레이 또는 Console에서 페이지와 상호작용할 때 변경된 요소 위에서 자세한 내용을 확인할 수 있어 CLS를 모니터링할 수 있습니다.
확장 프로그램을 사용하는 대신 콘솔에 붙여넣은 Performance Observer를 사용하여 레이아웃 변경을 기록하면서 웹페이지를 탐색할 수 있습니다.
교대 근무 모니터링을 설정한 후 로드 후 CLS 문제를 재현해 볼 수 있습니다. CLS는 사용자가 페이지를 스크롤하는 동안 지연 로드 콘텐츠가 여유 공간 없이 완전히 로드될 때 자주 발생합니다. 사용자가 포인터를 위에 두고 있을 때 콘텐츠가 이동하는 또 다른 일반적인 로드 후 CLS 원인입니다. 이러한 상호작용 중에 콘텐츠 이동이 발생하면 500밀리초 이내에 발생하더라도 예상치 못한 콘텐츠로 간주됩니다.
자세한 내용은 레이아웃 변경 디버그를 참고하세요.
CLS의 일반적인 원인을 파악한 후 Lighthouse의 기간 사용자 흐름 모드를 사용하여 레이아웃 변경을 도입하여 일반적인 사용자 흐름이 회귀하지 않도록 할 수도 있습니다.
필드의 CLS 요소 측정
현장에서 CLS를 모니터링하는 것은 CLS가 발생하는 상황을 판단하고 가능한 원인을 좁히는 데 매우 중요합니다. 대부분의 실험실 도구와 마찬가지로 현장 도구는 이동한 요소만 측정하지만 일반적으로 원인을 파악하기에 충분한 정보를 제공합니다. 또한 CLS 필드 측정을 사용하여 어떤 문제가 가장 먼저 해결해야 하는지 확인할 수도 있습니다.
web-vitals
라이브러리에는 이러한 추가 정보를 수집할 수 있는 저작자 표시 함수가 있습니다. 자세한 내용은 필드에서 성능 디버그를 참고하세요. 다른 RUM 제공업체도 이와 비슷하게 이 데이터를 수집하고 표시하기 시작했습니다.
CLS의 일반적인 원인
CLS의 원인을 파악했다면 문제 해결 작업을 시작할 수 있습니다. 이 섹션에서는 CLS의 보다 일반적인 이유와 이를 방지하기 위해 취할 수 있는 조치를 설명합니다.
크기가 없는 이미지
이미지와 동영상 요소에 항상 width
및 height
크기 속성을 포함하세요. 또는 CSS aspect-ratio
등을 사용하여 필요한 공간을 예약합니다. 이 접근 방식을 사용하면 이미지가 로드되는 동안 브라우저가 문서에 올바른 공간을 할당할 수 있습니다.
![이미지에 크기를 설정한 후 레이아웃 변경 횟수에 미치는 전후의 영향을 보여주는 Lighthouse 보고서](https://web.developers.google.cn/static/articles/optimize-cls/image/lighthouse-report-showing-9556bbb060b37.png?authuser=19&hl=ko)
이미지의 width
및 height
속성 기록
웹 초기에는 개발자가 width
및 height
속성을 <img>
태그에 추가하여 브라우저가 이미지를 가져오기 전에 페이지에 충분한 공간이 할당되도록 했습니다. 이렇게 하면 리플로우와 레이아웃 재배치가 최소화됩니다.
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
이 예의 width
및 height
에는 단위가 포함되지 않습니다. 이러한 '픽셀'은 브라우저가 페이지 레이아웃에서 640x360 영역을 예약하게 할 수 있습니다. 이미지의 실제 크기와 일치 여부에 관계없이 이 공간에 맞게 이미지가 늘어납니다.
반응형 웹 디자인이 도입되었을 때 개발자들은 width
및 height
를 생략하고 대신 CSS를 사용하여 이미지 크기를 조절하기 시작했습니다.
img {
width: 100%; /* or max-width: 100%; */
height: auto;
}
그러나 이미지 크기가 지정되지 않았으므로 브라우저에서 다운로드를 시작하고 크기를 확인할 때까지 이미지를 할당할 수 없습니다. 이미지가 로드되면서 텍스트를 페이지 아래로 내려가서 여유 공간을 확보하여 사용자에게 혼란과 불편을 초래합니다.
이때 가로세로 비율이 사용됩니다. 이미지의 가로세로 비율은 이미지의 너비에 대한 비율입니다. 일반적으로 콜론으로 구분된 두 개의 숫자 (예: 16:9 또는 4:3)로 표시됩니다. x:y 가로세로 비율의 경우 이미지는 너비가 x 단위이고 높이는 y 단위입니다.
즉, 측정기준 중 하나를 알고 있으면 다른 측정기준도 확인할 수 있습니다. 16:9 가로세로 비율:
- puppy.jpg의 높이가 360px인 경우 너비는 360x (16 / 9) = 640px입니다.
- puppy.jpg의 너비가 640픽셀인 경우 높이는 640x (9 / 16) = 360픽셀입니다.
이미지의 가로세로 비율을 알면 브라우저에서 높이와 관련 영역을 위한 충분한 공간을 계산하고 예약할 수 있습니다.
이미지 크기 설정을 위한 최신 권장사항
최신 브라우저는 이미지의 기본 가로세로 비율을
width
및 height
속성을 사용하지 않고
이미지에 이러한 속성을 설정하고
할 수 있습니다.
<!-- set a 640:360 i.e a 16:9 aspect ratio -->
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
그러면 모든 브라우저에서 요소의 기존 width
및 height
속성에 따라 기본 가로세로 비율이 추가됩니다.
이는 이미지가 로드되기 전에 width
및 height
속성을 기반으로 가로세로 비율을 계산합니다. 레이아웃 계산을 시작할 때 이 정보를 제공합니다. 이미지의 너비가 특정 너비여야 한다는 지시가 내려지면 (예: width: 100%
) 가로세로 비율이 높이를 계산하는 데 사용됩니다.
이 aspect-ratio
값은 기본 사용자 에이전트 스타일 시트가 아닌 HTML이 처리될 때 주요 브라우저에서 계산되므로 (이 게시물에서 자세한 이유 참고) 값이 약간 다르게 표시됩니다. 예를 들어 Chrome은 요소 패널의 스타일 섹션에 다음과 같이 표시합니다.
img[Attributes Style] {
aspect-ratio: auto 640 / 360;
}
Safari도 HTML 속성 스타일 소스를 사용하여 유사하게 동작합니다. Firefox는 계산된 이 aspect-ratio
를 Inspector(검사기) 패널에 전혀 표시하지 않지만 레이아웃에는 사용합니다.
위 코드의 auto
부분이 중요합니다. 이미지가 다운로드되면 이미지 크기가 기본 가로세로 비율을 재정의하기 때문입니다. 이미지 크기가 다르더라도 이미지가 로드된 후에도 레이아웃이 약간 변경됩니다. 하지만 이렇게 하면 HTML이 잘못된 경우 사용 가능해지면 이미지 가로세로 비율이 계속 사용됩니다. 실제 가로세로 비율이 기본값과 다르더라도 제공된 크기가 없는 이미지의 기본 크기인 0x0보다 레이아웃 변동이 적습니다.
반응형 이미지에 대해 자세히 알아보고 가로세로 비율을 자세히 살펴보려면 미디어 가로세로 비율을 사용한 버벅거림 없는 페이지 로드를 참고하세요.
이미지가 컨테이너에 있는 경우 CSS를 사용하여 컨테이너 너비에 맞게 이미지 크기를 조정할 수 있습니다. 이미지 높이에 고정된 값을 사용하지 않도록 height: auto;
를 설정합니다.
img {
height: auto;
width: 100%;
}
반응형 이미지는 어떤가요?
반응형 이미지를 사용할 때 srcset
는 브라우저가 선택할 수 있는 이미지와 각 이미지의 크기를 정의합니다. <img>
의 너비 및 높이 속성을 설정할 수 있도록 하려면 각 이미지가 동일한 가로세로 비율을 사용해야 합니다.
<img
width="1000"
height="1000"
src="puppy-1000.jpg"
srcset="puppy-1000.jpg 1000w, puppy-2000.jpg 2000w, puppy-3000.jpg 3000w"
alt="Puppy with balloons"
/>
내 이미지 사용자의 선택에 따라 가로세로 비율은 아트 디렉션에 사용됩니다. 예를 들어, 좁은 실내 공간에 이미지를 잘린 상태로 표시 영역을 설정하고 데스크톱에 전체 이미지를 표시합니다.
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" />
</picture>
Chrome, Firefox, Safari에서 이제 width
및 height
설정을
지정된 <picture>
요소 내 <source>
요소:
<picture>
<source media="(max-width: 799px)" srcset="puppy-480w-cropped.jpg" width="480" height="400" />
<source media="(min-width: 800px)" srcset="puppy-800w.jpg" width="800" height="400" />
<img src="puppy-800w.jpg" alt="Puppy with balloons" width="800" height="400" />
</picture>
광고, 삽입, 기타 늦게 로드된 콘텐츠
이미지 외에도 레이아웃 변경을 일으킬 수 있는 콘텐츠 유형이 있습니다. 광고, 삽입, iframe 및 기타 동적으로 삽입된 콘텐츠로 인해 콘텐츠가 아래로 이동하게 되어 CLS가 증가할 수 있습니다.
광고는 웹에서 레이아웃 변경에 가장 큰 영향을 미치는 요인 중 하나입니다. 광고 네트워크 및 게시자는 동적 광고 크기를 지원하는 경우가 많습니다. 광고 크기는 클릭률이 높아지고 입찰에서 더 많은 광고가 경쟁하기 때문에 실적/수익이 증가합니다. 안타깝지만 이렇게 하면 사용자가 페이지에서 조회 중인 콘텐츠를 아래로 밀어내는 광고로 인해 사용자 환경이 최적화되지 않을 수 있습니다.
삽입 가능한 위젯을 사용하면 YouTube 동영상, Google 지도의 지도 및 소셜 미디어 게시물과 같은 이동식 웹 콘텐츠를 페이지에 포함할 수 있습니다. 그러나 이러한 위젯은 로드하기 전에 콘텐츠의 크기를 인식하지 못하는 경우가 많습니다. 따라서 임베딩을 제공하는 플랫폼이 항상 위젯을 위한 공간을 예약하는 것은 아니며, 이로 인해 위젯이 최종적으로 로드될 때 레이아웃이 변하게 됩니다.
이 문제를 처리하는 기술도 모두 유사합니다. 주요 차이점은 삽입되는 콘텐츠에 대한 관리 권한의 정도입니다. 광고 파트너와 같은 제3자가 삽입하는 경우 삽입될 콘텐츠의 정확한 크기를 모르거나 이러한 삽입에서 발생하는 레이아웃 변경을 제어하지 못할 수 있습니다.
콘텐츠를 늦게 로드할 수 있는 공간 확보
콘텐츠 흐름에 늦게 로드되는 콘텐츠를 배치할 때 레이아웃 변경을 피할 수 있습니다. 초기 레이아웃에 공간을 남겨 두세요.
한 가지 방법은 min-height
CSS 규칙을 추가하여 공간을 확보하거나(예: 광고와 같은 반응형 콘텐츠) aspect-ratio
CSS 속성을 브라우저가 제공된 크기가 있는 이미지에 자동으로 사용하는 것과 유사한 방식으로 사용하는 것입니다.
미디어 쿼리를 사용하는 폼 팩터마다 광고 또는 자리표시자 크기의 미묘한 차이를 고려해야 할 수도 있습니다.
광고와 같이 높이가 고정되지 않은 콘텐츠의 경우 레이아웃 변경을 완전히 없애는 데 필요한 정확한 공간을 확보하지 못할 수 있습니다. 작은 광고가 게재되는 경우 게시자는 레이아웃 변경을 방지하기 위해 더 큰 컨테이너의 스타일을 지정하거나 이전 데이터를 기반으로 광고 슬롯에 가장 적합한 크기를 선택할 수 있습니다. 이 방식의 단점은 페이지의 빈 공간이 증가한다는 것입니다.
대신 초기 크기를 사용될 가장 작은 크기로 설정하고 더 큰 콘텐츠의 경우 어느 정도의 이동을 허용할 수 있습니다. 앞서 제안한 대로 min-height
를 사용하면 상위 요소가 필요에 따라 커지면서 레이아웃 변경의 영향을 줄일 수 있습니다(빈 요소의 기본 크기 0픽셀보다 큰 경우).
예를 들어 반환되는 광고가 없는 경우 자리표시자를 표시하여 예약된 공간이 축소되지 않도록 하세요. 요소용으로 따로 설정한 공백을 제거하면 콘텐츠 삽입과 동일한 수준의 CLS가 발생할 수 있습니다.
표시 영역 아래에 늦게 로드되는 콘텐츠를 배치하기
표시 영역 상단에 더 가깝게 동적으로 삽입된 콘텐츠는 일반적으로 표시 영역 아래에 삽입된 콘텐츠보다 더 큰 레이아웃 변경을 야기합니다. 그러나 표시 영역의 아무 곳에나 콘텐츠를 삽입하면 여전히 약간의 변화가 발생합니다. 삽입된 콘텐츠를 위한 공간을 확보할 수 없는 경우 콘텐츠를 나중에 페이지에 배치하여 CLS에 미치는 영향을 줄이는 것이 좋습니다.
사용자 상호작용 없이 새 콘텐츠 삽입 방지
사이트를 로드하려고 할 때 표시 영역의 상단이나 하단에 표시되는 UI로 인해 레이아웃이 변경된 경우가 있을 수 있습니다. 광고와 마찬가지로 배너와 양식에서 페이지의 나머지 콘텐츠를 이동하는 경우가 많습니다.
<ph type="x-smartling-placeholder">이러한 유형의 UI 어포던스를 표시해야 하는 경우 로드 시 페이지의 콘텐츠가 예기치 않게 이동하지 않도록 표시 영역에 충분한 공간을 미리 확보해야 합니다 (예: 자리표시자 또는 스켈레톤 UI 사용). 또는 적절한 위치에 콘텐츠를 오버레이하여 요소가 문서 흐름의 일부가 되지 않도록 하세요. 이러한 유형의 구성요소에 대한 추가 권장사항은 쿠키 참고사항 관련 권장사항 게시물을 참조하세요.
경우에 따라 콘텐츠를 동적으로 추가하는 것이 사용자 환경의 중요한 부분입니다. 예를 들어 상품 목록에 더 많은 제품을 로드하거나 실시간 피드 콘텐츠를 업데이트하는 경우입니다. 이러한 경우 예기치 않은 레이아웃 변경을 방지할 수 있는 몇 가지 방법이 있습니다.
- 고정 크기 컨테이너 내의 기존 콘텐츠를 새 콘텐츠로 대체하거나 캐러셀을 사용해 전환 후 기존 콘텐츠를 삭제합니다. 전환이 완료될 때까지 링크와 컨트롤을 사용 중지하면 새 콘텐츠가 업로드되는 동안 의도하지 않은 클릭이나 탭을 방지할 수 있습니다.
- 사용자가 새 콘텐츠 로드를 시작하도록 하여 사용자가 당황하지 않도록 합니다 (예: '더보기' 또는 '새로고침' 버튼). 콘텐츠가 즉시 표시되도록 사용자 상호작용 전에 콘텐츠를 미리 가져오는 것이 좋습니다. 참고로 사용자 입력 후 500밀리초 이내에 발생하는 레이아웃 변경은 CLS에 포함되지 않습니다.
- 콘텐츠를 화면 밖으로 원활하게 로드하고 사용자에게 사용 가능하다는 알림을 오버레이합니다 (예: '위로 스크롤' 버튼 사용).
![Twitter와 Chloé 웹사이트에서 예상치 못한 레이아웃 변경을 일으키지 않는 동적 콘텐츠 로드의 예](https://web.developers.google.cn/static/articles/optimize-cls/image/examples-dynamic-content-4d11ddda2fa94.png?authuser=19&hl=ko)
애니메이션
CSS 속성 값을 변경하면 브라우저가 이러한 변경사항에 반응해야 할 수 있습니다. box-shadow
및 box-sizing
와 같은 일부 값은 재레이아웃, 페인트, 합성을 트리거합니다. top
및 left
속성을 변경하면 이동하는 요소가 자체 레이어에 있더라도 레이아웃이 전환됩니다. 이러한 속성을 사용하여 애니메이션을 적용하지 마세요.
다른 CSS 속성은 재레이아웃을 트리거하지 않고 변경할 수 있습니다. transform
애니메이션을 사용하여 요소를 변환, 크기 조정, 회전 또는 왜곡하는 등의 작업을 할 수 있습니다.
translate
를 사용하여 합성된 애니메이션은 다른 요소에 영향을 줄 수 없으므로 CLS에 포함되지 않습니다. 합성되지 않은 애니메이션도 레이아웃이 다시 발생하지 않습니다. 레이아웃 변경을 트리거하는 CSS 속성에 관한 자세한 내용은 고성능 애니메이션을 참고하세요.
웹 글꼴
웹 글꼴 다운로드 및 렌더링은 일반적으로 웹 글꼴이 다운로드되기 전에 다음 두 가지 방법 중 하나로 처리됩니다.
- 대체 글꼴은 웹 글꼴로 전환되어 스타일이 지정되지 않은 텍스트 (FOUT)가 플래시됩니다.
- '숨김' 텍스트는 웹 글꼴을 사용할 수 있게 되고 텍스트가 표시될 때까지 대체 글꼴을 사용하여 표시됩니다 (FOIT - 보이지 않는 텍스트가 플래시됨).
두 접근 방식 모두 레이아웃이 변경될 수 있습니다. 텍스트가 보이지 않더라도 여전히 대체 글꼴을 사용하여 배치되므로 웹 글꼴이 로드되면 텍스트 블록과 주변 콘텐츠가 표시되는 글꼴과 같은 방식으로 이동합니다.
다음 도구를 사용하면 텍스트 이동을 최소화할 수 있습니다.
font-display: optional
는 재레이아웃을 방지할 수 있습니다. 웹 글꼴은 초기 레이아웃 시점에 사용 가능한 경우에만 사용되기 때문입니다.- 적절한 대체 글꼴이 사용되었는지 확인합니다. 예를 들어
font-family: "Google Sans", sans-serif;
를 사용하면"Google Sans"
가 로드되는 동안 브라우저의sans-serif
대체 글꼴이 사용됩니다.font-family: "Google Sans"
만 사용하여 대체 글꼴을 지정하지 않으면 기본 글꼴이 사용되며 Chrome에서는 'Times'(기본sans-serif
글꼴보다 더 낮은 Serif 글꼴)가 사용됩니다. - 개선된 글꼴 대체 게시물에 설명된 대로 새로운
size-adjust
,ascent-override
,descent-override
,line-gap-override
API를 사용하여 대체 글꼴과 웹 글꼴 간의 크기 차이를 최소화합니다. - Font Loading API를 사용하면 필요한 글꼴을 가져오는 데 걸리는 시간을 줄일 수 있습니다.
<link rel=preload>
를 사용하여 중요한 웹 글꼴을 최대한 빨리 로드합니다. 미리 로드된 글꼴은 첫 번째 페인트를 충족할 가능성이 더 높습니다. 이 경우 레이아웃은 변경되지 않습니다.
다른 글꼴 권장사항은 글꼴 권장사항을 참고하세요.
페이지가 bfcache를 사용할 수 있도록 하여 CLS를 줄입니다.
CLS 점수를 낮게 유지하는 매우 효과적인 기법은 웹페이지에서 뒤로-앞으로 캐시 (bfcache)를 사용할 수 있도록 하는 것입니다.
bfcache는 사용자가 다른 페이지로 이동한 후에도 잠시 동안 브라우저 메모리에 페이지를 보관하므로, 이 페이지로 돌아오면 페이지를 떠난 대로 페이지가 복원됩니다. 즉, 앞에서 설명한 이유로 인해 로드 중에 일반적으로 표시될 수 있는 변화 없이 완전히 로드된 페이지를 즉시 사용할 수 있습니다.
이는 잠재적으로 초기 페이지 로드 시 레이아웃이 변경된다는 의미이지만, 사용자가 페이지를 다시 방문하면 동일한 레이아웃이 반복적으로 표시되지 않습니다. 항상 초기 로드에서도 변화를 피하는 것을 목표로 해야 하지만 완전히 해결하기가 더 까다로운 경우에는 적어도 bfcache 탐색에서 변화를 피하여 영향을 줄일 수 있습니다.
뒤로 및 앞으로 탐색은 많은 사이트에서 일반적으로 사용됩니다. 예를 들어 콘텐츠 페이지, 카테고리 페이지 또는 검색결과로 돌아가는 경우가 여기에 해당합니다.
이 기능이 Chrome에 출시되었을 때 CLS가 눈에 띄게 개선되었습니다.
bfcache는 모든 브라우저에서 기본적으로 사용되지만, 일부 사이트에서는 여러 가지 이유로 bfcache를 사용할 수 없습니다. bfcache 가이드에서 bfcache 사용을 방해하는 문제를 테스트하고 식별하는 방법을 자세히 알아보고 이 기능을 최대한 활용하여 사이트의 전체 CLS 점수를 높이는 데 도움을 받으세요.
결론
이 가이드의 앞부분에서 자세히 설명한 것처럼 CLS를 식별하고 개선하는 다양한 기법이 있습니다. Core Web Vitals에는 허용치가 내포되어 있으므로 CLS를 완전히 제거할 수 없더라도 이러한 기술 중 일부를 사용하면 영향을 줄일 수 있습니다. 이렇게 하면 이러한 한도 내에서 웹사이트 사용자에게 더 나은 경험을 제공할 수 있습니다.