웹 성능을 효과적으로 모니터링하기 — Smashing Magazine

웹사이트 성능을 측정하는 유일한 방법은 없습니다. 즉, Google이 순위 요소로 사용하는 핵심 웹 바이탈 측정항목은 방문자 경험의 다양한 측면을 다루므로 훌륭한 출발점이 됩니다.

• 콘텐츠가 포함된 최대 페인트(LCP): 초기 페이지 로드 시간을 측정합니다.
• CLS(누적 레이아웃 변경): 렌더링 후 콘텐츠가 안정적인지 측정합니다.
• 다음 페인트(INP)와의 상호작용: 페이지가 사용자 입력에 얼마나 빨리 응답하는지 측정합니다.

페이지 무게나 서버 응답 시간과 같은 기술적 측면을 추적하는 데 사용할 수 있는 다른 웹 성능 지표도 많이 있습니다. 이는 최종 사용자에게 직접적으로 중요하지 않은 경우가 많지만 페이지 속도를 늦추는 원인에 대한 통찰력을 제공합니다.

또한 User Timing API를 사용하여 특히 웹사이트에서 중요한 페이지 로드 마일스톤을 추적할 수도 있습니다.

합성 및 실제 사용자 데이터

웹 성능 데이터에는 두 가지 유형이 있습니다.

• 합성 테스트 통제된 테스트 환경에서 실행됩니다.
• 실제 사용자 데이터 실제 웹사이트 방문자로부터 수집됩니다.

종합 모니터링은 페이지 속도 문제를 식별하는 데 도움이 되는 매우 상세한 보고서를 제공할 수 있습니다. 특정 네트워크 속도, 장치 크기 또는 테스트 위치를 선택하여 데이터 수집 방법을 정확하게 구성할 수 있습니다.

무료 DebugBear 웹 사이트 속도 테스트를 사용하여 웹 사이트를 확인하여 종합 모니터링에 대한 실제적인 느낌을 얻으십시오.

즉, 합성 테스트 설정이 실제 방문자의 일반적인 설정과 일치하지 않을 수 있으며 사람들이 웹 사이트와 상호 작용할 수 있는 모든 가능한 방식을 스크립트로 작성할 수는 없습니다.

그렇기 때문에 실제 사용자 모니터링(RUM)도 필요합니다. 하나의 경험을 보는 대신 다양한 로드 시간과 특정 방문자 세그먼트가 어떻게 영향을 받는지 확인할 수 있습니다. 특정 페이지 조회수를 검토하여 특정 방문자의 실적 저하 원인을 파악할 수 있습니다.

동시에 실제 사용자 데이터는 웹 API 제한 및 성능 문제로 인해 합성 테스트 보고서만큼 상세하지 않습니다.

DebugBear는 합성 모니터링과 실제 사용자 모니터링을 모두 제공합니다.

• 합성 테스트를 설정하려면 웹사이트 URL만 입력하면 됩니다.
• 실제 사용자 지표를 수집하려면 웹사이트에 분석 스니펫을 설치해야 합니다.

빠른 웹사이트를 위한 3단계

데이터를 수집하면 웹 성능 최적화의 수명주기 전반에 걸쳐 도움이 됩니다. 다음 3단계 프로세스를 따를 수 있습니다.

1. 식별하다: 웹사이트 전체에서 데이터를 수집하고 느린 방문자 경험을 식별합니다.
2. 진단하다: 최적화를 찾기 위해 기술적 분석에 대해 자세히 알아보세요.
3. 감시 장치: 최적화가 작동하는지 확인하고 성능 회귀에 대한 알림을 받습니다.

각 단계를 자세히 살펴보겠습니다.

1단계: 느린 방문자 경험 식별

처음에 웹사이트 성능 문제를 조사하게 된 이유는 무엇입니까? 고객 보고서 때문이든 Google Search Console의 핵심 웹 바이탈 섹션의 낮은 점수 때문이든 이미 몇 가지 구체적인 문제를 염두에 두고 있을 것입니다.

실제 사용자 데이터는 느린 페이지를 확인하는 가장 좋은 장소입니다. 이는 사이트의 기술적 문제로 인해 실제로 사용자 경험이 저하되는지 여부를 알려줍니다. 전체 웹사이트에서 수집하는 것은 쉽습니다(단, 각 URL에 대해 합성 테스트를 설정해야 합니다). 또한 성과 지표와 함께 조회수를 얻을 수도 있습니다. 한 달에 두 명의 방문자가 방문하는 적당히 느린 페이지는 하루에 수천 명의 방문자가 방문하는 적당히 빠른 페이지만큼 중요하지 않습니다.

DebugBear RUM 제품의 Web Vitals 대시보드는 사이트의 성능 상태를 확인하고 가장 많이 방문한 페이지와 많은 방문자가 경험이 좋지 않은 URL을 표시합니다.

또한 웹사이트 검사를 실행하여 사이트맵에서 URL 목록을 가져온 다음 Google Chrome 사용자 경험 보고서(CrUX)의 실제 사용자 데이터와 비교하여 각 페이지를 확인할 수도 있습니다. 그러나 이는 CrUX 데이터세트에 포함될 최소 트래픽 임계값을 충족하는 페이지에서만 작동합니다.

스캔 결과는 추가 조사가 필요할 수 있는 웹 바이탈 점수가 낮은 페이지를 강조 표시합니다.

실제 사용자 데이터를 사용할 수 없는 경우 Google의 Lighthouse 도구를 기반으로 하는 Unlighthouse라는 검색 도구가 있습니다. 각 페이지에 대해 종합 테스트를 실행하므로 결과를 필터링하여 최적화가 필요한 페이지를 식별할 수 있습니다.

2단계: 웹 성능 문제 진단

