더 나은 응답성 측정항목을 향해

응답성 측정에 대한 Google의 생각을 알아보고 의견을 제공해 주세요.

Chrome 속도 측정항목팀에서는 웹페이지가 사용자 입력에 얼마나 빠르게 응답하는지 파악하기 위해 노력하고 있습니다. 응답성 측정항목 개선을 위한 아이디어를 공유하고 여러분의 의견을 듣고자 합니다.

이 게시물에서는 두 가지 주요 주제를 다룹니다.

1. 현재 반응성 측정항목인 최초 입력 반응 시간 (FID)을 검토하고 대안이 아닌 FID를 선택한 이유를 설명합니다.
2. 개별 이벤트의 엔드 투 엔드 지연 시간을 더 잘 캡처할 수 있도록 Google에서 고려한 몇 가지 개선사항을 소개합니다. 이러한 개선사항은 전체 기간 동안 페이지의 전반적인 응답성을 보다 전체적으로 파악하는 것을 목표로 합니다.

최초 입력 반응 시간(First Input Delay)이란 무엇인가요?

최초 입력 반응 시간 (FID) 측정항목은 브라우저에서 페이지의 첫 번째 사용자 상호작용을 처리하는 데 걸리는 시간을 측정합니다. 특히 사용자가 기기와 상호작용하는 시간과 브라우저가 실제로 이벤트 핸들러 처리를 시작할 수 있는 시간 간의 차이를 측정합니다. FID는 탭한 후 또는 키를 누를 때만 측정됩니다. 즉, 다음 이벤트가 처음 발생하는 경우에만 고려합니다.

• click
• keydown
• mousedown
• pointerdown (뒤에 pointerup가 오는 경우에만)

다음 다이어그램은 FID를 보여줍니다.

이러한 이벤트 핸들러를 실행하는 데 소요된 시간 및 이후에 브라우저에서 화면을 업데이트하기 위해 실행한 작업은 FID에 포함되지 않습니다. 입력을 처리하기 전에 기본 스레드가 사용 중이었던 시간을 측정합니다. 이러한 차단 시간은 일반적으로 긴 JavaScript 작업으로 인해 발생합니다. 이러한 작업은 언제든지 중지할 수 없으므로 브라우저에서 입력 처리를 시작하기 전에 현재 작업을 완료해야 합니다.

FID를 선택한 이유는 무엇인가요?

Google은 측정항목을 개선하여 사용자에게 실질적인 혜택을 제공하기 위해서는 실제 사용자 환경을 측정하는 것이 중요하다고 생각합니다. FID를 측정하기로 선택한 이유는 사용자가 방금 로드된 사이트와 상호작용하기로 결정할 때 사용자 환경의 일부를 나타내기 때문입니다. FID는 사용자가 사이트와의 상호작용에서 응답을 보기 위해 기다려야 하는 시간을 포착합니다. 즉, FID는 사용자가 상호작용 후 대기하는 시간의 하한입니다.

총 차단 시간 (TBT) 및 상호작용 시간 (TTI)과 같은 다른 측정항목은 장기 작업을 기반으로 하며 FID와 마찬가지로 로드 중 기본 스레드 차단 시간도 측정합니다. 이러한 측정항목은 현장과 실습 모두에서 측정할 수 있기 때문에 많은 개발자가 FID보다 이러한 측정항목 중 하나를 선호하지 않는 이유를 문의했습니다.

원인은 다음과 같습니다. 가장 중요한 이유는 이러한 측정항목이 사용자 환경을 직접 측정하지 않기 때문입니다. 이러한 모든 측정항목은 페이지에서 JavaScript가 실행되는 양을 측정합니다. 오래 실행되는 JavaScript는 사이트에 문제를 일으키는 경향이 있지만, 이러한 작업이 발생할 때 사용자가 페이지와 상호작용하지 않는 경우 사용자 환경에 반드시 영향을 미치지는 않습니다. 페이지는 TBT 및 TTI에서 높은 점수를 기록하지만 사용자에게 속도가 빠르다고 느끼지만 느리게 느껴지거나 점수가 낮을 수 있습니다. Google의 경험에 따르면 이러한 간접적 측정 결과 측정항목이 일부 사이트에서는 제대로 작동하지만 대부분의 사이트에서는 그렇지 않은 것으로 나타났습니다. 간단히 말해, 장기 작업과 TTI가 사용자 중심이 아니기 때문에 이러한 작업은 취약해집니다.

