Waarom elke seconde laadtijd telt

Wie een pagina opent op een telefoon, in de trein of buiten het dorp, ziet eerst niets. Hoe lang dat duurt, merkt je bezoeker eerder dan jij, want jij opent je eigen site meestal op een snelle laptop.

In dit artikel lees je wat Google onder snel verstaat, wat traagheid kost, hoe snel de sites zijn die wij bouwden, waar de vertraging vaak zit en hoe je je eigen site zelf meet.

Hoe snel moet een website laden?

Google meet de ervaring van een pagina met drie cijfers, de Core Web Vitals. Voor elk cijfer geeft Google een grens voor goed en een grens voor slecht. Een pagina is goed als bij minstens drie van de vier bezoeken (het 75e percentiel) alle drie de cijfers binnen de grens blijven, gemeten bij echte bezoekers en apart voor telefoon en computer.

De LCP is het cijfer dat het dichtst bij “hoe snel laadt mijn site” komt. Daarover gaat de rest van dit artikel. Meer over de drie cijfers lees je in Core Web Vitals in 2026.

Wat kost een trage site?

Een trage site kost op drie plekken. Bezoekers haken af voordat ze iets gezien hebben. Wie betaalt voor advertenties, betaalt ook voor de klik van iemand die vertrekt voordat de pagina er staat. En voor vindbaarheid schrijft Google dat het de Core Web Vitals gebruikt in zijn rankingsystemen, en raadt het aan ze op orde te hebben. Tegelijk schrijft Google dat het altijd de meest relevante inhoud wil tonen, ook als de pagina minder prettig werkt.

Denk aan iemand die een loodgieter zoekt met lekkage in de keuken. Hij opent drie resultaten tegelijk. Wie als eerste een telefoonnummer en een duidelijke knop laat zien, krijgt het telefoontje. De andere twee laden misschien een seconde later goed, maar dan is de keuze al gemaakt.

Hoeveel omzet een seconde precies kost, verschilt per site en per bezoeker. Dat hebben wij niet zelf gemeten, en een vast getal noemen we daarom niet. Wel heb je de snelheid grotendeels zelf in de hand, anders dan veel andere dingen die meewegen.

Hoe snel zijn de sites die wij bouwden?

We meten met dezelfde methode op elke site: een telefoonscherm, een processor die vier keer trager is gemaakt, een trage verbinding en een lege cache, zonder cookies of toestemming. Elke homepage meten we drie keer en we nemen de middelste uitkomst. We meten de tijd tot het grootste stuk inhoud in beeld staat (de LCP). In de tabel staan de sites waarvan de laadtijd op de casepagina staat.

Alle negen blijven in deze meting onder de 2,5 seconden die Google goed noemt. Let op: Google kijkt bij die grens naar echte bezoekers, wij maten in een testopstelling. Een telefoon met een snellere verbinding laadt dezelfde site sneller.

Waarom is de ene site sneller dan de andere?

De techniek telt, maar verklaart niet alles. Ook het gewicht van de pagina en het aantal bestanden verklaren het verschil maar ten dele. Twee voorbeelden, met het gewicht van de homepage zoals op de casepagina staat:

• Sittard Taxi heeft op de homepage een boekwizard in Nuxt: 412 KB in 15 verzoeken. De dienst- en plaatspagina's zijn statische pagina's van zo'n 32 KB HTML.
• Taxi Grou laadt 355 KB in 8 verzoeken, met een aanvraagformulier op de homepage.

Taxi Grou laadt dus minder bestanden en is toch trager. Vaak bepaalt één element bovenaan, zoals een grote foto of een formulier, de laadtijd. Ook een cookiemelding kan het grootste element op het scherm zijn, en dan bepaalt die de LCP in plaats van je eigen inhoud. Let op: de gewichten op de casepagina's zijn gemeten op 24 september 2026, de laadtijden van deze twee sites op 22 oktober.

WordPress is niet vanzelf traag. Daily Phones draait op WordPress en stond in onze meting na 0,94 s in beeld. Of een WordPress-site snel is, hangt af van het thema, de plugins en de beelden.

Waar zit de vertraging meestal?

Trage sites delen vaak dezelfde oorzaken:

• Afbeeldingen die veel te zwaar worden aangeleverd en geserveerd.
• Scripts en lettertypen die het tekenen van de pagina tegenhouden.
• Een stapeling van trackers, plugins, chatknoppen en marketingtools, elk met eigen bestanden.
• Een boekmodule, kaart of video van een andere partij die bij het openen al laadt.
• Hosting die niet past bij het verkeer, of verkeerd is ingericht.
• Geen caching, waardoor elke bezoeker alles opnieuw ophaalt.

Hoe meet je de snelheid van je eigen site?

Je hebt er geen specialist voor nodig. Zo krijg je een eerlijk beeld:

1. Open PageSpeed Insights van Google en vul je adres in. Je krijgt cijfers van echte bezoekers, als die er genoeg zijn, en een testmeting.
2. Kijk in Search Console naar het rapport Core Web Vitals. Dat laat per groep pagina's zien of ze goed zijn, verbetering nodig hebben of slecht zijn, op basis van echte bezoekers.
3. Meet op een telefoon, niet alleen op je laptop. Of zet in de instellingen voor ontwikkelaars in Chrome de verbinding en de processor op trager.
4. Meet drie keer en neem de middelste uitkomst. Eén meting kan toevallig snel of traag zijn.
5. Meet meer dan de homepage. Neem ook een gewone pagina, zoals een dienst of een artikel.
6. Schrijf de datum op. Zo zie je later of een nieuwe functie of foto de site trager maakte.

