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