First Input Delay (FID)

필립 월튼
필립 월튼

브라우저 지원

  • 76
  • 79
  • 89
  • x

소스

좋은 첫인상을 남기는 것이 얼마나 중요한지 모두가 잘 알고 있습니다. 이는 새로운 사람을 만날 때 중요하며 웹에서 경험을 구축할 때도 중요합니다.

웹에서 좋은 첫인상은 사용자가 충성도 높은 사용자가 될지 또는 떠나고 다시 방문하지 않는지를 판가름할 수 있습니다. 문제는 좋은 인상을 주는 요인은 무엇이고 사용자에게 어떤 유형의 노출을 유도할지 어떻게 측정할 수 있느냐입니다.

웹에서는 첫인상이 다양한 형태로 나타날 수 있습니다. 즉, 사이트의 디자인과 시각적 매력에 대한 첫인상은 물론 사이트 속도와 반응성에 대한 첫인상을 얻게 됩니다.

웹 API를 통해 사용자가 사이트 디자인을 얼마나 좋아하는지 측정하기는 어렵지만 속도와 반응성은 측정이 어렵습니다.

콘텐츠가 포함된 첫 페인트 (FCP)로 사용자의 사이트 로드 속도를 측정할 수 있습니다. 하지만 사이트에서 화면에 픽셀을 얼마나 빨리 그리는지 알 수 있는 것은 이야기의 일부일 뿐입니다 사용자가 이러한 픽셀과 상호작용하려고 할 때 사이트의 반응성 또한 중요합니다.

최초 입력 반응 시간 (FID) 측정항목은 사이트의 상호작용과 반응에 대한 사용자의 첫인상을 측정하는 데 도움이 됩니다.

FID란 무엇인가요?

FID는 사용자가 처음 페이지와 상호작용한 시점부터 (즉, 사용자가 링크를 클릭하거나 버튼을 탭하거나 맞춤 JavaScript 기반 컨트롤을 사용하는 시점) 브라우저에서 상호작용에 대한 응답으로 이벤트 핸들러 처리를 실제로 시작할 수 있는 시점까지의 시간을 측정합니다.

좋은 FID 점수란 무엇인가요?

우수한 사용자 환경을 제공하려면 사이트의 최초 입력 지연이 100밀리초 이하여야 합니다. 대부분의 사용자가 이 목표를 달성하도록 하려면 모바일 및 데스크톱 기기별로 분류된 페이지 로드의 75번째 백분위수를 측정해 보면 좋습니다.

적절한 FID 값은 2.5초 이하이고, 좋지 않은 값은 4.0초보다 크고, 그 사이에는 개선이 필요합니다.

FID 세부정보

이벤트에 응답하는 코드를 작성하는 개발자는 종종 이벤트가 발생하는 즉시 코드가 실행된다고 가정합니다. 하지만 사용자들은 모두 이와 반대의 상황을 자주 경험합니다. 휴대전화에 웹페이지를 로드하여 상호작용하려고 했지만 아무런 일도 일어나지 않아 좌절했습니다.

일반적으로 입력 지연(입력 지연 시간이라고도 함)은 브라우저의 기본 스레드에서 다른 작업을 수행하느라 아직 사용자에게 응답할 수 없기 때문에 발생합니다. 이러한 일이 발생할 수 있는 일반적인 이유 중 하나는 브라우저에서 앱에서 로드한 대용량 JavaScript 파일을 파싱하고 실행하는 데 시간이 걸리기 때문입니다. 이 과정에서 로드 중인 JavaScript가 다른 작업을 지시할 수 있으므로 이벤트 리스너를 실행할 수 없습니다.

다음과 같은 일반적인 웹페이지 로드 타임라인을 고려하세요.

페이지 로드 trace의 예

위의 시각화는 리소스 (대부분 CSS 및 JS 파일)에 대해 몇 가지 네트워크 요청을 실행하고 이러한 리소스의 다운로드가 완료된 후 기본 스레드에서 처리되는 페이지를 보여줍니다.

그 결과 기본 스레드를 일시적으로 사용 중인 기간이 생성되며 이는 베이지색의 task 블록으로 표시됩니다.

콘텐츠가 포함된 첫 페인트(FCP)상호작용 시작 시간 (TTI) 사이에 일반적으로 긴 첫 입력 지연이 발생합니다. 페이지가 일부 콘텐츠를 렌더링했지만 아직 안정적으로 상호작용하지 않기 때문입니다. 이러한 일이 어떻게 발생할 수 있는지 설명하기 위해 FCP 및 TTI가 타임라인에 추가되었습니다.

FCP 및 TTI를 사용한 페이지 로드 trace의 예

FCP와 TTI 간에는 상당한 시간(긴 작업 3개 포함)이 있습니다. 이 시간 동안 사용자가 링크 클릭 등 페이지와 상호작용하려고 하면 클릭이 수신된 시점과 기본 스레드가 응답할 수 있는 시점 사이에 지연이 발생합니다.

