First Input Delay (FID)

브라우저 지원

  • 76
  • 79
  • 89
  • x

소스

좋은 첫인상을 주는 것이 얼마나 중요한지 잘 알고 계실 것입니다. 새로운 사람을 만날 때뿐만 아니라 웹에서 환경을 구축할 때도 중요합니다.

웹에서 좋은 첫인상은 사용자가 충성도 높은 사용자가 될지, 아니면 떠났다가 다시 돌아오지 않는지를 판가름합니다. 문제는 무엇이 좋은 인상을 남기는지, 그리고 사용자에게 어떤 노출이 발생할지 어떻게 측정하느냐입니다.

웹에서는 첫인상이 매우 다양합니다. 사이트의 디자인과 시각적 매력에 대한 첫인상은 물론, 사이트의 속도와 반응성에 대한 첫인상을 받을 수 있습니다.

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

사용자가 사이트 로드 속도를 갖는 첫인상은 콘텐츠가 포함된 첫 페인트 (FCP)로 측정할 수 있습니다. 하지만 사이트에서 화면에 픽셀을 얼마나 빠르게 칠 수 있는지는 단지 이야기의 일부일 뿐입니다. 사용자가 해당 픽셀과 상호작용하려고 할 때 사이트의 반응도 마찬가지로 중요합니다.

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

FID란 무엇인가요?

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

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

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

올바른 FID 값은 2.5초 이하이고, 좋지 않은 값은 4.0초보다 크며, 그 사이의 값은 개선이 필요합니다.

FID 세부정보

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

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

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

페이지 로드 trace 예

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

이로 인해 기본 스레드가 일시적으로 사용 중인 기간이 발생하며, 이는 베이지색 작업 블록으로 표시됩니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

첫 입력으로 간주되는 것은 무엇인가요?

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

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

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

사용자가 사이트와 상호작용하지 않으면 어떻게 해야 할까요?

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

즉, FID 값이 없는 사용자도 있고 FID 값이 낮은 사용자도 있고 FID 값이 높은 사용자도 있을 수 있습니다.

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

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

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

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

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

FID 측정 방법

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

현장 도구

JavaScript에서 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 항목의 지연 값은 항목의 startTimeprocessingStart 타임스탬프 사이의 델타를 사용하여 측정됩니다. 대부분의 경우 이는 FID 값이지만 일부 first-input 항목은 FID 측정에 유효하지 않습니다.

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

측정항목과 API의 차이점

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

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

import {onFID} from 'web-vitals';

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

JavaScript에서 FID를 측정하는 방법에 관한 전체 예는 onFID() 소스 코드를 참고하세요.

FID 데이터 분석 및 보고

FID 값의 예상 편차 때문에 FID를 보고할 때는 값의 분포를 확인하고 더 높은 백분위수에 집중하는 것이 중요합니다.

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

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

FID를 개선하는 방법

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

변경 로그

측정항목을 측정하는 데 사용되는 API에서 버그가 발견되기도 하고 측정항목 자체의 정의에서 발견되는 경우도 있습니다. 따라서 변경이 필요한 경우도 있으며, 이러한 변경사항은 내부 보고서와 대시보드에서 개선되거나 회귀된 것으로 나타날 수 있습니다.

이러한 측정항목을 쉽게 관리할 수 있도록 이러한 측정항목의 구현 또는 정의에 대한 모든 변경사항이 이 변경 로그에 표시됩니다.

이러한 측정항목에 관한 의견이 있으면 web-vitals-feedback Google 그룹에 작성해 주세요.