코어 웹 바이탈 최적화 및 Next.js로 이전하는 데 중점을 둔 프로젝트를 통해 전환율이 5%, 세션당 페이지수가 87% 증가했습니다.
QuintoAndar는 브라질의 혁신적인 건설 기술 회사로, 부동산을 위한 디지털 엔드 투 엔드 솔루션을 제공하는 제품을 보유하고 있습니다. 올해 Google은 앱의 콘텐츠 허브 실적 개선에 중점을 둔 프로젝트를 진행했으며, 사용자 트래픽과 전환 측정항목을 늘리는 데 긍정적인 결과를 얻었습니다.
46%
이탈률 감소
87%
세션당 페이지수 증가
5%
검증 단계에서 전환 개선
도전과제
이 앱에는 40,000개가 넘는 페이지가 있는 아파트 콘텐츠 허브가 있어 사용자가 숙박 시설에 대한 정보를 얻고, 공용 공간의 사진을 확인하고, 주변 환경에 관해 읽고, 임대 또는 판매 가능한 등록정보를 찾을 수 있습니다. 다음 페이지는 QuintoAndar에 매우 중요합니다.
- 검색엔진 결과에서 발생하는 사용자 수가 꾸준히 증가함에 따라 자연 트래픽의 중요한 소스입니다.
- 다른 페이지에 비해 중장기적으로 전환율이 높습니다.
하지만 이러한 페이지의 성능과 사용자 환경에는 문제가 있었습니다.
- Core Web Vitals로 측정한 성능이 최적화되지 않았으며 페이지 로드 속도가 느리고, 사용자 입력에 대한 응답 속도가 느리며, 레이아웃이 불안정하다는 알려진 문제가 있었습니다.
- 앱의 다른 부분보다 이탈률이 높을 것으로 예상했지만 이탈률이 높았습니다.
- 당시 아직 출시되지 않았던 Google 검색의 페이지 경험 업데이트에서는 순위 알고리즘에 Core Web Vitals를 포함할 예정이었습니다. 즉, 페이지 실적이 검색 결과 표시 방식에 영향을 미칠 수 있었습니다.
동시에 Google은 회사의 다른 프로젝트에서 이익을 얻을 수 있는 몇 가지 개발자 환경 기회를 파악했습니다.
- 아파트 페이지를 포함한 트래픽이 많은 모든 페이지를 렌더링하는 서버 측 렌더링 로직은 사내에서 제작되었으며, 너무 복잡해져 신규 직원을 유지하고 온보딩하기가 어려웠습니다.
- 코드 분할과 같이 우수한 앱 성능을 달성하는 데 필수적인 기능도 맞춤 설정과 개발자의 수동 작업이 필요했습니다.
- QuintoAndar에는 30개가 넘는 React 웹 애플리케이션이 있습니다. 이러한 애플리케이션에 업데이트를 제공하고 권장사항에 따라 유지하는 것은 어려운 작업입니다.
접근 방식
Google은 사용자 환경을 개선하기 위해 아파트 콘텐츠 허브의 성능 최적화 프로젝트를 시작했습니다. 이러한 개선사항은 전환수 증가, SEO 개선, 사용성 향상으로 이어질 수 있기 때문입니다. 이 이니셔티브는 개발자 환경을 개선할 수 있는 적절한 기회이기도 했습니다.
Next.js로 이전
아파트 페이지의 새 버전이 Next.js로 구현되었습니다. 아파트 콘텐츠 허브는 앱의 다른 부분과 거의 독립적이므로 새로운 프레임워크를 시도해 볼 만한 좋은 후보로 보였습니다. QuintoAndar의 다른 React 앱에 영향을 주지 않으면서 이전 작업의 규모를 파악하고 이 기능이 어떻게 도움이 될 수 있는지 평가할 수 있습니다.
검색엔진에서 페이지를 계속 크롤링할 수 있어야 한다는 엄격한 요구사항이 있었습니다. Next.js는 서버 측 렌더링을 즉시 지원하여 이 요구사항을 충족하며 맞춤 설정이 필요하지 않습니다. 문서를 사용하면 서버에서 데이터 가져오기와 같은 작업을 실행하고 신규 개발자를 온보딩하는 방법에 관한 지식을 훨씬 더 쉽게 공유할 수 있습니다. 서버 측 렌더링은 콘텐츠가 포함된 첫 페인트 (FCP)와 같은 성능 측정항목을 개선하는 것으로도 알려져 있습니다.
프레임워크는 자동 코드 분할 및 prefetching와 같은 다른 성능 친화적인 기능도 제공합니다. 기존 구조에서 이미 이러한 기능을 제공하고 있었지만 개발자가 추가로 해야 하는 작업으로 인해 채택이 지연되었습니다. 예를 들어 페이지 또는 구성요소 수준에서 코드 분할을 수동으로 수행해야 했습니다.
JavaScript 리소스 최적화
첫 번째 단계는 사용되지 않는 코드를 삭제하는 것이었습니다. 각 JS 번들의 콘텐츠를 보여주는 Webpack Bundle Analyzer 보고서를 살펴보고 모든 서드 파티 스크립트를 신중하게 검토했습니다. 그 결과 이 특정 페이지에서 사용되지 않은 일부 추적 라이브러리를 정리할 수 있었습니다.
YouTube팀은 더 나아가 기존 기능의 성능 비용을 평가했습니다. 예를 들어 '좋아요' 버튼을 사용하려면 상당히 많은 JS가 필요했습니다. 하지만 아파트 페이지에서는 앱의 다른 부분에서 더 자주 사용되고 있는 이 버튼을 0.5% 미만의 사용자만 사용했습니다. 엔지니어링팀과 제품팀의 논의를 거쳐 이 기능을 삭제하기로 결정했습니다.
Brotli를 사용한 정적 압축과 같은 다른 JS 최적화는 이미 적용되어 있었습니다. 이 최적화는 BrotliWebpackPlugin
를 사용하여 빌드 시 실행되었으며 다른 유형의 정적 리소스에도 적용되었습니다. 처음에는 CDN에서 제공하는 압축을 사용했지만 Brotli를 사용하면 gzip에 비해 JS 크기가 18% 줄었습니다. 하지만 빌드 시간에 Brotli 압축으로 전환하여 24% 를 줄일 수 있었습니다.
이미지 리소스 최적화
모바일 버전에서는 스크롤 없이 볼 수 있는 부분의 대부분을 히어로 이미지가 차지합니다. 또한 페이지의 최대 콘텐츠 페인트 (LCP)이기도 합니다.
이전에는 모든 이미지에 이미 반응형 이미지를 게재하기 위한 srcset
및 sizes
속성이 있었습니다. 또한 Thumbor를 사용하여 주문형으로 이미지 크기를 조절하고 CDN을 구성하여 이미지를 효율적으로 캐시했습니다.
최신 휴대기기에는 픽셀 밀도가 매우 높은 디스플레이가 장착되어 있습니다. 즉, 브라우저는 가능한 경우 이미지의 3배 또는 4배 버전을 렌더링합니다. 해상도가 높아질수록 인간의 눈으로 차이를 인식하기가 어려워지지만 파일 크기는 관계없이 증가합니다. 최대 이미지 해상도 제한으로 사용자 환경을 저하시키지 않으면서 이미지 크기를 개선했습니다. 히어로 이미지는 최대 2배 버전으로 게재되도록 제한했습니다. 이는 3배 버전보다 약 35% 작고 4배 버전보다 50% 작습니다.
마지막으로 LCP 측정항목을 개선하기 위해 미리 로드 전략을 사용하여 최대한 빨리 다운로드하고 표시했습니다.
<link rel="preload" href="/img/450x450/892847321-143.0038687080606IMG20180420WA0037.jpg" as="image">
Next.js 내장 이미지 구성요소에는 반응형 크기 조절, 우선순위 설정된 로드 등 이러한 최적화가 많이 포함되어 있습니다. 이 프로젝트에서는 이 구성요소를 사용하도록 기존 이미지를 이전하지 않았지만, 새로운 기능에 이를 채택할 계획입니다.
레이아웃 변경 줄이기
아파트 페이지에 누적 레이아웃 변경 (CLS)과 관련된 몇 가지 문제가 있습니다. 레이아웃 전환을 담당하는 요소는 클라이언트에서만 렌더링되었습니다. 예를 들어 클라이언트에서 렌더링된 구성요소로 서버 측 마크업을 수화하거나 정의된 width
및 height
속성이 없는 이미지를 들 수 있습니다.
이러한 문제를 해결하기 위해 가능한 경우 이러한 요소의 정확한 크기를 설정하거나 min-height
를 사용하여 예상 값을 설정합니다. aspect-ratio
CSS 속성을 사용하는 등 더 많은 옵션이 있습니다. 또한 동적으로 렌더링된 구성요소가 레이아웃 전환을 일으키지 못하도록 자리표시자를 만들었습니다.
점진적인 변경사항 출시
Google은 사용자 환경을 개선하기 위해 최적화된 버전의 아파트 헙 페이지가 제대로 작동하는지 확인하고자 했습니다. 이를 위해 점진적인 출시 전략을 채택했습니다.
- 첫 번째 단계에서는 엄선된 몇 개의 URL에 새 버전이 게시되었으므로 하루에 수백 명의 사용자만 이를 볼 수 있었습니다.
- 두 번째 단계에서는 더 많은 페이지에 게시되어 하루에 수천 명의 사용자에게 도달했습니다.
- 세 번째이자 마지막 단계에서는 모든 페이지에 게시되었으며 모든 사용자를 대상으로 출시가 완료되었습니다.
이 기간 동안 엔지니어링팀은 프로덕션에서 페이지 성능을 지속적으로 측정하고 개선을 위해 노력했습니다. 또한 팀은 새 버전과 이전 버전 간의 비즈니스 측정항목을 비교했습니다. 이 검증 기간의 결과는 매우 긍정적이었습니다.
결과
팀은 SpeedCurve를 사용하여 아파트 페이지에 대해 실험실 테스트를 지속적으로 실행했습니다. 모바일 버전의 결과는 다음과 같습니다.
실험 측정항목 | 이전 | 이후 | 차이 |
---|---|---|---|
최대 콘텐츠 렌더링 시간(LCP) | 2.41초 | 1.48초 | -39% |
상호작용 시간 (TTI) | 12.16초 | 7.48초 | -39% |
총 차단 시간 (TBT) | 1124밀리초 | 1,056밀리초 | -4% |
레이아웃 변경 횟수(CLS) | 0.0402 | 0.0093 | -77% |
또한 실제 사용자에게 미치는 영향을 확인하고자 했습니다. Instana 웹사이트 모니터링으로 수집된 현장 데이터를 사용하여 출시 전후 1개월 동안의 데이터를 살펴봤습니다. 모바일 사용자의 75번째 백분위수를 비교한 결과 LCP가 26% 감소하고 FID가 72% 감소했습니다.
PageSpeed Insights에서는 지난 28일 동안의 현장 데이터 보고서를 제공합니다. 가장 많이 액세스된 아파트 페이지 하나만으로도 모바일 사용자를 위한 보고서를 생성하기에 충분한 데이터가 있었습니다. 2021년 11월 현재 모든 Core Web Vitals가 '좋음' 버킷에 있습니다.
점진적으로 출시하는 동안 이탈률이 감소한 것으로 나타났습니다. 모든 페이지의 출시가 완료될 때 Google 애널리틱스에 따르면 이탈률이 46% 감소하고, 세션당 페이지수가 87% 증가했으며, 평균 세션 시간이 49% 증가했습니다. 유료 검색의 경우 이탈률 감소 폭이 더 커서 59% 까지 떨어졌습니다. 이는 클릭당비용 (PPC) 광고에 대한 투자에 있어 긍정적인 신호입니다.
비즈니스 측정항목에 미치는 영향은 투어 일정 예약, 부동산 임대 또는 구매 신청과 같은 거래의 전환율을 분석하여 확인했습니다. 개선사항이 적용되는 동안 Google팀은 이전 버전과 새 버전 간의 전환을 비교했습니다. 같은 주에 새 버전이 적용된 페이지 그룹의 전환수가 5% 증가한 반면, 다른 페이지의 전환수는 동일한 측정항목에서 약간 감소했습니다.
결론
이 프로젝트는 프레임워크 없는 React에서 Next.js로의 장기적인 이전 작업의 첫 번째 부분입니다. 그 이후로 아파트 페이지를 담당한 팀은 개선된 개발자 환경에 관해 긍정적인 피드백을 주었습니다. 새 웹 앱을 부트스트랩해야 했던 다른 팀은 이미 Next.js를 사용해 부트스트랩했습니다. Google은 Next.js가 유지보수 작업을 간소화하고 다양한 앱 간에 공통 기반을 마련할 것으로 기대하고 있습니다.
전반적으로 아파트 콘텐츠 허브는 사용자 수와 거래 수 측면에서 지속적으로 성장하고 있습니다. 장기적으로 QuintoAndar의 운영 확장, 페이지 색인 생성 개선과 같은 SEO 이니셔티브 등 여러 요인이 이러한 결과에 기여했습니다. 이 프로젝트에서 페이지 실적도 긍정적인 전환 효과를 가져올 가능성이 큰 요인 중 하나라는 것을 확인했습니다.
사용자 데이터를 살펴보고 이 사례 연구에 나온 모든 전환 분석을 작성해 주신 SEO팀의 제품 관리자인 페드로 카르모님께 특별히 감사드립니다.