Performance Audit: CompleetFit Nijmegen

Docentweergave (Criteria & Verantwoording)

Zet deze modus aan om de beoordelingscriteria in de tekst te highlighten.

BC 1.1

Je maakt bij de opdracht duidelijk wat er van je gevraagd wordt en welke doelen jouw bijdragen dienen te bereiken.

BC 1.2

Je zet relevante theorie over mensgerichte ontwerpmethodes in om jouw keuzes te onderbouwen.

BC 3.1

Je verzamelt bij je ontwerpactiviteiten methodisch inzichten en beoordeelt de toegevoegde waarde daarvan.

BC 3.2

Je formuleert heldere conclusies waar bruikbare verbetersuggesties uit voortvloeien.

Fase 1 · Probleemdefiniëring

De klantvraag vertaald BC 1.1

CompleetFit Nijmegen — een fysiotherapie- en personal training praktijk — merkte dat hun website "traag aanvoelde". De vraag aan mij: waarom is onze website traag, en wat kunnen we eraan doen?

"Traag" is subjectief. Om dit meetbaar te maken, formuleerde ik drie onderzoeksvragen:

Hoe presteert de website objectief op Core Web Vitals (mobiel en desktop)?
Welke technische factoren veroorzaken de traagheid?
Welke verbeteringen leveren de meeste impact met de minste moeite?

Doelstelling: een datagedreven adviesrapport met geprioriteerde quick-wins die de klant direct kan doorvoeren.

CompleetFit Nijmegen homepage — CompleetFit homepage — above the fold (desktop)

Fase 2 · Theoretisch Kader

Web Performance theorie BC 1.2

Om de audit wetenschappelijk te onderbouwen, werk ik vanuit twee theoretische kaders.

Google Core Web Vitals

Google definieert drie kernmetrieken die samen de gebruikerservaring van een webpagina kwantificeren (Google, 2020):

Largest Contentful Paint (LCP) — hoe snel het grootste content-element zichtbaar is. Doel: <2,5 sec.
First Input Delay (FID) / Interaction to Next Paint (INP) — hoe snel de pagina reageert op interactie. Doel: <100ms.
Cumulative Layout Shift (CLS) — hoeveel de layout onverwacht verspringt. Doel: <0,1.

Critical Rendering Path

Het Critical Rendering Path (Grigorik, 2013) beschrijft de stappen die een browser doorloopt van het ontvangen van HTML tot het renderen van pixels op het scherm. Elke render-blocking resource (CSS, sync JS) vertraagt dit pad. Hoe meer bestanden de browser moet downloaden voordat hij kan renderen, hoe langer de gebruiker naar een wit scherm kijkt.

Het concept Time to First Byte (TTFB) is cruciaal: dit is de tijd tussen het verzoek van de browser en het eerste byte van de server. Een TTFB boven de 800ms wordt als "needs improvement" beschouwd; boven 1.800ms als "poor" (web.dev, 2023).

Fase 3 · Methodische Audit

Drie meetinstrumenten, één waarheid BC 3.1

Ik heb bewust drie verschillende meetmethoden ingezet om triangulatie toe te passen: als alle drie dezelfde conclusie opleveren, is het bewijs sterk.

Instrument 1: PageSpeed Insights

Google's officiële tool voor webprestaties. Ik heb zowel de mobiele als desktop audit uitgevoerd.

Prestaties

100

⚠ Nep — meet 403 pagina

Toegankelijkheid

95

Goed

Praktische tips

96

Goed

SEO

40

🔴 Kritiek — 403 blokkade

Kritische ontdekking: De performance score van 100 is misleidend. De server stuurt een 403 Forbidden naar de Lighthouse-bot, waardoor PSI alleen een lege foutpagina meet. Dit is op zichzelf al een ernstig probleem — het betekent dat Google de website niet kan indexeren.

PSI Mobiel scores — PSI Mobiel — scores (7 apr 2026)

PSI SEO 403 error — SEO detail — 403 Forbidden + crawl blokkade

Instrument 2: Browser Performance API

Omdat PSI de site niet kon meten, heb ik de JavaScript Performance API direct in de browser uitgevoerd. Dit geeft de échte laadtijden zoals een gebruiker ze ervaart.

Desktop vs. Mobiel vergelijking

Metriek	Desktop	Mobiel	Norm
TTFB	5.000 ms	3.636 ms	<800 ms
First Paint	5.192 ms	—	<1.800 ms
DOM Interactive	5.215 ms	3.706 ms	<3.000 ms
DOM Content Loaded	5.257 ms	3.736 ms	<3.000 ms
Full Page Load	5.762 ms	4.170 ms	<3.000 ms

Instrument 3: Network & Resource Analysis

Via JavaScript heb ik alle geladen resources, scripts, stylesheets en afbeeldingen geanalyseerd.

Totaal resources

85

Homepage alleen

Scripts

21

incl. 22 third-party

Render-blocking CSS

10

Vertragen first paint

DOM elementen

