Chrome UX 보고서에서 최초 입력 반응 시간 실험하기

<ph type="x-smartling-placeholder">

Chrome 사용자 환경 보고서 웹 커뮤니티가 실제 인터넷의 분포와 진화를 이해하도록 돕는 것이 사용자 실적 지금까지는 페인트 및 페이지 로드 측정항목을 중점적으로 살펴보았습니다. FCP (First Contentful Paint)와 OL (OL) 같은 웹사이트가 시각적으로 어떻게 작동하는지 이해할 수 있습니다. 먼저 2018년 6월 출시 버전에서는 웹페이지의 상호작용에 초점을 맞춥니다. 최초 입력 반응 시간 (FID). 이 새로운 측정항목을 통해 사용자 입력입니다.

FID는 최근 Chrome에서 오리진 트라이얼 웹사이트에서 이 새로운 웹 플랫폼을 실험하고 기능을 사용할 수 있습니다. 마찬가지로 FID는 Chrome UX 보고서에서 실험 측정항목을 사용할 수 있습니다. 즉, 별도의 '실험용' 내의 오리진 트라이얼 네임스페이스입니다.

FID 측정 방법

FID란 정확히 무엇일까요? 이 필드는 최초 입력 반응 시간 공지 블로그 게시물:

최초 입력 반응 시간 (FID)은 사용자가 처음 상호작용한 시점부터의 시간을 측정합니다. 사이트에서 (사용자가 링크를 클릭하거나, 버튼을 탭하거나, 맞춤 버튼을 사용할 때 자바스크립트 기반 제어)를 브라우저가 실제로 응답할 수 있습니다.

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">
</ph> <ph type="x-smartling-placeholder"></ph> <ph type="x-smartling-placeholder">
</ph> 사용량이 많은 기본 스레드가 특정 이벤트에 대한 응답을 지연하는 방식을 보여주는 애니메이션 사용자 상호작용입니다.

누군가의 초인종을 울리고 응답하는 시간을 측정하는 것과 같습니다. 문을 엽니다. 시간이 오래 걸리는 경우 여러 이유가 있을 수 있습니다. 예를 들어 사람이 문에서 멀리 떨어져 있거나 빠르게 움직일 수 없는 것일 수도 있습니다. 마찬가지로 웹페이지가 다른 작업을 하느라 바쁘거나, 사용자의 기기가 느립니다.

Chrome UX 보고서에서 FID 살펴보기

수백만 개의 출처에서 한 달간의 FID 데이터로 이미 방대한 양의 데이터를 확보했습니다. 많은 흥미로운 통찰을 발견하게 됩니다. 텍스트, 이미지, 오디오, 동영상 등 을 통해 BigQuery에 대한 Chrome UX 보고서에서 유용한 정보를 추출하는 방법을 알아보세요.

먼저 developers.google.com의 빠른 FID 경험 비율을 쿼리해 보겠습니다. 빠른 경험은 FID가 100ms 미만인 환경이라고 정의할 수 있습니다. RAIL 권장사항에 따라 지연이 100ms 이상이면 사용자가 즉시 느껴져야 합니다.

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
WHERE
  origin = 'https://developers.google.com'

결과에 따르면 이 출처에서 발생한 FID 경험의 95% 가 있습니다. 정말 괜찮은 것 같지만 다른 모든 출처와 비교하면 어떤가요? 어떻게 해야 할까요?

SELECT
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid

이 쿼리의 결과는 FID 경험의 84% 가 100ms 미만임을 보여줍니다. 따라서 Developers.google.com은 평균 이상입니다.

다음으로 이 데이터를 슬라이스하여 두 값 사이에 모바일 대비 데스크톱의 빠른 FID 비율 한 가지 가설은 모바일 광고가 기기의 FID 값이 더 느리며 데스크탑 컴퓨터. CPU가 덜 강력하다면 시간이 오래 걸릴 수 있습니다. 이로 인해 FID 환경이 느려집니다.

