FlyingPress: zo verbeterde ik mijn websitesnelheid

Ik mat een pagina met Lighthouse. Score: 85. Ik draaide dezelfde meting meteen nog een keer, zonder er iets aan te veranderen. Score: 100.

Vijftien punten verschil, direct achter elkaar — ruimer dan de verbetering die ik van FlyingPress verwachtte. Ik kon dus onmogelijk zien of die plugin iets deed.

Dus bouwde ik eerst een meetmethode die ik wél vertrouw. Dat kostte me drie mislukte pogingen. 🙂

De uitkomst in het kort

Met de standaardinstellingen, op vier pagina’s:

• Je pagina wordt bijna twee seconden eerder zichtbaar. Van 2,7 naar 1,0 seconde. Op alle vier.
• Je pagina is 0,3 tot 1,3 seconde eerder klaar.
• Je Lighthouse-score gaat 6 tot 14 punten omhoog.
• Je servertijd verandert niet. 0,02 seconde, met en zonder plugin.

Geen enkele pagina wordt trager. Dat schrijf ik met nadruk, want in mijn eerste meetronde leek dat wél zo — en dat bleek een meetfout.

Meetmethode

Wat is er mis met PageSpeed Insights?

PageSpeed Insights meet je website één keer. Dat lijkt logisch, maar het is precies het probleem.

Elke meting is een momentopname. Je server is net iets drukker, je netwerk hapert een fractie, je browser doet iets net anders. Daardoor komt dezelfde pagina de ene keer op 1,8 seconde uit en de andere keer op 2,7 — zonder dat er iets veranderd is.

Zolang die schommeling groter is dan wat je probeert te meten, weet je niets. Het is een weegschaal die er twee kilo naast kan zitten: prima om te zien of je honderd of tweehonderd kilo weegt, waardeloos om een dieet te beoordelen.

Die 85 en 100 uit mijn inleiding waren geen uitschieters. Toen ik het systematisch narekende, bleek mijn oude manier van meten op dezelfde onveranderde pagina een spreiding van elf punten te kunnen opleveren. Hoe ik normaal snel een indruk krijg staat in zo meet ik snel en betrouwbaar de laadsnelheid van websites. Voor deze test had ik iets strengers nodig.

Mijn oplossing

Zeven principes, elk voor een specifiek probleem:

1. Meerdere metingen per situatie. Eén meting is een gok. Ik doe er 24 per situatie en gebruik de mediaan. Daarmee kan één uitschieter geen kwaad meer.
2. A/A-ruismeting. Voordat ik iets test, meet ik twee keer dezelfde onveranderde situatie. Alles wat daaruit als “verschil” komt, is meetfout. Dat is mijn ondergrens.
3. ABBA-afwisseling. Niet eerst alles uit en daarna alles aan, maar aan-uit-uit-aan, twaalf blokken lang in één sessie. Wordt mijn server halverwege trager, dan raakt dat beide situaties gelijk.
4. Cache leegmaken tussen elk blok. Mijn site draait achter Cloudflare. Zet je de plugin om zonder de cache te legen, dan krijg je de oude pagina te zien en meet je niets.
5. Een minuut wachten na die purge. Hier ging het bij mij mis, en daar kom ik zo op terug.
6. Alles controleren in plaats van aannemen. Staat de plugin echt om? Is de cache echt leeg? Zit ik op mijn testsite en niet op mijn echte site?
7. Een marge in plaats van één getal. Ik rapporteer “tussen 441 en 449 milliseconde sneller”, niet “445 milliseconde”. Sluit die marge nul niet uit, dan zeg ik dat ik het niet weet.

De fout die alles op losse schroeven zette

Ik wachtte acht seconden na het legen van de cache. Dat leek ruim.

Toen viel me op dat mijn metingen tussen sessies niet klopten: dezelfde situatie gaf de ene keer 1685 milliseconde en de andere keer 2737. Ik ging op zoek, en vond dit binnen één enkel meetblok:

• meting 1: 1679 ms
• meting 2: 1679 ms
• meting 3: 2734 ms
• meting 4: 2733 ms

Halverwege klapt het om. Met exact dezelfde pagina — dat had ik gecontroleerd, acht keer achter elkaar precies 62.762 bytes.

De verklaring: het legen van de cache is niet klaar als het commando terugkomt. De eerste metingen kregen nog bestanden uit de oude cache, de latere de verse. Welke waarde ik kreeg, hing dus af van waar in het blok ik toevallig mat.

