Nieuwe website + forum erg lange laadtijd - Softwareontwikkeling

zondag 11 februari 2018 20:40

Acties:

0 Henk 'm!

Topicstarter

Vorig weekend heb ik mijn website (maar vooral forum) kunnen migreren naar WordPress. Sinds WordPress hier op draait, met alleen nodige plugins, is de website erg traag geworden.

Home is in vele gevallen snel maar schommelt ook. De meeste pagina's hebben 3 tot 5 sec nodig - volgens Google. Dit is teveel.

Ik zou dit graag willen verbeteren, maar weet niet zo goed waar te beginnen. De url waar ik het over heb is (*snip*)

Hoop dat jullie mij op weg kunnen helpen. Als jullie vragen hebben over instellingen dan hoor ik dat graag.

[ Voor 1% gewijzigd door Creepy op 12-02-2018 12:24 ]

zondag 11 februari 2018 20:43

Acties:

0 Henk 'm!

Reptile209

- gers -

Je kan met je eigen browser vaak al een profiel van de laadtijd maken (shift-F11 in Chrome dacht ik), dat geeft al wat richting van waar de vertraging zit. Dan kan je gericht naar oplossingen gaan zoeken (te veel media, trage queries, trage server, WordPress, etc).

Zo scherp als een voetbal!

zondag 11 februari 2018 21:05

Acties:

0 Henk 'm!

Stemis

Hi Herr,

Het 1e wat me opvalt is dat het laden van de 1e request al meer dan >2 seconden duurt.
Host je het zelf? of een webhosting pakket afgenomen?

Indien je het zelf host raadt ik je aan om PHP Opcache aan te zetten.
Dit zou de tijden al meer dan 50% moeten reduceren.

Zie hier een link voor Ubuntu 16.04

Het laden van de assets (.js .css) ziet er goed uit alleen duurt het wat langer omdat de 1e pageload zo lang duurt.

Laat even weten als je de OpCache aangezet heb!

[ Voor 41% gewijzigd door Stemis op 11-02-2018 21:15 ]

zondag 11 februari 2018 21:41

Acties:

0 Henk 'm!

Herr Flicker

Topicstarter

Hi Stemis,

Ik ga er morgen gelijk naar kijken. Ik heb een VPS bij transip lopen. Ik laat weten hoe het gaat!

zondag 11 februari 2018 22:00

Acties:

0 Henk 'm!

HollowGamer

Wees voorzichtig met Opcache, zoek even wat daarvoor het beste werkt met WP.

Ik zit nu niet achter de pc, maar hoe heb je de VPS ingesteld? Kan het de redirect van HTTP naar HTTPS zijn? Probeer eens direct met HTTPS.

Check ook meteen de DNS instellingen, genoeg sites die dit voor je doen.

zondag 11 februari 2018 22:00

Acties:

0 Henk 'm!

Flex

Ik zie dat je alleen al 3 plaatjes (Hero-image.jpg, vct-bericht.png, news1.png) in .PNG formaat op je website hebt staan die resp.135.5 kB, 124,3 kB en 323.5 kB zijn. Als je deze kwaliteit terugschroeft naar 75% in .JPG formaat scheelt je dat al de helft met laden, ongeveer 250 kB.

Voeg ook Expire Headers toe in je .htaccess voor je foto's.
Gebruik https://tools.pingdom.com om de snelheid van je website te controleren, en eventueel aan te passen.

zondag 11 februari 2018 22:02

Acties:

0 Henk 'm!

johanmulder

Nederlands Ondertiteld

Je kan ook de Developer Tools in bijvoorbeeld Internet Explorer of Google Chrome gebruiken om je snelheid/latency en grootte van resources te bekijken. Verder zijn er plugins die je verder kunnen helpen, zoals Yslow. Deze geven met scores en verbeterpunten aan hoe je je website kan optimaliseren.

Werkt met: Apple Macbook Pro 16" | Bouwt: Multi-cloud SaaS-oplossingen | Vader | Wereldreiziger | Rijdt: Mercedes GLC

zondag 11 februari 2018 22:06

Acties:

0 Henk 'm!

