코어 웹 바이탈을 최적화하고 Next.js로 이전하는 데 중점을 둔 프로젝트의 전환율은 5%, 세션당 페이지 수는 87% 증가했습니다.
QuintoAndar는 브라질의 Proptech 회사로, 부동산을 위한 디지털 엔드 투 엔드 솔루션을 제공하는 제품으로, 올해 Google에서는 앱에서 콘텐츠 허브의 성능을 개선하는 데 중점을 둔 프로젝트를 진행하여 사용자 트래픽과 전환 측정항목을 늘리는 등 고무적인 결과를 얻었습니다.
46%
이탈률 감소
87%
세션당 페이지수 증가율
5%
검증 단계에서의 전환 증가율
과제
이 앱에는 40,000페이지가 넘는 콘도 콘텐츠 허브가 있습니다. 사용자는 이 허브에서 부동산에 관한 정보를 얻고, 공용 공간의 사진을 확인하고, 주변 지역에 관한 정보를 확인하고, 임대 또는 매매 가능한 매물을 찾을 수 있습니다. 다음 페이지는 QuintoAndar에 매우 중요합니다.
- 검색 엔진 결과를 통해 유입되는 사용자가 꾸준히 증가하고 있는 자연 트래픽의 중요한 원천입니다.
- 다른 페이지에 비해 중장기 전환율이 높습니다.
하지만 다음 페이지의 성능과 사용자 경험 측면에서 문제가 있었습니다.
- 코어 웹 바이탈에서 측정한 성능은 최적화되지 않았으며 느린 페이지 로드, 사용자 입력에 대한 느린 응답, 레이아웃 불안정과 관련된 알려진 문제가 있었습니다.
- 앱의 다른 부분보다 이탈률이 높을 것으로 예상했으나 이탈률이 높았습니다.
- 당시에는 아직 출시되지 않았던 Google 검색의 페이지 경험 업데이트에는 순위 알고리즘에 코어 웹 바이탈이 포함되었기 때문에 페이지 성능이 검색결과가 표시되는 방식에 영향을 미칠 수 있었습니다.
동시에 회사 전체의 다른 프로젝트에서 이득을 얻을 수 있는 몇 가지 개발자 경험 기회를 확인했습니다.
- 콘도 페이지를 비롯하여 트래픽이 많은 페이지를 모두 렌더링하는 Google의 서버 측 렌더링 로직은 사내에서 만들어져서 신입 사원을 유지관리하고 온보딩하기에는 너무 복잡해졌습니다.
- 코드 분할과 같이 앱 성능을 높이는 데 필요한 필수 기능에도 맞춤 설정과 개발자의 수동 작업이 필요했습니다.
- QuintoAndar에는 30개가 넘는 React 웹 애플리케이션이 있습니다. 이러한 애플리케이션에 업데이트를 제공하고 권장사항에 따라 유지관리하는 것은 힘든 작업입니다.
접근 방법
Google은 사용자 환경을 개선하기 위해 콘도 콘텐츠 허브의 성능 최적화 프로젝트를 시작했습니다. 이러한 개선을 통해 전환율 증가, 검색엔진 최적화(SEO), 사용성 향상으로 이어질 수 있기 때문입니다. 이 이니셔티브는 또한 개발자 환경을 개선하기에 적합한 기회이기도 했습니다.
Next.js로 이전
새로운 버전의 콘도미니엄 페이지는 Next.js로 구현되었습니다. 콘도 콘텐츠 허브는 앱의 다른 부분과 대체로 독립적이기 때문에 새로운 프레임워크를 시도해 보는 데 적합해 보였습니다. 마이그레이션 작업의 규모를 이해하고 QuintoAndar의 다른 React 앱에 영향을 주지 않으면서 이 기능이 어떤 도움이 될 수 있는지 평가할 수 있습니다.
어려운 요구사항은 검색엔진에서 페이지를 크롤링할 수 있도록 유지하는 것이었습니다. Next.js는 서버 측 렌더링을 즉시 지원하여 이러한 요구사항을 충족하며 맞춤 설정이 필요하지 않습니다. 이 문서를 통해 서버에서 데이터 가져오기와 같은 작업을 수행하고 새 개발자를 온보딩하는 등의 작업을 수행하는 방법에 대한 지식을 더욱 쉽게 공유할 수 있습니다. 서버 측 렌더링은 콘텐츠가 포함된 첫 페인트 (FCP)와 같은 성능을 개선하는 것으로 알려져 있습니다.
이 프레임워크는 자동 코드 분할 및 미리 가져오기와 같이 성능 친화적인 기타 기능을 제공합니다. 기존 구조에서 이러한 기능을 이미 제공했음에도 불구하고 개발자가 추가로 수행해야 하는 작업으로 인해 도입이 지연되었습니다. 예를 들어 페이지 또는 구성요소 수준에서 코드를 분할하는 작업은 수동으로 이루어져야 했습니다.
JavaScript 리소스 최적화
첫 번째 단계는 사용하지 않는 코드를 삭제하는 것이었습니다. Google에서는 각 JS 번들의 콘텐츠를 보여주는 Webpack 번들 분석 도구 보고서를 살펴보고 모든 서드 파티 스크립트를 신중하게 검토했습니다. 결과적으로 이 페이지에서 사용되지 않은 일부 추적 라이브러리를 정리할 수 있었습니다.
또한 기존 기능의 성능 비용을 평가했습니다. 예를 들어 '좋아요' 버튼을 사용하려면 JS가 많이 필요했습니다. 하지만 콘도 페이지에서 사용자 중 0.5% 미만이 버튼과 상호작용했는데, 이는 앱의 다른 부분에서 사용 가능하고 더 자주 사용되는 버튼입니다. Google은 엔지니어링 및 제품 모두에 관한 논의를 마친 후 이 기능을 삭제하기로 했습니다.
BrotliWebpackPlugin를 사용하여 빌드 시간에 수행된 Britli를 사용한 정적 압축과 같은 다른 JS 최적화가 이미 마련되어 있으며 다른 유형의 정적 리소스에도 적용되었습니다. 처음에는 CDN에서 제공하는 압축에 의존했고 Brotli는 gzip에 비해 JS 크기를 18% 줄였습니다. 하지만 빌드 시간에 Brotli 압축으로 전환했고 그 결과 24% 의 감소를 달성할 수 있었습니다.
이미지 리소스 최적화
모바일 버전에서는 스크롤 없이 볼 수 있는 부분 대부분을 히어로 이미지가 차지합니다. 페이지의 최대 콘텐츠 렌더링 시간 (LCP)이기도 합니다.
이전에는 모든 이미지에 이미 반응형 이미지를 게재하기 위한 srcset 및 sizes 속성이 있었습니다. 또한 Thumbor를 사용해 주문형 이미지 크기를 조절하고 효율적으로 캐시하도록 CDN을 구성했습니다.
최신 휴대기기는 픽셀 밀도가 매우 높은 디스플레이를 사용합니다. 즉, 가능한 경우 브라우저는 3배 또는 4배 버전의 이미지를 렌더링합니다. 해상도가 높아질수록 사람의 눈은 차이를 인식하기가 더 어려워지지만 파일 크기는 그와 상관없이 증가합니다. 최대 이미지 해상도 한도를 설정하여 사용자 환경을 저해하지 않으면서 이미지 크기를 개선했습니다. 히어로 이미지는 최대 2x 버전을 제공하도록 제한했습니다. 이는 3x 버전보다 약 35% 작고 4x 버전보다 50% 작은 크기입니다.
이를 위해 Google은 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) | 1,124밀리초 | 1,056밀리초 | -4% |
| 누적 레이아웃 이동(CLS) | 0.0402 | 0.0093 | -77% |
또한 실제 사용자에게 미치는 영향도 확인해 보고 싶었습니다. Google은 Instana 웹사이트 모니터링을 통해 수집된 현장 데이터를 사용해 출시 전후 1개월의 기간을 파악했습니다. 모바일 사용자의 75번째 백분위수와 비교했을 때 LCP는 26%, FID는 72% 감소했습니다.
PageSpeed Insights는 지난 28일 동안의 필드 데이터 보고서를 제공합니다. 가장 많이 액세스된 콘도 페이지만 모바일 사용자에 대한 보고서를 생성하기에 충분한 데이터를 얻었습니다. 2021년 11월부터 모든 코어 웹 바이탈이 '양호' 버킷에 있습니다.
점진적인 출시 기간 동안 이탈률이 감소하는 현상이 발견되었습니다. 모든 페이지에 대한 출시가 완료될 무렵, Google 애널리틱스의 경우 이탈률은 46% 감소하고 세션당 페이지 수는 87% 증가했으며 평균 세션 시간은 49% 증가했습니다. 유료 검색의 이탈률 감소 폭이 훨씬 더 컸고, 이는 59% 감소한 수치입니다. 이는 클릭당 지불 (PPC) 광고에 대한 투자 측면에서는 긍정적인 신호입니다.
비즈니스 측정항목에 미치는 영향에 관해서는 투어 일정 예약, 부동산 임대 신청과 같은 거래의 전환율을 분석했습니다. 개선사항이 계속해서 출시되는 동안 우리 팀은 이전 버전과 새 버전 간의 변환을 비교했습니다. 같은 주에 새 버전이 적용된 페이지 그룹의 전환이 5% 증가한 반면, 다른 페이지에서는 동일한 측정항목이 약간 감소했습니다.
결론
이 프로젝트는 프레임워크가 없는 React에서 Next.js로의 장기적인 마이그레이션 작업의 첫 번째 부분입니다. 이후 콘도 페이지에서 작업했던 팀은 개발자 환경 개선에 대해 긍정적인 의견을 주었습니다. 다른 팀들은 이미 Next.js를 사용하여 새로운 웹 앱을 부트스트랩했습니다. Next.js는 유지관리 작업을 간소화하고 다양한 앱 간의 공통점을 구축해 줄 것입니다.
전반적으로 콘도 콘텐츠 허브는 사용자 수와 거래의 절댓값 측면에서 꾸준히 성장해 왔습니다. 장기적인 분석 결과, QuintoAndar의 운영 확대와 페이지 색인 생성 개선과 같은 검색엔진 최적화 이니셔티브의 확대 등 여러 요인이 여기에 기여하고 있습니다. 이 프로젝트를 진행하는 동안 페이지 실적은 긍정적인 전환 효과를 가져올 가능성이 큰 요소 중 하나라는 것을 확인했습니다.
이 우수사례에서 볼 수 있는 모든 전환 분석을 사용자 데이터를 자세히 살펴보고 만들어 주신 검색엔진 최적화팀의 제품 관리자인 페드로 카르모님께도 감사의 말씀을 전합니다.