Wel eens een video-game gespeeld, waarbij de console niet direct reageerde op jouw handeling op de controller? Deze vorm van input delay of input latency, is het meest bekend onder de noemer 'laggy'.
Wat is (First) Input Delay?
First Input Delay is een performance metric, waarbij gemeten wordt hoe snel er door een website (of in geval van gaming, de console) gereageerd kan worden op de eerste handeling van een gebruiker. Als een website op dat moment bezig is met uitvoer van bijvoorbeeld JavaScript, zal het langer duren voordat de website reageert op een door de bezoeker aangeklikte link of formulierveld. Zie dit in actie in een .
Des te langer dit duurt, des te gefrustreerder je bezoekers worden, met als gevolg dat ze hun heil snel elders zullen zoeken. Meet en verbeter zonodig daarom de First Input Delay van je website. Oftewel, ga na hoe snel de website reageert op:
- een klik op een knop;
- drukken op een touch-screen (zoals mobiel of tablet);
- indrukken van een toets op de toetsenbord.
Denk aan het uitklappen van een navigatie of bekijken van meer informatie, of het intypen van tekst in een zoekbalk of formulier. De metafoor die Google gebruikt:
"It’s like measuring the time from ringing someone’s doorbell to them answering the door"
Estimated Input Latency
Iedereen snapt: zo snel mogelijk een logo, afbeelding of gewoonweg tekst boven de vouw weergeven, om een bezoeker het idee te geven dat er iets gebeurt in zijn of haar scherm. Deze First Meaningful Paint moet je snel tot stand brengen, om de bezoeker het gevoel van een snel ladende webpagina te geven.
Hoe je de First Meaningful Paint verbetert, lees je in het vorig artikel, omtrent optimaal serveren van CSS.
Echter, na deze zogenaamde First Meaningful Paint, zal er interactie komen vanuit de bezoeker. Een optimale First Meaningful Paint staat dus los van een optimale (First) Input Latency. Terwijl de bezoeker al content ziet en denkt de interactie aan te kunnen gaan met je website, is de browser nog bezig om betrokken JavaScript uit te voeren, waardoor je handeling nog niet verwerkt akn worden.
Dit heet "Input Delay". Deze metric wordt binnen Lighthouse onder de loep genomen onder de noemer "First Input Delay" (FID), welke zich in het rapportage vertaalt tot "Estimated Input Latency". Schematisch verhoudt FID zich ten opzichte van andere pagespeed metrics, als volgt in een tijdlijn van de browser-taken:
Bron: developers.google.com
Blijf onder 50ms voor betere conversie
Idealiter zou deze onder de 50 milliseconden moeten liggen. Vanaf die grens zal het gevoel van vertraging vanuit website bezoekers toenemen, met kans op daling in verdere conversie als gevolg van frustraties bij bezoekers. Google's LightHouse analyse meet dit binnen de drukste 5 seconden van de pageload. Google spreekt over een 'laggy' gedrag wanneer de Input Delay boven de 50 milliseconden uit komt.
De eigen website van Wix, is een voorbeeld waar deze metric negatief uitvalt (zie onderstaande screenshot). Estimated Input Latency en TTI gaan in die zin hand in hand, dat JavaScript op beide metrics van invloed is. Niet geheel verbazingwekkend is dat ook de TTI metric van Wix hoog uitvalt.
Google geeft omtrent First Input Delay aan om deze metric vooral onder de loep te nemen in geval van:
- Server-side rendered (SSR) JavaScript apps
Alle JavaScript moet eerst gedownload, geparsed en uitgevoerd worden. Terwijl een app reeds bruikbaar kan lijken, kan het voor gebruikers verleidelijk zijn om alvast te klikken op zichtbare buttons, terwijl JavaScript binnen de app nog bezig is verdere content te tekenen in de browser. Zeker op oudere toestellen kan de ervaring vervolgens minder optimaal zijn; - Sites with lots of third-party iframes
Advertenties en widgets om twitter/facebook-tijdlijn of addthis/sharethis knoppen toe te passen, hebben impact op de inhoud en weergave van een website. Dit kan onder meer ten koste gaan van de First Input Delay.
Estimated Input Latency reduceren
Google heeft een library beschikbaar gesteld, waarmee deze input delay metric is vast te leggen. Reduceren van de First Input Delay, kan lastig zijn wanneer JavaScript reeds gebundeld is. Probeer waar mogelijk om code op te splitsen, zodat er meer vrije momenten zijn om de browser de interactie te laten verwerken. Een (quick & dirty) alternatief, is om gebruik te maken van setTimeout met een 0ms timer om de uitvoer van JavaScript te onderbreken.
Veel JavaScript code waarbij de HTML code niet gemuteerd wordt? Dan kun je overwegen om code in een Web Worker te plaatsen om de main thread vrij te maken. Een praktijk-case (inclusief drempels) lees je op davidea.st. Het doel is immers voornamelijk om de main thread zo snel mogelijk in idle-status te brengen, zodat door de browser direct geacteerd kan worden op interacties door de gebruiker. Een alternatief, is gebruik maken van requestidlecallback. voor taken dat bijvoorbeeld geen directe invloed op de DOM/HTML hoeft uit te oefenen.
Afhankelijk van de gekozen tactiek, kan de oplossing ten koste gaan van andere metrics, zoals de TTI. Blijf dus altijd alle performance metrics meten, bij voorkeur de echte data.
CrUX en RUM
Bovenstaand is juist waar Google nadruk op wil leggen: Real User Monitoring (RUM). Een website kan snel zijn voor jou als developer, met ongetwijfeld goed internet. Echter, hoe ervaart je werkelijk doelgroep een website en pagina's binnen de website? Gebruikt het doelgroep vooral oudere toestellen of zitten ze veelal in een omgeving met minder snel of stabiel internet? Dan is het noodzaak daar op te anticiperen. Dat kan middels Chrome's User Experience Report.
Dat is waar je als website bouwer mee aan de slag wil, om de resultaten voor je opdrachtgevers (en hun potentiële klanten) te kunnen verbeteren!