웹사이트에서 느린 페이지를 식별한 후에는 페이지에서 지연을 유발하는 실제 상황이 무엇인지 살펴봐야 합니다.

디버깅 페이지 로드 시간

콘텐츠가 포함된 최대 페인트(LCP)와 같은 페이지 로드 시간 측정항목에 문제가 있는 경우 합성 테스트 결과를 통해 자세한 분석을 제공할 수 있습니다. 페이지 속도 실험을 실행하여 특정 최적화의 영향을 시험하고 측정할 수도 있습니다.

로드 시간은 다양한 사용자 및 장치별 요인에 따라 달라지므로 페이지 속도를 디버깅할 때 실제 사용자 데이터가 여전히 중요할 수 있습니다. 예를 들어 사용자 장치의 크기에 따라 LCP를 담당하는 페이지 요소가 달라질 수 있습니다. RUM 데이터는 모든 방문자에 대해 CSS 선택기 및 이미지 URL과 같은 영향을 미칠 수 있는 요소에 대한 분석을 제공하여 정확히 수정해야 할 사항을 파악하는 데 도움을 줍니다.

느린 상호작용 디버깅

RUM 데이터는 일반적으로 INP(Interaction to Next Paint) 측정항목과 관련된 문제를 올바르게 진단하는 데에도 필요합니다. 특히 실제 사용자 데이터는 느린 상호 작용의 원인에 대한 통찰력을 제공할 수 있으며, 이는 다음과 같은 질문에 답하는 데 도움이 됩니다.

• 어떤 페이지 요소가 책임이 있나요?
• 이미 활성화된 백그라운드 작업을 처리하는 데 시간이 소요됩니까, 아니면 상호 작용 자체를 처리하는 데 소요됩니까?
• 전체 CPU 처리 시간에 가장 많은 영향을 미치는 스크립트는 무엇입니까?

이 데이터를 상위 수준에서 확인하여 추세를 식별할 수 있을 뿐만 아니라 특정 페이지 조회수를 검토하여 특정 방문자 경험에 영향을 미친 요소를 확인할 수 있습니다.

3단계: 성능 모니터링 및 회귀에 대응

웹사이트 성능을 지속적으로 모니터링하면 변경 후 성능이 향상되는지 추적하고 점수가 낮아지면 알림을 받을 수 있습니다.

성능 회귀에 대응하는 방법은 실험실 기반 합성 테스트를 보는지 실제 사용자 분석을 보는지에 따라 달라집니다.

합성 데이터

합성 테스트에 대한 테스트 설정은 실행 간에 표준화됩니다. 브라우저 업그레이드와 같은 인프라 변경으로 인해 때때로 변경이 발생하지만 성능은 일반적으로 웹 사이트에서 로드한 리소스와 웹 사이트에서 실행되는 코드에 따라 결정됩니다.

측정 항목이 변경되면 DebugBear를 사용하면 두 테스트 결과 간의 전후 비교를 볼 수 있습니다. 예를 들어 다음 스크린샷은 FCP(First Contentful Paint) 지표의 회귀를 표시합니다. 비교 결과, 페이지에 새 이미지가 추가되어 다른 페이지 리소스와 대역폭을 놓고 경쟁하는 것으로 나타났습니다.

보고서를 보면 이전에 로드하는 데 255밀리초가 걸렸던 CSS 파일이 이제는 915밀리초가 걸리는 것이 분명합니다. 페이지 콘텐츠를 렌더링하려면 스타일시트가 필요하므로 이제 페이지가 더 느리게 로드되므로 최적화가 필요한 항목에 대한 더 나은 통찰력을 얻을 수 있습니다.

실제 사용자 데이터

실제 사용자 측정항목에 변화가 있는 경우 다음 두 가지 원인이 있을 수 있습니다.

1. 방문자 특성이나 행동의 변화, 또는
2. 웹사이트의 기술적 변경.

예를 들어, 광고 캠페인을 시작하면 리디렉션이 늘어나고 캐시 적중이 줄어들며 방문자 인구 통계가 바뀌는 경우가 많습니다. RUM 데이터에서 회귀 현상이 발견되면 첫 번째 단계는 변경 사항이 웹사이트에서 발생했는지 아니면 방문자의 브라우저에서 발생했는지 확인하는 것입니다. 보다 명확한 정보를 얻으려면 광고 캠페인, 리퍼러 도메인 또는 네트워크 속도의 조회수 변화를 확인하세요.

해당 방문의 실적이 일반 방문자와 다른 경우 이는 억압이 웹 사이트의 변경으로 인한 것이 아니라는 것을 의미합니다. 그러나 이러한 방문자 집단에게 더 나은 서비스를 제공하고 좋은 경험을 제공하려면 웹사이트를 변경해야 할 수도 있습니다.

기술 변경의 원인을 확인하려면 LCP 하위 부품과 같은 구성 요소 분석 지표를 살펴보세요. 이는 서버 응답 시간의 변경, 새로운 렌더링 차단 리소스 또는 LCP 이미지로 인한 회귀 원인을 좁히는 데 도움이 됩니다.

또한 성능 저하를 유발하는 다양한 LCP 요소 선택기 또는 특정 스크립트와 같은 페이지 보기 속성의 변화를 확인할 수도 있습니다.

결론

일회성 페이지 속도 테스트는 성능 최적화를 위한 훌륭한 출발점입니다. 그러나 DebugBear와 같은 모니터링 도구는 보다 포괄적인 웹 기반을 형성할 수 있습니다. 성과 전략 이는 장기적으로 빠른 속도를 유지하는 데 도움이 됩니다.

저희 웹사이트에서 무료 DebugBear 평가판을 받아보세요!

(gg, yk)