Het doel van het Chrome User Experience Report is om de webcommunity inzicht te geven in de spreiding en evolutie van de prestaties van gebruikers. Tot nu toe hebben we ons gericht op statistieken over de weergave en het laden van pagina's, zoals First Contentful Paint (FCP) en Onload (OL), die ons hebben geholpen inzicht te krijgen in hoe websites visueel presteren voor gebruikers. Vanaf de release van juni 2018 experimenteren we met een nieuwe, gebruikersgerichte statistiek die zich richt op de interactiviteit van webpagina's: First Input Delay (FID). Deze nieuwe statistiek stelt ons in staat beter te begrijpen hoe responsief websites zijn op gebruikersinvoer.
FID is onlangs beschikbaar gesteld in Chrome als een origin trial , wat betekent dat websites ervoor kunnen kiezen om te experimenteren met deze nieuwe webplatformfunctie. Evenzo zal FID beschikbaar zijn in het Chrome UX-rapport als een experimentele metriek, wat betekent dat het beschikbaar zal zijn gedurende de origin trial in een aparte "experimentele" naamruimte.
Hoe FID wordt gemeten
Wat is FID precies? Zo wordt het gedefinieerd in de blogpost over de aankondiging van First Input Delay :
First Input Delay (FID) meet de tijd vanaf het moment dat een gebruiker voor het eerst interactie heeft met uw site (bijvoorbeeld wanneer hij/zij op een koppeling klikt, op een knop tikt of een aangepast, op JavaScript gebaseerd besturingselement gebruikt) tot het moment dat de browser daadwerkelijk kan reageren op die interactie.
Het is vergelijkbaar met het meten van de tijd tussen het aanbellen en het moment dat iemand de deur opent. Als het lang duurt, kunnen daar verschillende redenen voor zijn. Bijvoorbeeld, de persoon is ver van de deur verwijderd of kan niet snel bewegen. Webpagina's kunnen ook bezig zijn met ander werk of het apparaat van de gebruiker kan traag zijn.
FID verkennen in het Chrome UX-rapport
Met één maand aan FID-gegevens van miljoenen bronnen is er al een schat aan interessante inzichten te ontdekken. Laten we eens kijken naar een paar query's die laten zien hoe je deze inzichten uit het Chrome UX-rapport op BigQuery kunt halen.
Laten we beginnen met het opvragen van het percentage snelle FID-ervaringen voor developers.google.com . We kunnen een snelle ervaring definiëren als een ervaring waarbij de FID minder dan 100 ms is. Volgens de aanbevelingen van RAIL zou een vertraging van 100 ms of korter direct voor de gebruiker moeten aanvoelen.
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'
De resultaten laten zien dat 95% van de FID-ervaringen op deze oorsprong als onmiddellijk worden ervaren. Dat lijkt veelbelovend, maar hoe verhoudt dit zich tot alle oorsprongen in de dataset?
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
De resultaten van deze query laten zien dat 84% van de FID-ervaringen minder dan 100 ms duurt. Developers.google.com scoort dus bovengemiddeld.
Laten we vervolgens proberen deze data te segmenteren om te zien of er een verschil is tussen het percentage snelle FID op desktopcomputers en mobiele apparaten. Een hypothese is dat mobiele apparaten lagere FID-waarden hebben, mogelijk vanwege tragere hardware in vergelijking met desktopcomputers. Als de CPU minder krachtig is, kan deze langer actief zijn en resulteren in tragere FID-ervaringen.
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
| vormfactor | snel_fid |
|---|---|
| bureaublad | 96,02% |
| telefoon | 79,90% |
| tablet | 76,48% |
De resultaten bevestigen onze hypothese. Desktops hebben een hogere cumulatieve dichtheid aan snelle FID-ervaringen dan telefoon- en tablet-form factors. Om te begrijpen waarom deze verschillen bestaan, bijvoorbeeld CPU-prestaties, zijn A/B-tests nodig die buiten het bereik van het Chrome UX-rapport vallen.
Nu we hebben gezien hoe u kunt vaststellen of een oorsprong snelle FID-ervaringen heeft, gaan we kijken naar een aantal oorsprongen die erg goed presteren.
Voorbeeld 1: http://secretlycanadian.com
Deze oorsprong heeft 98% van de FID-ervaringen binnen 100 ms. Hoe doen ze dat? Als we analyseren hoe het is opgebouwd in WebPageTest , zien we dat het een WordPress-pagina is met veel afbeeldingen, maar dat deze 168 KB JavaScript bevat dat in ongeveer 500 ms wordt uitgevoerd op onze testcomputer. Volgens het HTTP Archive is dit niet veel JavaScript, wat deze pagina in het 28e percentiel plaatst.
De roze balk die 2,7 tot 3,0 seconden duurt, is de fase 'HTML parseren' . Gedurende deze tijd is de pagina niet interactief en lijkt visueel onvolledig (zie "3,0 seconden" in de filmstrip hierboven). Daarna worden alle lange taken die wel verwerkt moeten worden, opgesplitst om ervoor te zorgen dat de hoofdthread stil blijft. De roze lijnen op rij 11 laten zien hoe het JavaScript-werk in korte bursts wordt verspreid.
Voorbeeld 2: https://www.wtfast.com
Deze oorsprong heeft 96% directe FID-ervaringen. Er wordt 267 KB JavaScript geladen (38e percentiel in HTTP Archive) en verwerkt dit gedurende 900 ms op de labmachine. De filmstrip laat zien dat de pagina ongeveer 5 seconden nodig heeft om de achtergrond te tekenen en ongeveer 2 seconden om de inhoud te tekenen.
Het meest interessante aan de resultaten is dat er niets interactiefs zichtbaar is terwijl de hoofdthread tussen de 3 en 5 seconden bezig is. Het is juist de traagheid van de FCP van deze pagina die de FID verbetert . Dit is een goed voorbeeld van hoe belangrijk het is om meerdere statistieken te gebruiken om de gebruikerservaring weer te geven.
Begin met verkennen
Meer over FID leest u in de aflevering van deze week van The State of the Web :
Doordat FID beschikbaar is in het Chrome UX Report, kunnen we een basislijn van interactieve ervaringen vaststellen. Aan de hand van deze basislijn kunnen we de verandering ervan in toekomstige releases observeren of individuele oorsprongen benchmarken. Als je FID wilt verzamelen in de veldmetingen van je eigen website, meld je dan aan voor de oorsprongstest door naar bit.ly/event-timing-ot te gaan en de functie Event Timing te selecteren. En natuurlijk kun je de dataset verkennen voor interessante inzichten in de status van interactiviteit op het web. Dit is nog een experimentele metriek, dus geef ons je feedback en deel je analyse in de discussiegroep van het Chrome UX Report of @ChromeUXReport op Twitter.