Trage wordpress backoffice door hosting?

[Sideburnn]

Beste,
voor een klant beheer ik zijn websites....alleen is inloggen en de backoffice een ramp.
Dit is zo traag...een carrousel aanpassen en plaatsen lukt bijvoorbeeld niet eens.
Ik ben zelf al van provider gewisseld, PC opnieuw geïnstalleerd, vanaf de PC van mijn vouw heb ik hetzelfde probleem, andere routers geplaatst, met WIFI geprobeerd.
Andere WP site geven dit probleem niet...wel de 2 die bij een en dezelfde partij gehost worden.
Ook al een ticket aangemaakt maar die kunnen ook niets vinden.........
Herkent iemand dit probleem en wat was de oplossing?

[Nielzsche]

Sideburnn schreef op donderdag 16 januari 2025 @ 12:43:
Beste,
voor een klant beheer ik zijn websites....alleen is inloggen en de backoffice een ramp.
Dit is zo traag...een carrousel aanpassen en plaatsen lukt bijvoorbeeld niet eens.
Ik ben zelf al van provider gewisseld, PC opnieuw geïnstalleerd, vanaf de PC van mijn vouw heb ik hetzelfde probleem, andere routers geplaatst, met WIFI geprobeerd.
Andere WP site geven dit probleem niet...wel de 2 die bij een en dezelfde partij gehost worden.
Ook al een ticket aangemaakt maar die kunnen ook niets vinden.........
Herkent iemand dit probleem en wat was de oplossing?

Kan mij eerlijk gezegd niet voorstellen dat het aan de host ligt. Ligt het misschien aan de plugins/thema's die gedraaid worden op de Wordpress websites? Ik weet niet of daar bijvoorbeeld een builder gebruikt wordt?

Mijn ervaring is dat dat vaak de bottleneck is.

[njitter]

Dit ligt aan de host die de klant gebruikt. Heeft niks met je eigen pc te maken aangezien alles in de browser draait.

Weet je welke host je klant gebruikt?

[SPee]

Ik zou de developer tools openen in je browser en kijken in de tabjes Netwerk en Performance hoe lang de request erover doen en hoe snel de pagina reageert als je wat probeert te doen.

[Eris]

Installeer de plugin: https://wordpress.org/plugins/query-monitor/ en kijk wat de oorzaak is het kan problemen zijn met plugins die random requests maken naar andere servers en daardoor traag worden

[Sideburnn]

Hi Eris,
ik heb quiry monitor geinstalleerd en krijg deze 2 meldingen....
A = Constant WP_MEMORY_LIMIT already defined
B = Constant DISALLOW_FILE_EDIT already defined

[Eris]

Sideburnn schreef op donderdag 16 januari 2025 @ 13:43:
Hi Eris,
ik heb quiry monitor geinstalleerd en krijg deze 2 meldingen....
A = Constant WP_MEMORY_LIMIT already defined
B = Constant DISALLOW_FILE_EDIT already defined

In je wp-config.php staat hij waarschijnlijk 2 keer in je kan ze veilig negeren. Of even de regelnummer opzoeken die ze weer geven

Je moet kijken naar:



Hoe langer de tijden zijn hoe beter... Als echt richting 1 a 2 seconden loopt kan je kijken wat de oorzaak is.

[blatenja]

Bij mij kwam dit door het niet instellen van object cache. Installeer Redis en kijk of dat verbetering brengt. Moet veelal via SSH en vervolgens de plugin installeren.

[ Voor 20% gewijzigd door blatenja op 20-01-2025 19:05 ]

[jurroen]

Vaak komt dit door een thema/plugin of een combinatie daarvan. Builders zoals Visual Composer zitten met ductape in elkaar - dat kan zeker zorgen voor vertraging in de back-end.

Het allerbeste zou je de problemen kunnen oplossen - maar dat kan een hels karwei zijn waarbij je vrij veel ervaring nodig hebt. Je kunt er ook voor kiezen om de symptomen te beatrijden, door bijvoorbeeld met object cache te werken, wat @blatenja aangeeft. Met Woocommerce wordt het verhaal wel ietwat anders.

De hoster kan vaak ook veel doen, ook al zeggen ze van niet. Maar dat is erg technisch en inhoudelijk. Kort gezegd, zelfs met "WordPress hosting" van een willekeurige boer heb je geen optimale omgeving.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Chorro]

Kan ook zijn dat de gehele website ontzettend traag is door bijv. javascript gerelateerde zaken maar door caching de frontend wel snel reageert. Meeste hostings/cache excluden de wp-admin van de cache, waardoor je juist in de backend dan wel traagheid ervaart.

[RobbyTown]

Het kan ook aan de webhoster zelf liggen.

Met WordPress herken ik dit niet maar wel met andere pakketten.

Vorige hoster had een forum. Kon je elkaar helpen.
Was iemand die draaien een phpbb. Die werd eens in de zoveel tijd enorm traag. Volgens support lag het aan de klant. Na aandringen en nog veel meer onderzoeken en testen. Bleek dat op bepaalde momenten de sql server het toch een beetje te druk had, door een andere klant. Na veel gedoe klant word op andere sql server gezet (6 maand onderzoek tijd nodig gehad). Probleem opgelost. Zijn forum weer snel. Dit ging z'n 9 maand goed en weer begon het gedoe opnieuw. Webhoster bewoog niet meer mee. Klant gaat naar andere webhoster. Draait al 2 jaar zonder problemen...

