Beste sitedealers,

Op dit moment huur ik via Transip een BladeVPS PureSSD met 6 cores, 8192 RAM en een 300GB SSD. Flinke bak al zeg ik het zelf.

Maar om 1 of andere reden is de eerste connectie met mijn website erg traag. Beide GTmetrix en Pingdom geven aan dat het verbinden met de server soms wel tot 3 seconden kan duren. Hoop dat iemand mij kan uitleggen waarom dit exact is? Het betreft de website https://tokyo.nl.

Ik weet dat 1 plugin ook voor een hoop vertraging zorgt (KK stars) die ga ik eraf gooien. Alleen kan ik niet achterhalen waarom de first byte zo langzaam is. GET tokyo.nl kost soms gewoon 3 seconden!

Hoop dat iemand mij hiermee kan helpen! Ik wil er best voor betalen mocht dit nodig zijn als het een ingewikkelt verhaal is.

Bedankt!

Hi,

Heb hetzelfde gehad bij TRANSIP. Het werkte eerste als een trein maar op een gegeven moment één bak ellende. Omdat het niet managed is mag je het lekker allemaal zelf uitzoeken.
Ik ken je helaas niet verder helpen maar wellicht dat iemand wel goede suggesties heeft ;)
Wou alleen mijn soortgelijke ervaring even delen.

Gr. Joachim

Wanneer het om optimalisatie van website, plugin of server gaat zou je eens advies in kunnen winnen bij Stijn Belmans op sd. Hij heeft voor mij ook diverse problemen van deze aart bekeken, advies uitgebracht en geholpen.

Ik zie in insights al veel optimalisaties die makkelijk te doen zijn, caching en afbeeldingen optimaliseren bijvoorbeeld. Als je hulp nodig hebt mag je me altijd een pm sturen.

Een vps van 6 tientjes is niet echt duur te noemen. Je kunt dan wel ruiken dat érgens op ingeleverd is. (SSD zegt niet zoveel als er nog 20 andere vpssen over dezelfde lijn gaan tenslotte), maar het storagesysteem zal in dit geval wel het traagste zijn. Zou je eens kunnen testen. (hdparm, ioseek)

Ook kun je eens kijken naar je 36 javascripts en 14 stylesheets die allemaal niet te cachen zijn.
Of de server eens updaten want zo te zien gebruik je een PHP versie die al 1,5 jaar end-of-life is, dus dat zal met de rest ook wel zijn. Kans is dus ook groot dat er nooit iets aan optimalisatie van de server is gedaan. (memcache, tmpfs, etc..)

@ Joachim, thanks! Ik merk het helaas ook de laatste tijd...
@ Kevin, als ik er niet uitkom ga ik hier zeker werk van maken bedankt
@ Granis, caching heb ik even uitgezet zodat iedereen wat makkelijker kan testen! Optimalisatie van afbeeldingen is minimaal en zou niet zoveel vertraging op moeten leveren. Het gaat vooral om de first byte hier!

@john, voor 1 website van 200 pagina's vind ik het best een flinke server! Maar je hebt gelijk al die javascripts en stylesheets blokkeren een hoop. Er is inderdaad weinig aan server optimalisatie gedaan, ben helaas niet zo technisch. Maar de PHP versie zou ik wel moeten kunnen update zelf. Is dit denk je het probleem van de slome first byte?

Origineel gepost door RdeBoer

@john, voor 1 website van 200 pagina's vind ik het best een flinke server! Maar je hebt gelijk al die javascripts en stylesheets blokkeren een hoop. Er is inderdaad weinig aan server optimalisatie gedaan, ben helaas niet zo technisch. Maar de PHP versie zou ik wel moeten kunnen update zelf. Is dit denk je het probleem van de slome first byte?

Nou, ik snap dat het duur lijkt, maar er zit veel van dat bedrag in cpu/ram natuurlijk. Gangbare prijs is gemiddeld 5 euro per cpu core en per GB ram. Dus érgens moet op ingeleverd zijn.
PHP 7.x is grofweg 2 keer zo snel dan php 5.6, dus met je huidige 5.5 zal dat meer kúnnen zijn. (dat zegt niet direct dat je site ook 2 keer zo snel wordt)
Kijk ook naar je database (mysql of mariadb). Als die zijn zooi niet fatsoenlijk kan cachen, dan kan dat al vaak voor serieuze performance issues zorgen. Je hebt genoeg ram dus, wat tweaken zou best mogelijk zijn.
Voor wp heb je bv nog een plugin om query parameters te verwijderen. (Dat zijn die ?ver=1.2.3 etc achter je ja/css urls). Zonder '?' in de url is dit allemaal beter te cachen. Dat levert weinig op voor je eerste hit, maar wel substantieel voor alle volgende requests.

