100 punten bij PageSpeed: wat we daarvoor hebben veranderd
Laadtijd is een rankingfactor, maar de gebruikelijke adviezen helpen zelden. Dit artikel beschrijft wat we aan onze eigen site daadwerkelijk hebben veranderd, welke maatregel hoeveel opleverde en waar we verkeerd zijn afgeslagen.
Het belangrijkste kort
- De grootste enkele winst kwam niet van het verkleinen van bestanden, maar van het vervangen van een bibliotheek van 458 KB door 6 KB eigen code.
- De op een na grootste oorzaak was een half geconfigureerde compressie: de server comprimeerde alleen HTML, niet CSS en JavaScript.
- Een layoutverschuiving met waarde 1 kostte 24 punten – veroorzaakt door nagelaadde CSS die pas na de eerste beeldopbouw aangreep.
- Wat het minst opleverde: beeldformaten. Wat het meest opleverde: dingen weglaten.
De uitgangswaarde was 58 van de 100 op de telefoon. Dat is geen slechte score voor een website met een 3D-effect in de kopsectie, maar wel een score die Google in het mobiele zoeken merkbaar afstraft. Aan het eind stonden er 100 punten op de computer en 98 op de telefoon, bij eveneens 100 voor toegankelijkheid.
Wat volgt is geen algemene checklist, maar het feitelijke verloop – inclusief de plekken waar we het mis hadden.
De uitgangssituatie
| Meetwaarde (mobiel) | voor | na |
|---|---|---|
| Prestatie | 58 | 98 |
| Toegankelijkheid | 95 | 100 |
| Eerste beeldopbouw | 6,1 s | 1,4 s |
| Grootste element zichtbaar | 11,1 s | 2,1 s |
| Totaal overgedragen | 298 KB | 184 KB |
| waarvan JavaScript | 121 KB | 5 KB |
De vijf ingrepen die echt telden
1. De bibliotheek vervangen, niet optimaliseren
De kopsectie toont een deeltjeswolk in 3D. Daarvoor draaide een bekende grafiekbibliotheek – 458 KB na het verkleinen. De meting wees uit dat 51 KB daarvan überhaupt nooit werd uitgevoerd.
De doorslaggevende blik was de vraag hoeveel we daadwerkelijk nodig hebben. Het waren elf bouwstenen: renderer, scène, camera, geometrie, materiaal en een paar hulpklassen. Dat alles is rechtstreeks tegen de grafische interface van de browser te programmeren.
Resultaat: 458 KB werd 6 KB. De weergave is identiek – we hebben dezelfde shaders overgenomen.
2. De compressie stond maar half aan
In de serverconfiguratie stond de compressie op «aan» – maar de regel die aangeeft welke bestandstypen moeten worden gecomprimeerd, was uitgecommentarieerd. Dat is de standaardinstelling van veel distributies. Gevolg: er werd uitsluitend HTML gecomprimeerd.
De grafiekbibliotheek ging dus ongecomprimeerd over de lijn. Na het inschakelen: 1243 KB werd 251 KB. Daarnaast leggen we de gecomprimeerde versies nu voorberekend ernaast, zodat de server niet bij elke aanvraag opnieuw rekent.
Inspanning: twee regels configuratie. Effect: bijna een megabyte per eerste aanroep.
3. De animatiebibliotheek helemaal verwijderen
Voor het invloeien bij het scrollen draaide er nog een bibliotheek, 114 KB. De meting wees haar bovendien aan als veroorzaker van gedwongen layoutherberekeningen – ze vroeg tijdens het scrollen geometrie op en dwong de browser de layout midden in de beweging opnieuw te berekenen.
Vervangen door een IntersectionObserver die enkel een klasse zet. De eigenlijke beweging doet CSS. 114 KB minder, geen herberekeningen meer, ongeveer 40 regels eigen code.
4. Het favicon was 205 KB groot
Een kleinigheid met verbazend effect, omdat het heel vroeg wordt geladen. Vervangen door een SVG-bestand van 6 KB, gemaakt uit het bestaande logo.
Wist je dat?
Voor de weergave in de Google-zoekresultaten heb je niets aan een SVG-favicon – Google accepteert daar alleen rasterformaten, en het beeld moet vierkant zijn met een zijde die een veelvoud van 48 pixels is.
Wie er dus alleen een SVG neerzet, krijgt in het zoekresultaat de grijze plaatshouder in plaats van het eigen logo. Beide naast elkaar opgeven is de juiste weg.
5. Geometrie in het animatieframe opvragen
Een script las bij elke scrollgebeurtenis de totale hoogte van het document uit. Die eigenschap kan de browser niet uit het geheugen beantwoorden – hij moet daarvoor de layout van de hele pagina opnieuw doorrekenen, midden in het scrollen.
De regel die daaruit volgt en die overal geldt: in de gebeurtenis lezen, in het beeld daarna schrijven. Nooit andersom. Sindsdien wordt de paginahoogte één keer gemeten en onthouden, in plaats van zestig keer per seconde opnieuw opgevraagd.
De fout die 24 punten kostte
Om de laatste blokkerende aanvraag kwijt te raken, hadden we het stylesheet gesplitst: het deel dat voor het zichtbare gebied nodig is kwam rechtstreeks in het document, de rest werd nageladen. Een gangbare aanpak.
De knip lag bij een markering in het bronbestand waarachter we het zichtbare gebied vermoedden. In werkelijkheid stonden daarachter de regels voor het logo in de kopsectie, voor de tussenruimtes daaronder en voor het invloeien. De pagina bouwde zich dus zonder die regels op en werd een seconde later rechtgeschoven.
Het resultaat: Cumulative Layout Shift van 1,0 – en daarmee 76 in plaats van 100 punten op de computer. Bijzonder vervelend: lokaal met een afgeremde verbinding was de waarde 0, omdat het stylesheet daar vroeg genoeg aankwam. De fout was alleen op een snelle verbinding zichtbaar.
De les: ofwel het hele stylesheet in het document, ofwel geen enkel. Een gedeeltelijke inbouw veronderstelt dat je precies weet welke regel in het zichtbare gebied nodig is – en dat weet je bij een groeiende pagina nooit blijvend.
Wat weinig opleverde
Voor de volledigheid de maatregelen die in elke handleiding staan en bij ons nauwelijks meetbaar waren:
Beeldformaten. Onze startpagina heeft nauwelijks afbeeldingen – het logo is een SVG-bestand. Waar wel afbeeldingen voorkomen, loont de omzetting natuurlijk; als hoofdhefboom deugt ze alleen bij beeldrijke pagina's.
Lettertypen verder verkleinen. We hosten twee letterfamilies zelf en laden de in het zichtbare gebied benodigde vooraf. Verdere optimalisatie zou mogelijk zijn, maar beweegt de score niet.
Serverlocatie. Vaak aanbevolen, in ons geval irrelevant: de tijd tot de eerste byte lag al op 20 milliseconden. Wie daar al goed zit, wint met een distributienetwerk niets.
De aanpak om na te doen
- Meten voordat er iets wordt gewijzigd. Mobiel en desktop apart, de waarden noteren.
- Het grootste overgedragen bestand zoeken. Bijna altijd is dat JavaScript. De vraag is niet hoe je het verkleint, maar of je het nodig hebt.
- Compressie controleren. Niet óf ze aanstaat, maar voor welke bestandstypen.
- Blokkerende aanvragen tellen. Elk stylesheetbestand in de kopsectie houdt de eerste beeldopbouw op.
- Zonder rem op layoutverschuivingen testen. De ene test die bij ons ontbrak.
- Na elke wijziging opnieuw meten. Anders weet je aan het eind niet wat er heeft gewerkt.
Help me het PageSpeed-rapport van mijn site in een volgorde te vertalen. Wees streng; prijs niets. Mijn meetwaarden: - Mobiel: [score], desktop: [score] - LCP, TBT, CLS per apparaat: [waarden] - Grootste overgedragen bestanden met grootte: [lijst] - Render-blokkerende aanvragen: [lijst] - Meldingen uit het rapport: [tekst invoegen] Over de site: - Hoe hij is gebouwd: [CMS / statisch / bouwpakket] - Is JavaScript nodig voor de zichtbare inhoud? [ja/nee] - Hoe wordt CSS uitgeleverd? [extern / vooraf / deels vooraf] Opdrachten: 1. Wijs elke melding aan een oorzaak toe en zeg welk kengetal ze beïnvloedt – LCP, TBT of CLS. 2. Sorteer de maatregelen op effect per inspanning. Noem bij elke maatregel hoeveel punten ze realistisch beweegt en waarom. 3. Noem de maatregelen uit het rapport die bij mijn bouwwijze praktisch niets opleveren – en onderbouw dat, in plaats van ze gewoon weg te laten. 4. Vraag bij elk groot JavaScript-bestand eerst of het nodig is, voordat je het verkleinen voorstelt. 5. Wijs erop als CSS maar deels vooraf wordt uitgeleverd, en leg uit waarom dat voor CLS slechter kan zijn dan helemaal niet. 6. Noem wat ik na elke wijziging opnieuw zou moeten meten. Verzin geen meetwaarden.
Conclusie
De score zelf is niet het doel – het is een meetwaarde, geen bedrijfsresultaat. Wat telt is de ervaring erachter: een pagina die na 1,4 seconden leesbaar is, wordt door meer mensen gelezen dan een die er zes seconden over doet. Bij mobiele bezoekers via het mobiele netwerk is het verschil groter dan elke tekstoptimalisatie.
De weg daarheen liep in ons geval via één terugkerende vraag: hebben we dit nodig? Vijf van de zes ingrepen bestonden eruit iets te verwijderen, niet iets toe te voegen.
Veelgestelde vragen
Hoe bereik je 100 punten bij PageSpeed Insights?
Bij de meeste websites via drie stappen: het grootste JavaScript-bestand verwijderen of vervangen, de compressie voor CSS en JavaScript daadwerkelijk inschakelen, en layoutverschuivingen wegnemen. Beeldformaten en serverlocatie zijn zelden het knelpunt.
Hoe belangrijk is laadtijd voor de Google-ranking?
Het is een bevestigde factor, maar geen sterke – inhoud en relevantie wegen zwaarder. Het grotere effect is indirect: trage pagina's worden vaker afgebroken, en dat gedrag telt mee in de beoordeling.
Wat is Cumulative Layout Shift en hoe verhelp je het?
De meetwaarde voor elementen die na de eerste beeldopbouw van positie veranderen. Meest voorkomende oorzaken: afbeeldingen zonder vaste maten, nagelaadde stylesheets en lettertypen met sterk afwijkende metrieken. Je verhelpt het door de ruimte vooraf vast te leggen – via breedte- en hoogteopgaven of een vaste beeldverhouding.
Moet je de CSS in de HTML inbouwen?
Bij kleine stylesheets ja, maar dan volledig. Een gedeeltelijke inbouw met nalading van de rest bespaart één aanvraag en levert daarvoor layoutverschuivingen op zodra er een regel in het zichtbare gebied ontbreekt. Bij ons was het 7 KB gecomprimeerd – daarvoor loont de volledige inbouw.
Hoeveel levert het afzien van bibliotheken op?
In ons geval de grootste enkele post: 458 KB grafiekbibliotheek werd 6 KB eigen code, plus 114 KB animatiebibliotheek naar nul. Of dat loont hangt ervan af hoeveel van de bibliotheek je daadwerkelijk gebruikt – de meting wijst ongebruikte JavaScript aan.
Marketing die zichzelf opzet
De bèta van de Studio Engine is open. Reserveer je plek en denk vanaf het begin mee.
Deelnemen aan de bèta →