[Wordpress] www naar https traag

[Ernemmer]

Ik ben vandaag maar een bezig gegaan met het testen van mijn site.

Via pingdom.com ben ik er achter gekomen dat de redirect van www.tekenbureaujansen.nl naar https://tekenbureaujansen.nl erg veel tijd in beslag neemt.
https://tools.pingdom.com/#!/dEpFEq/www.tekenbureaujansen.nl

Als ik dezelfde test doe naar de https variant komt er een veel betere score uit.
https://tools.pingdom.com...ps://tekenbureaujansen.nl

Mijn klanten zullen praktisch altijd www.tekenbureaujansen.nl gebruiken en ik zou dan ook graag zien dat dat adres de snelle variant is en https eventueel langzamer.

Iemand een idee hoe ik dit kan oplossen? Via Google kan niet echt een oplossing vinden.

[Blauw]

Heb je je code in private_html staan of in public met een symlink?

[Ernemmer]

Blauw schreef op zondag 7 mei 2017 @ 09:45:
Heb je je code in private_html staan of in public met een symlink?

De site staat in public_html.

Ik moet er nog wel even bij vertellen dat ik er totaal geen verstand van heb. Ik heb de site bij Neostrada staan en via Softaculous in cpanel, Wordpress geinstalleerd.

[DJMaze]

Je Google PageSpeed Insights rating is laag, en het laden van de pagina ook.
Maak de single-page website eens zonder de overhead van WordPress en een bloated Theme.
Het kwartje valt dan vast wel.

[ Voor 8% gewijzigd door DJMaze op 08-05-2017 00:32 ]

[johnkeates]

Het probleem is dat je een website neergezet hebt die technisch gewoon slecht is, en je de kennis niet hebt om het te verbeteren... daar is dus helaas geen klik en klare oplossing voor voor mensen die er geen verstand van hebben.

[AW_Bos]

Welke plugins heb je al van Wordpress? Je kan proberen om W3 Total cache te installeren.
Dit kan ook mooi leesvoer zijn: http://www.wpbeginner.com/wordpress-performance-speed/

Ik heb je layout overigens niet gezien, maar zorg dat deze ook compact en snel is. Gebruik sprites voor je losse afbeeldingen, gebruik geen onnodige plugins. Zorg ervoor dat je de CSS minified en opslaat in een extern CSS-stijlblad, evenals je javascript als dat kan. Afbeeldingen netjes resizen en niet te groot maken. Desnoods bij veel afbeeldingen in een galerij bijvoorbeeld lazy-loading gebruiken, zodat alleen alles geladen wordt wat zichtbaar is.

En beginner kan er prima wat mee doen, maar een snelle layout speelt ook mee!

[ Voor 65% gewijzigd door AW_Bos op 08-05-2017 00:45 ]

[q-enf0rcer.1]

AW_Bos schreef op maandag 8 mei 2017 @ 00:41:
Welke plugins heb je al van Wordpress? Je kan proberen om W3 Total cache te installeren.
Dit kan ook mooi leesvoer zijn: http://www.wpbeginner.com/wordpress-performance-speed/

Ik heb je layout overigens niet gezien, maar zorg dat deze ook compact en snel is. Gebruik sprites voor je losse afbeeldingen, gebruik geen onnodige plugins. Zorg ervoor dat je de CSS minified en opslaat in een extern CSS-stijlblad, evenals je javascript als dat kan. Afbeeldingen netjes resizen en niet te groot maken. Desnoods bij veel afbeeldingen in een galerij bijvoorbeeld lazy-loading gebruiken, zodat alleen alles geladen wordt wat zichtbaar is.

En beginner kan er prima wat mee doen, maar een snelle layout speelt ook mee!

Lazy loaden van afbeeldingen op een one page website zou ik niet alleen voor een galerij doen, maar ook voor alle afbeeldingen die below the fold zitten.

[ruud1234]

Ik heb een soortgelijke issue, maar dan omgekeerd. De http variant scoorde een FTTB van 200-300 msec. Na het omzetten naar https is de FTTB nu 3,5 tot 4 SECONDEN.

Er is verder helemaal niets aan de site gewijzigd. De provider begrijpt er ook niets van, volgens hem is er op de server geen enkele redirect of timeout die dit kan veroorzaken.