실험실 측정은 확실히 중요하고 진단에 매우 유용한 도구이지만 실제로 중요한 것은 사용자의 사이트 경험입니다. 실제 사용자 조건을 반영하는 사용자 중심 측정항목을 사용하면 사용자 환경에서 의미 있는 정보를 포착할 수 있습니다. 우리는 그 경험의 일부만을 사용해 시작하기로 결정했지만, 이 부분이 전체 경험을 대표하지는 않는다는 것을 알고 있습니다. 이러한 이유로 Google에서는 사용자가 입력이 처리되기를 기다리는 시간의 더 큰 청크를 캡처하기 위해 노력하고 있습니다.

어떤 개선을 고려하고 있나요?

Google은 현재 FID에서 측정하는 방식을 확장하면서도 사용자 환경과의 강력한 연결을 유지하는 새로운 측정항목을 개발하려고 합니다.

새 측정항목을 다음과 같이 설정하려고 합니다.

1. 첫 번째 입력뿐만 아니라 모든 사용자 입력의 응답성을 고려합니다.
2. 각 이벤트의 지연 시간뿐 아니라 전체 기간을 캡처합니다.
3. 동일한 논리적 사용자 상호작용의 일부로 발생하는 이벤트를 그룹화하고 상호작용의 지연 시간을 모든 이벤트의 최대 기간으로 정의합니다.
4. 전체 수명 주기 동안 페이지에서 발생하는 모든 상호작용에 대한 집계 점수를 만듭니다.

성공하려면 사이트가 이 새로운 측정항목에서 낮은 점수를 받으면 사용자 상호작용에 빠르게 반응하지 않는다고 확신할 수 있어야 합니다.

전체 이벤트 기간 캡처

첫 번째 명백한 개선 사항은 이벤트의 더 넓은 엔드 투 엔드 지연 시간을 캡처하는 것입니다. 위에서 언급한 대로 FID는 입력 이벤트의 지연 부분만 캡처합니다. 브라우저가 실제로 이벤트 핸들러를 처리하는 데 걸리는 시간은 고려하지 않습니다.

다음 다이어그램에서 볼 수 있듯이 이벤트의 수명 주기에는 다양한 단계가 있습니다.

Chrome에서 입력을 처리하는 단계는 다음과 같습니다.

1. 사용자의 입력이 발생합니다. 이것이 발생하는 시간은 이벤트의 timeStamp입니다.
2. 브라우저는 조회 테스트를 실행하여 이벤트가 속한 HTML 프레임 (기본 프레임 또는 일부 iframe)을 결정합니다. 그러면 브라우저가 해당 HTML 프레임을 담당하는 적절한 렌더기 프로세스로 이벤트를 전송합니다.
3. 렌더기는 이벤트를 수신하고, 이벤트를 처리할 수 있을 때 처리할 수 있도록 큐에 추가합니다.
4. 렌더러는 핸들러를 실행하여 이벤트를 처리합니다. 이러한 핸들러는 입력 처리의 일부인 setTimeout 및 가져오기와 같은 추가 비동기 작업을 대기열에 추가할 수 있습니다. 그러나 이 시점에서 동기 작업이 완료되었습니다.
5. 실행되는 이벤트 핸들러의 결과를 반영하는 프레임이 화면에 페인트됩니다. 이벤트 핸들러에 의해 대기열에 추가된 비동기 작업은 여전히 미완성 상태일 수 있습니다.

위의 (1) 단계와 (3) 단계 사이의 시간을 이벤트의 지연으로, FID가 측정합니다.

위의 (1)단계와 (5)단계 사이의 시간을 이벤트 소요 시간으로 간주합니다. 이것이 새로운 측정항목에서 측정되는 값입니다.

이벤트 시간에는 지연이 포함되지만 이벤트 핸들러에서 발생하는 작업과 이러한 핸들러가 실행된 후 브라우저가 다음 프레임을 그리는 데 필요한 작업도 포함됩니다. 이벤트의 기간은 현재 항목의 duration 속성을 통해 Event Timing API에서 확인할 수 있습니다.

이벤트를 상호작용으로 그룹화

측정항목 측정을 지연에서 기간으로 확장하는 것이 좋은 첫 번째 단계이지만, 측정항목과 상호작용하는 사용자 환경이 아닌 개별 이벤트에 초점을 맞춘 중요한 차이를 남깁니다.