Met zestig seconden wachten blijft het stabiel. Alle cijfers in dit artikel komen uit metingen ná die ontdekking. De metingen ervoor heb ik weggegooid — inclusief de conclusie dat mijn homepage trager werd, die er niet bleek te zijn.

Mijn testopstelling

• Vier pagina’s: mijn homepage, mijn artikel over PageSpeed Insights, mijn contactpagina en mijn Gratis WordPress Boost-pagina
• Mobiel, met de standaardsimulatie van Lighthouse: trage 4G en een langzame telefoon
• Staging-omgeving bij Rocket.net in Frankfurt, met Cloudflare ervoor
• 720 metingen, verdeeld over een ruismeting en twee effectmetingen
• Alle instellingen op standaard, niets aangepast

Nulmeting

Eerst mat ik hoe onbetrouwbaar mijn eigen meting is. Twaalf blokken, niets veranderd, maar ik deed alsof ik twee dingen vergeleek.

Het moment dat je iets ziet verschijnen (FCP) bleek muurvast: de marge is 10 milliseconde. Daar kan ik dus zeer kleine verschillen mee aantonen.

Het moment dat je pagina klaar is (LCP) is een ander verhaal: daar is de marge ruim 1200 milliseconde. Binnen een meetblok zit alles binnen 11 milliseconde van elkaar, maar tussen blokken springt het. Dat betekent dat ik LCP-verschillen onder ongeveer een seconde met terughoudendheid moet presenteren.

Meting met de standaardconfiguratie

Toen zette ik FlyingPress aan, zonder één instelling aan te raken.

Het moment dat je iets ziet verschijnen ging op alle vier de pagina’s van ongeveer 2,7 naar 1,0 seconde: homepage 2733 naar 954 ms, artikelpagina 2732 naar 983, contactpagina 2583 naar 958 en de Boost-pagina 2733 naar 973.

Bijna twee seconden winst, op elke pagina, tegen een marge van 10 milliseconde. Dit is het stevigste cijfer uit mijn hele onderzoek.

Het moment dat je pagina klaar is verbeterde ook overal: de artikelpagina van 4135 naar 2820 ms, de Boost-pagina van 3035 naar 2438, de homepage van 2882 naar 2440 en de contactpagina van 2733 naar 2439.

Kijk naar die tweede getallen: 2820, 2438, 2440, 2439. Vier verschillende pagina’s komen met FlyingPress aan allemaal rond dezelfde 2,4 seconde uit. Zonder de plugin lopen ze uiteen van 2,7 tot 4,1 seconde.

FlyingPress legt dus een bodem onder je laadtijd — maar omdat élke pagina zonder de plugin trager was dan die bodem, is het altijd winst.

De scores: homepage 91 naar 98, artikel 82 naar 96, contact 92 naar 98, Boost 90 naar 98.

Wat níét veranderde is de tijd die mijn server nodig heeft om te antwoorden: 0,02 seconde, met en zonder. Mijn hosting was daar al zo snel dat FlyingPress niets toe te voegen had. Hoe ik die basis inrichtte staat in hoe heb ik een razendsnelle WordPress website gemaakt.

Wat doet elke functie afzonderlijk?

FlyingPress heeft 39 knoppen. Ze allemaal met Lighthouse testen zou 39 uur kosten. Dat hoeft ook niet: voor de meeste kun je gewoon kijken of een bestand kleiner wordt of een script verdwijnt. Dat zijn harde feiten waar geen ruis in zit.

Zo controleer je het zelf:

1. Open een incognitovenster — ben je ingelogd in WordPress, dan laadt je pagina de complete beheerdersinterface mee. Bij mij was dat 5,9 MB die een bezoeker nooit ophaalt.
2. F12, tabblad Network, vink Disable cache aan, klik het telefoon-icoontje aan.
3. Meet met de instelling uit, zet hem om, leeg beide caches, en meet opnieuw.
4. Lees onderaan het getal bij transferred. Dat is wat je bezoeker echt binnenkrijgt; resources is de uitgepakte versie en die is bij mij vijf keer zo groot.

Vier instellingen leveren echt iets op:

• Scripts van derden bij interactie (staat uit): −165 kB. Op mijn site stelt dit Google Tag Manager uit tot iemand klikt of scrolt. Bij jou kan dat een heel ander bestand zijn — een chatwidget, advertentiescripts, een reviewtool. Kijk in je Network-tabblad welk extern bestand bij jou het zwaarst weegt; dát is wat deze knop aanpakt. Reken er wel op dat je meetscript pas meetelt zodra iemand iets doet.
• Emoji-scripts uitschakelen (staat uit): −1,4 kB
• Block-editor CSS uitschakelen (staat uit): −854 bytes
• CSS en JavaScript minificeren (staat aan): −229 bytes