Als iemand een steekhoudende suggestie heeft is deze; graag.

N.B. ik probeer niet dit topic te kapen maar de issue lijkt er ontzettend veel op....

[Ernemmer]

DJMaze schreef op maandag 8 mei 2017 @ 00:31:
Je Google PageSpeed Insights rating is laag, en het laden van de pagina ook.
Maak de single-page website eens zonder de overhead van WordPress en een bloated Theme.
Het kwartje valt dan vast wel.

Dat klopt, en ik gebruik dan ook Wordpress omdat dat voor een leek redelijk eenvoudig in elkaar te zetten is. En het zou natuurlijk best kunnen werken aangezien er toch wel een aantal sites gebruik maken van Wordpress. Mijn doel is dan ook niet om een supersnelle site te hebben er zullen ook praktisch geen bezoekers komen. Misschien dat er in de toekomst wel een betere site komt met meer informatie maar dat is op dit moment nog niet nodig.

Ik vond het verschil in laadtijd tussen http en https zo raar en was eigenlijk op zoek naar een snelle fix.
Misschien dat er iemand was die hetzelfde probleem had en het op een eenvoudige manier opgelost had.

AW_Bos schreef op maandag 8 mei 2017 @ 00:41:
Welke plugins heb je al van Wordpress? Je kan proberen om W3 Total cache te installeren.
Dit kan ook mooi leesvoer zijn: http://www.wpbeginner.com/wordpress-performance-speed/

Ik heb je layout overigens niet gezien, maar zorg dat deze ook compact en snel is. Gebruik sprites voor je losse afbeeldingen, gebruik geen onnodige plugins. Zorg ervoor dat je de CSS minified en opslaat in een extern CSS-stijlblad, evenals je javascript als dat kan. Afbeeldingen netjes resizen en niet te groot maken. Desnoods bij veel afbeeldingen in een galerij bijvoorbeeld lazy-loading gebruiken, zodat alleen alles geladen wordt wat zichtbaar is.

En beginner kan er prima wat mee doen, maar een snelle layout speelt ook mee!

Ik gebruik WP fastest cache voor het cachen en de enige andere plugin die ik gebruik is ThemeIsle Companion, maar die is nodig om de Zerif template te gebruiken.

De plaatjes zou ik nog wel kunnen optimaliseren maar de mainafbeelding is maar 550kb en de overige plaatjes zijn 50kb per stuk (totaal 4 plaatjes)

[ Voor 37% gewijzigd door Ernemmer op 08-05-2017 12:42 ]

[CH4OS]

Tools als pingdom zijn leuk, maar die kunnen enkel testen vanuit hun locaties. Strookt dat wel met de bezoekers die je hebben wilt op jouw website? Als ik namelijk vanuit mijn werk (wat ook een brakke internet verbinding heeft) naar de HTTP-website ga, dan ben ik gewoon direct op de HTTPS-variant.

Vergeet niet dat je met pingdom te maken hebt met testen over een lange verbinding/afstand (Stockholm - Amsterdam is al een ruime 1400km!), een dergelijke verbinding zal altijd trager zijn dan bijvoorbeeld nationaal (omdat pingdom geen testserver in Nederland heeft).

Mede daarom vind ik pingdom eigenlijk niet handig om performance mee te testen, tenzij jouw website dergelijk publiek (ook) aantrekt natuurlijk. Wil je dus toch pingdom gebruiken om jouw website te testen, hou er dan rekening mee, dat de laadtijden wat hoger zijn, omdat de TTFB gewoonweg hoger is.

Ga dus niet uit van een meting van 1 tool, test met meer, ook die wat dichterbij kunnen testen dan Stockholm.

Dat gezegd hebbende, nog wat andere toevoegingen:

Met deze debugbar kun je zien of het aan de parsing ligt en zo ja, waar.

Controleer de server configuratie; PHP7 is namelijk sneller dan PHP5, WordPress is in principe PHP7 compabitel in elk geval. Ter beeldvorming; ik had bij een overstap van PHP5 naar PHP7 op zich ook wel groot verschil; ik ging van een parsetijd van 50ms (een Laravel project) naar 35ms. Als gebruiker niet meteen merkbaar uiteraard, maar daar gaat het nu even niet om.

