사이트 실적과 비즈니스 측정항목 간의 상관관계를 찾는 것이 최적화 작업의 성공을 이끄는 열쇠였습니다.
Swappie는 리퍼폰을 판매하는 성공적인 스타트업입니다. 몇 년 동안 사이트 실적보다 새 기능 추가에 우선순위를 두었지만 모바일 사이트의 비즈니스 실적이 데스크톱 버전보다 뒤처지는 것을 발견하고 변화를 시도했습니다. 실적 최적화에 집중한 결과, 모바일 수익이 급증했습니다.
42%
모바일 방문자로부터 발생하는 수익 증가
10pp*
*%포인트 Rel mCvR 증가
기회 강조
상대적 모바일 전환율(상대적 mCvR)은 모바일 전환율을 데스크톱 전환율로 나누어 계산합니다. 속도 측정항목을 추적할 수 있는 기회는 많지만 이를 비즈니스 측정항목에 연결하는 것은 쉽지 않을 수 있습니다. 동일한 캠페인과 시즌성이 모바일과 데스크톱 모두에 도달하므로 상대적 mCvR 측정항목은 이러한 외부 매개변수의 영향을 제거하고 모바일 사이트가 개선되고 있는지 여부만 보여줍니다.
미국 내 10대 전자상거래 사이트의 평균 Rel mCvR은 50%이지만 Swappie는 24%였습니다. 이는 모바일 사이트에 문제가 있고 회사가 수익을 놓치고 있다는 것을 의미하므로 실적 개선 프로젝트가 시작되었습니다.
성능 개선의 영향 측정
Swappie는 Google 애널리틱스를 사용하여 이 템플릿 스프레드시트를 통해 Rel mCvR 및 모바일 평균 페이지 로드 시간의 일일 추적을 설정했습니다. 스프레드시트 사용 방법 안내를 읽어보세요. 또한 Google 애널리틱스 및 BigQuery를 통해 Core Web Vitals를 추적하기 시작했습니다. 추적을 설정하고 나서 개발자는 사이트 성능을 개선하기 시작했습니다.
3개월 만에 효과가 분명하게 나타났습니다. 상대적 모바일 전환율이 24% 에서 34% 로 증가했고 모바일 수익은 42% 증가했습니다.
23%
평균 페이지 로드 시간 단축
55%
LCP 감소
91%
CLS 감소
90%
FID 감소
최적화
LCP 및 CLS 최적화
Swappie의 개발팀은 오랫동안 간과되었던 사소한 부분을 개선할 여지가 많다는 사실을 발견했습니다. 다양한 뷰포트와 언어로 사이트를 살펴본 결과, 해결하기 쉽고 전반적인 실적에 큰 영향을 미치는 LCP 및 CLS 문제가 발견되었습니다. 예를 들어 가능하면 클라이언트 대신 서버에서 LCP 요소를 렌더링하면 LCP가 감소했습니다.
레이아웃 이동은 뷰포트와 연결에 따라 크게 달라질 수 있으므로 감지하기가 어려웠습니다. 사용자로부터 애널리틱스로 핵심 성능 보고서를 가져온 후 CLS가 감소하여 올바른 방향으로 가고 있음을 알게 되었습니다.
이미지
미리 로드, 지연 로드, 적절한 크기 조정을 통해 이미지가 최적화되었습니다. 주요 이미지 (예: LCP)를 미리 로드하고 필요할 때만 뷰포트 외부의 이미지를 로드합니다.
글꼴
Swappie는 제공업체를 전환하여 글꼴을 최적화했습니다. 이는 다양한 언어에 필요한 서체를 처리하는 최적의 방법이 필요했기 때문에 큰 영향을 미쳤습니다.
서드 파티 스크립트
Swappie는 각 서드 파티 스크립트와 위젯, 사용 위치, 제공하는 기능을 검토하는 데 많은 노력을 기울였습니다. 모든 이해관계자와 논의한 후 기능을 유지하면서 스크립트가 사이트에 미치는 영향을 줄이는 계획을 세웠습니다. 불필요한 부분을 삭제하고 나머지를 최적화하여 사이트의 서드 파티 JavaScript 양을 크게 줄였습니다.
사용하지 않는 코드 삭제 및 번들 최적화
가져오기를 최적화하고 사용하지 않는 JS 및 CSS를 삭제하여 Swappie의 사이트 성능을 약간 개선했지만 이러한 작은 개선사항이 시간이 지남에 따라 누적됩니다. 번들 설정도 최적화했습니다.
Swappie에서 성과 문화 조성하기
Swappie가 얻은 결과는 코드 변경뿐만 아니라 조직 및 우선순위 변경에서 비롯되었습니다.
엔지니어링 책임자인 Teemu Huovinen은 다음과 같이 설명합니다.
사이트 속도의 중요성을 제대로 강조하려면 사이트 속도를 비즈니스 측정항목에 연결해야 합니다. 시간과 리소스가 부족한 경우 항상 우선순위를 정하는 것이 중요합니다. 고객 가치를 우선시하는 것이 좋지만 사이트 속도가 사이트의 '느낌'만 개선하는 것이라고 생각하면 새 기능과 더 직접적인 전환 개선에 집중하기가 너무 쉽습니다. 사이트 속도를 비즈니스 측정항목에 연결하는 것이 항상 쉬운 것은 아닙니다. 이때 Rel mCvR을 사용한 계산이 큰 도움이 되었습니다.
테무 후오비넨
개발팀이 3개월 동안 사이트 속도에 전적으로 집중할 수 있게 되자 더 깊이 파고들 수 있는 동기가 생겼습니다.
YouTube의 영향력과 팀의 성장을 결합하면 더욱 인상적인 결과를 얻을 수 있습니다. 7명의 개발자 중 4명이 실적 개선 작업을 시작한 달 이내에 시작했습니다. 이 모든 공로는 팀에 돌아갑니다. 이 주제를 중심으로 모여 이렇게 큰 영향을 미칠 수 있었던 것은 정말 놀라운 일입니다.
테무 후오비넨
또한 Teemu는 개선하기 전에 데이터 기반 계획을 세우고, DevTools 성능 탭을 사용하는 방법을 배우고, 사용자 분석을 설정하는 데 시간을 할애하는 것이 중요하다고 지적합니다. 그래프 (특히 올바른 방향으로 진행되는 그래프)는 작업에 대한 의견과 검증을 얻을 수 있는 좋은 소스입니다. Lighthouse (실험실 기반) 점수와 함께 실제 환경에서 Core Web Vitals를 확인함으로써 가장 많은 사용자에게 영향을 미치는 적절한 사항을 최적화하는 데 집중할 수 있었습니다.