사용자가 가장 긴 작업의 시작 부분에 있는 페이지와 상호작용하려고 하면 어떻게 될지 생각해 보세요.

FCP, TTI, FID를 사용한 페이지 로드 trace의 예

브라우저에서 작업을 실행하는 동안 입력이 발생하므로, 브라우저에서는 작업이 완료될 때까지 기다려야 입력에 응답할 수 있습니다. 기다려야 하는 시간은 이 페이지에서 이 사용자의 FID 값입니다.

상호작용에 이벤트 리스너가 없으면 어떻게 되나요?

FID는 입력 이벤트가 수신된 시점과 기본 스레드가 다음 유휴 상태가 된 시점 사이의 델타를 측정합니다. 즉, 이벤트 리스너가 등록되지 않은 경우에도 FID가 측정됩니다. 많은 사용자 상호작용에는 이벤트 리스너가 필요하지 않지만 실행을 위해 기본 스레드가 유휴 상태여야 하기 때문입니다.

예를 들어 다음 HTML 요소는 모두 사용자 상호작용에 응답하기 전에 기본 스레드에서 진행 중인 작업이 완료될 때까지 기다려야 합니다.

  • 텍스트 필드, 체크박스, 라디오 버튼 (<input>, <textarea>)
  • 드롭다운 선택 (<select>개)
  • 링크 (<a>개)

첫 번째 입력만 고려하는 이유는 무엇인가요?

입력으로 인한 지연으로 인해 사용자 환경이 저하될 수 있지만, 주로 다음과 같은 몇 가지 이유로 최초 입력 지연을 측정하는 것이 좋습니다.

  • 첫 입력 지연은 사이트의 반응성에 대한 사용자의 첫인상이며, 첫인상은 사이트의 품질과 신뢰성에 대한 전반적인 인상을 결정하는 데 매우 중요합니다.
  • 오늘날 웹에서 볼 수 있는 가장 큰 상호작용 문제는 페이지를 로드하는 중에 발생합니다. 따라서 처음에 사이트의 첫 번째 사용자 상호작용을 개선하는 데 중점을 두는 것이 웹의 전반적인 상호작용을 개선하는 데 가장 큰 영향을 미칠 것으로 믿습니다.
  • 긴 첫 입력 지연 문제를 해결하는 방법(코드 분할, JavaScript를 미리 로드하는 등)에 권장되는 솔루션은 페이지 로드 후 느린 입력 지연 문제를 해결하기 위한 솔루션과 다를 수 있습니다. 이러한 측정항목을 구분하면 웹 개발자에게 보다 구체적인 성능 가이드라인을 제공할 수 있습니다.

첫 번째 입력으로 집계되는 항목은 무엇인가요?

FID는 로드 중 페이지의 응답성을 측정하는 측정항목입니다. 따라서 클릭, 탭, 키 누름과 같은 개별 액션의 입력 이벤트에만 중점을 둡니다.

스크롤 및 확대/축소와 같은 다른 상호작용은 연속적인 작업이며 완전히 다른 성능 제약이 있습니다. 또한 브라우저는 별도의 스레드에서 실행하여 지연 시간을 숨길 수 있는 경우가 많습니다.

이를 다르게 표현하면 FID는 RAIL 성능 모델에서 R (반응성)에 중점을 두는 반면, 스크롤 및 확대/축소는 A (애니메이션)과 더 관련이 있으며 성능 품질을 별도로 평가해야 합니다.

사용자가 사이트와 상호작용하지 않으면 어떻게 되나요?

모든 사용자가 사이트를 방문할 때마다 상호작용하는 것은 아닙니다. 또한 이전 섹션에서 언급했듯이 모든 상호작용이 FID와 관련이 있는 것은 아닙니다. 또한 일부 사용자의 첫 번째 상호작용은 좋지 않은 시점 (기본 스레드를 장시간 사용 중인 경우)과 일부 사용자의 첫 번째 상호작용은 좋은 시점 (기본 스레드가 완전히 유휴 상태일 때)이 됩니다.

즉, FID 값이 없는 사용자, FID 값이 낮은 사용자, FID 값이 높은 사용자 등이 있습니다.

FID를 추적, 보고, 분석하는 방법은 익숙한 다른 측정항목과 상당히 다를 수 있습니다. 다음 섹션에서는 이를 수행하는 가장 좋은 방법을 설명합니다.

입력 지연만 고려하는 이유는 무엇인가요?

위에서 언급했듯이 FID는 이벤트 처리의 '지연'만 측정합니다. 이벤트 처리 시간 자체 또는 이벤트 핸들러를 실행한 후 브라우저가 UI를 업데이트하는 데 걸리는 시간은 측정하지 않습니다.