Tools zoals YSlow kunnen geloof ik meerdere diensten aanspreken, zoals bijvoorbeeld Google Pagespeed Insights en eentje van Yahoo (naam even kwijt), erg handig om te zien waar de problemen in de verbinding zitten.

Aan de SSL-kant van het verhaal; check even (bijvoorbeeld via ssllabs.com) of je wat kan tunen aan de SSL-configuratie. Controleer dan bijvoorbeeld of de chain goed in elkaar zit, dat scheelt ook uiteindelijk tijd.

Loop ook even de plugins na, heb je ze wel daadwerkelijk nodig? Zijn deze wellicht verouderd en kan het dus zinvol zijn om over te stappen op een nieuwe, die bijvoorbeeld ook overweg kan met PHP7.x? Hou er namelijk rekening mee, dat de meeste rotzooi aan code vanuit de plugins komt, niet zozeer vanuit WordPress zelf.

Soms kan ook een webaccelerator zoals Varnish uitkomst bieden, als dat eenmaal en goed is opgezet, gaat dat veel in laadtijd schelen.

Als laatste:
Op internet zijn ook veel guides over dit onderwerp te vinden. Velen raden W3 Total Cache aan, moet zeggen dat ik andere ervaringen heb toen ik nog een WordPress site had draaien.

En als allerbelangrijkste: meten is niet alleen weten, maar zeker ook vergeten! Test en meet daarom veel, dan zie je waar de problemen vooral zitten en kun je daarop acteren. Los het dus ook niet als brandje op, maar probeer het wel te monitoren, zodat een website eigenlijk altijd prima reageert / reageert zoals verwacht.

[ Voor 54% gewijzigd door CH4OS op 08-05-2017 13:14 ]

[q-enf0rcer.1]

Ernemmer schreef op maandag 8 mei 2017 @ 12:37:
Ik gebruik WP fastest cache voor het cachen en de enige andere plugin die ik gebruik is ThemeIsle Companion, maar die is nodig om de Zerif template te gebruiken.

De plaatjes zou ik nog wel kunnen optimaliseren maar de mainafbeelding is maar 550kb en de overige plaatjes zijn 50kb per stuk (totaal 4 plaatjes)

550kb is naar mijn mening toch wel veel, ik heb je afbeelding even getest. Alleen al met lossless compressie krijg ik daar 50kb vanaf. Als je daar een goede compressie tool op lostlaat kun je denk ik op 200kb uitkomen. Toch wel een groot verschil.

Je homepage weegt maar ~850kb, dan is 550kb voor een afbeelding natuurlijk wel een erg groot deel.

Edit: even met ImageOptim getest, ik krijg de afbeelding op 80kb zonder zichtbaar kwaliteitsverlies.

[ Voor 13% gewijzigd door q-enf0rcer.1 op 08-05-2017 16:07 ]

[André]

Wat CH40S ook al zegt: Pingdom doet te weinig metingen, dat heeft niets met de werkelijkheid te maken. Zet de sitespeedsamplerate van Google Analytics even naar 100% en je hebt een meting bij al je bezoekers. Dan kun je zien of zij ook een hoge redirect tijd ervaren.

[Ernemmer]

CH40S schreef op maandag 8 mei 2017 @ 12:58:
Tools als pingdom zijn leuk, maar die kunnen enkel testen vanuit hun locaties. Strookt dat wel met de bezoekers die je hebben wilt op jouw website? Als ik namelijk vanuit mijn werk (wat ook een brakke internet verbinding heeft) naar de HTTP-website ga, dan ben ik gewoon direct op de HTTPS-variant.

Vergeet niet dat je met pingdom te maken hebt met testen over een lange verbinding/afstand (Stockholm - Amsterdam is al een ruime 1400km!), een dergelijke verbinding zal altijd trager zijn dan bijvoorbeeld nationaal (omdat pingdom geen testserver in Nederland heeft).