Een andere optie is om je plugins uit te schakelen en stuk voor stuk weer aan te zetten. Dan kun je achterhalen welke plugins de oorzaak zijn dat de boel opeens erg traag wordt. Deze kun je dan vervangen door betere of anders implementeren.

ALs ik http://www.bytecheck.com/results?res...%2Ftokyo.nl%2F vergelijk met http://www.bytecheck.com/results?res...2F%2Fwww.nu.nl dan duurt 'wait' erg lang. Je server geeft dus pas laat antwoord. Geen idee wat daarvan de oorzaak kan zijn. Dat zal je zelf moeten uitzoeken. Geeft je website / apache pas laat antwoord, zit het in de verbinding? Hoe lang duurt het voordat je een plain html file via deze test doet.
Is het dan wel snel?
Zo ja --> kijk naar je website, php, apache, mysql setup etc. Is alles up to date. Zijn al genoeg ideeen hierboven neergezet.
Zo niet --> dan is er iets in de verbinding wat niet goed zit.

Dus testen testen, debuggen en kijken waar het probleem zit.

Ik kwam laatst deze partij tegen: Cyberfusion. Heb geen ervaring met hen maar zie dat zij Managed pakketten aanbieden voor TransIP servers.

@John, ik heb PHP en mijn hele server weer up2date gemaakt. Hierdoor merk ik wel iets verbetering. Caching staat ook weer aan dus dat moet ook schelen bij vervol hits. Daarnaast ook de plugin erop gezet die je aanraden. Thanks daarvoor.

Ik weet dat 1 plugin zeer veel speed sloopt alleen die kan ik op dit moment nog niet weghalen maar dat zal in de toekomst wel gebeuren.

Verder blijft die first byte zo mega langzaam. Enig idee hoe dat kan?

Greets,

Zoals eerder al gezegd is, test de TTFB met een kale html pagina die niet door wordpress wordt gemaakt. Gewoon een kleine .html dus.
De speed die je dan ziet is wat maximaal haalbaar is op je server.

Check ook met iets zoals mysqltuner.pl of je nog e.e.a. aan je mysql instellingen kunt verbeteren.

Drop ook gewoon je plugins eens en kijk wat je ttfb dan is. Elke plugin sloopt over het algemeen een beetje van je speed af en soms zijn het gewoon 1-2 plugins die er veel vanaf slopen. Op de bijbehorende forums kun je dan vaak wel wat issues en oplossingen vinden.

Een iets ingewikkelder oplossing kan zijn om bv. de apache module mod_pagespeed te installeren. Die module probeert een stuk of 40 optimalisaties uit (van image resizen/optimaliseren tot het minifyen en js/css samenvoegen). Nadeel van mod_pagespeed is wel dat het some websites breekt, juist vanwege het samenvoegen van js files of omdat ie js naar de footer verplaatst e.d. Voordeel is dan wel dat je dat soort specifieke optimalisaties kunt deactiveren en alsnog profiteren van de rest. Er gaat wel wat tijd in zitten voordat je dat goed hebt, maar het resultaat kan verbazingwekkend zijn.

Misschien ook ff minifier aanzetten. Verder zie ik geen gecacheste versie. Site laat wel snel. Maar ik zit op glasvezel dus weet niet of dat uitmaakt.

Bedoel je dit met vertraging van 1e bit? Een vertraging door 2 redirects:
http://www.tokyo.nl - 301 redirect -> https://www.tokyo.nl/ - 301 redirect -> https://tokyo.nl/


Verder:
a. 3-4x wordt wp-admin/admin-ajax.php aangeroepen -> werk je niet met meerdere mensen tegelijk aan je website? Zet dan wp hearbeat uit. Je gebruikt dan veel minder resources. Onze ervaring is dat we op 1 server van meer dan 30 processen per 24 uur terug gingen naar gemiddeld 6!

Heb niet getest of dit het laden van een Wordpress website versnelt, m.a.w. of nu minder vaak wp-admin/admin-ajax.php wordt aangeroepen, maar je server is i.i.g niet met onnodige dingen bezig.

b. weet niet of je dit al gedaan hebt, cq. is genoemd, maar zet Pingbacks and Trackbacks uit.

c. Idem xmlrpc.php, want volgens mij is deze ook verantwoordelijk voor een vertraging.

Mijn advies: weg bij TransIP. Verhuis het naar Antagonist, hun servers hebben hele snelle responstijden is mijn ervaring. Neem vervolgens een abonnement bij Cloudflare voor 25$ per maand. Cloudflare resolved je DNS, biedt bescherming voor DDoS aanvallen, bespaart bandbreedte door caching en beveiligt je website met een Web Application Firewall.

Verder: regel je caching met een plugin zoals WP Rocket en zorg dat alleen de nodige javascripts geladen worden op iedere pagina d.m.v. Gonzales.