Bij SmartRanking zijn we altijd op zoek naar nieuwe kennis en inzichten op het gebied van SEO, dit delen we graag! In onze Status 200 Expert Found interviewreeks gaan we met ervaren vakidioten in gesprek. Dankzij hun diepgaande kennis en ervaring krijg je waardevolle inzichten hoe je jouw SEO strategie naar een hoger niveau tilt.
In dit tweede interview spreken we Erwin Hofman, een ervaren PageSpeed consultant die al sinds 2001 bezig is met development en websitesnelheid.
Ik ben Erwin Hofman en werk als onafhankelijke pagespeed consultant en CTO bij RUMvision vanuit Groningen. RUMvision is een pagespeed monitoring tool die werkt op basis van real-time data.
Ik begon ooit (2001) met het bouwen van een eigen CMS (genaamd LightBolt). Rond die tijd werd WordPress ook populairder. Het verschil in snelheid begon op te vallen naarmate WordPress meer features kreeg. Toen ben ik er meer op gaan letten, maar ben ik ook juist meer pagespeed kennis op gaan doen vanuit artikelen.
De opgedane best practices en kennis heb ik vervolgens in ons CMS geïmplementeerd om het snelheidsverschil met WordPress nog groter te maken in ons voordeel. Niet veel later ben ik een eigen webbureau begonnen en uiteindelijk ook de consultancy kant ingerold om al mijn opgedane kennis met andere agencies en merchants te delen.
Dat je met individuele tweaks een website steeds sneller kunt maken, maakt het interessant. Vervolgens heeft een snellere site ook verschillende voordelen. De buy-in blijkt weleens lastig, maar wat veelal vergeten wordt is dat je met pagespeed meerdere vliegen in één klap slaat:
Waar de Core Web Vitals met 28 dagen vertraging komt (vanwege de velddata), vindt de impact op conversie direct plaats. Ik verwoord het vervolgens als volgt: met die conversiewinst zou je bijvoorbeeld hele teams (zoals development, CRO of SEO team) kunnen bekostigen of zelfs uitbreiden. Bovendien bereik je met verbeterde pagespeed iedereen. Zowel mensen die direct op je site komen, als ook vanuit ads, e-mailcampagnes of Google SERP.
Het is absoluut een goede zet geweest. Ik heb het hierboven al geschetst: het raakt meerdere onderdelen van je onderneming. Bovendien zijn meer mensen in meer verschillende rollen bekend geworden met het concept.
Er zijn weleens geluiden of vraagstukken of CO2-uitstoot c.q. de duurzaamheid van een site een ranking factor wordt. Maar feitelijk is het dus al indirect een ranking factor via Core Web Vitals.
Dat doe ik op verschillende manieren:
Ik zal er niet omheen draaien: niet direct nee. Maar dat komt juist weer doordat het één van vele ranking factoren is. En andere onderdelen zwaarder blijven wegen en dus meer aandacht blijft krijgen.
Wat ik wel heb zien veranderen en wat tegelijkertijd de winst is geweest van Google (zoals eerder geschetst), is dat pagespeed tegenwoordig breder gedragen wordt en bij meer stakeholders bekendheid heeft gekregen.
Het interessante is dat de fundamenten van een snelle site geen trends zijn, zoals de fundamenten van SEO in het algemeen ook overeind blijven staan. Bijvoorbeeld qua content: blijf voor de gebruiker schrijven in plaats van te overdrijven. Tuurlijk komen er zaken voorbij als PWAs en SPAs, of Google introduceert een nieuwe metric (zoals INP in maart 2024). Daaromheen probeer ik op LinkedIn dan vooral te informeren, dus echt inspelen op een trend zou ik het niet noemen.
Maar als ik dan toch iets moet noemen: Google is Speculation Rules aan het pushen en dat kan zeker voor statische sites interessant zijn. Tegelijkertijd zijn meer dan 90% van mijn cases echter e-commerce, en dan kan het sneller zijn dat een pagespeed best practice dat voor een statische website werkt, voor een webshop niet werkt of met veel meer nuances komt.
Frameworks. De hoeveelheid JavaScript wordt in frameworks namelijk steeds groter. De eenvoud van het starten met een framework kan er bovendien voor zorgen dat een developer niet meer bekend is met de fundamenten van het web.
Een voorbeeld: doordat browsers blijven ontwikkelen, heb je tegenwoordig steeds minder JavaScript nodig. Zoals bij het lazy loaden van afbeeldingen of zelfs het bouwen van een interactieve image gallery. Wanneer een developer daar niet van op de hoogte is en blind vertrouwt op wat een framework doet, kan het zijn dat een site nog jarenlang onnodige JavaScript blijft serveren.
Dat baseer ik vooral op kennis en ervaring. Een Lighthouse rapport probeert de lezer een indruk te geven van de invloed van een aanbeveling. Echter, Lighthouse (wat een synthetische test is) en Core Web Vitals (wat gebaseerd is op een subset van echte gebruikers) zijn niet hetzelfde. Het gevolg kan zijn dat je dagen besteedt aan een Lighthouse aanbeveling waar je in praktijk niets van terugziet.
Voordat ik daadwerkelijk mijn aanbevelingen deel, begin ik dan ook altijd met het inzichtelijk krijgen van RUM (Real User Monitoring) data. Ik heb dan immers een beeld van de condities als internetverbinding en type toestel, want de doelgroep verschilt altijd per website. Die data combineer ik met de waarde die elk individueel metric laat zien, waarmee ik inschat welke best practice of huidige anti-pattern een hogere prioriteit zou moeten krijgen dan een andere.
Door dit te mengen met mijn kennis van hoe browsers werken en wat in andere cases heeft gewerkt, kan ik mijn aanbevelingen op de juiste manier prioriteren.
Dat heb ik eigenlijk al verklapt: met RUM data. Google’s gratis Core Web Vitals data kan een begin zijn. Maar deze meet niet alles, mist nuances, heeft geen filtermogelijkheden in de data en loopt 28 dagen achter. Wanneer een developmentteam mijn aanbevelingen doorvoert en het marketingteam een week later een blik aan third parties open trekt en los laat op de site, wordt het met Google’s data lastig bewijzen dat onze technische inspanning tot verbetering heeft geleid.
Met real-time RUM data wordt de bewijslast sterker, waardoor voor mij de real-time data onmisbaar is.
Een erg recente case is https://tinylibrary.nl/. Dit is een Shopify shop die het al goed deed, maar ze wilden ruim aan de gezonde groene kant van Core Web Vitals zitten. En publieke data laat zien dat dit is gelukt: https://www.rumvision.com/tools/core-web-vitals-history/tinylibrary.nl/.
Tijdens het performance.now() evenement gaan we nog enkele cases delen, alhoewel specifiek rondom INP verbeteringen.
Erg interessante vraag! Gelukkig niet. Mijn werk ziet er dan ook anders uit dan development (waar ik weleens een live database heb weggegooid) of technisch SEO werk (waar ook ik weleens een noindex heb laten staan). In die rollen kun je dus een hele site ineens plat leggen of uitsluiten van indexatie en zoekmachine SERPs.
Ik kan daar echter geen pagespeed equivalent op bedenken vanuit een pagespeed positie. Het komt overigens weleens voor dat een developmentteam een training niet noodzakelijk acht en mijn aanbevelingen mengt met hun eigen kennis, met fouten tot gevolg. Daar leer ik echter ook weer van.
Dat zijn er misschien twee, beide voorbeelden van standaard aanbevelingen die je in nagenoeg elke SEO blogpost leest:
Ik merk dat men hier te veel focus op gaat leggen. Iedereen begrijpt dat een 10 MB afbeelding geen goed zal doen. Echter, wanneer je hero of productafbeelding 500 kb is, zul je misschien nooit echte UX winst boeken uit het verder optimaliseren naar 250 kb via pogingen als WebP of tinyjpg.com. Zeker met een doelgroep in Nederland of geheel Noord- en West-Europa zullen andere optimalisaties meer verschil gaan maken.
Sinds 2015 (of meer specifiek, sinds dat we HTTP/2 hebben) ligt deze nuance een stuk anders. Dit advies stamt uit het tijdperk waarin een browser maximaal 6 tot 8 bestanden per domein kon downloaden. Je kunt je voorstellen dat dat een flinke beperking en vertraging teweeg brengt.
En alhoewel bol.com nog volgens dat principe hun website inlaadt, wordt het binnen HTTP/2 zelfs afgeraden om je bestanden te combineren (ook wel mergen of bundling genoemd). Een download van één groot bestand duurt langer dan de download van dezelfde hoeveelheid kilobytes, verdeeld over meerdere (en dus per stuk kleinere) bestanden. Daarbovenop zijn er nog enkele andere (client side caching) voordelen van het niet bundelen van allerlei CSS en JS bestanden.
Voel niet de druk om alles binnen SEO te moeten weten. Weliswaar is Core Web Vitals onderdeel van SEO, maar het is tegelijkertijd echt weer zijn eigen niche. En ook een erg technische niche waarbij je net weer andere onderdelen van de werking van een browser moet weten om het goed te begrijpen. Mijn antwoorden op de vorige vraag schetsen al dat er veel nuances kunnen zijn en dat het pagespeed speelveld blijft veranderen.
Wil je toch met pagespeed bezig? Dan is https://web.dev/articles/vitals een goed begin en stel (zoals binnen elk SEO niche) vragen over de resultaten die je ziet. Zo heb ik in mijn beginjaren Lighthouse scores tot in den treure lopen hacken. Daar heb ik toentertijd van geleerd. Weten hoe een browser werkt en omgaat met downloaden en uitvoeren van resources helpt absoluut ook in mijn niche.
Erwin heeft op 21 maart 2024 over de INP gesproken op 301 Groningen Redirected. Zijn presentatie met 35 slides online te bekijken. Als SEO specialist haal je hier waardevolle inzichten uit over wat de INP is en hoe je je websitesnelheid verbeterd.
Met een passie voor SEO en een ongeëvenaarde drive om resultaten te behalen, is Jarik Oosting de drijvende kracht achter SmartRanking. Met meer dan 13 jaar ervaring in het veld heeft Jarik een schat aan kennis opgebouwd, variërend van technische SEO tot complexe migraties. Als oprichter van SmartRanking heeft hij een team van gelijkgestemde SEO specialisten samengebracht die bedrijven helpen hun online potentieel te realiseren.
Zijn academische achtergrond in Informatiewetenschappen aan de Rijksuniversiteit Groningen, met een specialisatie in Natural Language Processing, geeft hem een unieke kijk op de wereld van SEO. Voor Jarik gaat het niet alleen om vindbaarheid in zoekmachines, maar om het delen van kennis en het begeleiden van bedrijven naar duurzaam online succes.