Waarom is mijn website traag en kost het ons klanten?

Op de laptop op kantoor opent de site gewoon en ziet alles er prima uit. Dan zegt een klant dat het op zijn telefoon eindeloos duurde, of u opent de site zelf op mobiele data op een parkeerplaats en ziet het logo alleen op een wit scherm staan terwijl de rest nog moet volgen. U zoekt op waarom is mijn website traag, draait een gratis snelheidstest en krijgt een pagina vol rode markeringen en jargon die niet zegt wat u nu eigenlijk moet doen.

De gebruikelijke conclusies zijn dat de hosting zwaarder moet of dat de hele site opnieuw gebouwd moet worden. Soms klopt een van beide. Vaker zijn de oorzaken beperkt in aantal, zichtbaar in de browser die u al heeft, en komen de goedkope oplossingen eerst. Een trage site is niet alleen vervelend: een bezoeker die lang genoeg heeft gewacht om zich te ergeren, vult zelden een formulier in, en het is een van de stillere redenen waarom een site wel bezoekers krijgt maar geen aanvragen.

Waarom is mijn website traag: de gebruikelijke oorzaken

Afbeeldingen zijn veel groter dan de ruimte die ze innemen. Foto’s gaan rechtstreeks van de camera of een stockbibliotheek de pagina op, meerdere keren breder dan het vak waarin ze staan, en de browser downloadt het hele bestand voordat hij het verkleint. Het teken: de opbouw van de pagina verschijnt snel, maar de foto’s vullen zich één voor één, en op een telefoon is de site merkbaar slechter dan op een bekabelde desktop.

Te veel plugins, widgets en scripts. Een site op een CMS of een websitebouwer verzamelt door de jaren heen extra’s: een slider, een chatwidget, meerdere analytics-tags, een cookiebanner, een boekingsmodule die niemand meer gebruikt, een automatisch afspelende video in de header. Elk daarvan laadt zijn eigen code voordat de pagina tot rust komt. Het teken: de pagina blijft doorwerken lang nadat de tekst zichtbaar is, knoppen reageren even niet en de lay-out verspringt terwijl onderdelen binnenkomen.

De server reageert traag. Voordat er ook maar één onderdeel van de pagina verschijnt, wacht de browser op de server. Een goedkoop gedeeld hostingpakket, een CMS dat elke pagina bij elk bezoek helemaal opnieuw opbouwt omdat caching uitstaat, of een database die jarenlang is gegroeid: ze laten allemaal hetzelfde zien. Even een leeg wit scherm, en dan alles tegelijk.

De bezoeker zit ver van de server. Een site die in het ene land wordt gehost en vanuit een ander land wordt bezocht, verliest tijd puur door de afstand; thuis voelt hij snel, in het buitenland traag, en thuis merkt niemand er iets van. Het teken: de klachten komen uit één bepaalde regio.

Iets op de pagina houdt al het andere tegen. Een lettertype dat eerst gedownload moet zijn voordat er tekst getekend kan worden, een kaart die op elke pagina is ingebed, een script dat wacht op een externe dienst die een slechte dag heeft. Het teken: de site is de ene dag prima en de andere niet, of blijft leeg tot één bepaald element verschijnt.

Hoe u ziet welke oorzaak de uwe is

Alles hieronder doet u met een telefoon, een laptop en de gratis hulpmiddelen die al in uw browser zitten. Werk de lijst op volgorde af; de eerste controle die misgaat, is meestal uw oorzaak.

1. Open de site op een telefoon via mobiele data, niet via wifi. Klok grofweg de tijd met een horloge, van het tikken op de link tot het moment dat u kunt lezen en tikken, en doe daarna hetzelfde op de laptop. Een telefoon die veel slechter presteert, wijst op afbeeldingen en zware scripts.
2. Let op wat er als eerste verschijnt. Ververs de pagina en noteer de volgorde. Een leeg scherm gevolgd door alles tegelijk wijst op de server; eerst tekst en dan foto’s die druppelsgewijs binnenkomen wijst op afbeeldingen; een verspringende lay-out en knoppen die niet reageren wijzen op scripts.
3. Draai één gratis snelheidstest van een grote zoekmachine of browsermaker en negeer de score. Lees alleen de lijst met grootste bestanden en de voorgestelde verbeteringen: die benoemen in gewone taal te grote afbeeldingen, ongebruikte scripts en een trage serverreactie. Test een dienstenpagina, niet alleen de homepage.
4. Open de ontwikkelaarstools van de browser op het netwerktabblad, ververs en sorteer op grootte. Als de grootste regels afbeeldingsbestanden zijn die veel groter zijn dan de zichtbare foto, heeft u uw antwoord; staan er tientallen scripts van domeinen die u niet herkent, tel dan de plugins.
5. Zet elke plugin, widget en externe tag op de site op een rij en schrijf bij elk wie hem gebruikt en waarvoor. In onze ervaring is de lijst langer dan iedereen had verwacht, en een deel ervan is dood.
6. Controleer het hostingpakket en de caching-instelling. Log in op het hostingpaneel en kijk waarvoor u betaalt en of paginacaching aanstaat. Weet u het niet, dan weet degene die de site heeft gebouwd het wel, en die vraag kost één e-mail.
7. Test vanuit uw andere markten. Vraag een collega in het buitenland dezelfde pagina te klokken, of gebruik een gratis test waarbij u de testlocatie kunt kiezen.

