De praktijkhouder van een fysiotherapiepraktijk met drie locaties rond Amersfoort belde met een herkenbaar verhaal. De website was twee jaar eerder gebouwd, zag er goed uit en de teksten klopten. Maar patiënten klaagden dat het online afsprakenformulier “niet werkte”, en een nieuwe medewerker had bij het solliciteren gezegd dat de site op haar telefoon niet wilde laden. Een tweede bureau had een offerte gedaan voor een compleet nieuwe site. Ze wilde eerst weten of dat echt nodig was.

Dit is een case over een website sneller maken zonder het ontwerp aan te raken. De cijfers zijn afgerond, de praktijk is geanonimiseerd, maar de stappen zijn precies zoals ze zijn uitgevoerd.

De situatie: 7,4 seconden op mobiel

De nulmeting deden we met WebPageTest vanuit Londen, gesimuleerd 4G, drie herhalingen, op de homepage en op de afsprakenpagina. De homepage was op mobiel na 7,4 seconden bruikbaar; de afsprakenpagina na ruim 9. PageSpeed Insights gaf een mobiele score van 23. In Search Console stonden alle pagina’s op “slecht”, vooral op LCP.

Het watervaldiagram vertelde het verhaal in één beeld. De pagina laadde 3,8 megabyte aan gegevens, waarvan 2,9 megabyte afbeeldingen. Er werden 94 afzonderlijke bestanden opgehaald. De server deed er gemiddeld 1,2 seconden over voordat hij überhaupt begon te antwoorden. En het afsprakenformulier laadde een externe widget die op elke pagina meekwam, ook waar geen formulier stond.

Belangrijk: de site was gebouwd met een populaire paginabouwer en 34 actieve plugins. Niets daarvan was fout op zich. Het was gewoon nooit op snelheid afgesteld.

De aanpak in vier dagen

We spraken vooraf twee dingen af: geen zichtbare wijzigingen aan het ontwerp, en alles eerst op een staging-kopie testen voordat het live ging. Daarna in deze volgorde:

Dag 1: hosting en server

De site draaide op een gedeeld hostingpakket van een paar euro per maand, met PHP 7.4 en zonder servercaching. De hostingpartij bood binnen hetzelfde account een pakket met PHP 8.2 en LiteSpeed-servercaching aan voor een paar tientjes per maand meer. Na de overstap en het activeren van paginacaching daalde de wachttijd tot de server ging antwoorden van 1,2 seconden naar ongeveer 0,3. Dat was in één klap de grootste winst, zonder één regel op de site aan te passen.

Dag 2: afbeeldingen

Er stonden 610 afbeeldingen in de mediabibliotheek, veel in originele camera-resolutie van 4.000 pixels breed. We hebben alles verkleind naar maximaal 1.920 pixels, gecomprimeerd en naar WebP omgezet, met de originelen in een back-up. De homepage ging van 2,9 megabyte aan afbeeldingen naar ongeveer 400 kilobyte. De grote foto bovenaan kreeg voorrang bij het laden, de foto’s verderop lazy loading.

Dag 3: plugins en scripts

Van de 34 plugins bleken er 9 uit te staan of niets meer te doen: een oude slider, twee sociale-mediaknoppen die niemand gebruikte, een plugin voor een actie uit 2023. Die zijn verwijderd. De externe afsprakenwidget hebben we beperkt tot de twee pagina’s waar hij nodig was. Google Fonts zijn lokaal geplaatst. De overgebleven JavaScript wordt uitgesteld geladen, met een paar uitzonderingen die na testen nodig bleken voor het menu.

Dag 4: controle en livegang

Alle pagina’s doorgeklikt op staging, formulieren getest, afspraakproces tot en met de bevestigingsmail doorlopen. Daarna live gezet, cache geleegd en opnieuw gemeten.

Het resultaat

  • Homepage op mobiel: van 7,4 naar 1,9 seconden bruikbaar.
  • Afsprakenpagina: van ruim 9 naar 2,3 seconden.
  • Paginagewicht homepage: van 3,8 megabyte naar 0,7 megabyte.
  • Aantal bestanden: van 94 naar 31.
  • PageSpeed mobiel: van 23 naar 84. De score interesseerde ons minder dan de seconden, maar de praktijkhouder vond het prettig om te zien.

Zes weken later stonden de pagina’s in Search Console op goed. Het aantal online gemaakte afspraken lag in de twee maanden erna ruwweg een derde hoger dan in dezelfde periode het jaar ervoor. We durven niet te beweren dat dat volledig aan de snelheid ligt; er speelde ook een seizoenseffect. Maar de klachten over het formulier stopten volledig.

Wat deze case leert

Een nieuwe site was niet nodig. Het ontwerp was prima; de techniek eronder was verwaarloosd. Een redesign had waarschijnlijk dezelfde plugins en dezelfde foto’s gekregen en na een jaar hetzelfde probleem gehad.

De volgorde doet ertoe. Eerst hosting, dan afbeeldingen, dan scripts. De grootste winst zat in de eerste twee stappen en die zijn ook het minst risicovol. Wie begint met scripts uitstellen en minify-instellingen, doet het moeilijkste eerst en riskeert een kapotte site voor weinig winst. Meer over hoe u de bottleneck van uw hosting zelf herkent, leest u in dit artikel over hosting als oorzaak.

Meet echt, en meet mobiel. Op de kantoorcomputer van de praktijk was de site altijd “prima” geweest. Alle klachten kwamen van telefoons.

Snelheid moet onderhouden worden. De praktijk heeft na de optimalisatie een onderhoudsabonnement genomen, zodat nieuwe foto’s automatisch verkleind worden en plugins niet weer aangroeien. Waarom een snelle site anders binnen een jaar weer traag is, staat in dit artikel over blijvende snelheid.

Is dit ook op uw website van toepassing?

Deze case is geen uitzondering. De meeste trage WordPress-sites die wij zien hebben dezelfde vier oorzaken: goedkope hosting zonder caching, te grote afbeeldingen, te veel plugins en scripts die overal geladen worden. Het is werk van enkele dagen, niet van weken, en het is zelden nodig om iets zichtbaars te veranderen.

Wilt u weten waar uw site staat? Meet hem op een telefoon met PageSpeed Insights en kijk vooral naar de seconden bij LCP. Boven de vier seconden is er vrijwel zeker flinke winst te halen. Een eenmalige gerichte snelheidsoptimalisatie met een meting vooraf en achteraf, zoals WebMaintor die aanbiedt, is dan een stuk goedkoper dan de offerte voor een nieuwe website die u misschien al in de mailbox heeft liggen.