영국의 한 주요 뉴스 웹사이트는 몇 개월 만에 75번째 중앙값 CLS를 0.25에서 0.1로 250% 개선했습니다.
시각적 안정성 문제
레이아웃 전환은 매우 방해가 될 수 있습니다. Telegraph Media Group (TMG)에서는 독자들이 주로 뉴스를 소비하기 위해 애플리케이션을 사용하므로 시각적 안정성이 특히 중요합니다. 기사를 읽는 동안 레이아웃이 바뀌면 독자가 현재 위치를 놓칠 수 있습니다. 이로 인해 불편을 끼쳐 드려 죄송합니다.
엔지니어링 관점에서 페이지가 이동하거나 리더를 중단하지 않도록 하는 것은 쉽지 않을 수 있습니다. 특히 애플리케이션 영역이 비동기식으로 로드되고 페이지에 동적으로 추가되는 경우 더욱 그렇습니다.
TMG에는 클라이언트 측 코드에 기여하는 여러 팀이 있습니다.
- 핵심 엔지니어링 콘텐츠 추천 및 댓글과 같은 영역을 강화하기 위해 서드 파티 솔루션을 구현합니다.
- 마케팅. A/B 테스트를 실행하여 독자가 새로운 기능이나 변경사항과 상호작용하는 방식을 평가합니다.
- 광고. 광고 요청 및 광고 사전 입찰 관리
- 광고소재 트윗이나 동영상과 같은 기사 내 코드 삽입, 맞춤 위젯 (예: 코로나19 케이스 추적기)
이러한 각 팀이 페이지 레이아웃을 갑자기 변경하지 않도록 하는 것은 쉽지 않을 수 있습니다. 누적 레이아웃 이동 측정항목을 사용하여 독자에게 얼마나 자주 발생하는지 측정한 결과, 팀은 실제 사용자 환경에 대한 더 많은 통계를 얻고 달성해야 할 명확한 목표를 세울 수 있었습니다. 그 결과 75번째 퍼센티일 CLS가 0.25에서 0.1로 개선되고 통과 버킷이 57% 에서 72%로 증가했습니다.
250%
75번째 백분위수 CLS 개선도
15%
CLS 점수가 우수한 사용자 증가
시작점
CrUX 대시보드를 사용하여 페이지가 원하는 것보다 더 많이 이동하고 있음을 확인할 수 있었습니다.
이상적으로는 독자의 75% 이상이 '좋은' 환경을 이용할 수 있도록 하기 위해 레이아웃 불안정성의 원인을 파악하기 시작했습니다.
레이아웃 이동을 측정하는 방법
Chrome DevTools와 WebPageTest를 함께 사용하여 레이아웃이 이동하는 원인을 파악했습니다. DevTools에서 성능 탭의 환경 섹션을 사용하여 레이아웃 전환의 개별 인스턴스와 전반적인 점수에 기여한 정도를 강조 표시했습니다.
WebPageTest에서는 '레이아웃 전환 강조 표시'를 선택하면 타임라인 뷰에서 레이아웃 전환이 발생하는 위치를 강조 표시합니다.
가장 많이 방문한 템플릿의 각 변화를 검토한 결과 개선 방법에 관한 아이디어 목록을 작성했습니다.
레이아웃 변경 줄이기
레이아웃 전환을 줄일 수 있는 네 가지 영역(광고, 이미지, 헤더, 삽입)에 중점을 두었습니다.
광고
광고는 JavaScript를 통한 초기 페인트 후에 로드됩니다. 로드된 일부 컨테이너에는 예약된 높이가 없었습니다.
정확한 높이는 알 수 없지만 슬롯에 로드된 가장 일반적인 광고 크기를 사용하여 공간을 확보할 수 있습니다.
경우에 따라 광고의 평균 높이를 잘못 판단했습니다. 태블릿 리더의 경우 슬롯이 접혔습니다.
슬롯을 다시 살펴보고 가장 일반적인 크기를 사용하도록 높이를 조정했습니다.
이미지
웹사이트의 많은 이미지가 지연 로드되며 이미지를 위한 공간이 예약되어 있습니다.
하지만 도움말 상단의 인라인 이미지에는 컨테이너에 예약된 공간이 없고 태그와 연결된 너비 및 높이 속성이 없었습니다. 이로 인해 로드될 때 레이아웃이 이동했습니다.
이미지에 너비 및 높이 속성을 추가하기만 하면 레이아웃이 전환되지 않았습니다.
헤더
헤더가 마크업에서 콘텐츠 아래에 있었고 CSS를 사용하여 상단에 배치되었습니다. 원래 의도는 탐색 전에 콘텐츠 로드에 우선순위를 두는 것이었지만 이로 인해 페이지가 잠시 전환되었습니다.
헤더를 마크업 상단으로 이동하면 이러한 전환 없이 페이지를 렌더링할 수 있었습니다.
삽입
자주 사용되는 일부 삽입에는 정의된 가로세로 비율이 있습니다. 예를 들어 YouTube 동영상이 있습니다. 플레이어가 로드되는 동안 YouTube에서 썸네일을 가져와 동영상이 로드되는 동안 자리표시자로 사용합니다.
효과 측정
이 문서 시작 부분에 언급된 도구를 사용하여 기능 수준에서 영향을 매우 쉽게 측정할 수 있었습니다. 하지만 템플릿 수준과 사이트 수준에서 모두 CLS를 측정하고 싶었습니다. 합성적으로는 SpeedCurve를 사용하여 사전 프로덕션과 프로덕션에서 모두 변경사항을 검증했습니다.
그러면 코드가 프로덕션에 도달하면 RUM 데이터 (mPulse에서 제공)에서 결과를 검증할 수 있습니다.
RUM 데이터를 확인하면 Google에서 진행 중인 변경사항이 독자에게 긍정적인 영향을 미치고 있다는 확신을 가질 수 있습니다.
Google에서 수집하는 RUM 데이터의 최종 수치를 확인했습니다. 페이지 순위에 영향을 미칠 예정이므로 지금 특히 중요합니다. 먼저 CrUX 대시보드를 통해 제공되는 월별 출처 수준 데이터와 BigQuery를 쿼리하여 이전 p75 데이터를 가져오는 두 가지 방법으로 Chrome UX 보고서를 사용했습니다. 이렇게 하면 CrUX로 측정된 모든 트래픽에서 75번째 중앙값 CLS가 0.25에서 0.1로 250% 개선되었으며 통과 버킷이 57% 에서 72%로 증가했음을 쉽게 확인할 수 있었습니다.
또한 Chrome UX Report API를 활용하여 템플릿으로 분할된 일부 내부 대시보드를 만들 수 있었습니다.
CLS 회귀 방지
성능을 개선하는 데 있어 중요한 측면은 회귀를 방지하는 것입니다. 주요 측정항목에 대한 몇 가지 기본 실적 예산을 설정하고 여기에 CLS를 포함했습니다.
테스트가 예산을 초과하면 Google에서 원인을 조사할 수 있도록 Slack 채널에 메시지가 전송됩니다. 또한 템플릿이 예산 범위 내에 있더라도 부정적인 영향을 미친 변경사항을 파악할 수 있도록 주간 보고서를 설정했습니다.
또한 mPulse를 사용하여 정적 알림과 이상 감지를 모두 설정하여 RUM 데이터와 합성 데이터를 모두 사용할 수 있도록 예산을 확대할 계획입니다. 이를 통해 비정상적인 변경사항을 파악할 수 있습니다.
CLS를 염두에 두고 새로운 기능에 접근하는 것이 중요합니다. 앞서 언급한 변경사항 중 상당수는 독자에게 게시된 후에 수정해야 했던 사항입니다. 앞으로는 처음부터 예기치 않은 레이아웃 전환을 방지할 수 있도록 모든 신규 기능의 솔루션 설계 시 레이아웃 안정성을 고려할 예정입니다.
결론
지금까지 구현한 개선사항은 매우 간단했으며 상당한 영향을 미쳤습니다. 이 도움말에서 설명한 많은 변경사항은 적용하는 데 시간이 많이 걸리지 않았으며 가장 흔히 사용되는 모든 템플릿에 적용되었으므로 독자에게 광범위한 긍정적인 영향을 미쳤습니다.
사이트에 아직 개선해야 할 부분이 있습니다. Google은 CLS를 더욱 개선할 수 있도록 클라이언트 측 로직을 서버 측에서 더 많이 실행할 수 있는 방법을 모색하고 있습니다. Google은 측정항목을 지속적으로 개선하고 독자에게 최상의 사용자 환경을 제공하기 위해 측정항목을 계속 추적하고 모니터링할 것입니다.