사용자 중심 성능 측정항목

Philip Walton

실적이 얼마나 중요한지 누구나 알고 있습니다. 하지만 실적과 웹사이트를 '빠르게' 만드는 것에 관해 이야기할 때 구체적으로 어떤 의미를 말하나요?

사실 실적은 상대적입니다.

  • 사이트가 한 사용자 (고성능 기기를 사용하고 빠른 네트워크에 연결된 사용자)에게는 빠르지만 다른 사용자 (저가형 기기를 사용하고 느린 네트워크에 연결된 사용자)에게는 느릴 수 있습니다.
  • 두 사이트가 정확히 동일한 시간에 로드가 완료될 수 있지만, 하나는 더 빠르게 로드되는 것처럼 보일 수 있습니다 (콘텐츠를 끝까지 기다렸다가 표시하는 대신 점진적으로 로드하는 경우).
  • 사이트가 빠르게 로드되는 것처럼 보일 수 있지만 사용자 상호작용에 느리게 반응하거나 전혀 반응하지 않을 수 있습니다.

성능을 이야기할 때는 정확해야 하며 측정항목 측면에서 성능을 언급해야 합니다. 정량적으로 측정할 수 있는 객관적인 기준이지만 측정하는 측정항목이 유용해야 합니다.

측정항목 정의

이전에는 웹 성능을 load 이벤트로 측정했습니다. 그러나 load는 페이지 수명 주기에서 잘 정의된 순간이지만 이 순간이 반드시 사용자가 중요하게 생각하는 순간과 일치하는 것은 아닙니다.

예를 들어 서버는 즉시 '로드'되는 최소 페이지로 응답하지만 load 이벤트가 발생한 후 몇 초가 지나기 전까지 콘텐츠 가져오기 또는 페이지에 아무것도 표시하지 않습니다. 이러한 페이지는 기술적으로 로드 시간이 빠르지만 이 시간은 사용자가 페이지 로드를 경험하는 방식과 일치하지 않습니다.

지난 몇 년 동안 Chrome팀은 W3C 웹 성능 작업반과 협력하여 사용자가 웹페이지의 성능을 얼마나 잘 경험하는지 더 정확하게 측정하는 일련의 새로운 API 및 측정항목을 표준화하기 위해 노력해 왔습니다.

측정항목이 사용자와 관련이 있도록 하기 위해 다음과 같은 몇 가지 주요 질문을 중심으로 측정항목을 구성합니다.

이러한 문제가 발생하나요? 내비게이션이 시작되었나요? 서버가 응답했나요?
유용하게 사용하셨나요? 사용자가 상호작용할 수 있을 만큼 충분한 콘텐츠가 렌더링되었나요?
사용 가능한가요? 사용자가 페이지와 상호작용할 수 있나요? 아니면 페이지가 사용 중이신가요?
기쁨을 주는가요? 상호작용이 지연 없이 원활하고 자연스러운가요?

측정항목 측정 방법

실적 측정항목은 일반적으로 다음 두 가지 방법 중 하나로 측정됩니다.

  • 실험실: 도구를 사용하여 일관되고 통제된 환경에서 페이지 로드를 시뮬레이션합니다.
  • 현장: 실제로 페이지를 로드하고 상호작용하는 실제 사용자

두 옵션 중 어느 쪽이 더 낫다고 할 수는 없습니다. 일반적으로 좋은 성능을 보장하려면 두 가지를 모두 사용하는 것이 좋습니다.

실험실

새 기능을 개발할 때는 실험실에서 성능을 테스트하는 것이 필수적입니다. 기능이 프로덕션에 출시되기 전에 실제 사용자를 대상으로 성능 특성을 측정하는 것은 불가능하므로 기능이 출시되기 전에 실험실에서 테스트하는 것이 성능 저하를 방지하는 가장 좋은 방법입니다.

현장에서

반면 실험실에서 테스트하는 것은 성능을 나타내는 적절한 대리 변수이지만 실제 사용자가 사이트를 경험하는 방식을 반드시 반영하지는 않습니다.

사이트의 실적은 사용자의 기기 기능과 네트워크 상태에 따라 크게 달라질 수 있습니다. 또한 사용자가 페이지와 상호작용하는지 여부나 상호작용 방식에 따라 달라질 수 있습니다.

페이지 로드도 항상 확정적이지는 않습니다. 예를 들어 맞춤 콘텐츠 또는 광고를 로드하는 사이트는 사용자마다 실적 특성이 크게 다를 수 있습니다. 실험실 테스트에서는 이러한 차이를 포착할 수 없습니다.

사이트가 사용자에게 어떤 성능을 발휘하는지 정확하게 파악하는 유일한 방법은 사용자가 사이트를 로드하고 상호작용할 때 사이트의 성능을 실제로 측정하는 것입니다. 이러한 유형의 측정을 일반적으로 실시간 사용자 모니터링 (RUM)이라고 합니다.

측정항목 유형

사용자가 실적을 인식하는 방식과 관련된 다른 유형의 측정항목도 여러 가지 있습니다.

  • 인지된 로드 속도: 페이지가 모든 시각적 요소를 로드하고 화면에 렌더링하는 속도입니다.
  • 로드 응답성: 구성요소가 사용자 상호작용에 빠르게 반응할 수 있도록 페이지에서 필요한 JavaScript 코드를 로드하고 실행하는 속도입니다.
  • 런타임 응답성: 페이지 로드 후 페이지가 사용자 상호작용에 얼마나 빠르게 반응할 수 있는지 나타냅니다.
  • 시각적 안정성: 페이지의 요소가 사용자가 예상하지 못한 방식으로 이동하여 상호작용을 방해할 수 있나요?
  • 부드러움: 전환 및 애니메이션이 일관된 프레임 속도로 렌더링되고 한 상태에서 다음 상태로 원활하게 전환되나요?

이러한 다양한 유형의 실적 측정항목을 고려할 때 단일 측정항목만으로는 페이지의 모든 실적 특성을 파악하기에 충분하지 않다는 점이 분명합니다.

측정해야 하는 중요한 측정항목

누락된 영역을 다루기 위해 새로운 측정항목이 도입되는 경우도 있지만, 사이트에 맞게 특별히 조정된 측정항목이 가장 적합한 경우도 있습니다.

커스텀 측정항목

앞에서 설명한 성능 측정항목은 웹의 대부분의 사이트의 성능 특성을 일반적으로 파악하는 데 적합합니다. 또한 사이트에서 경쟁업체와 실적을 비교할 수 있는 공통적인 측정항목을 보유하는 데도 유용합니다.

하지만 특정 사이트가 어떤 면에서든 고유하여 전체 성능을 파악하기 위해 추가 측정항목이 필요한 경우가 있습니다. 예를 들어 LCP 측정항목은 페이지의 주요 콘텐츠 로드가 완료된 시점을 측정하기 위한 것이지만, 가장 큰 요소가 페이지의 주요 콘텐츠에 포함되지 않아 LCP가 관련성이 없을 수 있습니다.

이러한 사례를 해결하기 위해 웹 성능 작업 그룹은 자체 맞춤 측정항목을 구현하는 데 유용할 수 있는 하위 수준 API도 표준화했습니다.

이러한 API를 사용하여 사이트에 특화된 성능 특성을 측정하는 방법은 커스텀 측정항목 가이드를 참고하세요.