Mede daarom vind ik pingdom eigenlijk niet handig om performance mee te testen, tenzij jouw website dergelijk publiek (ook) aantrekt natuurlijk. Wil je dus toch pingdom gebruiken om jouw website te testen, hou er dan rekening mee, dat de laadtijden wat hoger zijn, omdat de TTFB gewoonweg hoger is.

Ga dus niet uit van een meting van 1 tool, test met meer, ook die wat dichterbij kunnen testen dan Stockholm.

Dat gezegd hebbende, nog wat andere toevoegingen:

Met deze debugbar kun je zien of het aan de parsing ligt en zo ja, waar.

Controleer de server configuratie; PHP7 is namelijk sneller dan PHP5, WordPress is in principe PHP7 compabitel in elk geval. Ter beeldvorming; ik had bij een overstap van PHP5 naar PHP7 op zich ook wel groot verschil; ik ging van een parsetijd van 50ms (een Laravel project) naar 35ms. Als gebruiker niet meteen merkbaar uiteraard, maar daar gaat het nu even niet om.

Tools zoals YSlow kunnen geloof ik meerdere diensten aanspreken, zoals bijvoorbeeld Google Pagespeed Insights en eentje van Yahoo (naam even kwijt), erg handig om te zien waar de problemen in de verbinding zitten.

Aan de SSL-kant van het verhaal; check even (bijvoorbeeld via ssllabs.com) of je wat kan tunen aan de SSL-configuratie. Controleer dan bijvoorbeeld of de chain goed in elkaar zit, dat scheelt ook uiteindelijk tijd.

Loop ook even de plugins na, heb je ze wel daadwerkelijk nodig? Zijn deze wellicht verouderd en kan het dus zinvol zijn om over te stappen op een nieuwe, die bijvoorbeeld ook overweg kan met PHP7.x? Hou er namelijk rekening mee, dat de meeste rotzooi aan code vanuit de plugins komt, niet zozeer vanuit WordPress zelf.

Soms kan ook een webaccelerator zoals Varnish uitkomst bieden, als dat eenmaal en goed is opgezet, gaat dat veel in laadtijd schelen.

Als laatste:
Op internet zijn ook veel guides over dit onderwerp te vinden. Velen raden W3 Total Cache aan, moet zeggen dat ik andere ervaringen heb toen ik nog een WordPress site had draaien.

En als allerbelangrijkste: meten is niet alleen weten, maar zeker ook vergeten! Test en meet daarom veel, dan zie je waar de problemen vooral zitten en kun je daarop acteren. Los het dus ook niet als brandje op, maar probeer het wel te monitoren, zodat een website eigenlijk altijd prima reageert / reageert zoals verwacht.

Bedankt, ik zal de tools eens langsgaan.

Op SSL Labs krijg ik een A, dus dat lijkt mij goed.
Ik zit op PHP5, maar daar kan ik niks aan doen aangezien ik shared hosting afneem bij Neostrada.

André schreef op maandag 8 mei 2017 @ 16:09:
Wat CH40S ook al zegt: Pingdom doet te weinig metingen, dat heeft niets met de werkelijkheid te maken. Zet de sitespeedsamplerate van Google Analytics even naar 100% en je hebt een meting bij al je bezoekers. Dan kun je zien of zij ook een hoge redirect tijd ervaren.

De site analyseren zou natuurlijk erg leuk zijn, maar om daar ook weer in te duiken kost mij te veel tijd. Misschien op een later moment eens naar kijken, of niet alles zelf willen doen en iemand inhuren om een mooie site te maken.

[ Voor 8% gewijzigd door Ernemmer op 08-05-2017 16:17 ]

[Ernemmer]

dubbel

[ Voor 98% gewijzigd door Ernemmer op 08-05-2017 16:16 ]

[CH4OS]

Ernemmer schreef op maandag 8 mei 2017 @ 16:11:
Ik zit op PHP5, maar daar kan ik niks aan doen aangezien ik shared hosting afneem bij Neostrada.

Dan toch even de faq / kb doornemen: https://support.neostrada...wijzig-ik-mijn-php-versie en kwam met Googke zelfs een Facebook bericht van ze tegen, dat PHP7.1 zelfs beschikbaar is! Dat omzetten naar PHP7 is dus zo gedaan, vanuit cPanel. Of 7.1 ook werkt, geen idee, maar lijkt me wel, aangezien er tussen 7.0 en 7.1 weinig verschil zit, behalve de support vanuit Zend.

