Google 도구를 결합하여 웹사이트를 효과적으로 감사, 개선, 모니터링하세요.
게시일: 2020년 5월 28일
핵심 성능 보고서는 로드 성능, 사용자 입력에 대한 응답성, 레이아웃 안정성과 같은 기준에 따라 사용자 환경을 평가하는 측정항목입니다.
이 가이드에서는 웹사이트의 Core Web Vitals를 개선하는 워크플로를 살펴봅니다. 워크플로의 시작은 자체 필드 데이터를 수집하는지에 따라 달라집니다. 이 과정의 끝은 사용자 환경 문제를 진단하고 해결하는 데 유용한 Google 도구에 따라 달라질 수 있습니다.
코어 웹 바이탈은 필드에서 측정하는 것이 가장 좋습니다.
핵심 성능 보고서는 사용자가 웹사이트를 경험하는 방식을 측정하도록 특별히 설계되었으며 사용자 중심 측정항목입니다. Lighthouse와 같은 실험실 기반 도구는 잠재적인 성능 문제와 권장사항을 강조하는 진단 도구입니다. 실험실 기반 도구는 미리 정의된 특정 조건에서 실행되므로 사용자가 경험하는 실제 핵심 성능 보고서 측정항목을 반영하지 않을 수 있습니다.
예를 들어 Lighthouse는 시뮬레이션된 데스크톱 또는 모바일 환경에서 시뮬레이션된 제한을 사용하여 테스트를 실행하는 실험실 기반 도구입니다. 네트워크 및 기기 속도 저하 시뮬레이션은 성능 문제를 진단할 때 유용하지만, 네트워크 상태와 기기 기능의 다양한 측면 중 일부만을 반영하므로 사이트 사용자가 경험하는 상황을 반영하지 않을 수 있습니다.
Lighthouse와 같은 실험실 기반 도구도 일반적으로 완전히 새로운 방문자로 웹페이지를 '콜드 로드'합니다. 이 경우가 가장 느리게 로드되는 경우가 많지만, 실제로는 방문자가 이전에 방문했거나 사이트를 둘러볼 때 일부 애셋이 캐시되어 있을 수 있습니다. 신규 방문자와 도구는 쿠키 배너나 기타 콘텐츠가 표시되어 사이트를 다르게 경험할 수도 있습니다.
간단히 말해 실험실 기반 도구는 잠재적인 성능 문제를 나타내고 디버그 및 반복하는 데 도움이 될 수 있지만 실제 방문자가 웹사이트를 경험하는 방식을 나타내지는 않을 수 있습니다. 필드 데이터를 사용하여 실제 성능을 측정하고 Lighthouse와 같은 실험실 기반 도구를 사용하여 성능 개선 방법을 진단하세요. Lighthouse를 사용해야 하는 경우 섹션도 참고하세요.
Google은 Chrome 사용자 환경 (CrUX) 보고서를 통해 Core Web Vitals를 측정합니다. 실제 Chrome 사용자로부터 수집된 공개 데이터 세트입니다. 사이트의 Core Web Vitals를 보고하는 많은 Google 및 서드 파티 도구의 기본입니다.
하지만 CrUX에는 몇 가지 제한사항이 있습니다. 문제가 언제 발생했는지 알려줄 수 있지만 이유를 알려주기에는 데이터가 부족한 경우가 많습니다.
가능한 경우 자체 필드 데이터 수집
필드에서 웹사이트 성능을 개선하는 데 가장 적합한 데이터 세트는 사용자가 구축한 데이터 세트입니다. 이를 위해서는 웹사이트 방문자의 필드 데이터를 수집해야 합니다. 이 작업은 조직의 규모와 서드 파티 솔루션에 비용을 지불할지 아니면 직접 만들지에 따라 달라집니다.
유료 솔루션은 거의 확실히 핵심 웹 바이털 (및 기타 성능 측정항목)을 측정하며 일반적으로 결과 데이터를 자세히 살펴볼 수 있는 다양한 도구를 제공합니다. 리소스가 많은 대규모 조직에서는 이 방법을 선호할 수 있습니다.
하지만 대규모 조직에 속해 있지 않거나 서드 파티 솔루션을 구매할 수 없는 조직에 속해 있을 수도 있습니다. 이러한 경우 Google의 web-vitals 라이브러리를 사용하면 모든 웹 바이탈을 수집할 수 있습니다. 하지만 해당 데이터의 보고, 저장, 분석 방식에 대한 책임은 사용자에게 있습니다.
이미 Google 애널리틱스를 사용하고 있지만 자체 필드 데이터 수집을 시작하지 않은 경우 web-vitals 라이브러리를 사용하여 필드에서 수집된 웹 바이탈을 Google 애널리틱스로 전송하고 GA4의 BigQuery 내보내기를 사용하여 데이터를 보고할 수 있습니다.
Google 도구 이해하기
자체 필드 데이터를 수집하는지 여부와 관계없이 핵심 성능 지표를 분석하는 데 유용할 수 있는 Google 도구가 여러 개 있습니다. 워크플로를 설정하기 전에 각 도구의 대략적인 개요를 확인하면 어떤 도구가 가장 적합한지 파악하는 데 도움이 됩니다.
Chrome 사용자 환경 보고서 (CrUX)
앞서 언급한 것처럼 CrUX는 수백만 개의 웹사이트에서 실제 Google Chrome 사용자 세그먼트로부터 수집된 필드 데이터의 공개 데이터 세트입니다. 여기에는 트래픽이 충분한 웹사이트의 Core Web Vitals 측정항목과 기타 측정항목이 포함됩니다.
CrUX는 출처 수준에서 월별 BigQuery 데이터 세트로 제공되거나, URL 또는 출처에 CrUX 데이터 세트의 샘플이 충분한 경우 URL 또는 출처 수준에서 일일 API로 제공됩니다. CrUX 데이터는 프로그래매틱 액세스 및 사용자가 사용할 수 있는 시각적 도구를 위해 다양한 CrUX 도구를 통해 제공됩니다.
CrUX를 사용해야 하는 경우
자체 필드 데이터를 수집하더라도 CrUX는 여전히 유용합니다. CrUX는 Chrome 사용자의 일부를 나타내지만 웹사이트의 필드 데이터를 비교하여 CrUX 데이터와 어떻게 일치하는지 확인하는 데 유용합니다. 각각에는 장단점이 있으며, 이로 인해 차이가 발생할 수 있습니다. 웹사이트의 필드 데이터를 전혀 수집하지 않는 경우 웹사이트가 데이터 세트에 표시된다면 CrUX가 개요를 제공하는 데 특히 유용합니다.
CrUX를 직접 사용하거나 아래에 언급된 도구를 비롯한 다른 도구를 사용하여 사용할 수 있습니다. BigQuery 또는 API를 사용하여 CrUX 데이터 세트를 직접 사용하면 다른 도구에 표시되지 않는 데이터를 노출하는 데 유용합니다. 예를 들어 국가 수준 데이터는 다른 도구에서 사용할 수 없는 경우가 많으며, CrUX의 추가 측정항목을 확인하는 데도 유용합니다. 이러한 측정항목은 다른 도구에 표시되지 않는 경우가 많습니다.
CrUX를 사용하지 않아야 하는 경우
CrUX는 Chrome 사용자만 나타내며, 일부 Chrome 사용자만 나타냅니다. 전체 RUM 솔루션에는 Chrome 및 기타 브라우저에서 Web Vitals 측정항목을 지원하는 경우 더 많은 환경이 포함될 수 있습니다.
트래픽이 충분하지 않은 웹사이트는 CrUX 데이터 세트에 표시되지 않습니다. 이 경우 CrUX를 사용할 수 없으므로 필드에서 웹사이트의 실적을 파악하려면 자체 필드 데이터를 수집해야 합니다. 또는 실험실 데이터를 사용해야 하지만 앞에서 설명한 대로 대표성이 없을 수 있다는 제한사항이 있습니다.
CrUX에서 제공하는 데이터는 지난 28일 동안의 이동 평균이므로 개선사항이 CrUX 데이터 세트에 반영되는 데 상당한 시간이 걸리므로 개발 중에는 이상적인 도구가 아닙니다.
마지막으로 CrUX는 공개 데이터 세트이므로 제공할 수 있는 정보의 양과 이 데이터를 쿼리하는 방식이 제한됩니다. 자체 RUM 데이터를 캡처하면 LCP 요소와 같은 세부정보를 더 많이 수집하고 데이터를 더 많이 분류하여 문제를 파악할 수 있습니다. 로그인한 사용자가 로그아웃한 사용자보다 더 나은 또는 더 나쁜 핵심 웹 바이탈을 경험하나요? LCP가 느린 사용자에게 특정 LCP 요소가 있나요? 어떤 상호작용으로 인해 FID 및 INP 값이 높아지나요?
PageSpeed Insights (PSI)
PSI는 특정 페이지에 대한 CrUX의 필드 데이터 및 Lighthouse의 실험실을 보고하는 도구입니다. 자세한 내용은 개별 섹션을 참고하세요.
PSI를 사용해야 하는 경우
PSI는 모바일 및 데스크톱 사용자를 대상으로 페이지 수준 또는 출처 수준에서 CrUX 성능을 평가하는 데 유용합니다. 페이지 또는 사이트의 코어 웹 바이탈을 처음 개략적으로 파악하는 데 적합합니다. 또한 경쟁업체와 같은 다른 사이트의 핵심 성능 보고서 데이터를 볼 수 있습니다.
또한 PSI는 Lighthouse 데이터를 제공하며, 측정항목이 일치하는 경우 코어 웹 바이탈을 개선하는 데 유용한 권장사항을 제공합니다. 이러한 항목이 일치하지 않으면 Lighthouse 권장사항의 관련성이 떨어질 수 있습니다.
Lighthouse는 서버에서 실행되므로 DevTools에서 Lighthouse를 실행하는 것보다 더 일관된 기준을 형성할 수 있습니다.
PSI를 사용하지 않아야 하는 경우
PSI는 공개 URL에서만 사용할 수 있습니다. 공개적으로 액세스할 수 없는 개발 사이트에서는 사용할 수 없습니다.
CrUX 데이터는 사이트가 사이트 인기도 기준을 비롯한 특정 자격 요건을 충족하는 경우에만 사용할 수 있습니다. 페이지 또는 출처에 CrUX 데이터를 사용할 수 없는 경우 PSI는 Lighthouse 실험실 데이터만 표시할 수 있으므로 유용성이 떨어집니다.
마찬가지로 테스트 중인 특정 URL이 아닌 출처 수준 CrUX 데이터만 있는 경우에도 출처 수준 필드 데이터를 페이지 수준 실험실 진단과 연관시키는 유용성이 제한됩니다. 출처 수준 필드 데이터는 사이트의 실적을 요약하는 데 여전히 매우 유용한 정보이며 Lighthouse 감사가 도움이 될 수 있지만 이 경우 추가 주의가 필요합니다.
마지막으로 CrUX에서 페이지 수준 데이터를 사용할 수 있지만 Lighthouse 실험실 데이터와 다른 경우 Lighthouse의 권장사항이 제한적인 가치를 가질 수 있습니다. 이는 특히 로드 후 CLS 문제와 실험실 기반 감사가 덜 유용한 상호작용 핵심 웹 바이탈 (FID 및 INP)의 경우에 발생할 수 있습니다.
Search Console
Search Console은 핵심 웹 바이탈을 포함한 사이트의 검색 트래픽과 실적을 측정합니다. 사이트 소유권을 확인한 사이트 소유자만 사용할 수 있습니다.
Search Console의 유용한 기능은 유사한 페이지 (예: 동일한 템플릿을 사용하는 페이지)를 단일 그룹 평가로 그룹화한다는 것입니다. Search Console에는 CrUX의 필드 데이터를 기반으로 하는 Core Web Vitals 보고서도 포함되어 있습니다.
Search Console을 사용해야 하는 경우
Search Console은 개발자와 비개발자 모두가 다른 Google 도구에서는 평가할 수 없는 방식으로 검색 및 페이지 실적을 평가하는 데 적합합니다. CrUX 데이터를 표시하고 유사성을 기준으로 페이지를 그룹화하여 성능 개선이 전체 페이지 카테고리에 미치는 영향을 파악할 수 있습니다.
Search Console을 사용하지 않는 경우
유사성을 기준으로 페이지를 그룹화하는 다양한 서드 파티 도구를 사용하는 프로젝트나 웹사이트가 CrUX 데이터 세트에 표시되지 않는 경우에는 Search Console이 적합하지 않을 수 있습니다.
그룹의 예시 페이지가 나머지 그룹과 다른 특성을 갖는 경우에도 페이지 그룹화가 다소 혼란스러울 수 있습니다. 예를 들어 그룹이 전반적으로 특정 핵심 성능 보고서를 통과하지 못하지만 예시 페이지는 모두 동일한 핵심 성능 보고서를 통과하는 것처럼 보이는 경우입니다. 그룹에 캐시될 가능성이 적어 로드 속도가 느릴 수 있는 롱테일 또는 거의 방문하지 않는 페이지가 포함된 경우 이러한 문제가 발생할 수 있습니다. 롱테일에 이러한 페이지가 충분히 있으면 그룹의 전체 통과율에 영향을 미칠 수 있습니다.
등대
Lighthouse는 페이지 성능을 개선할 수 있는 구체적인 기회를 제공하는 실험실 도구입니다. Lighthouse 사용자 흐름을 사용하면 개발자가 페이지 로드 이상의 성능 테스트를 위한 상호작용 흐름을 스크립팅할 수도 있습니다.
Lighthouse-CI는 프로젝트 빌드 중에 Lighthouse를 실행하고 성능 회귀 테스트를 지원하기 위해 배포하는 관련 도구입니다. 풀 요청과 함께 Lighthouse 보고서를 표시하고 시간 경과에 따른 성능 측정항목을 추적합니다.
Lighthouse를 사용해야 하는 경우
Lighthouse는 로컬 및 스테이징 환경에서 개발하는 동안 성능 개선 기회를 찾는 데 유용합니다. Lighthouse CI는 성능 회귀 테스트가 필요하여 우수한 사용자 환경을 유지해야 하는 스테이징 및 프로덕션 환경의 빌드 및 배포 단계에서도 마찬가지로 유용합니다.
Lighthouse를 사용하지 않아야 하는 경우
Lighthouse (또는 Lighthouse CI)는 필드 데이터를 대체할 수 없습니다. Lighthouse는 사전 정의된 페이지 로드에서 잠재적인 문제와 권장사항을 나열하는 진단 도구입니다. 표시되는 추천이 사용자에게 표시되는 성능과 항상 일치하지 않을 수 있습니다.
Lighthouse는 PageSpeed Insights와 같은 도구를 통해 프로덕션 사이트를 진단하는 데 사용할 수 있지만, 프로덕션에 도달하기 전에 성능 문제를 해결하기 위해 개발 및 지속적 통합 환경에서 사용하는 것이 이상적입니다.
Lighthouse에서 제공하는 감사는 Chrome DevTools의 성능 패널에 있는 '통계'를 통해서도 확인할 수 있으며, 이를 통해 페이지 성능을 더 심층적으로 분석할 수 있습니다.
Chrome DevTools의 성능 패널
Chrome DevTools는 성능 패널을 비롯한 브라우저 내 개발 도구 모음입니다. 성능 패널은 두 가지 '모드'로 구성된 실험실 도구입니다.
'성능' 패널을 처음 열면 '실시간 측정항목' 화면에 현재 Core Web Vitals 측정항목이 표시되며 CrUX에서 필드 데이터를 가져올 수 있습니다. 페이지와 상호작용하면서 성능 문제를 파악하려고 할 때, 특히 CLS 및 INP 측정항목에서 볼 수 있는 로드 후 문제에 대해 성능을 '실시간'으로 볼 수 있어 유용합니다.
두 번째로, 성능 패널을 사용하면 개발자가 페이지 로드 또는 기록된 기간 동안 모든 페이지 활동의 프로필 (또는 트레이스)을 캡처할 수 있습니다. 이 뷰는 네트워크, 렌더링, 페인팅, 스크립팅 활동과 같은 측정기준과 페이지의 Core Web Vitals 전반에 걸쳐 관찰되는 모든 항목에 대한 심층적인 통계를 제공합니다. 또한 Lighthouse에서 제공하는 것과 유사한 통계도 포함됩니다.
성능 패널을 사용해야 하는 경우
개발자는 성능 패널을 사용하여 특정 페이지 성능에 대한 심층적인 통계를 얻어야 합니다.
실시간 측정항목 보기를 사용하면 페이지의 현재 성능 특성을 빠르게 파악할 수 있으며, 페이지와 상호작용할 때 잠재적인 문제를 발견할 수도 있습니다.
트레이스 뷰는 INP에 영향을 미치는 응답성 문제를 디버깅하는 데 특히 유용합니다. 응답이 좋지 않은 상호작용이 식별되고 반복 가능해지면 성능 패널에서 브라우저에서 발생하는 상황에 관한 풍부한 데이터를 제공하여 기본 스레드 차단부터 JavaScript 호출 스택, 렌더링 작업에 이르기까지 문제를 이해하는 데 도움을 줄 수 있습니다.
성능 패널을 사용하지 않아야 하는 경우
성능 패널은 주로 실험실 데이터를 제공하는 개발자 도구입니다(CrUX의 일부 필드 컨텍스트 포함). 필드 데이터를 대체하지는 않습니다.
트레이스 뷰에는 많은 디버깅 정보가 포함되어 있지만, 이로 인해 초보 개발자나 개발자 외 역할의 사용자가 이해하기 어려울 수 있습니다. 하지만 패널이 열리는 실시간 측정항목 뷰는 전체 세부정보가 필요하지 않은 사용자를 위해 더 사용하기 쉬운 인터페이스를 제공하여 이 문제를 해결합니다.
웹사이트의 코어 웹 바이탈을 건강하게 유지하기 위한 3단계 워크플로
사용자 환경을 개선하기 위해 노력할 때는 프로세스를 지속적인 사이클로 생각하는 것이 좋습니다. Core Web Vitals 및 기타 성능 측정항목을 개선하는 한 가지 방법은 다음과 같습니다.
- 웹사이트 상태를 평가하고 고충사항을 파악합니다.
- 디버그 및 최적화
- 지속적 통합 도구로 모니터링하여 회귀를 포착하고 방지합니다.
1단계: 웹사이트 상태 평가 및 개선 기회 파악
필드 데이터로 시작하여 웹사이트 상태를 평가하는 것이 좋습니다.
- PageSpeed Insights를 사용하여 오리진의 전반적인 핵심 성능 보고서 경험 측정항목과 개별 URL에 관한 구체적인 정보를 확인합니다.
- Search Console은 사이트에서 페이지 그룹화 기능이 잘 작동하는 개선이 필요한 페이지를 식별하는 데 유용합니다.
- RUM 데이터가 있는 경우 문제가 있는 특정 페이지 또는 트래픽 세그먼트를 식별하는 데 가장 적합한 옵션인 경우가 많습니다.
직접 수집한 필드 데이터를 분석하든 CrUX 데이터를 분석하든 이 첫 번째 단계는 매우 중요합니다. 필드 데이터를 수집하지 않는 경우 CrUX 데이터만으로도 충분히 안내를 받을 수 있습니다. 단, 웹사이트가 데이터 세트에 표시되어야 합니다.
PageSpeed Insights로 사이트 성능 분석하기
PageSpeed Insights에는 75번째 백분위수의 사용자 환경 데이터 중 지난 28일간의 CrUX 데이터가 표시됩니다. 즉, 사용자 환경의 75% 가 특정 측정항목에 설정된 기준점을 충족하면 환경이 '양호'한 것으로 간주됩니다.
실적을 확인할 특정 페이지가 있다면 해당 페이지를 사용합니다. 최적화를 처음 시작할 때 사이트의 전체적인 모습을 파악하려면 홈페이지부터 시작하는 것이 좋습니다. 홈페이지는 일반적으로 많은 사이트에서 가장 인기 있는 페이지 중 하나이기 때문입니다.
처음에는 PSI의 실제 사용자의 경험 섹션에 집중하세요. 입력한 URL과 전체 출처에 대한 모바일 및 데스크톱 데이터가 최대 4개 표시됩니다. 이러한 차이점을 비교해 보세요. 모바일은 리소스가 더 제한적이고 네트워크 조건이 불안정할 수 있는 기기에서 작동하므로 일반적으로 데스크톱보다 성능이 떨어집니다. URL과 출처 데이터가 크게 다른 경우 그 이유를 파악해 보세요. 홈페이지는 방문하는 첫 번째 페이지 (즉, 방문 페이지)인 경우가 많으므로 출처보다 느릴 수 있습니다. 출처 사용자는 초기화되지 않은 브라우저 캐시의 영향을 완전히 받습니다. 공유 애셋이 캐시되어 집계된 출처 수준 데이터가 줄어들기 때문에 후속 페이지가 더 빠르게 로드될 수 있습니다.
PSI에는 세 가지 코어 웹 바이탈 (LCP, CLS, INP)과 진단 TTFB 및 FCP 측정항목도 표시됩니다. Core Web Vitals 중 실패한 항목이 있는지, 있다면 얼마나 실패했는지 이를 통해 어디에 노력을 집중해야 하는지 알 수 있습니다.
이러한 숫자 간의 관계(특히 LCP)를 이해합니다. 이 예와 같이 LCP가 느린 경우 해당 측정항목의 마일스톤인 TTFB와 FCP를 확인하세요. 이 예시에서는 TTFB가 1.8초이므로 LCP 권장 기준인 2.5초를 충족하기가 매우 어렵습니다. 이는 백엔드 (서버 문제 또는 CDN 부족)가 느리거나, 네트워크가 느리거나, 첫 번째 HTML 바이트를 지연시키는 리디렉션이 있음을 나타냅니다. 자세한 내용은 TTFB 최적화 가이드를 참고하세요. FCP에는 1초가 더 걸리며 이는 네트워크가 느리다는 것을 나타낼 수 있습니다. 이 예에서는 LCP가 FCP 후 오래 지나지 않아 LCP 리소스가 페이지 자체 로드 후 잘 최적화되었음을 알 수 있습니다. 이제 CrUX는 리소스 유형 및 하위 파트에서 더 많은 진단 정보를 표시하므로 LCP 문제를 진단하는 데도 도움이 됩니다.
CLS의 경우 CrUX CLS와 Lighthouse CLS 점수를 확인하여 로드 CLS 문제인지 (Lighthouse에서 포착하고 권장함) 또는 Lighthouse에서 포착하지 않는 로드 후 CLS 문제인지 확인합니다. 자세한 내용은 CLS 최적화 가이드를 참고하세요.
반응성을 확인하려면 INP 점수를 살펴보세요. Lighthouse의 TBT 감사에서 초기 페이지 로드 중에 많은 JavaScript 처리가 발생하는지 확인합니다. 이는 INP에 영향을 미칠 수 있습니다. INP는 개선하기 까다로운 측정항목이므로 자세한 내용은 INP 최적화 가이드를 참고하세요.
Search Console에서 실적이 저조한 페이지 식별
PSI는 테스트하려는 특정 URL이나 사이트 전체가 있는 경우에 유용하지만, Search Console을 사용하면 특정 유형의 페이지에 노력을 집중할 수 있습니다. 특히 여러 페이지가 공통 테마나 기술을 공유하고 Search Console에서 이를 성공적으로 식별할 수 있는 경우에 유용합니다.
Search Console의 핵심 성능 보고서는 웹사이트 실적의 전체적인 그림을 보여주지만, 주의가 필요한 특정 페이지를 자세히 살펴볼 수도 있습니다. Search Console을 사용하면 다음 작업도 가능합니다.
- 개선이 필요한 개별 페이지 그룹과 우수한 사용자 환경을 제공하는 페이지 그룹을 파악합니다.
- 상태, 측정항목, 유사한 웹페이지 그룹 (예: 전자상거래 웹사이트의 제품 세부정보 페이지)으로 그룹화된 URL별 실적에 관한 세부 데이터를 확인합니다.
- 모바일과 데스크톱 모두에서 각 사용자 환경 품질 카테고리에 URL을 분류하는 상세 보고서를 확인하세요.
살펴볼 특정 페이지가 있으면 이전에 설명한 대로 PSI를 사용하여 해당 페이지의 문제에 대해 자세히 파악할 수 있습니다.
2단계: 디버그 및 최적화
1단계에서 성능 개선이 필요한 페이지와 개선할 코어 웹 바이탈 측정항목을 파악해야 합니다. Google 도구를 사용하여 근본 원인을 파악하고 문제를 식별하는 데 필요한 추가 정보를 얻을 수 있습니다.
- Lighthouse 감사를 통해 페이지에 대한 개략적인 안내를 확인합니다.
- 성능 패널 실시간 측정항목 보기를 사용하여 Core Web Vitals를 실시간으로 분석합니다.
- 성능 패널 추적을 사용하여 성능 문제를 디버그하고 코드 변경사항을 테스트합니다.
자세한 내용은 다음 가이드를 참고하세요.
Lighthouse로 기회 파악하기
PageSpeed Insights는 Lighthouse를 실행합니다. Chrome DevTools에서 Lighthouse를 실행할 수도 있습니다. 이는 로컬에서 수정사항을 검증하는 데 유용하지만, 성능 패널 (다음에 설명)은 로컬에서 성능 문제를 파악하고 수정하는 데 더 포괄적인 도구입니다.
핵심은 Lighthouse 감사가 해결하려는 문제 (예: 느린 LCP 또는 CLS 문제)를 복제하는지 확인하는 것입니다. 기본적으로 Lighthouse는 페이지 로드 중의 사용자 환경만 평가합니다. 실험실 도구이므로 TBT를 위해 INP도 제외합니다.
Lighthouse 측정항목에서 해결하려는 문제와 유사한 문제가 표시되면 감사에 있는 풍부한 정보를 통해 문제를 식별하고 해결 방법을 제안할 수 있습니다.
관심 있는 Core Web Vitals만 표시하도록 감사를 필터링하여 특정 측정항목과 관련된 문제 해결에 집중할 수 있습니다.
INP의 경우 TBT 감사로 이러한 측정항목에 영향을 줄 수 있는 문제를 파악하세요. 하지만 상호작용이 없으면 Lighthouse에서 진단할 수 있는 범위가 제한됩니다.
Chrome DevTools 실시간 측정항목 화면으로 실시간 분석
성능 패널의 Chrome DevTools 실시간 측정항목 화면에는 페이지 로드 중 및 페이지 탐색 중에 핵심 성능 보고서가 실시간으로 표시됩니다. 따라서 로드 후 발생하는 레이아웃 변경뿐만 아니라 INP도 캡처할 수 있습니다. 각 측정항목에 대한 자세한 정보를 확인할 수도 있습니다.
이 뷰는 성능 문제를 식별하는 데 도움이 되는 유용한 정보를 많이 제공하며 CrUX의 필드 정보도 가져올 수 있습니다. 자세한 내용은 트레이스를 통해 드릴다운하면 됩니다.
성능 패널로 드릴다운
Chrome DevTools의 성능 패널을 사용하면 기록된 기간 동안 모든 페이지 동작의 프로필 (또는 트레이스)을 기록할 수 있습니다.
성능 통계는 통계 측면 패널에서 확인할 수 있습니다. 또한 Core Web Vitals 측정항목과 해당 측정항목의 필드 값(있는 경우)도 표시됩니다.
레이아웃 변경 트랙은 레이아웃 변경을 강조 표시하며, 이를 클릭하면 CLS 디버깅을 위해 변경된 요소에 관한 세부정보가 표시됩니다.
LCP와 같은 주요 타이밍은 트레이스 하단에 있는 타이밍에 표시됩니다. 자세한 내용을 보려면 다음을 클릭하세요.
INP 문제로 이어질 수 있는 긴 작업도 프레임 차트에서 빨간색 삼각형으로 강조 표시됩니다.
이러한 기능과 성능 패널의 다른 부분에 있는 정보를 통해 수정사항이 페이지의 Core Web Vitals에 영향을 미치는지 확인할 수 있습니다.
필드에서 코어 웹 바이탈 디버깅
실험실 도구는 사용자에게 영향을 미치는 모든 핵심 성능 보고서 문제의 원인을 항상 파악할 수 있는 것은 아닙니다. 실험실 데이터에서는 고려할 수 없는 요소를 고려하므로 자체 필드 데이터를 수집하는 것이 매우 중요합니다.
자세한 내용은 필드에서 성능 디버그를 참고하세요.
3단계: 변경사항 모니터링
문제를 해결한 후에는 문제가 원하는 효과를 내는지, 새로운 문제가 핵심 웹 바이탈을 방해하지 않는지 확인해야 합니다. 이를 위해서는 개발자 워크플로의 일부로 성능 문제를 모니터링하여 성능 문제가 프로덕션에 출시되지 않도록 하고, 필드 데이터를 정기적으로 모니터링하여 이를 확인해야 합니다.
지속적 통합 (CI) 환경에서 성능 요청 모니터링
Lighthouse-CI를 사용하면 코드 커밋에 대해 Lighthouse 감사를 자동으로 실행하여 성능 회귀가 코드에 입력되는 것을 방지할 수 있습니다. 이를 통해 성능 타이밍 (변동될 수 있음)을 확인하거나, 성능 감사의 경우 코드에서 잘못된 관행을 방지하는 린팅 도구로 확인할 수 있습니다.
필드 데이터로 웹사이트 상태 추세 보기
프로덕션에 도달하기 전에 모든 성능 문제를 포착하고 해결하는 것이 좋지만 RUM을 사용하여 필드 데이터를 모니터링하는 것은 누락된 문제를 찾는 데 필수적입니다. 이러한 문제를 해결하는 데 도움이 되는 상업용 RUM 제품이 많이 있습니다. web-vitals JavaScript 라이브러리는 웹사이트의 필드 데이터 수집을 자동화하고, 선택적으로 이 데이터를 사용하여 맞춤 대시보드 및 알림 시스템을 지원할 수 있습니다.
RUM 솔루션이 없는 사이트의 경우 다양한 CrUX 도구를 필드 데이터의 기본 추세 분석으로 사용할 수 있습니다.
결론
빠르고 즐거운 사용자 환경을 보장하려면 성능 우선 사고방식을 갖고 진행 상황을 보장하는 워크플로를 채택해야 합니다. 감사, 디버그, 모니터링을 위한 적절한 도구와 프로세스를 사용하면 우수한 사용자 환경을 구축하고 우수한 핵심 성능 보고서에 정의된 기준점을 유지할 수 있습니다.