WeHoDo

Gebruik je binnen WordPress een webbuilder, zoals Themler?

PSN: plexforce (ps4)

zondag 11 februari 2018 22:10

Acties:

0 Henk 'm!

Ramon

Grootste probleem lijkt het laden van de html te zijn:

Afbeeldingslocatie: https://i.imgur.com/fut6peZ.png

Hier gebeurt iets, misschien een lastige query oid, die ervoor zorgt dat de server het veel te druk heeft. Serverside caching kan, maar ik zou eerst kijken of je dit zonder caching kan oplossen. Als dit is opgelost zal de site veel sneller moeten laden. Compressie van afbeeldingen verhogen is ook een optie, maar wel eentje met daadwerkelijk merkbare invloed op het 'genot' en zou ik dus pas als laatste uitweg proberen. Wat je wel zou kunnen proberen is om de CSS- en JS-bestanden samen te voegen, maar zoals gezegd, het grote probleem nu zit hem in de wachttijd aan de serverkant.

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

zondag 11 februari 2018 23:00

Acties:

0 Henk 'm!

DJMaze

Herr Flicker schreef op zondag 11 februari 2018 @ 20:40:
forum ....... WordPress

Herr Flicker schreef op zondag 11 februari 2018 @ 21:41:
een VPS bij transip

Dit is een heel normaal probleem.
TransIP gebruikt SAN en WordPress laad alle bestanden

Je wil een forum, waarom gebruik je dan niet forum software i.p.v. een logge veredelde blog machine?

Ik ontwikkel zelf een CMS met Forum (aangepaste phpBB) genaamd Dragonfly CMS en die laad pagina's gewoon in 50-100ms (PHP-FPM met OPcache).
Maar je kan natuurlijk ook SMF, phpBB of anders gebruiken.

Heb je een valide reden waarom je voor WordPress hebt gekozen, of is het omdat de halve wereld vindt dat je WordPress moet gebruiken?

Maak je niet druk, dat doet de compressor maar

zondag 11 februari 2018 23:16

Acties:

0 Henk 'm!

alex3305

Of je zou bij TransIP kunnen migreren naar shared hosting met Wordpress. Daar zijn de meeste, aanbevolen instellingen al voor je gedaan zodat je daarin zelf niet hoeft te sleutelen. Als het vooral een forum is zou ik inderdaad Wordpress niet per se aanraden. Ook als je weinig ervaring hebt met het optimaliseren hiervan.

Aangezien de code achter de website voor ons niet zichtbaar is, is het erg lastig inschatten waar het e.e.a. misgaat. Je zou met de suggesties zoals beschreven op deze site al redelijk ver kunnen komen.

Verder ziet het er trouwens erg fraai uit. Leuk en fris in elkaar geklust!

zondag 11 februari 2018 23:30

Acties:

0 Henk 'm!

DJMaze

@alex3305 migreren heeft geen zin.
Hij gebruikt Yoast SEO met de GeneratePress Premium theme, dat is zijn probleem (had ik niet genoemd).
Is ook zijn eigen schuld, hij zei "met alleen nodige plugins" en vertelde niet welke plugins.
En aangezien elke plugin in WordPress voor 99% het probleem is....

Maak je niet druk, dat doet de compressor maar

zondag 11 februari 2018 23:35

Acties:

0 Henk 'm!

alex3305

@DJMaze Het is natuurlijk makkelijk om Wordpress te bashen, idem met PHP, Apache of Linux. Dat de TS misschien geen kaas gegeten heeft van de interne werking van Wordpress, soit. Daar moeten we dan mee leven. In ieder geval zie ik hem geen migratie maken naar een ander platform. Wat echter wel reëel is, is het hosten op een platform die al voor hem geoptimaliseerd is. Bijvoorbeeld door middel van shared hosting of een managed vps.

@Herr Flicker In ieder geval lijkt het duidelijk dat je er niet helemaal komt met jouw standaard instellingen. Kun je aangeven welke LAMP stack je gebruikt (versies bijvoorbeeld), welke plugins je in Wordpress hebt hangen en eventueel een pagina of SQL trace doen. Daarbij refereer ik dan even naar mijn eerdere post.

