First Input Delay optimaliseren

Robin, 8 april 2021

Daar gaan we weer. Weer een artikel over Core Web Vitals. Je zou bijna zeggen dat die Core Web Vitals misschien wel eens belangrijk kunnen gaan worden. Deze keer duiken we in de zogenaamde First Input Delay (FID).

Wat is de First Input Delay?

De First Input Delay, vaak afgekort tot FID, heeft te maken met interactiviteit. Het meet de tijd die verstrijkt tussen de eerste interactie (het eerste verzoek tot interactie) van een bezoeker van je website tot de tijd dat een browser daadwerkelijk aan de slag kan met het verzoek.

Zo’n interactie klinkt misschien heel spannend maar in de praktijk is het een bezoeker die op een link klikt of bijvoorbeeld op een knop drukt.

Het is belangrijk om te weten dat de First Input Delay dus enkel meet hoelang het duurt voor een verzoek uitgevoerd kan worden. Hoelang het vervolgens duurt voordat het specifieke verzoek uitgevoerd wordt is niet van toepassing op de FID.

Waarom is de First Input Delay belangrijk?

Net als bij de andere Core Web Vitals is Google van mening dat de First Input Delay van essentieel belang is voor een goede ervaring voor de bezoekers van je website.

Google beredeneert dat een eerste indruk van cruciaal belang is voor de algehele ervaring. Zo’n eerste indruk wordt onder andere gemaakt door wat er zichtbaar is (ontwerp) en hoe snel dit ontwerp laadt.

Maar daarnaast is het ook belangrijk dat de eerste interactie soepel verloopt. Om dit te meten is de First Input Delay in het leven geroepen.

Conclusie: De First Input Delay is dus belangrijk omdat het iets zegt over de snelheid waarmee het eerste verzoek verwerkt kan gaan worden.

Hoe meet je de First Input Delay?

Google heeft, net als bij de andere Core Web Vitals, aangegeven wat volgens hun een goede score is voor de FID.

Kan de browser binnen 100 milliseconden beginnen aan het eerste verzoek, dan zit je in de groene zone en zit je dus goed.

Kan de browser tussen de 100 milliseconden en 300 milliseconden beginnen aan het eerste verzoek, dan zit je in de oranje zone en heb je nog iets te verbeteren.

Duurt het meer dan 300 milliseconden voordat de browser aan het eerste verzoek kan beginnen dan zit je in de rode zone en moet je echt aan de slag.

In het artikel Core Web Vitals meten heb ik stilgestaan bij het meten van de Core Web Vitals van jouw website. Hier nog even een korte opsomming én een belangrijke opmerking:

Opmerking: In tegenstelling tot de andere Core Web Vitals (Largest Contentful Paint en Cumulative Layout Shift) is de First Input Delay afhankelijk van een menselijke interactie. Dat is namelijk letterlijk wat FID meet, de tijd tussen de eerste menselijke interactie en wanneer de browser aan dit verzoek kan beginnen.

Het is dus simpelweg niet mogelijk de FID te meten zonder menselijke interactie.

Google geeft hier zelf het volgende over aan:

FID requires a real user and thus cannot be measured in the lab. However, the Total Blocking Time (TBT) metric is lab-measurable, correlates well with FID in the field, and also captures issues that affect interactivity. Optimizations that improve TBT in the lab should also improve FID for your users.

Philip Walton via https://web.dev/fid/

Dus wanneer je niet over real user data beschikt kun je het best kijken naar de Total Blocking Time om een beeld te krijgen van de FID.

In PageSpeed Insights zie je ook Veldgegevens waarbij je wel een First Input Delay score te zien krijgt en Labgegevens waarbij je geen First Input Delay score hebt maar wel een Time to Interactive en een Total Blocking Time.

Hoe optimaliseer je de First Input Delay?

Om de First Input Delay te optimaliseren kun je dus ook kijken naar het optimaliseren van je Total Blocking Time (TBT). Google heeft de volgende suggesties:

  • Verminder de impact van third-party code
  • Verminder de uitvoertijd van Javascript
  • Houdt het aantal verzoeken laag en de bestandsoverdrachten klein

Dit zijn enkele van de manieren om de First Input Delay te optimaliseren. Wil je verder de diepte in? Kijk dan eens naar het artikel Optimize First Input Delay van Google.

Probeer onze hosting 14 dagen gratis

Stap 1 van 3

Verminder de impact van third-party code

Third-party code is code van derden die je verwerkt hebt in je website. Denk bijvoorbeeld aan een code snippet van Hotjar of Google Analytics om data te meten.

Des te meer van dit soort code snippets van third-party’s, des te meer jouw browser moet laden voor hij daadwerkelijk aan de slag kan met het uitvoeren van bijvoorbeeld het eerste verzoek van jouw bezoeker.

Ga dus eerst bij jezelf na of je het meten van die specifieke data de impact op je FID waard vind.

Mocht je de data echt willen meten, kijk dan naar mogelijkheden om de third party code bijvoorbeeld te lazyloaden. Op die manier zorg je ervoor dat de third party code simpelweg later ingeladen wordt.

Verminder de uitvoertijd van Javascript

Net als bij third party code is het zo dat meer Javascript op een pagina er simpelweg voor zorgt dat de browser meer heeft om te laden. Verwijder dus alle ongebruikte Javascript van een pagina.

Daarnaast kun je er, bijvoorbeeld met een plug-in als WP Rocket, voor zorgen dat het laden van JavaScript wordt uitgesteld. Op die manier kan de browser bijvoorbeeld eerst aan de slag met het verwerken van de eerste interactie van een bezoeker.

Houdt het aantal verzoeken laag en de bestandsoverdrachten klein

Voor alles wat op jouw pagina staat moet een verzoek gedaan worden. Zo gaat er een verzoek van de browser naar de server om een tekst op te halen, om een afbeelding op te halen, een knop etc.

Dus des te meer elementen je op je pagina gebruikt, des te meer verzoeken er gedaan moeten worden.

Zo’n third-party code die we net bespraken, is ook een verzoek. Een verzoek van de browser, naar nog weer een andere server dan waar jouw website staat (bijvoorbeeld naar Hotjar of Google Analytics).

Logischerwijs zorgen meer verzoeken voor langere laadtijden. Dus, het tegenovergestelde is ook waar. Des te minder verzoeken, des te korter de laadtijden.

Die verzoeken zijn vaak de oorzaak van een bestandsoverdracht, bijvoorbeeld een afbeelding. Daarbij is het natuurlijk ook weer zo dat des te groter de afbeelding, des te langer de overdracht duurt.

Gelukkig heb je het artikel over het optimaliseren van je afbeeldingen al gelezen 😉 en weet je dit te voorkomen.

Conclusie

Om een goed te scoren met je First Input Delay moet het eerste verzoek van een bezoeker binnen 100 ms gestart kunnen worden.

Je kunt dit optimaliseren door ervoor te zorgen dat de browser niet eerst allerlei andere onderdelen (bijvoorbeeld third-party code) hoeft te laden en bijvoorbeeld door de manier waarop de pagina met Javascript omgaat te veranderen met een plug-in als WP Rocket.

Laat een reactie achter