GoDaddy에서 수백만 사이트의 웹사이트 성능을 개선하기 위해 구현한 변경사항에 관한 케이스 스터디로, 이를 통해 우수한 PageSpeed Insights 및 Core Web Vitals 점수를 달성할 수 있었습니다.
GoDaddy는 전 세계 기업가를 위한 세계 최대 규모의 서비스 플랫폼입니다. Google은 전 세계 2,000만 명 이상의 고객과 기업가가 온라인에서 성장하는 데 필요한 모든 지원과 도구를 제공하여 전 세계 커뮤니티를 강화하는 사명을 다하고 있습니다.
GoDaddy는 2019년 비즈니스 소유자가 목표를 달성하는 데 도움이 되는 간편한 도구와 서비스를 제공하겠다는 목표로 Websites + Marketing을 출시했습니다. Websites + Marketing은 웹사이트 제작을 마케팅 및 전자상거래 도구와 통합하고 이를 최고의 안내와 함께 제공하여 고객이 새로운 사업을 성공적으로 운영할 수 있도록 지원합니다.
웹사이트 + 마케팅이 출시된 이후 성능은 제품의 중요한 부분이었으며 적극적으로 모니터링하고 개선해 왔습니다. 이 도움말에서는 실험실 성능 테스트를 사용한 GoDaddy의 여정을 살펴보고 핵심 웹 성능을 사용하여 실제 데이터를 사용하게 된 과정과 고객 사이트의 통과율을 매우 높이기 위해 제품에 적용된 일련의 개선사항을 살펴봅니다.
Lighthouse로 실적 추적하기
Google은 실적 추적에 Lighthouse 데이터를 사용해 왔습니다. 웹사이트가 플랫폼에 게시될 때마다 Google Lighthouse를 서비스 https://github.com/godaddy/lighthouse4u로 제공하는 'Lighthouse4u'라는 내부 도구를 사용하여 성능을 측정합니다. 이를 통해 실험실 환경에서 사이트가 일반적으로 어떻게 작동하는지 알 수 있었습니다.
Google 플랫폼에서 호스팅하는 수백만 개의 사이트에는 다양한 기능과 콘텐츠가 있으므로 테스트 중인 각 사이트에 관한 메타데이터 (예: 사용된 템플릿, 렌더링된 위젯 유형 등)와 실적 데이터를 결합하는 것이 중요했습니다. 이를 통해 실적이 낮은 웹사이트 기능에 대한 결론을 도출하고 개선이 필요한 부분을 파악할 수 있었습니다.
예를 들어 '팝업 모달'이 페이지 속도에 부정적인 영향을 미치고 있음을 확인할 수 있었습니다. 이 기능이 있는 사이트의 실적은 이 기능이 없는 사이트보다 12포인트 낮았습니다. JavaScript 로드를 지연하도록 코드를 업데이트한 후 Lighthouse 점수가 2점 상승했습니다. 이 학습 내용은 페이지 로드 직후에 렌더링되는 '쿠키 배너'와 같은 다른 기능에도 적용할 수 있었습니다.
기능을 기반으로 문제가 있는 사이트를 살펴보는 것과 함께 JavaScript 번들을 분석한 결과, 크기의 상당 부분이 외부 종속 항목 (immutable.js 및 draft.js)에서 비롯된 것으로 확인되었습니다. 소비자를 재구성하여 필요에 따라 종속 항목을 지연 로드하도록 하여 번들 크기를 줄였습니다. 그 결과 일반적인 JavaScript 번들 크기가 50% 이상 감소하여 200KB 이상에서 90KB (축소됨)로 줄었습니다. 번들 크기가 작아지면서 브라우저가 초기 사이트 로드 수명 주기에서 더 일찍 외부 애셋을 로드하고 중요한 스크립트를 실행할 수 있게 되어 최대 콘텐츠 렌더링 시간 (LCP) 및 최초 입력 반응 시간 (FID)이 개선되었습니다.
Google의 지속적인 노력 덕분에 평균 고객 사이트 Lighthouse 점수가 2020년 11월의 약 40점에서 2021년 5월의 70점 이상으로 상승했습니다. 하지만 모든 시도가 성공한 것은 아니며, 로컬 테스트 환경에서 테스트한 결과와 현장에서 얻은 결과가 항상 일치하지 않는 경우도 있었습니다. 실험실 결과는 매우 유용했지만 이제는 현장에서 관찰된 실제 사용자 환경에 집중할 때가 되었습니다.
Core Web Vitals로 실제 사용자 데이터 추적
고객 사이트에 web-vitals 라이브러리를 추가한 후 하드웨어, 네트워크 속도, 사용자 상호작용 (예: 스크롤 또는 클릭)이 Lighthouse를 사용하는 실험실 환경과 같이 일관된 기준점에 있지 않은 실제 방문자의 실제 기기에서 데이터를 측정할 수 있었습니다. 이제 웹사이트 방문자가 겪고 있는 상황을 대표하는 데이터를 확보하게 되었으므로 올바른 방향으로 한 걸음 크게 나아간 셈입니다.
가장 취약한 링크인 누적 레이아웃 변경 (CLS)에 집중
새 데이터를 분석한 결과 웹사이트 속도를 개선하기 위해 취해야 할 조치에 대한 새로운 관점을 얻었습니다. Lighthouse 점수를 개선하기 위한 작업으로 인해 75번째 백분위 LCP는 860ms, 동일한 기준점의 FID는 10ms 미만이었습니다. 따라서 고객 사이트에서 이러한 측정항목의 통과율이 각각 78% 와 98%로 높았습니다. 하지만 누적 레이아웃 변경 (CLS) 숫자는 Lighthouse에서 익숙했던 것과 꽤 다르게 보입니다. 75번째 백분위수의 CLS는 0.17로 '통과' 기준점인 0.1을 초과했으며, 따라서 모든 사이트의 통과율은 47% 에 불과했습니다.
이 측정항목으로 인해 전체 합격률이 40%까지 떨어졌으므로 2021년 8월 말까지 이 수치를 60% 이상으로 끌어올리겠다는 야심찬 목표를 세웠습니다. 이를 위해서는 CLS에 집중해야 합니다.
실제로는 사용자가 페이지와 상호작용하고 '최상단' 콘텐츠를 지나 스크롤합니다. 이는 코어 웹 바이탈이 더 잘 포착하는 부분입니다. 사이트가 처음 로드되는 동안 사용자가 사이트와 상호작용하는 방식이 다양하기 때문에 CLS는 실험실 및 현장 데이터와 다릅니다.
모든 Core Web Vitals 통과하기
실적을 개선하려면 시행착오가 필요하며, 모든 시도가 예상대로 작동하지는 않습니다. 하지만 목표를 달성하는 데 도움이 된 몇 가지 개선사항이 있습니다.
이미지를 로드하기 위한 공간을 예약하면 이미지 아래의 콘텐츠가 이동하지 않아 CLS 점수가 크게 개선되었습니다. 이를 지원하는 브라우저에서 이 문제를 해결하기 위해 CSS aspect-ratio 속성을 사용했습니다. 이미지가 없는 경우 캐시된 투명한 자리표시자 이미지를 로드했습니다. 이 이미지는 크기가 몇 바이트 밖에 되지 않아 거의 즉시 로드되었습니다.
이 일반적인 이미지 동작을 통해 표시 영역 너비와 이미지 가로세로 비율을 기반으로 서버 측 렌더링 중에 최종 이미지 높이를 미리 계산할 수 있었습니다. 이렇게 하면 최종 이미지를 위해 적절하게 예약된 세로 공간이 있는 HTML 마크업이 생성됩니다. 이미지가 모바일 뷰포트의 전체 범위로 렌더링되므로 특히 휴대기기에서 개선사항이 눈에 띄었습니다.
고객 사이트의 특정 구성요소에는 동적 콘텐츠 (예: 외부 고객 리뷰 목록)가 있으며 서버 측 렌더링의 성능 이점을 활용하기 위해 순수 CSS로 변환할 수 없습니다. 콘텐츠 (즉, 높이)가 다르므로 레이아웃 전환을 개선하기 어려운 영역입니다. 이 경우 각 특정 구성요소의 평균 높이를 관찰하여 사전 결정된 min-height가 적용된 컨테이너로 구성요소를 래핑했습니다. 내부 동적 구성요소의 렌더링이 완료되면 min-height가 삭제됩니다. 완벽하지는 않지만 이 솔루션을 통해 레이아웃 전환을 크게 줄일 수 있었습니다.
CLS 개선에 중점을 두면서 LCP 개선도 계속 진행했습니다. 많은 웹사이트에서 이미지가 LCP에 가장 큰 영향을 미치는 요소이므로 개선이 필요한 부분이었습니다. IntersectionObserver를 사용하여 이미지 지연 로드를 개선했지만 이미지 크기가 각 브레이크포인트 (모바일, 태블릿, 데스크톱, 대형 데스크톱)에 가장 최적화된 방식으로 설정되지 않았음을 확인했습니다. 따라서 이미지 생성 코드를 업데이트하여 브레이크포인트별로 이미지를 클램프하고 크기 조절한 다음 픽셀 밀도를 기반으로 해상도를 다시 조절했습니다. 예를 들어 특정 대형 이미지의 크기가 192KB에서 102KB로 줄었습니다.
네트워크 연결이 좋지 않은 기기에서 웹사이트를 빠르게 렌더링하기 위해 연결 속도에 따라 이미지 품질을 동적으로 축소하는 코드를 추가했습니다. 이는 navigator.connection에서 반환된 downlink 속성을 사용하여 실행할 수 있습니다. Google은 이러한 네트워크 상태에 따라 애셋 API를 통해 이미지 품질을 낮추기 위해 URL 기반 쿼리 매개변수를 적용합니다.
고객 사이트의 여러 섹션이 동적으로 로드됩니다. 게시될 때 특정 사이트에서 렌더링될 섹션을 알고 있으므로 rel=preconnect 리소스 힌트를 사용하여 연결과 필요한 핸드셰이크를 미리 초기화했습니다. 또한 리소스 힌트를 사용하여 글꼴 및 기타 중요한 리소스를 빠르게 로드합니다.
고객은 사이트를 빌드할 때 다양한 기능을 허용하는 인라인 스크립트가 포함될 수 있는 다양한 섹션을 추가합니다. 이러한 스크립트를 HTML 페이지 전체에 인라인으로 포함하는 것이 항상 성능에 최적화되는 것은 아닙니다. 브라우저가 스크립트 콘텐츠를 비동기식으로 로드하고 파싱할 수 있도록 이러한 스크립트를 외부화하기로 결정했습니다. 새로 외부화된 스크립트는 페이지 간에 공유할 수도 있습니다. 이를 통해 브라우저 및 CDN 캐싱의 형태로 성능을 추가로 향상할 수 있었습니다. 브라우저가 더 빠르게 파싱하고 실행할 수 있도록 중요한 스크립트를 인라인으로 유지했습니다.
결과
CLS에 집중한 결과 Core Web Vitals 통과율이 약 40% 에서 거의 70%로 75%나 개선되었습니다.
사용자가 사이트를 업데이트하고 다시 게시하기 위해 Google 플랫폼을 다시 방문할 때마다 최신 성능 개선사항이 적용되므로 아래 차트와 같이 'Core Web Vitals 통과' 사이트 수가 꾸준히 증가하고 있습니다.
결론
실적 개선이 필요한 영역을 찾고 진행 상황을 성공적으로 추적하는 것은 측정에 사용되는 도구에 따라 크게 달라집니다. Lighthouse는 '실험실 설정'에서 페이지 상단의 실적을 측정하는 데 유용했지만, 페이지 스크롤과 같은 사용자 상호작용에서만 발생하는 실적 문제를 정확하게 포착하지는 못했습니다.
메타데이터를 사용하여 실제 Core Web Vitals를 추적함으로써 개선사항의 영향을 시각화, 타겟팅, 측정할 수 있었습니다. Core Web Vitals 점수를 개선하기 위한 여정을 통해 팀은 코드베이스 전반에서 발견된 비효율적인 패턴을 파악하고 대체할 수 있었습니다. 기대되는 변경사항이 예상만큼 영향을 미치지 않는 경우도 있었고 그 반대의 경우도 있었습니다. 세상은 깨끗한 곳이 아니므로 계속 시도해야 합니다.