First Input Delay (FID)

Philip Walton

브라우저 지원

• 76
• 79
• 89
• x

소스

경고: 최초 입력 지연 시간 (FID)은 더 이상 Core Web Vital이 아니며 다음 페인트에 대한 상호작용 (INP) 측정항목으로 대체되었습니다. 이에 따라 2024년 9월 9일에 FID 지원이 종료되었습니다. 이제 INP에 집중해야 합니다.

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

웹에서 좋은 첫인상은 사용자가 충성도 높은 사용자로 전환되는지 아니면 떠나서 다시는 돌아오지 않는지 결정하는 요소가 될 수 있습니다. 문제는 무엇이 좋은 인상을 주는지, 사용자에게 어떤 인상을 줄지 어떻게 측정할지입니다.

웹에서 첫인상은 다양한 형태로 나타날 수 있습니다. 사이트의 디자인과 시각적 매력에 대한 첫인상뿐만 아니라 속도와 응답성에 대한 첫인상도 있습니다.

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

사이트 로드 속도에 대한 사용자의 첫인상은 콘텐츠가 포함된 첫 페인트 (FCP)로 측정할 수 있습니다. 하지만 사이트가 화면에 픽셀을 얼마나 빠르게 그릴 수 있는지는 전체 이야기의 일부에 불과합니다. 사용자가 이러한 픽셀과 상호작용하려고 할 때 사이트의 응답성도 중요합니다.

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

FID란 무엇인가요?

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

좋은 FID 점수는 얼마인가요?

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

참고: 이 권장사항의 근거가 되는 연구 및 방법론에 대해 자세히 알아보려면 Core Web Vitals 측정항목 기준점 정의를 참고하세요.

FID 세부정보

이벤트에 응답하는 코드를 작성하는 개발자는 이벤트가 발생하는 즉시 코드가 실행된다고 가정하는 경우가 많습니다. 하지만 사용자는 이와는 반대의 경험을 자주 겪습니다. 휴대전화에 웹페이지를 로드하고 상호작용하려고 했지만 아무 일도 일어나지 않아 짜증이 났던 경험이 있을 것입니다.

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

FID는 이벤트 처리의 '지연'만 측정합니다. 총 이벤트 처리 시간 자체나 이벤트 핸들러를 실행한 후 브라우저가 UI를 업데이트하는 데 걸리는 시간은 측정하지 않습니다. 이 시간은 사용자 환경에 영향을 미치지만 FID의 일부로 포함하면 개발자가 비동기식으로 이벤트에 응답하도록 유도할 수 있습니다. 그러면 측정항목은 개선되지만 환경은 악화될 수 있습니다. 자세한 내용은 아래의 입력 지연만 고려하는 이유를 참고하세요.

일반적인 웹페이지 로드의 타임라인을 살펴보겠습니다.

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

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

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

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

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

입력은 브라우저가 태스크를 실행하는 중에 발생하므로 태스크가 완료될 때까지 기다려야 입력에 응답할 수 있습니다. 기다려야 하는 시간은 이 페이지에서 이 사용자의 FID 값입니다.

참고: 이 예에서는 사용자가 기본 스레드의 가장 바쁜 기간이 시작될 때 페이지와 상호작용하게 되었습니다. 사용자가 잠시 전 (유휴 기간)에 페이지와 상호작용한 경우 브라우저가 즉시 응답할 수 있었습니다. 입력 지연의 이러한 차이는 측정항목을 보고할 때 FID 값의 분포를 확인하는 것이 중요하다는 점을 강조합니다. 이에 관한 자세한 내용은 아래의 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를 측정하려면 실제 사용자가 필요하므로 실험실에서는 측정할 수 없습니다. 그러나 총 차단 시간 (TBT) 측정항목은 실험실에서 측정할 수 있으며, 현장의 FID와 잘 상관관계가 있으며, 상호작용에 영향을 미치는 문제도 포착합니다. 실험실에서 TBT를 개선하는 최적화는 사용자의 FID도 개선해야 합니다.

현장 도구

• Chrome 사용자 경험 보고서
• PageSpeed Insights
• Search Console (Core Web Vitals 보고서)
• web-vitals JavaScript 라이브러리

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 항목을 콘솔에 로깅하고 지연 시간을 계산하는 방법을 보여줍니다. 하지만 JavaScript에서 FID를 측정하는 것은 더 복잡합니다. 자세한 내용은 아래를 참고하세요.

위 예에서 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 항목을 상위 프레임에 보고할 수 있습니다.

참고: 교차 출처 iframe과 같은 일부 경우에는 JavaScript에서 FID를 측정할 수 없습니다.

FID 데이터 분석 및 보고

FID 값의 예상되는 변동으로 인해 FID를 보고할 때는 값의 분포를 살펴보고 상위 백분율에 집중하는 것이 중요합니다.

모든 Core Web Vitals 기준점의 백분위수 선택은 75번째이지만, 특히 FID의 경우 95~99번째 백분위수를 확인하는 것이 좋습니다. 이는 사용자가 사이트에서 겪는 특히 나쁜 첫 경험에 해당하기 때문입니다. 또한 가장 개선이 필요한 영역을 보여줍니다.

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

FID를 개선하는 방법

이 측정항목을 개선하는 기법을 안내하는 FID 최적화에 관한 전체 가이드를 확인하세요.

변경 로그

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

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

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