SELECT
  form_factor.name AS form_factor,
  ROUND(SUM(IF(fid.start < 100, fid.density, 0)) / SUM(fid.density), 4) AS fast_fid
FROM
  `chrome-ux-report.all.201806`,
  UNNEST(experimental.first_input_delay.histogram.bin) AS fid
GROUP BY
  form_factor
form_factor fast_fid
데스크톱 96.02%
전화 79.90%
태블릿 76.48%

결과는 가설을 입증합니다. 데스크톱은 누적 밀도가 더 높음 더 빠른 FID 경험을 꼽을 수 있습니다. 이유 이해하기 이러한 차이가 존재합니다(예: CPU 성능은 외부에서 A/B 테스트가 필요함) 확인할 수 있습니다.

이제 출처에 빠른 FID 환경이 있는지 식별하는 방법을 살펴보았습니다. 실적이 좋은 몇 가지 출처를 살펴보겠습니다.

예 1: http://secretlycanadian.com

Secretlycanadian.com의 WebPageTest 슬라이드

이 출처는 98% 100ms 미만의 FID 환경을 지원합니다 어떻게 작동할까요? 기본 제공되는 방법 분석하기 WebPageTest에서 이미지가 많이 포함된 WordPress 페이지이지만, 168KB의 실습용 머신에서 약 500ms 이내에 실행되는 JavaScript입니다. 이것은 HTTP 보관 파일에 따르면 많은 자바스크립트를 사용할 수 있습니다. 이 페이지를 28번째 백분위수로 배치합니다.

Secretlycanadian.com의 AWebPageTest 폭포식 구조

2.7~3.0초 길이의 분홍색 막대는 HTML 파싱 단계입니다. 이 기간 동안 페이지가 상호작용하지 않고 시각적으로 불완전해 보이는 시간('3.0초' 참조) 참조). 그 후에는 처리해야 하는 긴 작업이 모두 기본 스레드가 대기 상태를 유지하도록 분할됩니다. 위에 표시된 분홍색 선은 11행은 JavaScript 작업이 빠르게 분산되는 방식을 보여줍니다.

예 2: https://www.wtfast.com

wtfast.com의 WebPageTest 슬라이드

이 출처의 인스턴트 FID는 96%입니다. 있습니다. 267KB의 JavaScript (HTTP 보관 파일의 38번째 백분위수)를 로드하고 실험실 기기에서 900ms 동안 처리합니다 슬라이드에 배경을 그리는 데 5초 정도, 색을 칠하는 데 약 2초가 더 걸립니다. 있습니다.

wtfast.com의 WebPageTest 폭포

결과에서 가장 흥미로운 점 기본 스레드가 사용 중인 동안에는 상호작용이 전혀 표시되지 않는 것입니다. 3~5초일 수 있습니다. 실제로 이 페이지의 FCP 속도가 느려서 FID 개선 이는 여러 측정항목을 사용하는 것이 얼마나 중요한지 보여주는 좋은 예입니다. 사용자 경험을 나타냅니다.

탐색 시작

FID에 관한 자세한 내용은 이번 주 웹 현황 에피소드에서 확인하실 수 있습니다.

Chrome UX 보고서에서 FID를 사용하면 기준을 설정할 수 있습니다. 상호작용성 경험을 제공합니다 이 기준을 사용하면 개별 출처를 벤치마킹할 수 있습니다 먼저 자체 사이트의 현장 측정에서 FID를 수집하려면 출처에 가입 bit.ly/event-timing-ot로 이동하여 무료 체험판 사용 Event Timing 기능을 선택합니다 물론 탐색을 시작해 웹 상호작용 상태에 대한 흥미로운 통찰을 얻을 수 있습니다. 아직 실험 단계이므로 의견을 제공하고 공유해 주세요. Chrome UX 보고서 토론방에서 여러분의 분석 결과를 확인하세요. 또는 트위터에서 @ChromeUXReport를 확인하세요.