PM mij maar eens 
PM is leuk, maar we zijn wel benieuwd naar de oplossing.
Ja ik heb gekeken en de oorzaken zijn; grote afbeelding die dus gecompressed moeten worden, zelfde met zijn js & css.
De TTFB is enorm sloom (5000+ ms, moet rond de 100 a 500ms zijn). Als dit opgelost is, kunnen we verder kijken.
Veelal komt het door plugins die erg vertragend zijn.
Kijk anders eens in de netwerk-tab van je developer console van je browser, meestal onder de F12 functietoets. Daar zie je de tijdslijn waarin de bestanden waaruit je site bestaat wordt geladen. In mijn tijdslijn staat het HTML hoofddocument zelf 3-5 seconden te stampen.
Ik zou zeggen: brakke HTML? hier zitten onderdelen in die het snel laden / renderen op een of andere manier belemmeren / blokkeren. Dit lijkt overigens structureel, na een page-refresh speelt nog steeds hetzelfde euvel.
EDIT: of liever gezegd: het laden van het HTML-document zelf duurt lang, vraag is hoe dit komt.
Verplaats anders eens een of meer JavaScript bestanden naar de voet van de pagina en/of schakel er een of meer tijdelijk uit net zolang totdat je de boosdoener hebt gevonden en zoek vervolgens hoe deze vertraging in dat specifieke geval kan worden voorkomen.
Daarbij: heeft WP geen caching voor JS/CSS bestanden? Ik zie niet veel externe dingen / CDNs enzo?
Wp heeft caching, moet je zelf via een plugin installeren. De boosdoener is echt de ttfb.
EDIT: het is ook zo dat de TS zijn website tal van connecties maakt; 32 .js bestanden, 22 .css bestanden
De TTFB (Time To First Byte) is geen boosdoener, dit is slechts een tijdsindicatie die het resultaat is van andere zaken.
Wat we moeten zien te achterhalen is de veroorzaker van de hoge TTFB.
Als ik deze benchmark mag geloven (en goed begrijp) duurt de DNS lookup al ~2.5 seconden?
En dan duurt het laden van het HTML-document zelf een eeuw?
Daarin zitten ook nog een hoop grote -en ongecomprimeerde- elementen. Twee JPEGs van over een megabyte? o_O
Toon MeerDe TTFB (Time To First Byte) is geen boosdoener, dit is slechts een tijdsindicatie die het resultaat is van andere zaken.
Wat we moeten zien te achterhalen is de veroorzaker van de hoge TTFB.
Als ik deze benchmark mag geloven (en goed begrijp) duurt de DNS lookup al ~2.5 seconden?
En dan duurt het laden van het HTML-document zelf een eeuw?
Daarin zitten ook nog een hoop grote -en ongecomprimeerde- elementen. Twee JPEGs van over een megabyte? o_O
Precies wat ik zelf ook dacht na wat research... het lijkt wel alsof er meedere templates worden geladen die totaal geen invloed meer hebben op de huidig ingestelde template ook.
Dit zeiden @AarClay en @Ferhat.Remory al min of meer. Het voortraject (lookup + laden van pagina) duren al veelste lang. Je zou dus kunnen kijken:
- waarom lookup zolang duurt (brakke host? iets verkeerd geconfigureerd in DNS ofzo?)
- waarom de pagina zelf zo lang bezig is met laden (wat @AarClay dus zei: plugins?)
En dan inderdaad zoals @Ferhat.Remory aangaf kun je kijkrn of verdere optimalisatie nog/direct nodig is, maar dat zou je natuurlijk altijd kunnen meenemen, ongeacht of dit noodzakelijk is of niet. Als je ergens (een flinke) performance(winst) kunt pakken zou je dat eigenlijk altijd moeten doen.
Heb je nog geen account? Registreer je nu en word deel van onze community!