Nog een link: https://www.neostrada.nl/.../php-versie-wijzigen.html hier staat het zeofs in de screenshot.

Google Analytics is ook zo ingesteld.

[ Voor 36% gewijzigd door CH4OS op 08-05-2017 18:39 ]

[Ernemmer]

CH40S schreef op maandag 8 mei 2017 @ 18:34:
[...]
Dan toch even de faq / kb doornemen: https://support.neostrada...wijzig-ik-mijn-php-versie en kwam met Googke zelfs een Facebook bericht van ze tegen, dat PHP7.1 zelfs beschikbaar is! Dat omzetten naar PHP7 is dus zo gedaan, vanuit cPanel. Of 7.1 ook werkt, geen idee, maar lijkt me wel, aangezien er tussen 7.0 en 7.1 weinig verschil zit, behalve de support vanuit Zend.

Nog een link: https://www.neostrada.nl/.../php-versie-wijzigen.html hier staat het zeofs in de screenshot.

Google Analytics is ook zo ingesteld.

Thnx, ik had gedacht dat de PHP versie vanuit de hoster bedient en onderhouden werd.
Het is inderdaad makkelijk, en de site staat nu op 7.1

Volgens Pingdom is de site nu ook sneller.
Google analytisch snap ik niks van

[ Voor 7% gewijzigd door Ernemmer op 08-05-2017 20:47 ]

[CH4OS]

Nogmaals, staar je niet blind op pingdom (zeker op metrische waardes niet, ivm afstand bijvoorbeeld), het is te beperkt en het verteld eigenlijk niets.

[ Voor 25% gewijzigd door CH4OS op 09-05-2017 07:57 ]

[Ernemmer]

CH40S schreef op dinsdag 9 mei 2017 @ 07:56:
Nogmaals, staar je niet blind op pingdom (zeker op metrische waardes niet, ivm afstand bijvoorbeeld), het is te beperkt en het verteld eigenlijk niets.

Dat klopt maar de site is makkelijk te gebruiken en als het verder weg goed gaat, zal het dichterbij toch ook wel goed gaan.

Ik ben nu Pagespeed aan het doorkijken en de afbeeldingen aan het aanpassen. De overige dingen heb ik nog geen verstand van.

[ Voor 14% gewijzigd door Ernemmer op 09-05-2017 09:45 ]

[Verwijderd]

Ik raad je aan om WP-Rocket cache te gebruiken, scheelt een hoop.

Ook is het makkelijker om dingen te scripten i.p.v. een plugin te gebruiken, deze maken je site ook traag als fuck..

CDN zal ook helpen met je tests op Pingdom en GTMatrix

[ Voor 13% gewijzigd door Verwijderd op 09-05-2017 09:47 ]

[Ernemmer]

Verwijderd schreef op dinsdag 9 mei 2017 @ 09:47:
Ik raad je aan om WP-Rocket cache te gebruiken, scheelt een hoop.

Ook is het makkelijker om dingen te scripten i.p.v. een plugin te gebruiken, deze maken je site ook traag als fuck..

CDN zal ook helpen met je tests op Pingdom en GTMatrix

Zoals ik eerder al aangaf ben ik geen webdeveloper en scripten zal mij niet gaan lukken. Ik zal eens kijken naar WP-rocket cache of die beter werkt dan WP Fastest cache.

Ik zat net even te kijken op een site van een collega en die site scoort heel slecht bij Google maar laad wel heel snel.
https://developers.google...F%2Fjanwind.nl&tab=mobile

[crypt0rr]

@Ernemmer WP Super cache gebruik ik zelf met een site over HTTPS, werkt als een malle.

[Verwijderd]

Simpel gezegd:

Pingdom test de sitesnelheid vanaf een server in het buitenland. Gezien je ISP naar alle waarschijnlijkheid in Nederland zit heeft het weinig zin om je blind te staren op deze waardes. Je waardes zullen verbeteren op het moment dat je een CDN gebruikt. Op dat moment staat je content op meerdere servers wereldwijd verspreid waardoor het laden van je site sneller gaat omdat de afstand welke overbrugt dient te worden kleiner is van server naar server.

