솔직히 애드센스 심사가 반려됐을 때 콘텐츠만 들여다봤습니다. 글이 부족한가, 카테고리가 문제인가, 페이지가 너무 적은가. 원인을 찾겠다고 글을 추가하고 카테고리를 정리하면서 몇 주를 보냈습니다. 그런데 진짜 원인은 전혀 다른 곳에 있었습니다. CLS 점수가 0.4를 넘어 있었고, 저는 그때까지 CLS가 뭔지도 몰랐습니다. 방향을 잘못 잡으면 열심히 할수록 더 멀어집니다. 이 글은 그 경험을 바탕으로, CLS를 어떻게 진단하고 실제로 어떻게 고쳤는지를 정리한 것입니다.
CLS 원인 진단: PageSpeed Insights보다 DevTools가 정확합니다
CLS(Cumulative Layout Shift)란 페이지가 로딩되는 동안 화면 요소가 예기치 않게 움직이는 정도를 수치로 나타낸 지표입니다. 구글이 Core Web Vitals의 하나로 채택한 사용자 경험 측정 기준으로, 0.1 이하면 좋음, 0.25 이상이면 나쁨으로 분류됩니다(출처: Google Web.dev). 이 수치가 높으면 독자가 글을 읽다가 텍스트가 갑자기 아래로 밀리는 경험을 하게 됩니다. 한 번 겪어본 사람은 그게 얼마나 불쾌한지 압니다.
처음 PageSpeed Insights로 점수를 확인했을 때는 숫자만 나왔습니다. 0.43이라는 점수가 뜨긴 했는데, 어디서 레이아웃 이동이 생기는지 바로 알기는 어려웠습니다. CLS 관련 글들이 원인을 잘 나열해놓긴 하는데, 실제로 내 블로그 어디가 문제인지 찾는 방법을 제대로 설명한 글은 드물다고 생각합니다. 저도 처음엔 원인 목록만 보고 이것저것 건드리다 시간을 꽤 날렸습니다. 원인 목록이 아니라 진단 방법이 먼저 필요했는데, 그걸 모르고 결과만 고치려 했던 겁니다.
Chrome DevTools의 Performance 탭에서 직접 녹화해보니 상황이 훨씬 명확해졌습니다. Layout Shift 이벤트가 빨간색으로 표시되는데, 이미지가 로드될 때마다 그 아래 텍스트 전체가 확 밀리는 게 눈으로 보였습니다. 원인은 단순했습니다. 이미지 태그에 width와 height 속성을 전혀 지정하지 않은 것이었습니다. 브라우저가 이미지 크기를 모르니 일단 자리를 잡지 않고, 이미지가 로드된 뒤에 공간을 확보하면서 아래 콘텐츠를 밀어내는 구조였습니다. 단순한 원인이었는데, 그걸 찾는 데 생각보다 오래 걸렸습니다.
CLS를 유발하는 주요 원인으로는 이미지 태그에 width와 height를 지정하지 않은 경우가 가장 흔합니다. 그 외에 웹폰트 로딩 지연으로 인한 글자 크기 변화, 애드센스 등 동적으로 삽입되는 광고, YouTube나 지도 같은 iframe 임베드, top·left·width·height 속성을 변경하는 CSS 애니메이션, JavaScript로 페이지 상단에 주입되는 배너 등이 있습니다.
Google Search Console의 Core Web Vitals 리포트에서도 URL 단위로 문제를 확인할 수 있습니다(출처: Google Search Console). 다만 이건 이미 수집된 실사용자 데이터 기준이라 반영에 시간이 걸립니다. 빠르게 원인을 찾고 싶다면 Chrome DevTools 녹화를 먼저 해보는 쪽이 훨씬 실용적입니다. Search Console은 문제가 있다는 것을 알려주고, DevTools는 어디서 생기는지 보여줍니다. 둘을 같이 써야 합니다.
이미지 최적화와 애드센스 승인: 고치고 나서야 보인 것들
이미지 태그에 width와 height를 추가하는 작업부터 시작했습니다. 실제 이미지 비율에 맞춰 수치를 넣어주면 브라우저가 이미지 로드 전에 공간을 미리 잡아두기 때문에 레이아웃 이동이 생기지 않습니다. 단순한 작업인데 효과는 컸습니다. 유튜브 임베드는 aspect-ratio라는 CSS 속성으로 감쌌습니다. aspect-ratio란 요소의 가로세로 비율을 고정하는 속성으로, 16/9처럼 지정하면 iframe이 로드되는 과정에서 크기가 변하지 않습니다. 이 속성 하나가 유튜브 임베드 관련 CLS를 거의 다 잡아줬습니다.
폰트 처리에 대해서는 의견이 좀 갈립니다. font-display: swap을 쓰라고 권장하는 글이 많은데, 저는 CLS 관점에서는 font-display: optional이 더 안전하다고 생각합니다. font-display란 웹폰트가 로드되기 전까지 텍스트를 어떻게 보여줄지 결정하는 속성입니다. swap은 시스템 폰트를 먼저 보여주다가 웹폰트가 로드되면 교체하는 방식인데, 이 교체 순간에 글자 크기가 바뀌면서 레이아웃 이동이 생길 수 있습니다. optional은 폰트가 빠르게 로드되지 않으면 그냥 시스템 폰트를 쓰는 방식이라 교체 자체가 일어나지 않습니다. 시각적으로 웹폰트를 꼭 보여줘야 하는 경우라면 swap을 선택할 수도 있지만, CLS 점수를 낮추는 게 목표라면 optional이 더 유리합니다. swap이 무조건 좋다고 설명하는 글들은 CLS 영향을 생략하고 있는 겁니다.
광고 컨테이너 처리도 빠뜨리기 쉬운 부분입니다. 애드센스를 달고 나면 광고가 로드되면서 CLS가 새로 발생하는 경우가 있습니다. 광고 슬롯에 최소 높이를 미리 지정해두면 광고가 로드되기 전에도 공간이 확보되어 있어서 밀림이 생기지 않습니다. 직접 써봤는데, 이 부분을 처리하지 않으면 승인 이후에도 CLS 점수가 다시 나빠질 수 있습니다. 애드센스 승인을 받고 광고를 달았는데 다시 점수가 올라가는 걸 보면서, 승인받고 끝이 아니라는 걸 실감했습니다. 광고 자체가 CLS를 만들 수 있다는 점은 많은 글에서 빠져 있는 내용입니다.
CSS 애니메이션을 쓰는 경우라면 transform과 opacity 속성만 사용하는 것이 원칙입니다. top, left, width, height를 직접 바꾸는 애니메이션은 레이아웃 재계산을 유발해 CLS에 영향을 줍니다. transform은 레이아웃 재계산 없이 시각적 위치만 바꾸기 때문에 CLS를 일으키지 않습니다. 이 차이를 알고 나면 애니메이션 코드를 짤 때 선택 기준이 명확해집니다. 같은 시각적 효과라도 어떤 속성을 건드리느냐에 따라 성능에 미치는 영향이 완전히 달라집니다.
수정을 마치고 PageSpeed Insights를 다시 돌렸더니 CLS가 0.05로 내려갔습니다. 그 다음 애드센스 심사에서 승인이 났습니다. 당시에 CLS가 심사 기준에 영향을 줄 수 있다는 걸 알고 미리 체크했더라면 몇 주는 아꼈을 것입니다. 콘텐츠 보강보다 기술적인 지표 점검이 먼저여야 했습니다.
CLS는 SEO와 사용자 경험 모두에 영향을 미치는 지표입니다. 애드센스 심사를 준비 중이라면, 콘텐츠보다 먼저 PageSpeed Insights와 Chrome DevTools로 점수를 확인해보시길 권합니다. 이미지 태그에 width와 height를 추가하고, 유튜브 임베드에 aspect-ratio를 적용하고, 광고 슬롯에 최소 높이를 설정하는 것만으로도 점수는 크게 달라집니다. 저처럼 원인도 모른 채 콘텐츠만 붙잡고 있는 분이 있다면, 지금 바로 DevTools부터 열어보시는 것이 맞습니다.
참고