Vier zijn een ruil — ze kosten bytes maar leveren iets belangrijkers op:

• Alle JavaScript uitstellen: kost 240 bytes, maar haalt 11 blokkerende scripts weg. Dit is waar die twee seconden vandaan komen.
• Ongebruikte CSS verwijderen: kost 3,4 kB, maar je browser hoeft niet meer op stylesheets te wachten.
• Google Fonts lokaal hosten: kost 538 bytes, maar scheelt een verbinding naar Google.
• Vitals-monitoring: kost 2,7 kB en maakt je site niet sneller — het meet alleen. Of dat het waard is, hangt af van of je dat dashboard gebruikt.

En vijftien instellingen doen aantoonbaar niets op mijn site: lazyloaden, afbeeldingen schalen, YouTube-voorvertoningen, gravatars, lettertypen preloaden, systeemlettertype, elementen lazy renderen, links preloaden, dashicons, jQuery Migrate, XML-RPC, oEmbeds, Heartbeat, object caching en database opschonen.

Dat laatste is geen kritiek op de plugin. Mijn thema doet een deel al, mijn hosting de rest, en sommige functies hebben op mijn site simpelweg niets om te optimaliseren.

Zes instellingen heb ik niet onderzocht: specifieke scripts uitstellen bij interactie, nieuwe uploads automatisch optimaliseren, een aparte mobiele cache, cache voor ingelogde gebruikers, de cache automatisch verversen, en FlyingCDN. Ze staan allemaal standaard uit, en geen ervan verandert wat je bezoeker binnenkrijgt: ze werken aan de serverkant, vragen dat je zelf opgeeft waar ze op moeten letten, of kosten geld.

Meting met de optimale configuratie

Ik zette aan wat nog uit stond en iets opleverde: scripts van derden bij interactie, emoji-scripts, block-editor CSS en het uitschakelen van de RSS-feed. Minificatie stond al aan. De rest liet ik op standaard staan. Bewust: bytes vertellen niet alles. Lettertypen preloaden verandert wanneer iets binnenkomt, niet hoeveel — dat zie je in geen enkele byte-telling terug.

Het resultaat: 174 kB minder op elke pagina.

En verder niets. FCP, LCP en de score bewegen 0 tot 36 milliseconde. Ruim binnen de marge.

Dat klinkt teleurstellend maar is logisch: die 165 kB werd door “Alle JavaScript uitstellen” al buiten het kritieke pad gehouden. Hij downloadde nog wel, maar hield niets tegen. Door hem helemaal niet meer te laden bespaar je die kilobytes — maar het tekenen van je pagina wachtte er toch al niet op.

Die 174 kB is nog steeds echt: minder data voor je bezoeker, minder werk voor zijn telefoon, minder batterij. Alleen meet Lighthouse dat niet.

Conclusie

FlyingPress maakt mijn website aantoonbaar sneller. Bijna twee seconden eerder zichtbaar, op elke pagina, met een marge van tien milliseconde. Dat cijfer staat.

De winst zit vrijwel volledig in één ding: het opruimen van scripts en stylesheets die anders het tekenen van je pagina blokkeren. Elf blokkerende scripts weg, en dat is het. De cachefunctie doet aan mijn kant prachtig werk — 240 milliseconde naar 18 — maar mijn hosting ving dat al af, dus mijn bezoekers merken er niets van.

Vijftien van de negenendertig instellingen doen op mijn site niets meetbaars. Nog vier zijn een ruil. De rest is verwaarloosbaar. Uiteindelijk draait het om een handvol knoppen die het werk doen.

Maar het meest waardevolle dat deze test me opleverde is niet het oordeel over één plugin. Het is dat ik drie keer een fout in mijn eigen meting heb gevonden — en dat ik ze alleen vond omdat ik uitkomsten niet geloofde en ging kijken. Mijn eerste conclusie was dat mijn homepage trager werd. Die was fout. Zonder die controles had ik dat gepubliceerd.

Nuttig gevonden? Help een ander (en mij) en deel dit artikel.

De ruwe meetgegevens van alle metingen in dit artikel staan op GitHub: github.com/WiersmaWeb/Lighthouse — inclusief een toelichting per bestand en de commando’s om alles zelf na te rekenen.