<ph type="x-smartling-placeholder">
좋은 첫인상을 주는 것이 얼마나 중요한지 누구나 잘 알고 있습니다. 중요한 것은 새로운 사람들을 만날 때, 또 다른 플랫폼에서 환경을 구축할 때도 있습니다.
웹에서 좋은 첫인상은 충성도 높은 사용자가 되거나 이탈하고 다시는 돌아오지 않게 될 가능성이 큽니다. 문제는 좋은 인상을 남기는 요인은 무엇인지, 어떤 노출이 얼마나 되는지 어떻게 해야 할까요?
웹에서의 첫인상은 다양한 형태로 나타날 수 있습니다. 사이트 디자인과 시각적 매력에 대한 첫인상뿐만 아니라 반응이 가장 좋은 방법입니다.
사용자가 웹 API를 사용한 사이트 디자인을 얼마나 좋아하는지 측정하기는 어렵지만 속도와 반응성을 측정하는 것은 아닙니다.
사이트 로드 속도에 대한 사용자의 첫인상은 콘텐츠가 포함된 첫 페인트 (FCP). 하지만 사이트에서 픽셀을 얼마나 빨리 페인트할 수 있는지 이야기의 일부일 뿐입니다. 마찬가지로 중요한 것은 사용자가 픽셀과 상호작용하려고 할 때 발생합니다.
첫 입력 지연 (FID) 측정항목은 사용자가 입력한 영향을 미칠 수 있습니다.
FID란 무엇인가요?
FID는 사용자가 페이지와 처음 상호작용한 시점부터 링크를 클릭하거나 버튼을 탭하거나 JavaScript 기반의 맞춤 컨트롤을 사용하는 경우 브라우저가 실제로 이벤트 핸들러 처리를 시작할 수 있는 시점까지 자동으로 반응할 수 있습니다
좋은 FID 점수란 무엇인가요?
만족스러운 사용자 환경을 제공하려면 사이트에서 최초 입력 기능을 제공해야 합니다 100밀리초 이하의 지연 시간입니다. 이러한 목표를 달성할 수 있도록 대부분의 사용자에 대해 측정 가능한 기준점으로는 앱의 75번째 백분위수가 모바일 및 데스크톱 기기별로 분류되어 표시됩니다.
<ph type="x-smartling-placeholder">
FID 세부정보
이벤트에 응답하는 코드를 작성하는 개발자는 코드가 이벤트가 발생하는 즉시 실행됩니다. 하지만 사용자로서 정반대의 경험을 자주 겪었습니다. 상호작용하려고 시도했는데 아무것도 오지 않아 좌절감을 느꼈습니다. 확인할 수 있습니다
일반적으로 입력 지연 (즉, 입력 지연 시간)은 브라우저의 기본 스레드가 다른 작업을 하느라 아직도 사용자에게 응답할 수 없습니다. 이 문제가 발생하는 일반적인 이유 중 하나는 브라우저가 파싱 및 실행하느라 바쁘기 때문입니다. 할 수 있습니다. 실행되는 동안에는 모든 이벤트 리스너가 로드 중인 JavaScript가 다른 것입니다.
일반적인 웹페이지 로드의 다음 타임라인을 생각해 보세요.
위의 시각화는 두 번의 네트워크 요청을 하는 페이지를 보여줍니다. 리소스 (CSS 및 JS 파일 대부분) 및 해당 리소스 이후 다운로드가 완료되면 기본 스레드에서 처리됩니다.
이로 인해 기본 스레드가 잠시 사용 중인 기간으로 인해 베이지색으로 표시된 태스크 있습니다.
첫 번째 입력 지연이 긴 시간은 보통 첫 번째 콘텐츠가 포함된 페인트 사이에 발생합니다. (FCP) 및 상호작용 시간 (TTI)은 일부 콘텐츠를 렌더링했지만 아직 안정적으로 상호작용하지 않습니다. 설명 타임라인에 FCP 및 TTI가 추가되었습니다.
상당한 시간 (3회의 긴 지연 시간 포함)이 작업)에서 사용자가 다른 작업을 하려고 하면 FCP와 TTI 간에 페이지와 상호작용하면 (예: 링크 클릭) 클릭이 수신된 시점과 기본 스레드에서 있습니다.
사용자가 가장 긴 작업의 시작:
브라우저가 작업을 실행하는 동안 입력이 발생하므로 태스크가 완료될 때까지 기다려야 입력에 응답할 수 있습니다. 이 대기해야 하는 시간은 이 페이지에서 이 사용자의 FID 값입니다.
상호작용에 이벤트 리스너가 없으면 어떻게 해야 할까요?
FID는 입력 이벤트가 수신된 시점과 기본 이벤트 사이의 델타를 측정합니다. 스레드가 다음에 유휴 상태일 때 즉, 이벤트가 실행되거나 실패하는 경우에도 리스너가 등록되지 않았습니다. 많은 사용자 상호작용이 이벤트 리스너가 필요하지 않지만 기본 스레드가 다음 위치에서 유휴 상태여야 합니다. 실행할 수 있습니다
예를 들어 다음 HTML 요소는 모두 사용자에게 응답하기 전에 기본 스레드에서 진행 중인 작업을 완료해야 합니다. 상호작용:
- 텍스트 필드, 체크박스, 라디오 버튼 (
<input>,<textarea>) - 드롭다운 선택 (
<select>개) - 링크 (
<a>개)
첫 번째 입력만 고려하는 이유는 무엇인가요?
입력에서 지연이 발생하면 사용자 경험이 저하될 수 있지만, 무엇보다도 다음과 같은 몇 가지 이유로 최초 입력 지연을 측정하는 것이 좋습니다.
- 첫 입력 지연은 사용자가 내 사이트에 대한 첫인상을 첫인상은 전반적인 고객 만족도를 형성하는 데 영향을 주지 않습니다.
- 오늘날 웹에서 가장 큰 상호작용성 문제는 있습니다. 따라서 초기에는 사이트의 첫 번째 사용자를 개선하고 전반적인 사용자 환경이 전반적으로 개선되고 상호작용성에 관한 것입니다.
- 사이트에서 높은 최초 입력 지연을 해결하기 위한 권장 솔루션 (코드 분할, 자바스크립트 초기 로드 감소 등)가 페이지 로드 후 느린 입력 지연 문제를 해결하기 위한 동일한 솔루션을 제공합니다. 첫 번째 문자를 이러한 측정항목을 활용하면 보다 구체적인 실적을 가이드라인을 준수해야 합니다
첫 입력으로 집계되는 경우는 무엇인가요?
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-vitalsJavaScript 라이브러리
JavaScript에서 FID 측정
JavaScript에서 FID를 측정하려면 Event Timing
API를 참고하세요. 다음 예는 다음을 실행하는 방법을 보여줍니다.
만들기
PerformanceObserver
사용자의 현재 상태를
first-input
로그인하고 콘솔에 로깅합니다.
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 내에서 발생하는 입력을 보고하지 않지만 측정항목은 iframe 내에서 발생합니다.
이러한 요소가 페이지 사용자 환경의 일부이기 때문입니다. 이렇게 하면
CrUX와 RUM의 차이로 보입니다.
FID를 올바르게 측정하려면 FID를 고려해야 합니다. 서브 프레임에서 API 사용 가능
집계를 위해
first-input항목을 상위 프레임에 보고합니다.
개발자는 이 모든 미묘한 차이점을 기억하는 대신에
web-vitals JavaScript 라이브러리를 사용하여
이러한 차이를 처리하는 FID를 측정합니다 (가능한 경우 iframe 문제는 다루지 않음).
import {onFID} from 'web-vitals';
// Measure and log FID as soon as it's available.
onFID(console.log);
Android vitals의 소스 코드는
onFID()
을 참조하세요.
FID 데이터 분석 및 보고
예상되는 FID 값의 변동성으로 인해 FID 값을 보고할 때는 FID에서는 값의 분포를 살펴보고 상위 백분위수에 초점을 맞춥니다.
백분위수 Core Web Vitals 기준점은 75번째입니다. 특히 FID의 경우 여전히 매우 중요합니다. 95~99번째 백분위수를 확인해 보시는 것이 좋습니다. 특히 부정적인 첫 경험이 될 것입니다. 그리고 가장 개선이 필요한 영역이 표시됩니다.
이는 기기 카테고리 또는 유형별로 보고서를 분류하는 경우에도 마찬가지입니다. 대상 예를 들어 데스크톱과 모바일에 대해 별도의 보고서를 실행하는 경우 데스크톱 사용자의 95~99번째 백분위수에 집중해야 합니다. 모바일에서 가장 관심 있는 FID 값은 95~99번째여야 합니다. 모바일 사용자의 백분위수
FID 개선 방법
FID 최적화에 관한 전체 가이드에서 이 측정항목을 개선하는 기법을 확인할 수 있습니다.
변경 로그
가끔 측정항목을 측정하는 데 사용되는 API에서 버그가 발견되며, 측정항목 자체의 정의에서도 버그가 발견됩니다. 그 결과, 때때로 변경이 이루어져야 하며, 내부 보고서 및 대시보드에서 이러한 변경사항이 개선되거나 회귀로 나타날 수 있습니다.
이를 관리하는 데 도움이 되도록 이러한 측정항목의 구현 또는 정의에 대한 모든 변경사항이 이 변경 로그에 표시됩니다.
이러한 측정항목에 관한 의견이 있으면 web-vitals-feedback Google 그룹에 의견을 보내주세요.