Dit zijn me stats met WP Rocket:
• https://gtmetrix.com/reports/brianmertens.nl/SAuAyN89


@Ernemmer Bij welke partij neem je hosting af ?

[ Voor 3% gewijzigd door Verwijderd op 09-05-2017 10:08 ]

[phochs]

_{Kan zijn dat de vraag al eerder gesteld was, maar ik zag het zo snel niet voorbij komen.}
Hoe heb je de redirect naar https gedaan? Ik heb zelf ook diverse websites bij Neostrada draaien en herken dit probleem niet, dus wellicht zit er iets vaags in het doorverwijzen.

[Ernemmer]

Mijn site scoort daar nu ook redelijk goed na het aanpassen van de afbeeldingen.
https://gtmetrix.com/repo...nbureaujansen.nl/Fe6EdF7G

phochs schreef op dinsdag 9 mei 2017 @ 10:12:
Kan zijn dat de vraag al eerder gesteld was, maar ik zag het zo snel niet voorbij komen.
Hoe heb je de redirect naar https gedaan? Ik heb zelf ook diverse websites bij Neostrada draaien en herken dit probleem niet, dus wellicht zit er iets vaags in het doorverwijzen.

Ik heb zelf niks ingesteld, het is een automatisch installatie van Wordpress.

[CH4OS]

phochs schreef op dinsdag 9 mei 2017 @ 10:12:
_{Kan zijn dat de vraag al eerder gesteld was, maar ik zag het zo snel niet voorbij komen.}
Hoe heb je de redirect naar https gedaan? Ik heb zelf ook diverse websites bij Neostrada draaien en herken dit probleem niet, dus wellicht zit er iets vaags in het doorverwijzen.

Toen ik gisteren http -> https redirect testte van de site van TS ging dat ook gewoon goed. TS staart echter blind op Pingdom.

Bedenk me net dat de pagina gzippen ook stukken scheelt, is een aanpassing in de .htaccess in veel gevallen. Overstaopen naar http/2 kan dan in principe ook. Is op Apache wel wat lastiger dan NginX. Helaas doen hosyers voornamelijk Apache 2 gebruiken ipv het performantere NginX icm PHP-FPM.

[ Voor 21% gewijzigd door CH4OS op 09-05-2017 10:19 ]

[Verwijderd]

Ernemmer schreef op dinsdag 9 mei 2017 @ 10:15:
Mijn site scoort daar nu ook redelijk goed na het aanpassen van de afbeeldingen.
https://gtmetrix.com/repo...nbureaujansen.nl/Fe6EdF7G


[...]


Ik heb zelf niks ingesteld, het is een automatisch installatie van Wordpress.

MemCached en Redis aanzetten vanuit je DirectAdmin helpt ook!

Wel is het belangrijk dat je hosting deze features ondersteund.

[phochs]

Gelukkig hebben ze bij Neostrada geen DirectAdmin. Redis kan, weet niet of het nodig is want ik vind de website op het moment niet traag. Volgens mij had TS al wat wijzigingen gedaan en ik vind de laadsnelheid nu persoonlijk prima.

[CH4OS]

Verwijderd schreef op dinsdag 9 mei 2017 @ 10:17:
MemCached en Redis aanzetten vanuit je DirectAdmin helpt ook!

PHP7 heeft geen ondersteuning voor APC en MemCached naar mijn weten.

[Ernemmer]

CH40S schreef op dinsdag 9 mei 2017 @ 10:16:
[...]
Toen ik gisteren http -> https redirect testte van de site van TS ging dat ook gewoon goed. TS staart echter blind op Pingdom.

Bedenk me net dat de pagina gzippen ook stukken scheelt, is een aanpassing in de .htaccess in veel gevallen. Overstaopen naar http/2 kan dan in principe ook. Is op Apache wel wat lastiger dan NginX. Helaas doen hosyers voornamelijk Apache 2 gebruiken ipv het performantere NginX icm PHP-FPM.

