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