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