단일 사용자 상호작용의 결과로 다양한 이벤트가 실행될 수 있으며, 각 이벤트를 개별적으로 측정해도 사용자 경험을 명확하게 파악할 수 없습니다. 이 측정항목은 사용자가 탭, 키 누름, 스크롤, 드래그 시 응답을 기다려야 하는 전체 시간을 가능한 한 정확하게 캡처하기를 원합니다. 따라서 각 상호작용의 지연 시간을 측정하기 위한 상호작용의 개념을 도입했습니다.

상호작용 유형

다음 표에는 관련 있는 DOM 이벤트와 함께 정의할 네 가지 상호작용이 나열되어 있습니다. 이는 이러한 사용자 상호작용이 발생할 때 전달되는 모든 이벤트 집합과는 다릅니다. 예를 들어 사용자가 스크롤하면 스크롤 이벤트가 전달되지만 이 이벤트는 스크롤을 반영하도록 화면이 업데이트된 후에 발생하므로 상호작용 지연 시간의 일부로 간주하지 않습니다.

위에 나열된 처음 세 가지 상호작용 (키보드, 탭, 드래그)은 현재 FID가 적용됩니다. 새로운 반응성 측정항목에는 스크롤도 포함하려고 합니다. 스크롤은 웹에서 매우 일반적이며 페이지가 사용자에게 반응하는 방식을 결정하는 중요한 요소이기 때문입니다.

키보드

키보드 상호작용은 사용자가 키를 누를 때와 키에서 손을 뗄 때 두 부분으로 구성됩니다. 이 사용자 상호작용과 관련된 세 가지 이벤트, 즉 keydown, keyup, keypress가 있습니다. 다음 다이어그램은 키보드 상호작용의 keydown 및 keyup 지연과 지속 시간을 보여줍니다.

위 다이어그램에서는 keyup가 발생하기 전에 keydown 업데이트의 프레임이 표시되기 때문에 기간이 분리되지만 항상 그런 것은 아닙니다. 또한 프레임을 생성하는 데 필요한 마지막 단계가 렌더기 프로세스 외부에서 실행되므로 렌더기 프로세스에서 작업 도중에 프레임이 표시될 수 있습니다.

keydown 및 keypress는 사용자가 키를 누를 때 발생하는 반면 keyup는 사용자가 키를 놓을 때 발생합니다. 일반적으로 키를 누르면 기본 콘텐츠 업데이트가 실행됩니다. 텍스트가 화면에 표시되거나 특수키 효과가 적용됩니다. 하지만 keyup에서도 흥미로운 UI 업데이트를 표시하는 드문 사례를 포착하고 싶으므로 전반적인 소요 시간을 확인하려고 합니다.

키보드 상호작용에 걸리는 전체 시간을 캡처하기 위해 keydown 및 keyup 이벤트의 지속 시간을 최대로 계산할 수 있습니다.

탭

또 다른 중요한 사용자 상호작용은 사용자가 웹사이트를 탭하거나 클릭하는 것입니다. 위 다이어그램에서 볼 수 있듯이 keypress와 마찬가지로 일부 이벤트는 사용자가 누를 때 실행되고 다른 이벤트는 사용자가 놓을 때 실행됩니다. 탭과 연결된 이벤트는 데스크톱과 모바일에서 약간 다릅니다.

탭 또는 클릭의 경우 해제가 일반적으로 대부분의 반응을 트리거하지만 키보드 상호작용과 마찬가지로 전체 상호작용을 캡처하려고 합니다. 이 경우에는 탭 버튼을 누를 때 일부 UI가 업데이트되는 것이 실제로 그렇게 드문 일이 아니므로 그렇게 하는 것이 더 중요합니다.

이러한 모든 이벤트의 이벤트 기간을 포함하고자 하지만 많은 이벤트가 완전히 겹치므로 전체 상호작용을 포괄하려면 pointerdown, pointerup, click만 측정해야 합니다.

드래그

Google은 유사한 관련 이벤트가 있고 일반적으로 사이트의 중요한 UI 업데이트를 초래하므로 드래그도 포함하기로 결정했습니다. 하지만 이 측정항목에서는 드래그의 시작 부분과 마지막 부분인 드래그 종료 부분만 고려하려고 합니다. 이렇게 하면 추론을 쉽게 할 수 있을 뿐만 아니라 지연 시간을 고려한 다른 상호작용과 비교할 수 있습니다. 이는 mouseover와 같은 연속 이벤트를 제외하기로 한 Google의 결정과 일치합니다.

드래그 앤 드롭 API를 통해 구현된 드래그도 데스크톱에서만 작동하므로 고려하지 않습니다.

