Wij bouwen nu aan
Webshop voor diervoedingsmerkWordPress migratie voor advocatenkantoorWooCommerce koppeling met Exact OnlineElementor website voor architectenbureauMeertalige website voor exportbedrijfWordPress onderhoud voor horecaketenMaatwerk plugin voor vastgoedplatformWebshop met voorraadkoppeling voor retailerWebshop voor diervoedingsmerkWordPress migratie voor advocatenkantoorWooCommerce koppeling met Exact OnlineElementor website voor architectenbureauMeertalige website voor exportbedrijfWordPress onderhoud voor horecaketenMaatwerk plugin voor vastgoedplatformWebshop met voorraadkoppeling voor retailer
White label WordPress voor bureaus →Voor bureaus →
WP Agency
WP Agency

Technisch WordPress bureau voor websites, WooCommerce webshops en koppelingen. Een vast team voor nieuwe projecten en doorontwikkeling, vanuit Amstelveen.

Coachingpraktijk · WordPress optimalisatie

Van 9 naar 2 seconden laadtijd voor een coachingwebsite

Een coachingwebsite op Elementor met 46 plugins en managed hosting achter Cloudflare. Uit de cache laadde alles prima, maar wie de server wél raakte, wachtte 4 tot 12 seconden. Niemand kon zeggen waar die tijd heen ging. Wij hebben het per onderdeel gemeten, op een kopie én op productie. Dat bracht de laadtijd terug én verklaarde waar de rest vandaan komt.

  • Elementor
  • WordPress
  • Optimalisatie
Van 9 naar 2 seconden laadtijd voor een coachingwebsite
Diensten
WordPress performance-audit
Techniek
WordPress, Elementor, PHP-profiling
Klant
Coachingpraktijk (white label)

De klantvraag

Waar gaat die tijd precies heen?

Een pagina uit de cache was snel. Maar na een wijziging, op een stille pagina of ingelogd in de beheeromgeving wachtte je 4 tot 12 seconden. De hostingpartij wees naar Elementor als grootste tijdverbruiker, zonder te kunnen zeggen welke bewerking de tijd kostte. Eerdere pogingen met cache-instellingen hadden geen meetbaar effect gehad. De vraag was dus niet “maak het sneller”, maar: welk onderdeel kost hoeveel, en welke knop moet om?

Onze technische aanpak

Onze oplossing

We hebben een technische audit uitgevoerd op twee sporen. Op een exacte kopie van de site lieten we een PHP-profiler meelopen met een volledig bezoek, zodat we per functie zagen hoeveel tijd erin ging. Op de productieserver lazen we mee in configuratie, database, achtergrondtaken en logs, zonder iets te wijzigen. Dat leverde vier oorzaken op die elk apart onzichtbaar waren. De tijd zat vrijwel volledig in PHP. De opcache van de hosting zat vol, met een trefkans van 1,25 procent, zodat de server bij bijna elk bezoek 4.800 bestanden opnieuw compileerde. Een bug in Elementor schreef bij elk bezoek naar de database en had de instellingentabel laten groeien tot 4,4 GB. En de server lag vol achtergebleven bestanden: een foutlog van 3,7 GB, oude back-ups en ruim 100.000 verlopen taakclaims. De fixes die inhoud en vormgeving niet raken hebben we eerst op de kopie doorgevoerd en gemeten, daarna op productie, per stap met een databasekopie en terugdraaioptie.

Van techniek naar gebruik

Wat we hebben aangepakt

  • PHP-profiling per functie op een exacte kopie van de site
  • Correctiebestand dat de Elementor-bug afsluit en zichzelf uitschakelt zodra Elementor het zelf oplost
  • Element Cache ingeschakeld, na een byte-voor-byte vergelijking van zeven kernpagina's vóór en ná
  • Database en server opgeschoond: instellingentabel van 4,4 GB naar 6,5 MB en 9 GB schijfruimte terug
  • Plugin-audit van 46 plugins: 12 ongebruikt of dubbel, 10 vervangbaar door functies die de site al had
Detail van de website voor Coachingpraktijk, 1Detail van de website voor Coachingpraktijk, 2

Van meting tot verklaring

Ons ontwikkelproces

  1. Exacte kopie van de site en PHP-profiling van een volledig bezoek
  2. Meelezen op productie: configuratie, database, achtergrondtaken en logs
  3. Fixes op de kopie doorgevoerd en bytegewijs gecontroleerd
  4. Gefaseerde uitrol op productie met terugdraaioptie per stap
  5. Vervolgmeting op de server en onderbouwd verzoek aan de hostingpartij

Wat de audit oplevert

Resultaten & impact

  • Laadtijd kernpagina's van 2,2–2,8 naar 1,7–2,2 seconden, met veel minder schommeling
  • Geen schrijfacties per bezoek meer, geen groeiende tabel, geen cron-fouten
  • 9 GB schijfruimte terug en een database die weer past bij de inhoud
  • Hostingpartij vergrootte de opcache naar 512 MB op basis van onze meetgegevens

De constatering die het afmaakt

Waarom de laadtijd rond de 2 seconden bleef hangen

Een vervolgmeting op de server verklaarde het. De PHP-processen van de site werden na ongeveer tien seconden zonder bezoek beëindigd, en de opcache ging elke keer mee. Omdat Cloudflare het meeste verkeer afvangt, was de server bijna altijd zo lang stil. Precies de bezoeker die wél langs de server moest, trof er dus een die alles opnieuw compileerde. Meer geheugen hielp daar niet tegen; de levensduur van de processen is een hostinginstelling. Dat is het verschil tussen “de hosting is traag” en “dit is de knop die om moet”.

Een trage site is zelden één kapot onderdeel. Hier waren het er vier, elk apart onzichtbaar en samen goed voor seconden. Meten per onderdeel is wat gissen in weten verandert.

Ook een complexere websitevraag?

Bespreek wat jouw website moet kunnen.

Vertel ons over je huidige omgeving, de functies die je nodig hebt en je plannen voor de toekomst. We denken mee over de aanpak.

Bespreek je project WordPress audit Terug naar alle projecten