Chrome 사용자 환경 보고서의 목표는 웹 커뮤니티가 실제 사용자 성능의 분포와 발전을 이해하도록 돕는 것입니다. 지금까지는 콘텐츠가 포함된 첫 페인트 (FCP) 및 온로드 (OL)와 같은 페인트 및 페이지 로드 측정항목에 초점을 두었습니다. 이러한 측정항목은 사용자를 위해 웹사이트의 시각적 성능을 이해하는 데 도움이 되었습니다. 2018년 6월 출시부터 웹페이지의 상호작용에 초점을 맞춘 새로운 사용자 중심 측정항목인 최초 입력 반응 시간(FID)을 실험합니다. 이 새로운 측정항목을 통해 웹사이트가 사용자 입력에 어떻게 반응하는지 더 잘 파악할 수 있습니다.
FID는 최근 Chrome에서 오리진 트라이얼로 제공되었습니다. 즉, 웹사이트에서 이 새로운 웹 플랫폼 기능을 실험해 볼 수 있습니다. 마찬가지로 FID는 Chrome UX 보고서에서 실험용 측정항목으로 제공됩니다. 즉, 별도의 '실험용' 네임스페이스에서 오리진 트라이얼 동안 FID를 사용할 수 있습니다.
FID 측정 방법
FID란 정확히 무엇일까요? 최초 입력 반응 시간 공지사항 블로그 게시물에서 이 정의는 다음과 같이 정의됩니다.
최초 입력 반응 시간 (FID)은 사용자가 사이트와 처음 상호작용 (즉, 링크를 클릭하거나 버튼을 탭하거나 맞춤 자바스크립트 기반 컨트롤을 사용하는 시점)부터 브라우저에서 실제로 해당 상호작용에 응답할 수 있는 시점까지의 시간을 측정합니다.
이는 누군가의 초인종을 울리는 순간부터 문을 여는 사람까지 걸리는 시간을 측정하는 것과 같습니다. 시간이 오래 걸리는 경우 여러 가지 이유가 있을 수 있습니다. 예를 들어 사용자가 문에서 멀리 떨어져 있거나 빠르게 움직일 수 없는 것일 수 있습니다. 마찬가지로 웹페이지가 다른 작업을 수행하느라 바쁘거나 사용자의 기기가 느려질 수 있습니다.
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 성능)를 이해하려면 Chrome UX 보고서의 범위를 벗어나는 A/B 테스트가 필요합니다.
출처에 빠른 FID 환경이 있는지 식별하는 방법을 알아보았으므로 이제 성능이 매우 좋은 몇 가지 출처를 살펴보겠습니다.
예 1: http://secretlycanadian.com
이 출처는 FID 환경의 98%가 100ms 미만입니다. 어떻게 해결할 수 있을까요? WebPageTest에서 구축된 방식을 분석해보면 이 페이지는 이미지가 많은 WordPress 페이지이지만 실험실 컴퓨터에서 약 500ms 이내에 실행되는 168KB의 JavaScript를 포함하고 있음을 알 수 있습니다. 이 페이지는 28번째 백분위수에 있는 페이지인 HTTP Archive에 따르면 그다지 많은 자바스크립트는 아닙니다.
2.7초에서 3.0초에 걸친 분홍색 막대는 HTML 파싱 단계입니다. 이 시간 동안에는 페이지가 대화형이 아니며 시각적으로 불완전하게 표시됩니다 (위 슬라이드의 '3.0초' 참고). 그 후에는 기본 스레드가 대기 상태를 유지하도록 처리해야 하는 모든 장기 작업이 분리됩니다. 11행의 분홍색 선은 JavaScript 작업이 어떻게 빠른 버스트로 분산되는지 보여줍니다.
예 2: https://www.wtfast.com
이 출처에는 96% 인스턴트 FID 환경이 있습니다. 267KB의 자바스크립트 (HTTP 보관 파일의 38번째 백분위수)를 로드하여 실험실 머신에서 900ms 동안 처리합니다. 슬라이드에 따르면 페이지에서 배경을 그리는 데 약 5초, 콘텐츠를 그리는 데 2초가 더 걸립니다.
결과에서 가장 흥미로운 점은 기본 스레드가 3~5초 동안 사용 중인 동안에는 대화형이 표시되지 않는다는 점입니다. FID를 개선하는 것은 실제로 이 페이지의 FCP 속도가 느려지는 것입니다. 이는 사용자 환경을 표현하는 데 많은 측정항목을 사용하는 것의 중요성을 보여주는 좋은 예입니다.
살펴보기
FID에 관해 자세히 알아보려면 이번 주 The State of the Web 에피소드를 참고하세요.
Chrome UX 보고서에서 FID를 사용할 수 있게 되면 상호작용 환경의 기준을 수립할 수 있습니다. 이 기준을 사용하여 향후 버전에서 변경사항을 관찰하거나 개별 출처를 벤치마킹할 수 있습니다. 자체 사이트의 필드 측정에서 FID 수집을 시작하려면 bit.ly/event-timing-ot로 이동하여 오리진 트라이얼에 가입하고 Event Timing 기능을 선택하세요. 물론 웹에서의 상호작용 상태에 대한 흥미로운 통찰력을 얻기 위해 데이터 세트를 탐색해 보세요. 이는 아직 실험용 측정항목이므로 Chrome UX 보고서 토론방 또는 트위터의 @ChromeUXReport에서 의견을 제공하고 분석을 공유해 주세요.