스크롤

사이트와 상호작용하는 가장 일반적인 형식 중 하나는 스크롤입니다. 새 측정항목의 경우 사용자의 초기 스크롤 상호작용 지연 시간을 측정하려고 합니다. 특히, Google은 사용자가 스크롤을 요청했다는 사실에 대한 브라우저의 초기 반응을 고려합니다. 전체 스크롤 환경을 다루지는 않습니다. 즉, 스크롤하면 많은 프레임이 생성되므로 스크롤에 대한 반응으로 생성된 초기 프레임에 중점을 둡니다.

첫 번째 항목만 볼 수 있는 이유는 무엇인가요? 우선 별도의 부드러움 제안으로 후속 프레임을 캡처할 수 있습니다. 즉, 사용자에게 스크롤의 첫 번째 결과가 표시된 후 나머지는 스크롤 환경이 얼마나 매끄러운지에 따라 측정되어야 합니다. 따라서 Google에서는 원활한 작업을 통해 이 문제를 더 잘 포착할 수 있다고 생각합니다. 따라서 FID와 마찬가지로, 우리는 별개의 사용자 환경을 고수하기로 했습니다. 즉, 사용자와 연관된 명확한 시점이 있고 지연 시간을 쉽게 계산할 수 있는 사용자 경험을 제공합니다. 전체 스크롤은 지속적인 환경이므로 이 측정항목에서 모든 스크롤을 측정할 필요는 없습니다.

그렇다면 왜 스크롤을 측정할까요? Chrome에서 수집한 스크롤 성능을 보면 스크롤이 일반적으로 매우 빠른 것을 확인할 수 있습니다. 하지만 여러 가지 이유로 새 측정항목에 초기 스크롤 지연 시간을 포함하고자 합니다. 첫째, 스크롤은 상당히 최적화되었기 때문에 속도가 매우 중요하기 때문입니다. 그러나 브라우저가 제공하는 일부 성능 이점을 웹사이트에서 우회하는 방법이 여전히 있습니다. Chrome의 가장 일반적인 방법은 기본 스레드에서 강제로 스크롤되도록 하는 것입니다. 따라서 Google 측정항목은 이러한 상황이 발생하는 경우를 알려줄 수 있어야 하며 이로 인해 사용자의 스크롤 성능이 저하됩니다. 둘째, 스크롤은 무시할 수 없을 만큼 중요한 기능입니다. 스크롤을 제외하면 큰 사각지대가 생겨 웹 개발자가 제대로 인식하지 못하고 시간이 지남에 따라 스크롤 성능이 저하될까 봐 걱정됩니다.

사용자가 스크롤할 때 전달되는 여러 이벤트가 있습니다(예: touchstart, touchmove, scroll). 스크롤 이벤트를 제외하고 이는 스크롤에 사용되는 기기에 따라 크게 달라집니다. 터치 이벤트는 휴대기기에서 손가락으로 스크롤할 때 전달되는 반면 휠 이벤트는 마우스 휠로 스크롤할 때 발생합니다. 스크롤 이벤트는 최초 스크롤이 완료된 후 실행됩니다. 웹사이트에서 비수동 이벤트 리스너를 사용하지 않는 한 일반적으로 DOM 이벤트가 스크롤을 차단하지 않습니다. 따라서 스크롤은 DOM 이벤트와 완전히 분리되어 있다고 생각합니다. 여기서는 사용자가 스크롤 동작을 생성할 만큼 충분히 이동한 시점부터 스크롤이 발생한 것을 보여주는 첫 번째 프레임까지를 측정하고자 합니다.

상호작용의 지연 시간을 정의하는 방법

위에서 언급했듯이 '아래' 구성요소와 '위로' 구성요소가 있는 상호작용을 별도로 고려해야 합니다. 그래야 사용자가 손가락을 길게 누르는 데 사용한 시간에 대한 기여도가 부여되지 않습니다.

이러한 유형의 상호작용의 경우 지연 시간에 연결된 모든 이벤트의 지속 시간을 포함하려고 합니다. 상호작용의 각 '다운' 및 '위' 부분의 이벤트 기간은 겹칠 수 있으므로 이를 달성하는 상호작용 지연 시간의 가장 간단한 정의는 연결된 이벤트의 최대 지속 시간입니다. 앞의 키보드 다이어그램을 다시 보면 keyup보다 길기 때문에 keydown 지속 시간이 여기에 해당합니다.

