Google indexeert de websites door middel van crawlen. Dit betekent dat Google de website doorzoekt en onderzoekt. Vroeger deden ze dit puur op basis van de html code waaruit de website bestaat. Tegenwoordig kan een website ook JavaScripts bevatten die html genereren. Daarom heeft Google gekozen om eerst de website te renderen en daarna te onderzoeken wat er precies op staat. Dit betekent dat wanneer je een witte tekst op een witte achtergrond zet, de lezer er niets van ziet, Google bot nu ook niet leest. Vroeger las de robot van Google dit wel.
Deze aanpassing heeft Google gedaan omdat zij vinden dat websites een goede Page Experience moeten hebben. Daar spreken ze al een aantal jaren over. Bij Page Experience gaat het om snelheid van laden, vriendelijkheid en dat een website niet als traag ervaren wordt. Een manier om een website snel te maken is om de website pagina niet in één keer in zijn geheel te laden. Maar via javascript aan te vullend met nieuwe informatie c.q. html code wanneer de lezer naar beneden scrolt. Je kent dit vast wel, denk maar aan Facebook, waar je eeuwig naar beneden kunt blijven scrollen. Maar ook als je een lange lijst hebt, is het niet handig om alles ineens te laden. Want op een mobieltje wordt dan deze lijst snel traag. Google indexeert niet alles van zo'n pagina. Ze indexeren 5 tot 10 bladzijden qua omlaag scrollen. Ze overwegen om in de toekomst meer te indexeren indien gebruik wordt gemaakt van deze manier van laden.
Alles draait om performance en het gaat niet zozeer hoe de website op de PC overkomt. Meer dan 80% van de webbezoekers bezoeken de website met hun mobieltje. En mobiele gebruikers hebben niet altijd beschikking over snel internet. 3G of 4G is heel wat trager dan de snelle kabel-internet of glasvezel. En als de website op de mobiel traag laat, dan is de kans aanwezig dat de bezoeker denkt tjonge, ik wacht niet, ik ga iets anders doen.
Maar niet alleen snelheid is belangrijk. Iedereen heeft wel eens meegemaakt dat je op de mobiel een website opent en je van alles heen en weer ziet gaan. Of dat wanneer je op iets klikt ineens van alles verschuift en je op iets anders klikt. Dit is zo irritant! Dit wordt shifting genoemd. En Google vindt dat websites die veel shifting kennen, irritante websites die niet aangeboden moeten worden indien er alternatieven zijn met minder shifting.
Dat is de reden dat vanaf eind mei / begin juni 2021 bij de ranking van websites rekening wordt gehouden met de performance en hoe de website ervaren wordt. Dit wordt Core Web Vitals genoemd. Webvitals bestaan uit First Input Delay (FID), Largest Contentful Paint (FCP) en Cumulative Layout Shift (CLS). Wat in deze meeting nog niet meegenomen wordt, maar wel belangrijk is, is First Contentful Paint (FCP). Er zijn honderden ranking items zoals titel van de website, hoe vaak bepaalde woorden in de tekst voorkomt, waar Google rekening mee houdt. Maar sinds juni 2021 houdt Google voor mobiele gebruikers ook rekening met Webvitals. Gecommuniceerd was dat dit vanaf mei 2021 zou gebeuren, maar Google heeft bij invoering problemen ondervonden en heeft het één maand uitgesteld. Google wil dit later ook voor de PC uitrollen. Want sinds Mobile First indexering presenteert Google twee indexeringen. Eentje voor de PC en eentje voor de mobiel. En Google indexeert in principe altijd de mobiele versie van de website.
Wat maakt Webvitals en ranking uit? Stel je hebt een webwinkel en deze site wordt traag geladen. Daarnaast heeft het shifting waardoor de Webvitals score laag is. Als er alternatieve webwinkels zijn met dezelfde producten, dan zullen deze hoger geïndexeerd kunnen worden dan de webwinkel die traag laad en slechte score voor Webvitals heeft.
Performance Dwerghamster.nl begin september 2021
Impact website Dwerghamster.nl
Ik zag vanaf juni 2021 ineens een drop in het aantal bezoekers. Het ging om maar liefst om 50% van de bezoekers. Zelf had ik al wat over Webvitals en laadsnelheid op mijn blog geschreven, maar niet gerealiseerd dat mijn website door Google als "slecht" beschouwd werd. In juni dacht ik dat dit door het weer en de EK Voetbal zou komen. En daarna dacht ik ach het wordt vakantietijd en corona is over. Maar toen ik ging verdiepen, realiseerde ik dat niet alles te verwijten was aan de zomer. De laadtijd van Dwerghamster.nl bedroeg maar liefst 5 seconden of langer. Ik had de website in december 2020 geüpdate en dacht een beter website neer te zetten. Het was zeker mobielvriendelijker. Maar de website had meer scripts, meer css style en was zwaarder om te laden. Daarnaast kies ik voor kwaliteit en op mijn website staan prachtige foto's. Ik had juist in december grotere versies van de foto's op mijn voorpagina neergezet.
Chrome UX Report (afgekort CrUX) en impact van werkelijke gebruikerservaringen
Google maak gebruik van Webvitals scores die vergaard worden door CrUX. Hiermee verzamelen zij real live ervaringsdata. Maar via Google Analystics vergaren zij ook data als de bezoeker Firefox of Microsoft Edge gebruikt. Via CrUX neemt Google steekproeven hoe de performance van de website is inclusief de laadtijd. Dit betekent dat het om daadwerkelijke ervaringen gaat. En dat betekent ook dat wanneer veel kinderen op de website zitten, de scores slechter kunnen zijn dan als er veel volwassen mensen op de website zitten. Want kinderen gebruiken oude telefoons en hebben vaker te maken met een slechte internet verbinding (bijv. op school via wifi). En mijn website wordt juist door veel kinderen bezocht.
Een snelle oplossing waar ik zelf niet voor gekozen heb
Een snelle oplossing voor het verbeteren van performance is een CDN server tussen de website server te zetten. CDN staat voor Content Delivery Network en simpel uitleg hiervoor is dat webhosting feitelijk gaat om één server waarop de bestanden van de website staan. Indien de bezoeker een pagina laad, dan worden alle onderdelen van deze pagina van deze ene server geladen. Stel je bezoeker komt uit Japan en de webhosting wordt gehost in Denemarken. Dan wordt alle onderdelen via Denemarken getransporteerd naar Japan.
CDN wordt ingesteld zodat het tussen zit. Het is dus geen vervanger van de webhosting en -server. Maar fungeert als een tussenstation. Als bijv. Naam.nl geladen wordt, wordt eerst de CDN server aangeroepen en die haalt de data van de webserver. Maar de CDN server staat over de hele wereld en is heel gespreid. In drukke landen staan er zelfs meer CDN servers. En wat CDN server doet is dat wanneer een onderdeel al geladen is, hij niet meer van de webserver laad, maar via één van de CDN servers die dichter bij de bezoeker staat. Bijvoorbeeld in mijn voorbeeld een CDN server in Japan. Waardoor onderdelen van de webpagina zoals foto's, css style bestanden, JavaScripts bestanden en wat je maar kunt denken wat identiek blijft, geladen wordt via de CDN server die in Japan staat.
Maar diverse CDN dienstverleners bieden (vaak tegen betaling) extra service. Wanneer een pagina geladen wordt met een jpg foto, dat zij niet de jpg variant transporteren, maar zelf een eerder omgezette variant webp transporteren. Of zelfs wanneer de foto heel groot is qua breedte en lengte, terwijl de gebruiker een kleiner scherm heeft, de kleiner versie van de foto getransporteerd wordt. En de html code zelfs aangepast geladen wordt, zodat de foto exact hetzelfde op het scherm eruit ziet, maar veel minder data getransporteerd wordt. En de laadtijd heel snel is.
Een CDN server tussen zetten c.q. aanmelden bij een CDN server dienstverlener is zeker hiervoor de oplossing. En dat hoeft niet eens zo duur te zijn. Cloudflare is een voorbeeld van een CDN dienstverlener en de basis is gewoon gratis. Waardoor je met paar klikken kunt instellen dat de website sneller geladen wordt en als beter ervaren wordt. En waardoor je in Google hoger komt qua indexering.
Maar ik kies hier niet voor. En de reden hiervan is dat mijn website door mijzelf geschreven is. Het gaat hier niet om een Wordpress website. En ik ben van mening dat de beste software geschreven wordt op langzame computers. De beste programmeurs komen uit landen waar veel langzame computers zijn. Ik programmeerde vroeger op de Commodore Amiga die slechts 7 mhz CPU had. En elk script ging ik heel lang over nadenken of het niet sneller kon. Ik ben dus ook van mening dat wanneer iemand een BI model heeft gebouwd en zegt "het is wel traag, maar dat komt door de grote hoeveelheid aan data en dat de server traag is", je hem juist een trager server en PC moet geven. Want dan gaat zo iemand nadenken hoe hij het bouwt en hoe het beter kan.
Ik heb juist gekozen om als eerst elk onderdeel heel overwogen aan te passen en te verbeteren. Basis moet goed zijn en dan pas een CDN server tussen zetten. Trouwens één dingetje wat een CDN server niet zo mooi vindt van mijn website, is dat ik onderaan een teller qua aantal bezoekers heb staan. En dat maakt elk geladen webpagina een unieke pagina. En kan dit niet door de CDN server gecached worden. Beter is om de bezoekersaantal via een JavaScript later te laden en aan te vullen qua html code.
Hieronder beschrijf ik wat ik allemaal in de zomer- en herfstmaanden van 2021 gedaan heb om de performace te verbeteren en goede Webvitals scores te krijgen.
Cache instellingen van de webserver aanpassen
Stel een bezoeker is een maand geleden op de website geweest en komt terug als bezoeker. Hij laad een ander pagina, maar wel met eenzelfde template. Dan worden dezelfde style bestanden en JavaScripts geladen. Veel browsers hebben grote cache mappen en kleine bestanden worden lang bewaard. Maar hoelang de browser dit bewaard, is ook afhankelijk van de webserver die aangeeft welk policy m.b.t. cache is. Beste is dat een terug kerend bezoeker niet alles opnieuw geladen wordt. Maar de style bestanden en andere bestanden zoals de banner, JavaScript etc. niet geladen worden maar hergebruikt worden via zijn cache.
Dit geldt natuurlijk niet alleen voor terugkerende bezoekers. Maar ook voor bezoekers die een tweede of derde pagina openen. Beste is dat zoveel mogelijk dezelfde bestanden geladen worden waardoor deze bestanden juist niet geladen worden. En de pagina's van de website sneller gepresenteerd worden. Zo heb ik later ook besloten om af te stappen op de verschillende templates. Zo had het onderdeel Syrische hamster, Blog, etc. allemaal een eigen template map met bestanden. Daarin stonden de style bestanden en banners. Ik heb het nu zo geprogrammeerd dat hij bij het starten van een webpagina instellingen meegegeven worden die leiden tot een ander uiterlijk binnen dezelfde template. Tevens ben ik afgestapt van een logo plaatje bovenin. Dat is vervangen door een tekst en deze tekst heeft een style die heel veel weg heeft van de oude plaatje. Daardoor minder te laden bestanden en is elk webpagina meer hetzelfde.
Qua cache policy heb ik gekozen voor één jaar. Een nadeel is dat wanneer je een style bestand aangepast hebt, een terugkerend bezoeker de oude style bestand krijgt die nog op de device staat. Dit los ik op door in de style bestand een versie nummer te vermelden. Of via het bestandsnaam style-v2.css. Of via timestamp van de css, of wel de datum en tijdstip van de laatste wijziging. En dit komt erachter te staan, of wel styel.css?30042021. Laatste symbolisch want een timestamp bestaat uit een groot getal dat zelfs microseconden te herleiden zijn.
Foto's in ander formaat zodat sneller geladen worden
Als tweede stap heb ik de foto's aangepakt. Alle foto's op deze website staan in hoge kwaliteit jpg formaat. Dit formaat is al wat jaren oud en is blijkbaar niet meer optimaal. Alternatief is webp formaat en geeft ongeveer dezelfde kwaliteit foto, maar is veel kleiner qua bestandsgrootte. Ik heb een script geschreven die de website root uitleest en de foto's automatisch omzet in webp. Tevens qua webserver zo ingesteld dat wanneer een jpg geladen wordt, eerst gekeken wordt of de browser webp aankan (oude browsers kennen dit formaat namelijk niet) en als dit zo is, of er naast jpg een webp variant aanwezig is. En zo ja, dan wordt niet de jpg geladen maar de webp versie.
Op mijn website staan her en der foto's die automatisch verkleind worden. Dit werd realtime gedaan en daarom elke keer verkleind. Dit gebeurde ook in het menu van mijn fotoalbum. Ik heb deze scripts aangepast en nu wordt bij eerste keer omgezet in een thumb versie en deze op de webserver opgeslagen. En de volgende bezoeker krijgt deze versie aangeboden. Eigenlijk iets wat heel logisch is, maar ik nooit als een echt bezwaar gezien heb.
Daarna heb ik de banner boven in aangepast. Op de mobiele versie is de banner niet zichtbaar. Met betrekking tot CSS style is het zo dat ook al bekijk je op de mobiel, alle CSS styles gelezen wordt. En heb je een style "banner" waarbij je mobiel variant geen background-image hebt en bij grote schermen variant wel. Dan wordt dit op de mobiel wel geladen. Dat is zeer inefficiënt en persoonlijk zeg ik dat de browser dit niet moet doen. Een style met een specifieke naam die niet bij een bepaald html element wordt gebruikt, wordt ook niet geladen. Daarom heb ik een JavaScript geschreven die toetst of het om een breed scherm gaat of om een mobiele gebruiker. En als de schermbreedte groot is, dan wordt een element banner vervangen. En op deze wijze wordt de banner alleen geladen als die ook getoond wordt.
Mijn breedbeeld website variant had borders om de website heen. Dit waren transparante borders en ik vond dit zelf geweldig bedacht. Je ziet dit niet ergens anders en was uniek voor deze website. Maar dit waren .png bestanden en moesten ook elke keer geladen worden. Terwijl 80% van de bezoekers dit niet zag. Ik heb besloten om deze banners te verwijderen. Want hoe minder je laad, hoe sneller de website geladen wordt. En deze banners waren al 4 externe bestandjes.
Anders opbouwen van de html code
Je wilt als programmeur precies aan de regels houden en de website html code goed opbouwen. Elk website pagina begint met html-tag (< html >) en dan de head-tag (< head >) en dan body-tag (< body >). Veel programmeurs en website bouwen zoals ik dat ook deed, zetten de externe links naar de stylen en JavaScripts in de head gedeelte.
Maar sta stil bij hoe de browser de website rendert. Alles wat in de head staat, wordt altijd als eerst geladen. De browser gaat ervan uit dat alle stylen die in de head staan, belangrijk zijn en eerst geladen moeten worden en gaat dan kijken welk invloed zij hebben op het renderen van de pagina. Daarom wordt dit ook wel blocking styles genoemd. Want er wordt door de browser nog niets gedaan totdat de browser alle stylen doorgerekend heeft. Een style m.b.t. de footer (onderste deel van de website) die niet in beeld is, wordt dan ook doorgerekend indien je deze style in de head laat.
Beste is om een onderscheid te maken in stylen die noodzakelijk zijn, stylen die iets extra's toevoegen en in stylen die gebruikt worden maar nog niet direct bij eerste deel van de webpagina (bijv. de footer). De noodzakelijke stylen kan je beste in de head laden. Rest van de stylen kan je beter in de body gedeelte laden op het moment dat ze nodig zijn. Of wel de style van de footer bij de footer element.
Ik heb daarom de style bestand in twee delen gesplitst. En de container style en banner style in de head geladen evenals de basis instellingen zoals welke font gebruikt moet worden. Daarnaast heb ik gekozen om de style bestanden niet meer als externe bestanden aan te roepen. Dit omdat de meeste bezoekers van Dwerghamster.nl slechts] één tot enkele pagina's bekijken. En mijn webserver gebruikt compressie waardoor wanneer iemand een pagina oproept de html gecomprimeerd geladen wordt. En dat is heel klein. Ook al is mijn style aantal kb's groot, gecomprimeerd is het maar een paar kb. Daardoor hoeft er minder aantal bestanden geladen te worden. Maar het is wel zo, als je een CDN server gebruikt, je waarschijnlijk beter af bent met losse externe css bestanden.
Dit geldt ook voor JavaScripts. Bij JavaScripts kan je externe JavaScripts als defer laden. De instelling defer betekent dat de JavaScript pas geladen wordt op moment dat de website gerenderd is. En niet eerder. De link naar de externe JavaScript mag gerust in de head staan. Maar als de JavaScript daar staat zonder defer instelling, dan wordt deze door de browser direct geladen en uitgevoerd. Indien je JQuery gebruikt, dan kan je dit niet als defer laden indien je inline JQuery JavaScript gebruikt. Zo gebruik ik Jquery en dat is niet handig (en is iets wat ik later wil aanpassen). Wat ik heb gebouwd is een JavaScript cache binnen mijn scripts. En dat alle JavaScripts onderin de body (en dus niet in de head) geladen wordt. En daarna komt pas de inline JavaScript.
Als iets niet gebruikt wordt, moet je het ook niet laden
Zoals hierboven de aanpassing m.b.t. de style en de banner beschreven, moet je stil staan wat geladen wordt en wat niet zichtbaar of niet gebruikt wordt. De banner heb ik met een klein JavaScript opgelost. Bij het bouwen van mijn website versie 5 in 2020 had ik dit ook al ingebouwd met betrekking tot de verschillende JavaScripts. Ik heb het zo gemaakt dat je per pagina kunt instellen welke JavaScripts nodig zijn. Maar waar ik geen tijd voor had genomen is om dit per webpagina goed in te stellen. Waardoor veel webpagina's veel te veel ongebruikte JavaScripts laadde. Dat is iets wat Google afkeurt en neemt ook mee in de ranking.
Daardoor was de gemiddelde laadtijd per pagina ook langzaam. Ik heb in juli en augustus 2021 alles beter ingesteld en dat zag je direct terug in de laadtijden die je met Google Analytics ook kunt bekijken.
Dit geldt ook voor fonts met symbolen. Ik maak gebruik van Fontawresome en dat is voor groot deel gratis. Dit zijn allemaal logo's van bedrijven en symbolen die iedereen wel kent. Bijvoorbeeld Facebook logo of symbool Home. Maar door alle symbolen te laden en slechts een paar te gebruiken, zorg je ervoor dat je teveel ongebruikte elementen laad. Ook dit keurt Google af. Wat ik gedaan heb is de font bestand aangepast en laad ik nu alleen de symbolen en logo's die ik daadwerkelijk gebruik. Daardoor is de website compacter en hoeft er minder geladen te worden.
Geen cumulative shifting
Als je mijn website voor de aanpassingen opende, dan zag je bovenin het menu bewegen en zag je ook de Google Ads tussen komen. Mijn website schoof behoorlijk. Daarom heb ik de template geheel herschreven en zodanig gemaakt dat er nauwelijks meer shifting aanwezig is. Bijna niets beweegt. Op één dingetje na, en dat zijn de symbolen van Fontawresome. Want die laad ik later en dat doe ik omdat belangrijker is dat content eerst getoond wordt en dan pas de verfraaiing.
Wat ik onder andere heb gedaan is dat ik de externe font een swap ingesteld heb. Dat betekent dat alle teksten die in deze font getoond worden, niet wachten op het laden van deze font. Maar direct getoond worden. Nadeel is dat ze getoond worden in een ander font waardoor je juist shifting krijgt. Ik heb daarom een tweede font ingesteld die hierop het meest lijkt en deze ingesteld zodat ze eenzelfde hoogte en breedte hebben. Waardoor shifting voorkomen wordt. Dit wordt in vakjagon ook wel "fall back font" genoemd.
De Google Ads zorgen ook voor veel shifting. Om de werkelijke gebruikersgevoel te verbeteren heb ik het zo geschreven dat Google Ads pas na 7 seconden geladen worden. De eerste 7 seconden zie je op mijn site geen ads. Daarmee zorg ik ook dat de ads niet in eerste viewpoort, het zichtbaar gedeelde, zichtbaar zijn.
Na de bovenstaande aanpassingen naast diverse aanpassingen qua template waren de shifting problemen opgelost en is de score van Cumulative Lagse Shifting sterk verbeterd.
First Contentful Paint (FCP) verbeteren
De website Dwerghamster.nl wordt gehost op een server die niet al te snel is. Om de First Contentful Paint, of wel de snelheid dat het eerste iets van de website getoond wordt, te verbeteren heb ik de logo bovenin aangepast. Het is geen plaatje meer, maar puur tekst. En de style hiervan staat wel in de head en zijn zeer beperkt. Daardoor wordt de logo heel snel gerenderd en getoond. De gedachtengang heb ik niet zelf bedacht. Ik kwam een vlog tegen die vertelde hoe CNN dit had opgelost. CNN toont direct hun logo op hun website waardoor hun FCP score heel goed is.
Largest Contentful Paint (LCP)
Dit is een belangrijk onderdeel van de Webvital score. Het gaat hier om de grootste element in de viewpoort die zichtbaar is bij het laden. Hoe ouder de mobiel, hoe kleiner het scherm, hoe minder hierop staat. En de moderne mobiele telefoons zijn langwerpig en staat meer op. Wat je bij mijn website ziet is dat op diverse pagina's eerst een foto wordt en werd geladen. Dan was de foto de grootste element. Soms is het beter de foto iets naar beneden neer te zetten zodat op de mobiel eerst tekst geladen wordt en daaronder de foto staat. Of wel eerste en eventueel de tweede alinea zonder foto. Daardoor wordt de tekst de grootste element en dat laad veel sneller.
Op de hoofd onderdelen van deze website heb ik de foto wel laten staan. Zoals de voorpagina van deze website waar een Wildkleur Russische dwerghamster te zien is. Daar heb ik gezorgd dat via preload de foto eerder wordt geladen dan onbelangrijke onderdelen. Waardoor ook deze pagina een goede LCP score hebben.
Voor webshops is mijn advies om de pagina zodanig in te kleden dat je op de voorpagina een sfeer foto staat die niet al te groot van bestand is en daaronder twee kleiner elementen met een aanbieden. En daaronder de webshop zelf. Daardoor zal de sfeer foto de LCP zijn en bepaald de score. En van artikel pagina's je zo moet maken dat niet het artikel qua foto als LCP gezien wordt. Want veel bezoekers zullen van de voorpagina naar een artikel gaan en terug gaan naar de voorpagina.
First Input Delay (FID)
Als sinds 2019 is de First Input Delay score laag en ik heb er nooit goed bij stil gestaan. First Input Delay betekent de wachttijd tussen de eerste klik van de gebruiker en de reactie van de website. Dat kan het klikken van een link zijn of op het symbool menu om het menu te openen. FID kan traag zijn als er veel JavaScripts geladen worden en gerund worden. Dan voelt de website traag aan. Je kent dit misschien wel, dat wanneer je klik en denkt doet deze website nu iets? Heb ik wel geklikt? Google is van mening dat trage websites niet leuk is voor gebruikers en wil deze websites dan ook minder hoog ranken.
Ook al had ik mijn JavaScripts aangepast, mijn FID score werd niet beter. Ik heb toen gedacht dat het kwam door de foto's en het openen van deze foto's. Na het aanpassen hiervan bleek wederom de FID score niet verbeterd te zijn. Het heeft me heel veel denktijd gekost en veel puzzelen voordat ik begreep waarom de score slecht was. Om de website op een iPad mooi te tonen had ik een meta tag viewpoort aangepast naar 0.88. Het gaat om deze code: < meta name="viewport" content="width=device-width, initial-scale=1.0" >. En waar 1.0 staat, stond bij mij dus 0.88. En dat zorgde voor een zeer slechte FID score. De reden begrijp ik nog niet helemaal, maar ik vermoed dat het komt omdat alle mobiele gebruikers stil staan bij deze viewport instelling en dit doen ze op moment dat de website geladen is. En dat wanneer snel ergens geklikt wordt, de browser nog bezig is met de viewport instelling. Maar... Het zou ook maar zo kunnen dat het een bug is van Webvitalsscore. Want bijna niemand gebruikt een initial-scale instelling van 0.88. Ik heb dat omdat de breedte van de website net te groot is voor een iPad. Maar op dit moment zijn de bezoekers met een tablet device zeer beperkt.
Contrast verbeteren
Omdat Google de website rendert en dan interpreteert, houden zij ook rekening met het contrast. Mijn menu bovenin had een lichtblauwe kleur en de achtergrond kleur was lichtgeel. Bij één van de website testtools kreeg ik een melding te zien dat het contrast niet goed was. Ik heb daarom de blauwe kleur wat donkerder gemaakt. Dit is iets wat nog niet in de Webvitalsopgenomen is, maar persoonlijk verwacht ik dat binnen enkele jaren Webvitalsuitgebreid wordt en contrast van website meegenomen wordt als weging van Webvitalsscore.
Performance Dwerghamster.nl eind november 2021
Lange adem, Webvitalsworden gerekend over gemiddelde van 28 dagen
Aanpassingen aan de website is fysiek direct te zien. Maar qua Webvitalsniet. Want webvital score wordt gebaseerd op werkelijke ervaringen en bezoeken en dit over een gemiddelde van 28 dagen. Elke aanpassing duurt dus heel lang om impact te meten. Wel heb je Google Speed Insight tool om de website te testen. Maar dit geeft niet altijd de werkelijke score aan. Juni heb ik de foto's verbetert qua webp formaat en eind juli en de eerste twee weken van augustus heb ik de website herschreven qua software. Maar ik zag medio augustus dat de impact nog niet naar wens was. En heb tot eind september nog aanpassingen gedaan. Pas half oktober zag ik de webvital score sterk verbeteren en pas eind oktober voldeed mijn website aan alle eisen.
Het is ook goed om te weten dat CrUX data, de gemeten daadwerkelijke webvitals, één keer per maand vrij gegeven wordt. Dit is data dat voor iedereen beschikbaar is om in te zien en Google gebruikt dit bij hun ranking. Deze data wordt op de tweede donderdag van de volgende maand vrijgegeven. Qua Google ranking ga je niet direct zien dat webvital verbeteringen leiden tot hoger ranking. Dat kent een lange adem.
Wat ik ook merkte is dat wanneer ik grote aanpassingen deed aan mijn website, dat Google Webmaster Tools wat nu Google Search Console heet, in de war raakt. Google weet niet goed hoe hij dan moet meten of de website aan de Webvitalsvoldoet.
Tot slot
Het is voor mij nu wachten of het verbeteren van de website leidt tot hoger ranking en meer bezoekers. Wat ingeval bereikt heb is dat de laadtijden veel beter zijn en de website mobielvriendelijker is geworden.
Martin Braak
Geschreven ter vastlegging wat ik gedaan heb en om anderen te helpen met het verbeteren van hun websites. Bovenstaande wat ik allemaal m.b.t. mijn website heb gedaan tussen juni en oktober 2021. Dit artikel is in november 2021 geschreven.