De oplossing, op volgorde

Goedkoopste eerst. In onze ervaring winnen de meeste sites het grootste deel van hun snelheid terug in de eerste drie stappen, zonder herbouw.

1. Verklein en comprimeer de afbeeldingen. Exporteer foto’s op het formaat dat de lay-out werkelijk gebruikt, in een modern webformaat, en vervang de originelen; op een CMS doet een plugin voor afbeeldingsoptimalisatie de hele bibliotheek in één keer. Dit is de meest voorkomende oplossing en kost een middag.
2. Verwijder wat niet wordt gebruikt. Deactiveer en verwijder elke plugin, widget en tag waarvoor niemand een gebruiker kan noemen, voeg dubbele analytics-tags samen tot één, vervang een ingebedde kaart door een statische afbeelding die naar de kaart linkt, en laad alles onder het eerste scherm pas bij het scrollen.
3. Zet caching aan. Met paginacaching levert de server een kant-en-klare kopie in plaats van de pagina voor elke bezoeker opnieuw op te bouwen. De meeste CMS-platformen en hostingpartijen bieden het aan als instelling of als plugin.
4. Los de blokkerende elementen op. Laad lettertypen zo dat de tekst meteen in een vervangend lettertype verschijnt en later wordt omgewisseld, stel scripts uit die niet nodig zijn voor het eerste scherm, en haal video uit de header. Meestal een uurtje van een ontwikkelaar, geen project.
5. Breng de site dichter bij de bezoeker. Een content delivery network (CDN) bewaart kopieën van uw statische bestanden in veel regio’s, zodat een bezoeker in een ander land van dichtbij downloadt. De meeste hostingpartijen en domeindiensten bieden er een aan; verkoopt u over de grens, dan hoort dit op de lijst vóór welke hostingupgrade dan ook.
6. Upgrade de hosting pas als bewezen is dat de server traag is. Blijft het wachten op een leeg scherm bestaan nadat caching aanstaat, dan is het pakket de bottleneck. Stap over op een pakket dat bij het verkeer past, niet op het goedkoopste dat technisch werkt.
7. Bouw de zwaarste pagina’s opnieuw, niet de site. Sleept een template tientallen componenten op elke pagina mee, dan is het vaak genoeg om de belangrijkste landingspagina’s op een lichtere structuur te herbouwen. In onze websiteprojecten is snelheid een opleveringscriterium, en dit is de stap waarin een pagina wordt ontworpen rond wat hij moet doen in plaats van rond wat het thema biedt.

Snelheid bepaalt ook hoe de site wordt gevonden: zoekmachines meten dezelfde wachttijden die uw bezoekers voelen, dus de aanpassingen hierboven horen bij elk eerlijk SEO-werk. En als de site al langere tijd traag is, zijn er stilletjes aanvragen verloren gegaan; vastleggen waar elke aanvraag vandaan komt, en daar beginnen onze CRM- en analyticsprojecten, vertelt u of de ingreep iets heeft veranderd.

Wat u meet

• Tijd tot een bruikbare pagina op een telefoon via mobiele data, elke keer op dezelfde manier met de hand geklokt, maandelijks.
• Paginagewicht en aantal verzoeken voor de belangrijkste landingspagina’s, uit het netwerktabblad, voor en na elke aanpassing.
• Serverreactietijd zoals de snelheidstest die toont, de wachttijd voordat er iets binnenkomt, die moet dalen zodra caching aanstaat.
• Bouncepercentage en ingevulde formulieren op de pagina’s die u heeft aangepast, in uw analytics, een paar weken na de aanpassing vergeleken met een paar weken ervoor.

Waar wij in beeld komen

Een eigenaar met een vrije avond, een uurtje van een ontwikkelaar en een login voor de hosting kan dit allemaal zelf. Wat wij toevoegen is de volgorde: afbeeldingen en dode ballast vóór de hosting, caching vóór een herbouw, en een meting voor en na, zodat de verbetering een feit is en geen gevoel. Wilt u de diagnose liever uit handen geven, dan is een korte briefing met het adres van de site en de pagina’s die er het meest toe doen genoeg om te beginnen.

← Alle artikelen