Het onlangs uitgebrachte Lighthouse 10, de technologie achter PageSpeed Insights en Chrome DevTools, introduceert twee nieuwe site-audits. Deze audits zouden nuttig moeten zijn als onderdeel van de audit omdat ze betrekking hebben op sitebeveiliging en gebruikerservaringsfactoren.
Technisch gezien is een van de audits een uitbreiding van een eerdere audit, maar in wezen is het een nieuwe audit.
Lighthouse bevat verschillende soorten audits, waaronder toegankelijkheidsaudits, best practices-audits, prestatie-audits, progressive web app-audits en een SEO-audit.
Deze twee nieuwe audits komen voort uit twee verschillende audits binnen Lighthouse. De ene maakt deel uit van de best practice-audit en de andere maakt deel uit van de categorie doelmatigheidscontrole.
Nieuwe back/forward cache-audit
Iets waar niet vaak aan wordt gedacht, is de achterwaartse / voorwaartse cache, ook wel bekend als bfcache.
bfcache is een voor optimalisatie ingeschakelde cache waarmee webpagina’s onmiddellijk kunnen worden geladen wanneer een gebruiker achteruit of vooruit navigeert binnen een website.
Websites zonder ingeschakelde bfcache dwingen sitebezoekers om webpagina’s een tweede keer te downloaden wanneer ze heen en weer navigeren binnen een website.
Maar met bfcache ingeschakeld, ervaren sitebezoekers zelf direct laden.
De ontwikkelaarspagina van Google op bfcache legt het als volgt uit:
“De achterwaartse/voorwaartse cache (bfcache) slaat een momentopname van de pagina op in het geheugen voor wanneer de pagina wordt hersteld vanuit de browsegeschiedenis.
Dit versnelt navigatie terug naar de pagina aanzienlijk, maar sommige browser-API’s (bijv. downloadluisteraars) kunnen ervoor zorgen dat de bfcache mislukt en de pagina normaal laadt.
Er zijn best practices om ervoor te zorgen dat pagina’s in aanmerking komen om te worden gecached in de bfcache.
De eerste optimalisatie is om nooit de downloadgebeurtenis te gebruiken.
Volgens Web.dev:
“De downloadgebeurtenis is problematisch voor browsers omdat het ouder is dan bfcache, en veel pagina’s op het internet werken in de (redelijke) veronderstelling dat een pagina niet meer zal bestaan nadat de downloadgebeurtenis is geactiveerd.
Dit vormt een uitdaging omdat veel van deze pagina’s ook zijn gebouwd met de veronderstelling dat de downloadgebeurtenis elke keer dat een gebruiker uitlogt, zou worden geactiveerd, wat niet langer waar is (en dat al lang niet meer is).
Mozilla’s webpagina voor ontwikkelaars voor het downloadevenement raadt het ook af:
“Waarschuwing: ontwikkelaars moeten dit evenement vermijden.”
Lighthouse 10 heeft nu auditing voor bfcache.
Hoe het werkt, is dat het weggaat van de webpagina die wordt getest en er vervolgens naar terugkeert.
Eventuele problemen met de mogelijkheid om bfcache te gebruiken worden onder de aandacht gebracht van bfcache auditing.
Er zijn drie soorten storingen:
bruikbaar
Problemen die kunnen worden opgelost. Ondersteuning in behandeling
Functies die nog niet door Chrome worden ondersteund, voorkomen dat de browser de webpagina in het cachegeheugen opslaat. Niet uitvoerbaar
Dit zijn problemen buiten de pagina zelf die niet kunnen worden gecontroleerd of opgelost.
Lees meer: Chrome-ontwikkelaarspagina over bfcache:
Zorg ervoor dat de pagina kan worden hersteld vanuit de achterwaartse/voorwaartse cache
Uitbreiding veldcontrole Plakken in wachtwoorden
Gebruikers toestaan wachtwoorden in een wachtwoordformulierveld te plakken is een verbetering van de beveiliging.
Als u de mogelijkheid om wachtwoorden vast te houden uitschakelt, voorkomt u dat sitebezoekers wachtwoordmanagers gebruiken die sterke wachtwoorden gebruiken.
Eerdere versies van Lighthouse die deze best practice met betrekking tot het vasthouden aan formuliervelden testten, waren beperkt tot het testen van alleen het wachtwoordveld.
Lighthouse 10 verbetert deze controle door deze uit te breiden om te testen of een invoerveld (niet alleen lezen) vastloopt.
Google’s aankondiging van deze nieuwe audit legt uit waarom het belangrijk is:
“Voor de meeste sites is het voorkomen van hooking een negatieve gebruikerservaring op het netwerk en verhindert het legitieme beveiligings- en toegankelijkheidsworkflows.”
Een “alleen-lezen” invoerveld is een formulierveld dat standaard vooraf ingevulde invoer bevat.
Alle andere invoervelden zouden snapping moeten toestaan, omdat dit handig is voor toegankelijkheid, gebruikerservaring en het verbeteren van de beveiliging.
De Google-pagina voor het oplossen van problemen met ontwikkelaars voor dit type audit biedt deze tips voor het oplossen van dit probleem:
“Hoe snapping op wachtwoordvelden in te schakelen
#Zoek de code die plakken voorkomt
Om snel de code te vinden en te inspecteren die voorkomt dat deze wordt geplakt:
Vouw het deelvenster Breakpoints gebeurtenislistener uit.
Vouw de klembordlijst uit.
Schakel het selectievakje Plakken in.
Plak tekst in een wachtwoordveld op uw pagina.
DevTools zou moeten stoppen bij de eerste coderegel in de corresponderende hook-gebeurtenislistener.
Google raadt aan om het JavaScript-luisteraarscript te identificeren dat plakken verhindert en vervolgens te verwijderen.
Twee nieuwe vuurtorenaudits
Veel SEO-audits testen niet op beveiligingsproblemen, vermoedelijk omdat beveiliging niets te maken heeft met ranking, een overtuiging die mogelijk onjuist is.
Ik heb jarenlang betoogd dat beveiliging een SEO-probleem is, omdat slechte beveiliging een negatieve invloed heeft op de rankings.
Als het doel van een audit is om redenen op te sporen waarom rankings in het gedrang kunnen komen, zou naar mijn mening een veiligheidscontrole deel moeten uitmaken van de SEO-audit.
Lighthouse 10 is live in de PageSpeed Insights-tool en zal verschijnen in Chrome-versie 112, die momenteel gepland staat voor release op 29 maart 2023.
Wie de nieuwe Lighthouse 10 vanuit de Chrome DevTools-interface wil testen, kan dat doen met de ontwikkelaarsversie van de browser van Google, Chrome Canary, die alle nieuwste functies van de reguliere versie van Chrome bevat.
Lees over de nieuwe audits in de aankondiging van Lighthouse 10:
Wat is er nieuw in Lighthouse 10: Nieuwe audits
Uitgelichte afbeelding door Shutterstock/Asier Romero

Hey, ik ben Brent, en ik speel al een lange tijd mee in de SEO scene. Ik ben vooral heel actief in de Amerikaanse markt, en hou dan ook wel van een uitdaging. Ik ben sinds kort aan het uitbreiden binnenin de Benelux, en besluit hier dan ook te oversharen!
Wil je meer leren, klik dan op lees meer!