phochs schreef op dinsdag 9 mei 2017 @ 10:18:
Gelukkig hebben ze bij Neostrada geen DirectAdmin. Redis kan, weet niet of het nodig is want ik vind de website op het moment niet traag. Volgens mij had TS al wat wijzigingen gedaan en ik vind de laadsnelheid nu persoonlijk prima.

De site is volgens mij nu ook een stuk sneller, bedankt voor alle hulp.

[Verwijderd]

CH40S schreef op dinsdag 9 mei 2017 @ 10:21:
[...]
PHP7 heeft geen ondersteuning voor APC en MemCached naar mijn weten.

Bij 7.1 wel ? Zowel Redis als Memcached



Ook bij 7.0 zie ik:

[ Voor 14% gewijzigd door Verwijderd op 09-05-2017 10:27 ]

[Ernemmer]

Verwijderd schreef op dinsdag 9 mei 2017 @ 10:25:
[...]


Bij 7.1 wel ? Zowel Redis als Memcached

[afbeelding]

Ook bij 7.0 zie ik:

[afbeelding]

Die nog even aangezet, een vinkje zetten lukt nog wel

[Verwijderd]

Ernemmer schreef op dinsdag 9 mei 2017 @ 10:29:
[...]


Die nog even aangezet, een vinkje zetten lukt nog wel

Als je het aan hebt gezet (Redis) raad ik je aan even de volgende handleiding te volgen:

• https://www.vimexx.nl/hel...je-redis-binnen-wordpress

Eventjes de plugin downloaden, en 4 regels toevoegen in je WP-config.. Ik weet dat het klinkt als scripten, maar zie het als knippen plakken :P!

[Ernemmer]

Verwijderd schreef op dinsdag 9 mei 2017 @ 10:34:
[...]


Als je het aan hebt gezet (Redis) raad ik je aan even de volgende handleiding te volgen:

• https://www.vimexx.nl/hel...je-redis-binnen-wordpress

Eventjes de plugin downloaden, en 4 regels toevoegen in je WP-config.. Ik weet dat het klinkt als scripten, maar zie het als knippen plakken :P!

Als het goed is moet het nu werken.

Als ik nu mijn theme update, moet ik dan die regeltjes er weer inplakken of wordt de wp-config niet aangepast?

[ Voor 18% gewijzigd door Ernemmer op 09-05-2017 11:00 ]

[Verwijderd]

Ernemmer schreef op dinsdag 9 mei 2017 @ 10:54:
[...]


Als het goed is moet het nu werken.

Als ik nu mijn theme update, moet ik dan die regeltjes er weer inplakken of wordt de wp-config niet aangepast?

WP-config hoef je 1x aan te passen, zit niet in je wp-content/themes folder dus hoef je niet per theme te wijzigen!

[AW_Bos]

Even een bericht voor diegene die meelezen en Direct Admin gebruiken. Dit geldt alleen voor een DirectAdmin installatie die op Cloud Linux is geinstalleerd. Standaard ondersteunt DirectAdmin geen Redis, of een uitgebreide module-keuze per PHP-versie.

Deze mededeling dus even voor mensen die straks gaan vragen waar ze dit nou kunnen vinden .

[ Voor 3% gewijzigd door AW_Bos op 09-05-2017 11:16 ]

[Verwijderd]

AW_Bos schreef op dinsdag 9 mei 2017 @ 11:15:
Even een bericht voor diegene die meelezen en Direct Admin gebruiken. Dit geldt alleen voor een DirectAdmin installatie die op Cloud Linux is geinstalleerd. Standaard ondersteunt DirectAdmin geen Redis, of een uitgebreide module-keuze per PHP-versie.

Deze mededeling dus even voor mensen die straks gaan vragen waar ze dit nou kunnen vinden .

Dat verklaard het natuurlijk! Thanks

[CH4OS]

Verwijderd schreef op dinsdag 9 mei 2017 @ 10:25:
[...]


Bij 7.1 wel ? Zowel Redis als Memcached

[afbeelding]

Ook bij 7.0 zie ik:

[afbeelding]

Hmmm, oke, vreemd, eigenlijk, naar mijn idee. Dan zou ik eerder Zend's eigen opcache gebruiken ipv het verouderde memcached. Dat Redis er tussen staat is dan an sich weer niet vreemd; dat wordt steeds vaker gebruikt. En die heb jij zo te zien ook beschikbaar (eigenlijk iedereen die op PHP5.6 of hoger zit)