keydown 및 keyup 기간도 중복될 수 있습니다. 예를 들어 다음 다이어그램과 같이 두 이벤트에 관해 표시된 프레임이 동일한 경우 이러한 상황이 발생할 수 있습니다.

이러한 최댓값을 사용하는 방법에는 장단점이 있습니다. Google은 의견을 수렴합니다.

• 장점: 단일 기간 값만 측정한다는 점에서 스크롤을 측정하려는 방식과 일치합니다.
• 장점: keyup는 일반적으로 아무 일도 하지 않으며 사용자가 키 누름과 해제를 빠르고 느리게 실행할 수 있는 키보드 상호작용과 같은 사례의 노이즈를 줄이는 것을 목표로 합니다.
• 단점: 사용자의 전체 대기 시간을 캡처하지 않습니다. 예를 들어 드래그의 시작이나 끝은 캡처하지만 둘 다 캡처하지는 못합니다.

연결된 이벤트가 하나만 있는 스크롤의 경우, 스크롤의 결과로 브라우저가 첫 번째 프레임을 생성하는 데 걸리는 시간으로 지연 시간을 정의하려고 합니다. 즉, 지연 시간은 첫 번째 DOM 이벤트의 timeStamp 이벤트 (손가락을 사용하는 경우 touchmove)가 스크롤을 트리거하기에 충분히 큰 이벤트와 스크롤이 이루어지는 것을 반영하는 첫 번째 페인트 사이의 델타입니다.

페이지당 모든 상호작용 집계

상호작용의 지연 시간을 정의한 후에는 많은 사용자 상호작용이 있을 수 있는 페이지 로드의 집계 값을 계산해야 합니다. 집계된 값이 있으면 다음이 가능합니다.

• 비즈니스 측정항목과의 상관관계를 파악합니다.
• 다른 성능 측정항목과의 상관관계를 평가합니다. 이상적으로는 새 측정항목이 기존 측정항목에 가치를 더하도록 충분히 독립적일 것입니다.
• 소화하기 쉬운 방식으로 도구에서 가치를 쉽게 노출할 수 있습니다.

이 집계를 수행하려면 다음 두 가지 질문을 해결해야 합니다.

1. 어떤 수치를 집계하려고 하나요?
2. 이 수치를 어떻게 집계하나요?

Google에서는 몇 가지 옵션을 살펴보고 평가 중입니다. 이 집계에 관한 고객님의 의견을 환영합니다.

한 가지 옵션은 유형(스크롤, 키보드, 탭 또는 드래그)에 따라 다를 수 있는 상호작용 지연 시간의 예산을 정의하는 것입니다. 예를 들어 탭 예산이 100ms이고 탭 지연 시간이 150ms라면 해당 상호작용의 예산을 초과하는 금액은 50ms가 됩니다. 그런 다음 페이지의 사용자 상호작용에 대한 예산을 초과하는 최대 지연 시간을 계산할 수 있습니다.

또 다른 옵션은 페이지 전체 기간 동안의 상호작용 평균 또는 중앙값을 계산하는 것입니다. 따라서 지연 시간이 80ms, 90ms, 100ms라면 페이지의 평균 지연 시간은 90ms입니다. 상호작용 유형에 따라 다른 기대치를 설명하기 위해 '예산 초과' 평균 또는 중앙값을 고려할 수도 있습니다.

Web Performance API에서는 어떤 모습일까요?

이벤트 타이밍에서 누락된 것은 무엇인가요?

안타깝게도 이 게시물에 나와 있는 모든 아이디어를 Event Timing API를 사용하여 캡처할 수 있는 것은 아닙니다. 특히 API와의 특정 사용자 상호작용과 관련된 이벤트를 알 수 있는 간단한 방법은 없습니다. 이를 위해 API에 interactionID를 추가할 것을 제안했습니다.

Event Timing API의 또 다른 단점은 스크롤 상호작용을 측정할 수 있는 방법이 없다는 것입니다. 따라서 Google에서는 Event Timing 또는 별도의 API를 통해 이러한 측정을 사용 설정하기 위해 노력하고 있습니다.

지금 무엇을 시도해 볼 수 있나요?

지금은 여전히 탭/드래그와 키보드 상호작용의 최대 지연 시간을 계산할 수 있습니다. 다음 코드 스니펫은 이러한 두 측정항목을 생성합니다.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

의견

이 아이디어에 대한 의견을 이메일(web-vitals-feedback@googlegroups.com)로 알려주세요.