Hoe lees je de uitkomst?

PageSpeed Insights geeft twee soorten uitkomsten. Bovenaan staan, als er genoeg bezoekers zijn, de cijfers van echte bezoekers over de afgelopen 28 dagen; heeft de pagina te weinig bezoek, dan zie je de cijfers van je hele site. Daaronder staat een testmeting met een score van 0 tot 100. Die score is een samenvatting van één testmeting en handig om problemen te vinden. Voor de Core Web Vitals kijkt Google naar echte bezoekers. Een score van 70 met goede cijfers van echte bezoekers is dus geen reden voor paniek, en een hoge score met slechte cijfers van echte bezoekers wel een reden om verder te kijken.

Is de LCP te hoog, kijk dan eerst welk element het grootste is. Meestal is dat een foto of een kop met een eigen lettertype. Hoe je een trage site sneller maakt, lees je bij website sneller maken.

Waarom meten op een telefoon?

Een laptop op kantoorwifi is de gunstigste situatie die er is. Je bezoeker zit vaak op een telefoon, met een tragere processor en een verbinding die wisselt. Google houdt telefoon en computer daarom ook apart bij. Een site die op je laptop meteen staat, kan op een telefoon met een trage verbinding seconden langer leeg blijven. Meet dus in de situatie van je bezoeker, niet in die van jezelf.

Wat kun je zelf doen aan een trage site?

Niet alles vraagt een bouwer. Deze stappen kun je vaak zelf zetten of gericht vragen:

• Verklein je foto's. Een foto van je telefoon is vaak veel groter dan het scherm ooit toont. Zet foto's op de maat waarop ze getoond worden, in een modern formaat.
• Ruim scripts op. Loop na welke trackers, pixels en tools er op je site staan. Wat niemand meer gebruikt, kan eraf.
• Laad zware onderdelen pas als ze nodig zijn. Een kaart, video of chatknop hoeft niet te laden voordat iemand erop klikt.
• Beperk lettertypen. Elk extra lettertype en elke extra dikte is een bestand meer.
• Kijk naar je hosting. Staat je site op een server die langzaam antwoordt, dan helpt de rest maar ten dele.

Hoe bouwen wij snelheid in?

Snelheid achteraf repareren is dweilen. Daarom zit het bij ons in het fundament: onze sites in Astro zijn statisch, en onze applicaties in Nuxt bouwen de pagina op de server op, zodat de bezoeker direct een opgebouwde pagina krijgt in plaats van een leeg scherm dat zich nog moet vullen.

• Beelden in moderne formaten, op de juiste maat en pas geladen als ze in beeld komen.
• Alleen laden wat de pagina echt nodig heeft.
• Lettertypen slim geladen, zonder tekst die opeens van vorm wisselt.
• Caching vanaf de eerste dag ingericht.
• Een performance-budget dat vanaf het begin van de bouw meeloopt.

Wat vraag je aan je bouwer?

Laat je een site maken, vraag dan vooraf naar snelheid, niet achteraf:

• Hoe snel laadt een vergelijkbare site die jullie bouwden, gemeten op een telefoon, en op welke datum?
• Welke scripts van andere partijen komen erop, en waarom?
• Hoe gaan jullie om met foto's die wij later zelf toevoegen?
• Meten jullie de snelheid voor de oplevering, en krijgen wij de uitkomst te zien?
• Wie let erop dat de site snel blijft na de lancering?

Hoe hou je een snelle site snel?

Een snelle site wordt vanzelf weer traag als niemand oplet: elke nieuwe functie, tracker of foto knabbelt eraan. Daarom hoort meten bij onderhoud. In ons onderhoudsabonnement kijken we periodiek hoe snel je site laadt en of er te zware afbeeldingen bij zijn gekomen. Kleine dingen lossen we meteen op.

Wanneer dit niet geldt

Onze cijfers zijn eigen metingen van de homepage, in een testopstelling, per site op één dag (22 oktober, 24 oktober of 3 november 2026). Ze zijn geen gegevens van echte bezoekers uit Google, en ze zijn niet gelijk aan de uitkomst van PageSpeed Insights, dat anders meet. In de tabel staan alleen de sites waarvan de casepagina een laadtijd noemt.

Wat we niet weten: we hebben niet gemeten hoeveel extra aanvragen of omzet een snellere site oplevert. Hoe snel een pagina reageert op een tik (INP) meet onze testopstelling niet, en het verspringen zien we alleen tijdens het laden. En een snelle homepage zegt niets over een pagina met een zware kaart of video; meet die apart.

Veelgestelde vragen

Benieuwd wat het voor jou wordt? Stuur ons het adres van je site, dan vertellen we waar de tijd zit. Meer over hoe we bouwen lees je bij webdevelopment. Je werkt rechtstreeks met Nawid; per project zet hij een vast team van specialisten in.

Bronnen

Geraadpleegd op 3 november 2026.

• web.dev, Web Vitals (grenzen en het 75e percentiel)
• web.dev, Largest Contentful Paint (LCP)
• web.dev, Interaction to Next Paint (INP)
• web.dev, Cumulative Layout Shift (CLS)
• Google Search Central, Understanding Core Web Vitals and Google search results
• Google Search Central, Understanding page experience in Google Search results
• Google, About PageSpeed Insights (28 dagen, gegevens van de hele site)
• Google, Search Console Help, Core Web Vitals report
• Empireyo, Werkwijze (performance-budget) en Webdevelopment (meting voor de livegang)
• Empireyo, cases Basestep, snelrepareren.nl, TaalPro, Atiq Tandartsen, Daily Phones, Ikiz, Sittard Taxi, Taxi Grou en ArtsenPool