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