Tegenwoordig zijn er op internet veel online checks mogelijk waarbij gratis gekeken wordt hoe snel een website laadt zoals bijvoorbeeld: https://pagespeed.web.dev/ Met behulp van zo'n test kun je vaak hele zinnige informatie over je website krijgen - zolang je weet hoe je de test moet uitvoeren en hoe je de rapportage hoort te lezen.

Let er dan bijvoorbeeld op dat zo'n check ook uitgevoerd kan zijn vanaf een canadese server in plaats van een europese zodat er veel meer hops genomen moeten worden voordat de requests op de server aankomen en alles ingeladen is.
Daarnaast geven die websites soms verwarrende omschrijvingen van de oorzaak van eventuele traagheid. Daarom leggen we hier duidelijk uit waar je naar moet kijken wanneer jouw site langzaam laadt of traag reageert.

Of een website snel of traag is is afhankelijk van verschillende factoren. De belangrijkste vijf zijn:
 

• Applicatiecode / database queries die niet efficiënt geschreven zijn
• Teveel data / http-requests per pagina (de website wordt trager als er meer gedownload moet worden)
   Slechte internetverbinding (lokaal) 
• Verkeerde tuning van de server
• Overbelasting / onder-dimensionering van de server

Bij inefficiënt geschreven applicatiecode of database queries moeten er overbodig veel handelingen door de server worden uitgevoerd. Een voorbeeld uit de praktijk:
Op de eerste pagina van een website die traag was stond een lijst met drie willekeurige producten in de spotlight. Om dit te doen werden eerst alle artikelen opgehaald uit de database en daarna werden er m.b.v. een stuk script drie willekeurige uitgekozen. Dit levert natuurlijk veel meer werk op dan nodig en dus vertraging. De applicatie had ook een rechtstreekse MySQL query kunnen doen voor drie willekeurige producten.

Helaas bevatten veel applicaties en zelfgeschreven scripts dit soort inefficiënte code. En ook al zou je twee keer snellere servers gebruiken (die je overigens niet zult vinden) dan nog krijg je zo'n site maar twee keer zo snel. Dat zal nooit genoeg zijn om de website soepel te laten laden. En het lost ook het eigenlijke probleem niet op.

Dan heb je nog de tweede factor: teveel data per pagina. Veel websites gebruiken bijvoorbeeld afbeeldingen die niet in juiste formaat op de server geplaatst zijn. Zodra bijvoorbeeld een 18 megapixel afbeelding van de server opgevraagd wordt en deze vervolgens nog geschaald moet worden tot een 200 pixel brede afbeelding, dan gaat het downloaden van een pagina veel te veel tijd kosten: er moet onnodig veel data opgehaald worden. Schaal afbeeldingen dus altijd tot het formaat en de kwaliteit die nodig zijn. We zien ook vaak websites met 30 stylesheets en 60 scriptfiles die allemaal van de server opgehaald moeten worden. Bundel dat soort bestanden wanneer dat mogelijk is en verklein (minify) javascript en css. Kijk altijd kritisch naar wat bezoekers op de website te zien moeten krijgen en wat je daar allemaal voor aanlevert. 
Een filmpje in de pagina inladen, blurren en dan uitsnijden met wat letters is leuk. Maar een animated gif van diezelfde letters was leuker geweest en vele malen kleiner.

Is dit allemaal al dik in orde maar ervaar je nog steeds een trage website? Het lijkt voor de hand liggend maar een trage internetverbinding of slechte wifi kan daar natuurlijk ook de oorzaak van zijn.
Controleer daarom altijd of andere sites bij andere providers ook traag zijn. Is dat zo, los dan eerst de verbindingsproblemen op. Zit je op wifi, test de snelheid van de website dan eens via een bedrade verbinding.

Omdat webapplicaties nauw samenwerken met verschillende componenten op de server zoals PHP en MySQL of bijvoorbeeld Redis en Varnish is het belangrijk om te zorgen dat alles optimaal samenwerkt. Het optimaal instellen hiervan noemen we ook wel tuning. Heeft je server veel geheugen, dan kan MySQL bijvoorbeeld veel meer data vasthouden en hoeft het niet meer van disk gelezen te worden. En tussenresultaten hoeven minder snel naar disk geschreven te worden om geheugen te besparen.
Wij leveren onze servers standaard op met een goede tuning voor de taak die ze in eerste instantie toebedeeld krijgen. Toch valt hier wanneer alles eenmaal een tijd draait vaak nog winst te behalen. Je kunt ons daarom altijd vragen de tuning van een server (opnieuw) onder de loep te nemen. Belangrijk om te onthouden is wel dat tuning weinig zin heeft wanneer je applicatiecode inefficiënt geschreven is. Kijk daar dus altijd eerst naar.

Een server die onvoldoende resources heeft voor de websites en applicaties die er op draaien raakt overbelast. Is er al gekeken of de code efficienter kan en is de server al netjes getuned dan kun je misschien nog wel wat winst boeken door optimaal gebruik van caching of een CDN zoals CloudFlare, maar als het dan nog steeds niet opgelost is blijft er maar één mogelijkheid over: uitbreiding van de resources. Voor het versnellen van websites en applicaties praten we dan vaak over meer RAM geheugen of meer CPU cores. Inefficiënte code kan overigens tot op zekere hoogte gecompenseerd worden met behulp van ruimere server specs dus je kunt in zo'n geval ook overwegen extra resources af te nemen in plaats van dure programmeurs te betalen.

Voor bijzonder grote omgevingen die niet meer op een enkele server passen kunnen we maatwerkoplossingen bieden. Zo schalen we verder dan een enkele (grote) server aan zou kunnen. Mocht dit aan de orde zijn dan plannen we graag een adviesgesprek met je in!