Mail.ru 홈페이지에서 코어 웹 바이탈을 개선하기 위해 수개월 동안 노력한 결과 누적 레이아웃 변경 (CLS)의 75번째 백분위수가 60% 증가했으며, 평균 세션 시간은 2.7%, 핵심 섹션의 전환율은 10% 이상 증가했습니다.
처음
Mail.ru는 러시아어를 사용하는 인터넷 분야의 선도적인 이메일 서비스 중 하나로, 트래픽 측면에서 러시아의 상위 5위 사이트에 속합니다. Mail.ru는 많은 사람들에게 중요한 리소스입니다. 매달 수억 명이 방문하는 이 포털은 사람들이 이메일, 뉴스, 소셜 미디어, 인터넷 검색 성능 등에 액세스할 수 있는 포털입니다.
Mail.ru는 방문자에게 높은 품질의 사용자 환경을 제공하기 위해 코어 웹 바이탈을 개선하기 시작했습니다. 최적화 전략에 대해 논의하기 전에 먼저 Mail.ru 홈페이지의 몇 가지 기술적인 세부사항을 알아 두어야 합니다.
이 프로젝트는 Google의 사내 템플릿 엔진인 Fest를 사용해 오랫동안 개발되어 왔지만 2019년부터 Svelte 3로 이전하기 시작했습니다.
Svelte는 가상 DOM을 사용하지 않는 방식으로 반응형을 구현하므로 리소스 사용량이 적습니다. Svelte의 접근 방식은 프로덕션 번들에서 사용되지 않는 함수를 삭제합니다. 함수가 사용되지 않으면 이러한 함수를 구현하는 코드가 컴파일러에 의해 생성되지 않기 때문입니다. 사용되지 않은 코드는 컴파일 중에 삭제되므로 번들이 더 작아집니다. 이렇게 하면 페이지 시작 중에 총 차단 시간 (TBT)을 줄일 수 있습니다.
실적 측정항목 추적
코어 웹 바이탈을 최적화하기 전에 현장에서 성능을 평가하는 것이 좋습니다. 코어 웹 바이탈을 사용하기 전에는 내부 성능 대시보드에서 콘텐츠가 포함된 첫 페인트 (FCP)와 같은 다른 측정항목을 추적했습니다.
코어 웹 바이탈을 수집하고 시각화를 위해 성능 대시보드에 전송하도록 측정항목 수집 스크립트가 수정되었습니다. Google의 권장사항에 따라 스크립트는 PerformanceObserver API를 사용하여 측정항목을 얻습니다. 이 API는 Mail.ru 내 범용 프런트엔드 '플랫폼'의 일부입니다.
대시보드에는 사용자에 대해 다음과 같은 측정항목이 표시되었습니다 (2021년 3월 15~21일 주간의 평균값).
| 측정항목 그룹 이름 | 코어 웹 바이탈 | 기타 웹 바이탈 | |||||
|---|---|---|---|---|---|---|---|
| 측정항목 이름 | LCP | FID | CLS | FCP | 미정 | 상호작용까지의 시간 | |
| 코어 웹 바이탈 기준점에 따른 사용자 비율 | good | 52% | 92% | 33% | 35% | 42% | 43% |
| 개선 필요 | 19% | 5% | 23% | 38% | 16% | 25% | |
| 위험 | 29% | 3% | 44% | 27% | 42% | 32% | |
코어 웹 바이탈 개선
코어 웹 바이탈 개선을 위한 많은 안내가 존재하지만 모든 프로젝트에는 고유한 과제가 있습니다. Mail.ru 홈페이지의 경우 다음과 같은 기회가 확인되었습니다.
- 광고 배너의 자리표시자를 구현하여 CLS를 줄입니다.
- 서버 측 렌더링 (SSR)을 사용하여 최대 콘텐츠 렌더링 시간 (LCP) 줄이기
- LCP와 최초 입력 반응 시간 (FID)을 줄이기 위한 코드 분할.
CLS 개선을 위한 골격
CLS는 Mail.ru 홈페이지에서 가장 저조한 필드 측정항목 중 하나였습니다. 이후 Chrome DevTools의 성능 패널에서 이 페이지를 프로파일링한 결과 광고가 문제의 원인인 것으로 밝혀졌습니다. Google은 레이아웃의 안정성을 개선하기 위해 광고가 로드되기 전에 자리표시자를 사용하여 광고를 위한 공간을 예약하기로 했습니다.
자리표시자를 구현할 때 첫 번째 단계는 자리표시자를 대체할 콘텐츠의 크기를 결정하는 것입니다. Mail.ru 홈페이지의 데스크톱 버전에는 광고 크기가 엄격하게 기록되어 있습니다. 디자인팀과 논의한 후 SVG 애니메이션 UI 스켈레톤은 인지되는 콘텐츠 로드 시간을 단축하기 위해 자리표시자로 사용되었습니다.
SSR의 귀환
Fest에서 Svelte로의 전환을 쉽게 하기 위해 우리는 처음부터 다시 시작하지 않고 기존 프로젝트를 점진적으로 다시 작성했습니다. 2021년 3월까지 대부분의 프런트엔드를 Svelte로 이전했고 백엔드 성능 문제를 분류하고 해결한 후 SSR을 프로덕션 애플리케이션에 도입했습니다.
SSR을 구현한 후 CLS 회귀의 원인을 발견했는데, 처음에는 발견하지 못했습니다. 페이지의 첫 번째 콘텐츠를 렌더링할 때 뉴스 섹션이 삽입되지 않았습니다. 서버에서 제공한 페이지 마크업을 처음 그린 후 클라이언트에 뉴스 섹션을 삽입하는 시점 사이에 지연이 발생했습니다. 이 동작으로 인해 광고 스켈레톤 전환이 발생하여 CLS가 악화되었습니다.
Chrome의 DevTools가 Layout Shift 이벤트를 표시했지만, 처음에는 그 이유를 찾지 못했습니다. SSR 자체는 문제가 아니었지만 나중에 솔루션을 발견하는 데 도움이 되었습니다. 페인팅 지연을 담당하는 코드를 수정하여 뉴스 구성요소의 레이아웃 안정성을 개선했습니다.
SSR이 CLS에 미칠 수 있는 또 다른 효과는 하이드레이션 전후의 구성요소 이동으로, 이는 추가적인 레이아웃 변경으로 이어질 수 있습니다. 특히 모바일 버전에서 이 문제가 발생했으며 수화 구성요소 마크업에 각별히 주의를 기울여야 했습니다. 이 문제를 해결할 수 있는 좋은 방법은 가능한 한 많은 디스플레이 로직을 자바스크립트에서 CSS로 전송하는 것이었습니다.
코드 분할 및 사용되지 않는 폴리필
인지되는 페이지 로드 속도를 개선하기 위해 LCP 및 FID 값을 낮추기 위한 작업이 필요했습니다. 이를 달성하는 한 가지 방법은 코드 분할을 사용하는 것입니다. Mail.ru 홈페이지 자체 외에도 Google 팀은 포털 탐색을 위한 위젯을 개발하고 있습니다. 현재 많은 Google 프로젝트에 포함되어 있습니다.
기록상의 이유로 위젯은 페이지의 맨 처음에 동기 로드 스크립트로 삽입됩니다. 시간이 지남에 따라 이 스크립트의 폴리필 비율이 증가했습니다. 이러한 폴리필을 로드하는 데 따른 부정적인 성능 영향을 제한하기 위해 우리는 최신 브라우저와 기존 브라우저 모두에 코드 분할을 구현했습니다.
Google에서는 최신 또는 기존 브라우저용 JavaScript 번들을 로드할 때 module/nomodule 패턴을 사용하지 않기로 결정했습니다. <script> 요소의 type="module" 속성이 요구에 따라 충분히 최신 브라우저를 타겟팅하지 않았기 때문입니다. Mail.ru는 이 문제를 해결하기 위해 백엔드에서 최신 브라우저 버전을 식별하는 사내 도구를 사용하여 이러한 브라우저에 맞게 조정할 수 있습니다.
백엔드에서 브라우저를 식별할 수 있게 되면 최신 브라우저와 기존 브라우저에 대한 코드 분할을 구현했습니다. 그 결과 최신 브라우저용으로 동기식으로 로드되는 JavaScript 위젯의 크기가 43.3% 감소했습니다. 이 방법은 일부 다른 포털 스크립트에도 적용되었습니다.
코드 분할은 번들 크기를 줄이고 Core Web Vitals에 긍정적인 영향을 미칠 뿐만 아니라 개발자 경험도 개선합니다. 사용자 중 3.5% 만이 기존 브라우저를 사용하며 그 비율은 감소 추세입니다. 따라서 코드 분할을 구현함으로써 개발자들은 기존 브라우저에 필요한 폴리필 블로트를 모든 사용자에게 소개하지 않고도 최신 브라우저 API를 사용할 수 있었습니다.
결과
최적화 작업을 진행한 후 필드 데이터에서 2021년 5월 24~30일에 해당하는 주의 평균값을 관찰했습니다.
| 측정항목 그룹 이름 | 코어 웹 바이탈 | 기타 웹 바이탈 | |||||
|---|---|---|---|---|---|---|---|
| 측정항목 이름 | LCP | FID | CLS | FCP | 미정 | 상호작용까지의 시간 | |
| 코어 웹 바이탈 기준점에 따른 사용자 비율 | good | 58% (+6%) | 93% (+1%) | 93% (+60%) | 43% (+8%) | 49% (+7%) | 51% (+8%) |
| 개선 필요 | 18% | 4% | 3% | 34% | 17% | 24% | |
| 위험 | 24% | 3% | 4% | 23% | 34% | 25% | |
아래 그래프는 '플랫폼'에 따른 웹페이지 실적 측정항목 값의 변화를 보여줍니다. 그래프에서 중요한 두 날짜에 주목하세요.
- 2021년 3월 23일: 마지막 페이지 섹션이 포함된 반복 버전이 Svelte로 이전되었습니다.
- 2021년 4월 19일: 반환된 SSR 및 CLS 회귀를 수정하기 위해 레이아웃이 수정된 반복 버전이 출시되었습니다.
5월 1일부터 5월 10일까지 값이 감소한 이유는 러시아의 5월 휴일 때문입니다.
'플랫폼'을 사용하여 얻은 결과는 Chrome UX 보고서 (CrUX)의 측정항목 값 증가와 일치합니다.
초기 개선사항 적용 전의 평균 사용자 세션 시간 값과 출시 후 1주일을 비교하면 2.7% 증가한 것으로 나타났습니다. 또한 페이지의 대부분의 섹션에서 전반적으로 전환이 크게 증가했습니다. 특히 Mail.ru 이메일 앱으로의 전환은 11.6%, 뉴스 섹션의 전환은 13.5% 증가했습니다.
181%
양호한 CLS 기준점의 점유율 상승
2.7%
평균 세션 시간 증가
13.5%
뉴스 섹션 전환율 증가
가장 예상치 못한 결과는 마케팅 배너의 클릭률(CTR)이 17.4% 증가한 것입니다. SSR 및 미리 로드 태그를 도입하여 렌더링 시간이 크게 단축되었습니다.
페이지의 나머지 섹션을 분석한 결과, 대부분의 섹션에서 실적이 크게 개선된 것을 확인했습니다. 이 페이지에서 핵심이 아닌 날씨 및 코로나바이러스와 같은 섹션의 전환율도 각각 9.6%, 9.5% 증가했습니다.
결론
관련된 작업이 장기간 유지될 수 있다는 점에서 성능을 개선하기란 쉽지 않습니다. 시간 경과에 따른 측정항목의 변화를 정기적으로 모니터링하고 모든 새로운 제품 기능으로 인해 코어 웹 바이탈에서 회귀가 발생하지 않는지 확인해야 합니다. 이를 위해 성능 예산에서 코어 웹 바이탈의 변화를 모니터링합니다.
무엇보다도 Google에서는 관리자, 디자이너, 테스터, 품질보증 담당자 등 제품 팀의 모든 구성원에게 코어 웹 바이탈의 중요성을 강조했습니다. 각 팀원은 성과 측정항목을 알고 있어야 하며 이를 개선할 수 있어야 합니다. 또한 성능 최적화 목표를 정기적으로 비즈니스 프로세스에 통합합니다. 고품질의 사용자 환경을 성공적으로 제공하는 것은 모든 팀원의 노력이 있어야만 가능합니다.