First Input Delay (FID)

Philip Walton

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

웹에서는 좋은 첫인상이 충성도 높은 사용자가 되는 것과 떠나 다시 돌아오지 않는 것의 차이를 만들 수 있습니다. 문제는 좋은 인상을 주는 요소가 무엇이며, 사용자에게 어떤 인상을 주고 있는지 어떻게 측정하느냐입니다.

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

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

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

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

FID란 무엇인가요?

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

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

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

FID 세부정보

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

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

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

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

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

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

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

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

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

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

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

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

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

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

입력 지연은 사용자 환경을 저하시키지만 다음과 같은 몇 가지 이유로 첫 번째 입력 지연을 측정하는 것이 좋습니다.

• 첫 번째 입력 지연은 사이트의 응답성에 대한 사용자의 첫인상이 되며, 첫인상은 사이트의 품질과 신뢰성에 대한 전반적인 인상을 형성하는 데 매우 중요합니다.
• 오늘날 웹에서 발생하는 가장 큰 상호작용 문제는 페이지 로드 중에 발생합니다. 따라서 사이트의 첫 번째 사용자 상호작용을 개선하는 데 집중하는 것이 웹의 전반적인 상호작용을 개선하는 데 가장 큰 영향을 미칠 것으로 생각합니다.
• 사이트에서 높은 첫 번째 입력 지연을 수정하는 데 권장되는 솔루션(코드 분할, 사전 JavaScript 로드 감소 등)이 페이지 로드 후 느린 입력 지연을 수정하는 데도 동일한 솔루션은 아닙니다. 이러한 측정항목을 분리하면 웹 개발자에게 더 구체적인 성능 가이드라인을 제공할 수 있습니다.

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

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

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

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

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

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

즉, 일부 사용자는 FID 값이 없고 일부 사용자는 FID 값이 낮으며 일부 사용자는 FID 값이 높을 수 있습니다.

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

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

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

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

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

FID 측정 방법

FID는 실제 사용자가 페이지와 상호작용해야 하므로 필드에서만 측정할 수 있는 측정항목입니다. 다음 도구를 사용하여 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 항목의 지연 값은 항목의 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 항목을 상위 프레임에 보고할 수 있습니다.

FID 데이터 분석 및 보고

FID 값의 분산이 예상되므로 FID를 보고할 때는 값의 분포를 살펴보고 높은 백분위수에 집중하는 것이 중요합니다.

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

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

FID 개선 방법

FID 최적화에 관한 전체 가이드에서 이 측정항목을 개선하는 기법을 확인할 수 있습니다.

변경 로그

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

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

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