zondag 11 februari 2018 23:39

Acties:

0 Henk 'm!

jant

[ Kun je aangeven welke LAMP stack je gebruikt (versies bijvoorbeeld),

23:34  root@urk ~ # curl -IL https://vespa-ciao.nl
HTTP/1.1 200 OK
Date: Sun, 11 Feb 2018 22:39:01 GMT
Server: Apache/2.2.27 (Unix) mod_ssl/2.2.27 OpenSSL/1.0.1e-fips
X-Powered-By: PHP/7.1.0

[ Voor 21% gewijzigd door jant op 11-02-2018 23:42 ]

Een album per dag; een selectie: https://open.spotify.com/playlist/6s3nNLl8pJpCwLR3LPligA?si=dddc51153b2a49e8

zondag 11 februari 2018 23:40

Acties:

0 Henk 'm!

DJMaze

@alex3305 ik bash WordPress niet, het is een top systeem voor een blog. Ik zou niemand iets anders aanraden als ze willen bloggen of een simpele website van 4 pagina's ofzo.
Goed, er zat een upgrade bugje in 4.9.3 wat WordPress weer ouderwets maakte zoals elke andere website.
Maar dat maakt WordPress niet slechter, alleen gewoon weer zoals de anderen.

Maak je niet druk, dat doet de compressor maar

maandag 12 februari 2018 11:38

Acties:

0 Henk 'm!

Stemis

HollowGamer schreef op zondag 11 februari 2018 @ 22:00:
Wees voorzichtig met Opcache, zoek even wat daarvoor het beste werkt met WP.

Welke risico's zitten hier dan aan vast?
Het is een optimalisatie op PHP niveau, wat je erop hebt draaien maakt niet uit!

HollowGamer schreef op zondag 11 februari 2018 @ 22:00:
Check ook meteen de DNS instellingen, genoeg sites die dit voor je doen.

Kan je dit toelichten?
Ik zie niet in wat DNS instellingen met zijn probleem van > 2s laadtijd van 1e response te maken hebben.

maandag 12 februari 2018 12:02

Acties:

0 Henk 'm!

HollowGamer

Stemis schreef op maandag 12 februari 2018 @ 11:38:
[...]

Welke risico's zitten hier dan aan vast?
Het is een optimalisatie op PHP niveau, wat je erop hebt draaien maakt niet uit!

[...]

Kan je dit toelichten?
Ik zie niet in wat DNS instellingen met zijn probleem van > 2s laadtijd van 1e response te maken hebben.

Opcache dient wel degelijk goed worden ingesteld voor de applicatie.
Sommige hebben bijvoorbeeld wel de save_comments optie nodig, andere weer niet.
En zo zijn er nog genoeg dingen om te checken voordat je het zomaar aanzet.

Misschien kan je deze link eens checken:
https://mxtoolbox.com/Sup...espa-ciao.nl&run=toolpage

Of het invloed heeft op de snelheid van de site is inderdaad waar, maar het kan wel issues veroorzaken.

[ Voor 6% gewijzigd door HollowGamer op 12-02-2018 12:09 ]

maandag 12 februari 2018 12:58

Acties:

0 Henk 'm!

Stemis

HollowGamer schreef op maandag 12 februari 2018 @ 12:02:
[...]

Opcache dient wel degelijk goed worden ingesteld voor de applicatie.
Sommige hebben bijvoorbeeld wel de save_comments optie nodig, andere weer niet.
En zo zijn er nog genoeg dingen om te checken voordat je het zomaar aanzet.

# Edit ik begreep je verkeerd
Je hebt gelijk, er kan het 1 en ander ingesteld worden maar dat is alleen nodig voor tweaking of als je problemen ondervindt.
In principe zou het inschakelen van opcache geen invloud hebben op de werking van de applicatie en een grote performance increase moeten opleveren, ook zonder tweaking.

[ Voor 55% gewijzigd door Stemis op 12-02-2018 13:06 ]

dinsdag 13 februari 2018 10:36

Acties:

0 Henk 'm!

Banpei

Hachiroku on this touge?

Een optie zou kunnen zijn om een NewRelic evaluatie account aan te maken en de monitor te installeren op de vps. Dit zou meer inzicht moeten geven in hoeveel tijd er gebruikt wordt aan elk van de componenten (en eventuele tabellen binnen de database). Zo zou je bijvoorbeeld waarschijnlijk meteen moeten zien of het een database, IO of external content probleem is.
NewRelic heeft ook een Wordpress sectie, en daar kun je ook meteen zien of een bepaalde plugin meer tijd nodig heeft dan anderen.

Installatie is binnen 5 minuten gepiept en de metrics zouden dan binnen 5 minuten zichtbaar moeten zijn.

[ Voor 25% gewijzigd door Banpei op 13-02-2018 10:44 ]

AE86 gevonden! | So what I thought I'd do was, I'd pretend to be one of those deaf-mutes.

dinsdag 13 februari 2018 20:07

Acties:

0 Henk 'm!

Herr Flicker

Topicstarter

@archie2012
https redirect is ingesteld via het .htaccess bestand. Het gebruiken van https in de url balk doet helaas geen verschil merken.

@Flex De 3 images op de front kunnen inderdaad een stuk kleiner. Maar hij doet het op elke pagina - ook waar geen of bijna geen images worden geladen.

@WeHoDo Nee, er is geen gebruik gemaakt van een webbuilder. Enkel een premium thema (GeneratePress)

@Ramon Die wachttijd aan de serverkant - ik denk ook dat het probleem daar zit. Want de css en javascript bestanden an sich zijn niet bijster groot namelijk. Waar kan dit aan liggen, of waar zoek ik het probleem?

@DJMaze Zo te zien ben je niet echt een Wordpress liefhebbern dus

. De keuze is gemaakt voor Wordpress omdat ik als designer (en mijn kompaan) hier het beste mee overweg kunnen. Ik snap dat het veel gebruikt wordt maar dat is niet de reden geweest. Er komen veel updates voor uit en er is ontzettend veel voor te krijgen. En zoals je ziet is de website niet alleen een forum maar zit er nog veel meer aan pagina's bij. Vandaar de keuze.

@alex3305 Migreren zie ik mij inderdaad niet doen. Maar ik wil wel een lijstje maken met de plugins die er op dit moment draaien:
-Akismet anti-spam
-All-in-one activiteiten kalender
-BBP style pack
-BBP topic count
-bbPress
-BP member reviews
-BuddyPress
-BuddyPress Global Search
-Snippets
-Cookie Notice
-Custom login page customizer
-GD bbpress Tools
-Generatepress premium
-Image upload for bbpress
-tinyMCE advanced
-WP Smush
-WP optimize
-Yoast SEO

Wat server en versie informatie:
Apache version: Apache/2.2.27
PHP version: 7.1.0
MySQL version: 5.1.73
CPU Model: Westmere E56xx/L56xx/X56xx (Nehalem-C)
CPU Details: 2 Core (2200 MHz)
Distro Name: CentOS release 6.8 (Final)
Kernel Version: 2.6.32-642.13.1.el6.x86_64
Platform: x86_64

@archie2012 Ik zie je link van mxtoolbox. Krijg 4 errors terug:
1. Bad Glue Detected
2. At least one name server failed to respond in a timely manner
3. Local NS list does not match Parent NS list
4. Open Zone Transfer Detected

Op dit moment weet ik nog niet of het dus aan de Wordpress ligt, de plugins of iets bij de server.
Er draait een testomgeving (op een subdomein) en kan daar wat proberen met plugins uitschakelen. Natuurlijk is de database daar niet zo groot als op de live gang.

dinsdag 13 februari 2018 20:13

Acties:

0 Henk 'm!

Ramon

@Herr Flicker Dat zijn best een hoop plugins. Zijn die echt allemaal nodig?

Ik weet niet of je de beschikking hebt over een MySQL query log (of de mogelijkheid hebt om die aan te zetten) maar daar zal je waarschijnlijk snel kunnen zien wat er traag is.

Check mijn V&A ads: https://tweakers.net/aanbod/user/9258/

dinsdag 13 februari 2018 20:25

Acties:

0 Henk 'm!

alex3305

@Herr Flicker ik weet niet of je inmiddels al wat aangepast hebt. Maar momenteel laadt de website binnen de seconde consequent.

dinsdag 13 februari 2018 20:50

Acties:

0 Henk 'm!

Herr Flicker

Topicstarter

@Ramon
Zijn er inderdaad best wat. Er zijn ook dingen zelf geschreven. Maar door het forum (bbpress) zijn bepaalde plugins wel nodig. Dit schrijf ik niet zelf.

Ik probeer op dit moment de mysql query log te vinden

@alex3305 ik heb niks veranderd, maar ik kom zelf nooit binnen een seconde uit. Het ligt vast ook aan je internet.

Net wel geprobeerd om wat plugins uit te schakelen. Er is 1 plugin (die alle topics aan de rechterkant laadt) die wat vertraging in de zaak brengt. Maar als ik de network tab in de inspector aan heb staan zie ik veel grijze balken (wachten op de server? / stalled)

dinsdag 13 februari 2018 22:01

Acties:

0 Henk 'm!

Solopher

Ik moet als disclaimer toevoegen dat ik niet heel erg veel ervaring heb met Wordpress, ik host wel een Wordpress website die soms veel piek traffic heeft, om dit op te vangen heb ik de gebruiker W3 Total Cache laten installeren.

Waar ik wel ervaring mee heb ik het beheer van linux servers, als ik even kijk naar de software die je aangeeft:
Je kernel is ontzettend oud (2.6.x).
Apache is antiek.
MySQL (5.1.x) is antiek.
Waarom draai je CentOS 6.8?
Ik weet zeker dat het upgraden van je server naar CentOS 7 en een nieuwe versie van MySQL 5.7 ontzettend gaat helpen.

Mocht je MySQL hebben geüpgraded zal ik je table engine ook aanpassen van MyISAM naar InnoDB.
En zoals ook al bovenin wordt aangegeven: Je kunt OPcache installeren, maar dit is in dit geval slechts een kleine verbetering. Aangezien ik niet denk dat je bottleneck in PHP zit maar eerder in MySQL.

woensdag 14 februari 2018 00:15

Acties:

0 Henk 'm!

sig69

Wat server en versie informatie:
Apache version: Apache/2.2.27
PHP version: 7.1.0
MySQL version: 5.1.73
CPU Model: Westmere E56xx/L56xx/X56xx (Nehalem-C)
CPU Details: 2 Core (2200 MHz)
Distro Name: CentOS release 6.8 (Final)
Kernel Version: 2.6.32-642.13.1.el6.x86_64
Platform: x86_64

Wat ik in dit lijstje mis:
-geheugen
-opslag

Roomba E5 te koop

woensdag 14 februari 2018 09:55

Acties:

0 Henk 'm!

TheNephilim

Wtfuzzle

De combinatie bbPress en BuddyPress zal zeer waarschijnlijk een groot aandeel hebben in je probleem. Dat zijn twee vrij grote plugins die heel wat hooks gebruiken/ed. om te werken. Probeer je website eens te testen zonder bbPress en BuddyPress. Gewoon home page laden met én zonder deze plugins geactiveerd.

woensdag 14 februari 2018 10:07

Acties:

0 Henk 'm!

Verwijderd

Als je bezig gaat met snelheidsoptimalisatie binnen WordPress is het vooral een kwestie van 'Trial & Error'. Gebruik daarbij vooral de inspector in Google Chrome (tabblad Network). Zet vervolgens Opcache eens uit. Kijk wat dat oplevert. Geen verschil? Probeer dan eens alle plug-ins de deactiveren, en test opnieuw. Zeer waarschijnlijk levert dit al enorm veel op. Dan weet je 1 ding; er is een plug-in die een duit in het zakje doet. Zet de plug-ins vervolgens per stuk weer aan, en herhaal continue. Het vergt veel tijd, maar helpt wel om de boosdoener uiteindelijk te vinden.

Nog wat tips:

Deactiveer je thema eens, en selecteer eens het standaard thema wat WordPress aanbied. Levert dit positieve resultaten op? Dan is je thema vermoedelijk te zwaar
Maak eens gebruik van Varnish. Je website wordt dan direct ingeladen vanuit het geheugen. Levert vaak positieve resultaten op
Pas je memory_limit aan binnen wp_config.php naar bijvoorbeeld 256M.

Ik ben benieuwd!

woensdag 14 februari 2018 10:16

Acties:

0 Henk 'm!

Solopher

Verwijderd schreef op woensdag 14 februari 2018 @ 10:07:
Pas je memory_limit aan binnen wp_config.php naar bijvoorbeeld 256M.

Dit is een slechte tip, hierdoor kun je later juist performance issues krijgen. Ik weet niet waar het memory_limit nu op staat, maar dit kun je het beste zo laag mogelijk houden.
Probeer het probleem bij de oorzaak op te lossen, i.p.v. dingen als max_execution_time / memory_limit aan te gaan passen.

Varnish is dan wel weer een goede tip, maar dit is vrij lastig te configureren (als je er nog geen ervaring mee hebt).

woensdag 14 februari 2018 10:17

Acties:

0 Henk 'm!

Verwijderd

Solopher schreef op woensdag 14 februari 2018 @ 10:16:
[...]

Dit is een slechte tip, hierdoor kun je later juist performance issues krijgen. Ik weet niet waar het memory_limit nu op staat, maar dit kun je het beste zo laag mogelijk houden.
Probeer het probleem bij de oorzaak op te lossen, i.p.v. dingen als max_execution_time / memory_limit aan te gaan passen.

Varnish is dan wel weer een goede tip, maar dit is vrij lastig te configureren (als je er nog geen ervaring mee hebt).

Mee eens, al biedt het in sommige situaties weleens soelaas. Maar wat je zegt, dat is eigenlijk een pleister op de wond.

donderdag 15 februari 2018 16:13

Acties:

0 Henk 'm!

Banpei

Hachiroku on this touge?

Solopher schreef op dinsdag 13 februari 2018 @ 22:01:
MySQL (5.1.x) is antiek.
...
Mocht je MySQL hebben geüpgraded zal ik je table engine ook aanpassen van MyISAM naar InnoDB.

Waar baseer je op dat zijn tabellen MyISAM zijn? In 5.1 is de default engine wel MyISAM, maar dit hoeft niet het geval te zijn en hij kan ze net zo goed meteen in InnoDB gezet hebben.

Overigens wil een conversie naar InnoDB niet meteen zeggen dat je automatisch betere performance krijgt. MyISAM heeft een veel lagere overhead, en als je niet al te veel concurrency hebt (lees: meer dan 10 connections tegelijkertijd) en niet al te grote tabellen (minder dan 10MB) valt het met de table locks nog best mee. Wordpress databases zijn over het algemeen meestal kleiner dan 10MB en dat past ook met gemak in filesystem cache. Tenzij je het natuurlijk op een SAN draait.

Solopher schreef op dinsdag 13 februari 2018 @ 22:01:
kleine verbetering. Aangezien ik niet denk dat je bottleneck in PHP zit maar eerder in MySQL.

Lekker makkelijk gezegd en totaal ongefundeerd.

Het is waar dat het langzaamste component de bottleneck is, en vaak de database een van de langzame componenten in de keten is. Maar als ik kijk naar mijn eigen (getunede) Wordpress instances heeft PHP hier ongeveer 95% aandeel in de totale tijd die nodig is voor een response. Vandaar dat ik ook eerder aangaf aan de TS op een test account aan te maken bij Newrelic, die hier veel beter inzicht in kan geven.

Mocht het toch de database zijn, kun je altijd een hoop winst halen uit het inzetten van memcache om bijvoorbeeld de wp_options te offloaden.

@Herr Flicker
Zodra er meer inzicht is in waar het probleem zit, kunnen we veel gerichter je helpen een oplossing te vinden.

AE86 gevonden! | So what I thought I'd do was, I'd pretend to be one of those deaf-mutes.