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