성능이 얼마나 중요한지에 대해 모두 들어보셨을 것입니다. 그런데 성능과 웹사이트를 '빠르게' 만드는 것이 구체적으로 무엇을 의미할까요?
사실 성능은 상대적입니다.
- 강력한 기기를 갖춘 빠른 네트워크에서는 사이트가 속도가 빠르지만, 저사양 기기를 사용하는 느린 네트워크에 있는 다른 사용자에게는 느릴 수 있습니다.
- 두 개의 사이트가 정확히 동일한 시간 내에 로드를 완료할 수도 있지만, 한 사이트는 로드 속도가 더 빨라질 경우 속도가 더 빨라질 수 있습니다 (콘텐츠를 표시할 때까지 기다리지 않고 점진적으로 콘텐츠를 로드하는 경우).
- 사이트가 빠르게 로드되는 것처럼 보이지만 사용자 상호작용에 느리게 반응하거나 전혀 반응하지 않을 수 있습니다.
성능에 대해 이야기할 때는 metrics 측면에서 정확하게 성능을 언급하는 것이 중요합니다. 정량적으로 측정할 수 있는 객관적 기준이지만 측정하는 측정항목이 유용한지 확인하는 것도 중요합니다.
측정항목 정의
지금까지 웹 성능은 load 이벤트로 측정되었습니다. 그러나 load가 페이지 수명 주기에서 잘 정의된 순간이라고 해도 이 시점이 사용자가 관심을 갖는 부분과 반드시 일치하는 것은 아닙니다.
예를 들어 서버는 즉시 '로드'되는 최소한의 페이지로 응답하지만 load 이벤트가 실행된 후 몇 초까지는 콘텐츠 가져오기나 페이지에 아무것도 표시하는 것을 연기할 수 있습니다. 이러한 페이지는 엄밀히 말하면 로딩 시간이 빠르지만, 이 시간은 사용자가 페이지 로드를 경험하는 방식과 일치하지 않습니다.
지난 몇 년 동안 Chrome팀은 W3C Web Performance Working Group과 협력하여 사용자가 웹페이지의 성능을 경험하는 방식을 더 정확하게 측정하는 새로운 API 및 측정항목을 표준화하기 위해 노력해 왔습니다.
사용자와 측정항목의 관련성을 높이기 위해 다음과 같은 몇 가지 핵심 질문을 중심으로 구성하겠습니다.
| 문제가 있나요? | 내비게이션이 성공적으로 시작되었나요? 서버가 응답했습니까? |
| 유용한가? | 사용자가 참여할 수 있을 만큼 충분한 콘텐츠가 렌더링되었나요? |
| 사용 가능한가? | 사용자가 페이지와 상호작용할 수 있는지, 아니면 사용 중입니까? |
| 즐거운가? | 상호작용이 원활하고 자연스러우며 지연이 없는가? |
측정항목 측정 방법
실적 측정항목은 일반적으로 다음 두 가지 방법 중 하나로 측정됩니다.
- 실습: 도구를 사용하여 일관되고 통제된 환경에서 페이지 로드를 시뮬레이션
- 필드: 실제로 페이지를 로드하고 상호작용하는 실제 사용자
이 두 옵션이 반드시 다른 옵션보다 더 좋거나 나쁜 것은 아닙니다. 실제로 우수한 성능을 위해서는 두 옵션을 모두 사용하는 것이 좋습니다.
실험실
새 기능을 개발할 때는 실험실에서 성능을 테스트하는 것이 필수적입니다. 프로덕션에 기능이 출시되기 전에는 실제 사용자를 대상으로 성능 특성을 측정할 수 없으므로 기능이 출시되기 전에 실험실에서 기능을 테스트하는 것이 성능 저하를 방지하는 가장 좋은 방법입니다.
들판
실험실에서 테스트하는 것이 성능에 대해 합리적인 지표이지만 실제 사용자가 사이트를 어떻게 경험하는지를 반영하는 것은 아닙니다.
사이트 성능은 사용자의 기기 성능 및 네트워크 상태에 따라 크게 달라질 수 있습니다. 또한 사용자가 페이지와 상호작용하는지 또는 어떻게 상호작용하는지에 따라 달라질 수 있습니다.
또한 페이지 로드가 항상 확정적인 것은 아닙니다. 예를 들어 맞춤 콘텐츠 또는 광고를 로드하는 사이트는 사용자마다 크게 다른 실적 특성을 경험할 수 있습니다. 실험실 테스트에서는 이러한 차이를 포착하지 못합니다.
사용자를 위해 사이트의 실적을 제대로 파악할 수 있는 유일한 방법은 사용자가 사이트를 로드하고 상호작용할 때 사이트의 성능을 실제로 측정하는 것입니다. 이러한 유형의 측정을 일반적으로 RUM (실제 사용자 모니터링)이라고 합니다.
측정항목 유형
사용자가 실적을 인식하는 방식과 관련된 다른 여러 가지 유형의 측정항목이 있습니다.
- 인식된 로드 속도: 페이지가 로드되고 모든 시각적 요소를 화면에 렌더링할 수 있는 속도입니다.
- 로드 응답성: 구성요소가 사용자 상호작용에 빠르게 응답하기 위해 페이지가 필요한 자바스크립트 코드를 로드하고 실행할 수 있는 속도입니다.
- 런타임 응답성: 페이지 로드 후 페이지가 사용자 상호작용에 얼마나 빠르게 반응할 수 있는지 나타냅니다.
- 시각적 안정성: 페이지 요소가 사용자가 예상하지 못한 방식으로 전환되어 상호작용을 방해할 수 있나요?
- 부드러움: 전환 및 애니메이션이 일관된 프레임 속도로 렌더링되고 한 상태에서 다음 상태로 부드럽게 흐르나요?
이러한 모든 유형의 실적 측정항목을 고려할 때, 페이지의 모든 성능 특성을 포착하는 단일 측정항목만으로는 충분하지 않을 수 있습니다.
중요한 측정 항목
- 콘텐츠가 포함된 첫 페인트 (FCP): 페이지 로드가 시작된 시점부터 페이지 콘텐츠의 일부가 화면에 렌더링되는 시점까지의 시간을 측정합니다. (실습, 필드)
- 콘텐츠가 포함된 최대 페인트 (LCP): 페이지 로드가 시작된 시점부터 가장 큰 텍스트 블록 또는 이미지 요소가 화면에 렌더링되는 시점까지의 시간을 측정합니다. (실습, 필드)
- 다음 페인트에 대한 상호작용(INP): 페이지에서 이루어지는 모든 탭, 클릭 또는 키보드 상호작용의 지연 시간을 측정하며, 상호작용 횟수를 기준으로 페이지의 가장 낮은 상호작용 지연 시간 또는 가장 긴 상호작용 지연 시간을 단일 대표 값으로 선택하여 페이지의 전반적인 응답성을 설명합니다. (실습, 필드)
- 총 차단 시간 (TBT): FCP와 TTI 사이의 총 시간 중에서 기본 스레드가 입력 응답을 방지할 만큼 오랫동안 차단된 시간을 측정합니다. (실습)
- 누적 레이아웃 변경 (CLS): 페이지가 로드되기 시작하는 시점과 페이지의 수명 주기 상태가 숨김으로 변경되는 시점 사이에 발생하는 모든 예상치 못한 레이아웃 변경의 누적 점수를 측정합니다. (실습, 필드)
- 첫 바이트 소요 시간 (TTFB): 네트워크가 리소스의 첫 번째 바이트로 사용자 요청에 응답하는 데 걸리는 시간을 측정합니다. (실습, 필드)
누락된 영역을 포함하기 위해 새로운 측정항목이 도입되는 경우도 있지만, 사이트에 맞게 맞춤 설정된 측정항목이 가장 좋은 경우도 있습니다.
커스텀 측정항목
앞에서 다룬 성능 측정항목은 대부분의 웹 사이트의 성능 특성을 일반적으로 이해하는 데 유용합니다. 또한 사이트에 대해 경쟁사와 실적을 비교할 수 있는 공통된 측정항목을 사용할 수 있어 유용합니다.
하지만 어떤 면에서 특정 사이트가 고유해 전체 실적을 제대로 파악하기 위해 추가 측정항목이 필요한 경우가 있을 수 있습니다. 예를 들어 LCP 측정항목은 페이지의 기본 콘텐츠의 로드가 완료된 시점을 측정하는 데 목적이 있지만, 가장 큰 요소가 페이지의 기본 콘텐츠에 포함되어 있지 않아 LCP가 관련이 없는 경우가 있을 수 있습니다.
이러한 사례를 해결하기 위해 웹 성능 실무 그룹(Web Performance Working Group)은 자체 맞춤 측정항목을 구현하는 데 유용할 수 있는 하위 수준 API도 표준화했습니다.
이 API를 사용하여 사이트에 맞는 성능 특성을 측정하는 방법을 알아보려면 맞춤 측정항목 가이드를 참조하세요.