739

Divi page builder

Gedetecteerde third-party trackers

Dienst	Type	Geschatte impact
Google Tag Manager	Analytics/Ads	+200-500ms
Facebook Pixel	Tracking	+200-400ms
LinkedIn Insight	Tracking	+100-300ms
Ahrefs Analytics	SEO Tool	+100ms
Trustindex.io	Review widget	+200ms
Google Ads Conversie	Advertising	+200ms

Fase 4 · Bevindingen & Diagnose

Vijf knelpunten, geprioriteerd

Op basis van de drie meetinstrumenten heb ik vijf kernproblemen geïdentificeerd, gerangschikt van meest naar minst impactvol.

#1 Server Response Time (TTFB: 3,6 – 5,0 sec)

Oorzaak: WordPress + Divi page builder + beveiligingsplugin (vermoedelijk Wordfence) op een trage shared hosting omgeving.

Impact: De gebruiker staart 5 seconden naar een wit scherm op desktop — vóórdat er überhaupt iets gebeurt.

Fix: Server-side caching (WP Super Cache of LiteSpeed Cache), CDN (Cloudflare), PHP 8.2+ upgrade. Geschatte winst: −3 tot −4 sec.

#2 Crawler-blokkade (403 Forbidden → SEO 40/100)

Oorzaak: Beveiligingsplugin blokkeert Googlebot en Lighthouse met een 403 Forbidden status.

Impact: De website wordt NIET geïndexeerd door Google. Potentiële klanten die zoeken op "fysiotherapie Nijmegen" vinden CompleetFit niet.

Fix: Wordfence whitelist instellen voor bekende crawlers. Geschatte winst: SEO 40 → 90+.

#3 Ongeoptimaliseerde afbeeldingen (tot 18× te groot)

Oorzaak: Originele uploads zonder resize, geen WebP-formaat, geen lazy loading. Voorbeeld: DSC_2729.jpg is 1920×1280px maar wordt weergegeven op 452×301px — 18,1× meer pixels dan nodig.

Impact: Onnodige data-overdracht; op mobiel met beperkt databudget extra kritiek.

Fix: srcset met responsive afbeeldingen, WebP-conversie, loading="lazy". Geschatte winst: −500KB tot −2MB.

#4 22 Third-Party Scripts

Oorzaak: Google Tag Manager, Facebook Pixel, LinkedIn Insight, Ahrefs, Trustindex en Google Ads Conversie — allemaal zonder gecoördineerde laadstrategie.

Impact: Elke tracker voegt 100-500ms toe aan Time to Interactive.

Fix: Consolidatie via GTM, defer non-essential scripts, consent-based loading. Geschatte winst: −800ms tot −1,5 sec.

#5 10 Render-Blocking CSS Bestanden

Oorzaak: Divi + Divi Pixel + Autoptimize + Trustindex + Adobe Typekit laden elk hun eigen stylesheet. De browser kan pas renderen als alle 10 CSS-bestanden geladen zijn.

Impact: First Contentful Paint wordt uitgesteld.

Fix: Critical CSS inlinen, non-critical CSS deferen, bestanden combineren. Geschatte winst: −200 tot −500ms FCP.

Fase 5 · Conclusies & Aanbevelingen

Van data naar actie BC 3.2

De kern: de website van CompleetFit is niet "een beetje traag" — hij is fundamenteel gebroken op twee niveaus.

Conclusie 1: De snelheidstest liegt

Conclusie

De PageSpeed Insights score van 100 is een vals positief. De beveiligingsplugin blokkeert de Lighthouse-crawler met een 403 Forbidden, waardoor Google alleen een lege foutpagina analyseert. De échte laadtijd — gemeten via de Performance API — is 4 tot 6 seconden.

Quick-win

Whitelist Googlebot in de firewall-instellingen. Dit lost zowel de nepscores als de SEO-blokkade op.

Conclusie 2: Het probleem is de server, niet de frontend

Conclusie

De TTFB (Time to First Byte) is 3,6–5,0 seconden. De norm is <800ms. Dit betekent dat de server er 4× tot 6× langer over doet dan acceptabel is — vóórdat de browser überhaupt begint met het laden van CSS, JS of afbeeldingen. Geen enkele frontend-optimalisatie kan dit compenseren.

Quick-win

Implementeer server-side page caching en overweeg een CDN. Geschatte impact: −3 tot −4 seconden.

Conclusie 3: De site is onvindbaar in Google

Conclusie

Met een SEO-score van 40/100 en een actieve crawl-blokkade is de site effectief onzichtbaar voor zoekmachines. Voor een fysiotherapiepraktijk die afhankelijk is van lokale vindbaarheid, is dit een directe commerciële schade.

Impact

Potentiële patiënten die zoeken op "fysiotherapie Nijmegen" of "personal trainer Nijmegen" vinden CompleetFit niet. Elke dag dat dit niet opgelost is, lopen ze klanten mis.

Beveiligd Datapunt

Performance
Audit.