[ Voor 92% gewijzigd door CH4OS op 09-05-2017 12:50 ]

[AW_Bos]

Verwijderd schreef op dinsdag 9 mei 2017 @ 12:27:
[...]


Dat verklaard het natuurlijk! Thanks

Inderdaad. Clound Linux gebruik een Lightweight Virtual Environment (LVE), waarbij de gebruikers in kleine containers werken en daarbij alle processen etc netjes binnen hun 'container' blijven. Met zulke dingen is het mogelijk om PHP per user uit te breiden.
Leuk speeltje, dat wel.

[Verwijderd]

CH40S schreef op dinsdag 9 mei 2017 @ 12:45:
[...]

Hmmm, oke, vreemd, eigenlijk, naar mijn idee. Dan zou ik eerder Zend's eigen opcache gebruiken ipv het verouderde memcached. Dat Redis er tussen staat is dan an sich weer niet vreemd; dat wordt steeds vaker gebruikt. En die heb jij zo te zien ook beschikbaar (eigenlijk iedereen die op PHP5.6 of hoger zit)

True, maar als ik 1 ding geleerd heb is het niet teveel afgaan op de stats van GTMatrix en Pingdom.. Helemaal wanneer je geen CDN gebruikt..

Al met al wel een handige post voor het versnellen van je WP natuurlijk.. Ik zie veel mensen W3 gebruiken echter ben ik er niet zo'n fan van.. Daarbij is Memcached ook niet 1,2,3 ingesteld helemaal niet wanneer je Woocommerce draait..

[CH4OS]

Ik ga sowieso al nooit uit van dergelijke tools. W3 Total Cache heb ik ooit ook eens mee zitten testen, maar gaf echt 0 verschil, eigenlijk. Ben wel dingen als Zend's OpCache gaan gebruiken (die kan jij overigens ook aan zetten, @Verwijderd )

En volgens https://www.hostnexus.com...cached-caching-explained/ kun je zelfs Memcached en Opcache naast elkaar gebruiken, al ben ik daar niet zo'n fan van.

[8088]

CH40S schreef op dinsdag 9 mei 2017 @ 12:45:
Dan zou ik eerder Zend's eigen opcache gebruiken ipv het verouderde memcached.

Dat is als zeggen dat je liever een IDE dan versiebeheer gebruikt.

OPcache (en andere PHP-accelerators) bewaart gecompileerde code in het werkgeheugen, zodat scripts niet bij iedere request opnieuw gecompileerd hoeven te worden. Dat scheelt rekenkracht en tijd.

Redis en Memcache zijn caches in het werkgeheugen (waarbij Redis ook naar je storage kan schrijven, zodat je cache na een crash weer snel paraat staat) waar je key/vars in op kunt slaan, zodat ze snel beschikbaar zijn en je (bijvoorbeeld) je database niet telkens hoeft te raadplegen.

Zolang je code Redis of Memcache niet aanspreekt, heeft het geen enkele zin deze op te starten en diens PHP-modules in te laden. Een PHP-accelerator daarentegen heeft vrijwel altijd zin.

[CH4OS]

8088 schreef op dinsdag 9 mei 2017 @ 14:14:
Dat is als zeggen dat je liever een IDE dan versiebeheer gebruikt.

OPcache (en andere PHP-accelerators) bewaart gecompileerde code in het werkgeheugen, zodat scripts niet bij iedere request opnieuw gecompileerd hoeven te worden. Dat scheelt rekenkracht en tijd.

Redis en Memcache zijn caches in het werkgeheugen (waarbij Redis ook naar je storage kan schrijven, zodat je cache na een crash weer snel paraat staat) waar je key/vars in op kunt slaan, zodat ze snel beschikbaar zijn en je (bijvoorbeeld) je database niet telkens hoeft te raadplegen.

Zolang je code Redis of Memcache niet aanspreekt, heeft het geen enkele zin deze op te starten en diens PHP-modules in te laden. Een PHP-accelerator daarentegen heeft vrijwel altijd zin.

Ah, dacht dat MemCached ook een opcacher was...