이 시간이 사용자에게 중요하고 환경에 영향을 미치지만 이 측정항목은 이 측정항목에 포함되지 않습니다. 이렇게 하면 개발자가 실제로 환경을 더 악화시키는 해결 방법을 추가할 수 있기 때문입니다. 즉, 이벤트 핸들러 로직을 비동기 콜백 (setTimeout() 또는 requestAnimationFrame()을 통해)에서 래핑하여 이벤트와 연결된 작업과 분리할 수 있습니다. 그 결과 측정항목 점수는 향상되지만 사용자가 인식하는 경우 응답이 느려집니다.

하지만 FID는 이벤트 지연 시간의 '지연' 부분만 측정하지만 이벤트 수명 주기를 더 많이 추적하려는 개발자는 Event Timing API를 사용하면 됩니다. 자세한 내용은 맞춤 측정항목 가이드를 참고하세요.

FID 측정 방법

FID는 실제 사용자가 페이지와 상호작용해야 하므로 필드에서만 측정할 수 있는 측정항목입니다. 다음 도구를 사용하여 FID를 측정할 수 있습니다.

필드 도구

자바스크립트에서 FID 측정

JavaScript에서 FID를 측정하려면 Event Timing API를 사용하면 됩니다. 다음 예는 first-input 항목을 수신 대기하고 콘솔에 로깅하는 PerformanceObserver를 만드는 방법을 보여줍니다.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

위 예시에서 first-input 항목의 지연 값은 항목의 startTime 타임스탬프와 processingStart 타임스탬프 사이의 델타를 사용하여 측정됩니다. 대부분의 경우 FID 값이지만 일부 first-input 항목은 FID 측정에 유효하지 않습니다.

다음 섹션에는 API 보고서 내용과 측정항목 계산 방법의 차이가 나와 있습니다.

측정항목과 API의 차이점

  • API는 백그라운드 탭에 로드된 페이지의 first-input 항목을 전달하지만 FID를 계산할 때 이러한 페이지는 무시해야 합니다.
  • 또한 API는 첫 번째 입력이 발생하기 전에 페이지가 백그라운드에 있었다면 first-input 항목을 전달하지만 FID를 계산할 때 이러한 페이지도 무시해야 합니다 (입력은 페이지가 전체 시간 동안 포그라운드에 있었던 경우에만 고려됨).
  • 페이지가 뒤로-앞으로 캐시에서 복원될 때 API는 first-input 항목을 보고하지 않지만, 이러한 경우에는 사용자가 이를 별개의 페이지 방문으로 경험하므로 FID를 측정해야 합니다.
  • API는 iframe 내에서 발생하는 입력을 보고하지 않지만 측정항목은 페이지의 사용자 환경의 일부이므로 데이터를 보고합니다. 이는 CrUX와 RUM의 차이를 보여줄 수 있습니다. FID를 제대로 측정하려면 이를 고려해야 합니다. 하위 프레임은 API를 사용하여 집계를 위해 first-input 항목을 상위 프레임에 보고할 수 있습니다.

개발자는 이러한 미묘한 차이점을 모두 기억하는 대신 web-vitals 자바스크립트 라이브러리를 사용하여 이러한 차이를 자동으로 처리하는 FID를 측정할 수 있습니다 (가능한 경우 iframe 문제는 다루지 않음).

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

자바스크립트에서 FID를 측정하는 방법에 관한 전체 예는 onFID()의 소스 코드를 참고하세요.

FID 데이터 분석 및 보고

FID 값의 예상 편차로 인해 FID를 보고할 때는 값의 분포를 살펴보고 상위 백분위수에 집중하는 것이 중요합니다.

모든 코어 웹 바이탈 기준점의 백분위수 선택이 75번째이지만, 특히 FID의 경우 사용자가 사이트에서 경험하는 특히 열악한 환경에 해당하는 95~99번째 백분위수를 살펴보는 것이 좋습니다. 가장 개선이 필요한 영역이 표시됩니다.

이는 보고서 데이터를 기기 카테고리 또는 유형별로 분류하는 경우에도 마찬가지입니다. 예를 들어 데스크톱과 모바일에 관해 별도의 보고서를 실행하는 경우 데스크톱에서 가장 중요하게 생각하는 FID 값은 데스크톱 사용자의 95~99번째 백분위수여야 하며 모바일에서 가장 중요하게 생각하는 FID 값은 모바일 사용자의 95~99번째 백분위수여야 합니다.

FID 개선 방법

이 측정항목을 개선하는 기법을 자세히 알아보려면 FID 최적화에 관한 전체 가이드를 참조하세요.

변경 로그

측정항목을 측정하는 데 사용되는 API에서 버그가 발견되기도 하고 측정항목 자체의 정의에서도 버그가 발견되기도 합니다. 따라서 변경이 필요한 경우도 있고 이러한 변경사항이 내부 보고서와 대시보드에 개선 또는 회귀로 표시될 수 있습니다.

이를 관리하는 데 도움이 되도록 이러한 측정항목의 구현 또는 정의에 대한 모든 변경사항이 이 CHANGELOG에 표시됩니다.

이러한 측정항목에 관한 의견이 있다면 web-vitals-feedback Google 그룹에서 공유해 주세요.