Dan ik zelf bij diezelfde webhoster. Een keer Matomo geïnstalleerd. Ook de backend was niet voorruit te branden. Ik denk dat zal vast komen door webhosting pakket specs. Matomo zal wel te zwaar zijn, want WordPress site (redelijk kaal op simpel thema en contactformulier en like plugin na) is vlot. Verder werkt het allemaal prima, directadmin ook snel. Goed de prijzen worden beetje te hoog voor de hobby. Ik verhuis de boel naar een andere partij. Goed alles draait even. Ik dacht laat ik Matomo eens testen. Nou ondanks dat het redelijk groot pakket is vliegt alles over het scherm net zoals mijn WordPress site. De specs zijn in elk geval gelijk (1 CPU en 1GB RAM).

[jurroen]

RobbyTown schreef op dinsdag 21 januari 2025 @ 10:50:
De specs zijn in elk geval gelijk (1 CPU en 1GB RAM).

Eén core van een i7-970 vs één Zen 4 core Zelfde specs maar een wereld van verschil.

[MuddyMagical]

Ga alsjeblieft niet blind allemaal caching plugins installeren zonder dat je weet wat er aan de hand is want dit lost het probleem niet op.

Een aantal mogelijke oorzaken kunnen zijn
- Trage webhost.
Je geeft aan dat de andere sites bij dezelfde hoster dit ook hebben? Dan zou je eens een backup van de site kunnen maken en een tijdelijke site bij bijvoorbeeld SiteGround opzetten om te testen of de site daar beter draait. Zo ja, dan is het een goed advies richting je klant om te verhuizen

- Veel plugins of plugins die met elkaar conflicteren
Het gemak om een plugin te installeren vanuit de repository maakt WordPress heel krachtig, maar is ook een gevaar. Let goed op welke plugins je installeert. Worden deze regelmatig onderhouden? Worden issues snel gefixt? Kan je een ontwikkelaar bereiken als er iets is?
Ga eens rustig door je plugins en check wat het nut is van de plugin voordat je hem installeert. Elke plugin kost meer rekenkracht en verwerkingstijd voor je site.

- Externe requests die worden gedaan waarop de site moet wachten.
Er zijn verschillende plugins die nog een verbinding maken naar een externe bron zoals fonts of icon maps. Daar moet je site op wachten en kan dus vertraging opleveren. Soms is het mogelijk om deze bronnen lokaal te zetten zodat je site er sneller toegang toe heeft.

- Zware website waarbij caching een oplossing kan zijn.
Bij een website waar de content niet full dynamisch is kan caching een goede toevoeging zijn. Desnoods bepaalde pagina's die weinig wijzigen per dag. Kort door de bocht: het is een methode waarbij dynamische content wordt omgezet in statische HTML die aan de bezoeker wordt voorgeschoteld. Dit is vele malen sneller dan dynamisch verschillende bronnen raadplegen en de pagina opbouwen.

Je zegt dat het vooral is als je inlogt in de wp-admin. Dus niet als je de site normaal bezoekt? Dan is caching niet de oplossing, maar ligt het probleem ergens in een plugin vermoedelijk.
Hierdoor moet je eigenlijk door de site heen en per plugin bepalen of die de oorzaak is.
Query monitor geeft je een goed inzicht in de laadtijden en queries naar de database, maar om de oorzaak te vinden is het handiger om de site lokaal te trekken en doormiddel van php monitoring en debug tools de oorzaak te vinden.

Instant update: Mocht je iemand fysiek zoeken die je eens kan helpen dan kan een WordPress Meetup een goeie zijn. Dit zijn bijeenkomsten waarbij iedereen die iets met WP doet welkom is en waar je veel verschillende kennis en ervaring kan vinden. Iedereen is bereid te helpen of tips te geven. In Rotterdam is er op dit moment geen gepland, maar ik vermoed dat dit binnenkort wel weer wordt gedaan. Anders kan je in bijvoorbeeld Amsterdam, Utrecht of Eindhoven terecht.

[ Voor 10% gewijzigd door MuddyMagical op 22-01-2025 09:32 ]

[ilaurensnl]

Zorg ten alle tijden dat je een back-up hebt.

1. Hosting kan traag zijn, je zou b.v. eerste een leeg wordpress installatie kunnen installeren om dat te testen, maar aangezien je al je eigen systeem hebt, zou je een van de onderstaande kunnen proberen. \

- Wat ik me kan voorstellen is dat het een van de plugins zijn, dus zou je ze kunnen uitzetten en kijken of dat helpt, daarna een voor een aanzetten mits het opgelost is.
- missende dependency die je kunt inschakelen in cpanel/directadmin b.v. check jouw logs direct via controle paneel, misschien zie je daar iets.
- Kan soms erg helpen om geheugen limiet hoger te zetten van wordpress, per script executie, zoek op google: wp increase memory limit

voor de rest kan het natuurlijk ook zijn dat die Wordpress installatie gecomprimeerd is, zeg niet dat het zo is maar wel een mogelijkheid.

[danielafcax]

Het kan ook een trage of overvolle database zijn.

Wil je sowieso adviseren om naar het inlogscherm te gaan, devtools erbij te pakken, tabje Network te openen en dan dat tabje open houden en inloggen zodat je kan zien welk script nu exact zo lang bezig is (als het een script is).

Als bovenstaand niet werkt, staging aanmaken, plug-ins 1 voor 1 uitschakelen tot je de bottleneck hebt.

Wil je ook eventueel wel helpen via P.M.