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