[wordpress] wp super cache blijft pagina's opnieuw cachen

[vandermark]

Ik heb een redelijk statische website en voor de snelheid gebruik ik wp super cache. Het valt me echter op dat erg vaak wanneer ik de homepage (zie link in mijn footer) bezoek de pagina op dat moment gecached wordt. Door bron te bekijken zie ik dan onderaan:

code:

<!-- Dynamic page generated in 1.437 seconds. -->
<!-- Cached page generated by WP-Super-Cache on 2016-05-22 14:53:28 -->

<!-- Compression = gzip -->

Met de datum & tijd van dat moment: ik krijg dus meestal een gecachde pagina, die net is gegenereerd door de pagina te bezoeken. Het is niet altijd zo maar wel (te) vaak naar mijn idee. Hoe kan ik erachter komen waar dit door wordt veroorzaakt? Op de support pagina van de plugin zie ik vergelijkbare vragen, echter zonder antwoorden.

[RobIII]

Als de cache expired is wordt 'ie (terecht) opnieuw gegenereerd. Als je TTL op 10 minuten staat en de pagina is 10 minuten door niemand bekeken dan is het dus logisch. Dus de relevante gegevens die we moeten weten: wat is je TTL (geen idee welke term wp supercache gebruikt) en heb je het bij vernieuwen binnen die tijd dan ook?

[Ventieldopje]

De pagina is één ding, maar cache je de afbeeldingen en assets (css / js) ook? Het is belangrijk ook daarvan de TTL goed in te stellen.

Zelf niet zo'n fan van WP Super Cache omdat het aantal mogelijkheden toch wat beperkt is itt. W3 Total Cache (W3TC). Het is wat uitgebreider maar dit soort dingen zijn wel te finetunen.

Feit blijft dat Wordpress in de meeste gevallen nou niet bekend staat om een super snel CMS, helaas.

[vandermark]

RobIII schreef op zondag 22 mei 2016 @ 15:31:
Als de cache expired is wordt 'ie (terecht) opnieuw gegenereerd. Als je TTL op 10 minuten staat en de pagina is 10 minuten door niemand bekeken dan is het dus logisch. Dus de relevante gegevens die we moeten weten: wat is je TTL (geen idee welke term wp supercache gebruikt) en heb je het bij vernieuwen binnen die tijd dan ook?

Dank voor je vragen. Ik heb de relevante instellingen zo staan, waarbij ik een vrij lange TTL hanteer, ook omdat ik een statische site heb (circa 20 blogs per jaar). Vaak verversen is dus niet nodig. Daarnaast heb ik een preload aanstaan die ervoor zou moeten zorgen dat verlopen bestanden automatisch worden vernieuwd:

Ventieldopje schreef op zondag 22 mei 2016 @ 16:24:
De pagina is één ding, maar cache je de afbeeldingen en assets (css / js) ook? Het is belangrijk ook daarvan de TTL goed in te stellen.

Zelf niet zo'n fan van WP Super Cache omdat het aantal mogelijkheden toch wat beperkt is itt. W3 Total Cache (W3TC). Het is wat uitgebreider maar dit soort dingen zijn wel te finetunen.

Feit blijft dat Wordpress in de meeste gevallen nou niet bekend staat om een super snel CMS, helaas.

Als een cache file wordt geserveerd vind ik de site meer dan snel zat, dat is dus het doel, 99% vd tijd een cache file serveren. Of afbeeldingen mee gaan vind ik minder belangrijk.

[Ventieldopje]

vandermark schreef op zondag 22 mei 2016 @ 19:57:
[...]


Dank voor je vragen. Ik heb de relevante instellingen zo staan, waarbij ik een vrij lange TTL hanteer, ook omdat ik een statische site heb (circa 20 blogs per jaar). Vaak verversen is dus niet nodig. Daarnaast heb ik een preload aanstaan die ervoor zou moeten zorgen dat verlopen bestanden automatisch worden vernieuwd:

[afbeelding]
[afbeelding]
[...]


Als een cache file wordt geserveerd vind ik de site meer dan snel zat, dat is dus het doel, 99% vd tijd een cache file serveren. Of afbeeldingen mee gaan vind ik minder belangrijk.

Afbeeldingen en andere assets zorgen _juist_ voor een speedup, ook op dynamische pagina's. Het dynamisch opbouwen van de pagina is één ding maar als het eenmaal een HTML pagina is en verzonden is naar de browser moet die nog alle assets laden. Je browser laad maar een beperkt aantal assets tegelijk waardoor het vaak verstandig is meerdere assets (css / js bestanden) samen te voegen en te comprimeren. Ook maakt de volgorde uit voor JS bestanden omdat eerst alle assets in de head worden geladen voordat de body wordt opgebouwd. Het is dus vaak verstandiger om scripts onder in de body te plaatsen zodat deze het renderen van de pagina niet blokkeren.

Alleen met een lange TTL haal je niet veel bijzonders uit, just my 2 cents.

[vandermark]

Ventieldopje schreef op zondag 22 mei 2016 @ 20:42:
[...]


Afbeeldingen en andere assets zorgen _juist_ voor een speedup, ook op dynamische pagina's. Het dynamisch opbouwen van de pagina is één ding maar als het eenmaal een HTML pagina is en verzonden is naar de browser moet die nog alle assets laden. Je browser laad maar een beperkt aantal assets tegelijk waardoor het vaak verstandig is meerdere assets (css / js bestanden) samen te voegen en te comprimeren. Ook maakt de volgorde uit voor JS bestanden omdat eerst alle assets in de head worden geladen voordat de body wordt opgebouwd. Het is dus vaak verstandiger om scripts onder in de body te plaatsen zodat deze het renderen van de pagina niet blokkeren.

Alleen met een lange TTL haal je niet veel bijzonders uit, just my 2 cents.

Ik gebruik ook autoptimize die css en javascript samenvoegt. Bij google page speed insights zijn ze daar ook tevreden mee.

[RobIII]

Ventieldopje schreef op zondag 22 mei 2016 @ 20:42:
Afbeeldingen en andere assets zorgen _juist_ voor een speedup

Natuurlijk dien je je assets, voor zover mogelijk, te cachen. Maar als je pagina al anderhalve seconde (server-side) nodig heeft om gegenereerd te worden:

vandermark schreef op zondag 22 mei 2016 @ 14:55:

code:

<!-- Dynamic page generated in 1.437 seconds. -->

dan zou ik daar toch eens beginnen; die assets komen later wel. Sterker: je browser weet pas welke assets geladen moeten worden als 'ie de pagina zélf binnen heeft. Voor die tijd gebeurt er sowieso helemaal niets.

Als vervolgens blijkt dat elke page load (zoals TS het iig doet voorkomen) een cache-miss is dan heb je geen zak aan übersnel ladende assets; dat is pas een tweede probleem.

[ Voor 19% gewijzigd door RobIII op 22-05-2016 21:17 ]

[Ventieldopje]

RobIII schreef op zondag 22 mei 2016 @ 21:15:
[...]

Natuurlijk dien je je assets, voor zover mogelijk, te cachen. Maar als je pagina al anderhalve seconde (server-side) nodig heeft om gegenereerd te worden:

[...]

dan zou ik daar toch eens beginnen; die assets komen later wel. Sterker: je browser weet pas welke assets geladen moeten worden als 'ie de pagina zélf binnen heeft. Voor die tijd gebeurt er sowieso helemaal niets.

vandermark schreef op zondag 22 mei 2016 @ 21:14:
[...]


Ik gebruik ook autoptimize die css en javascript samenvoegt. Bij google page speed insights zijn ze daar ook tevreden mee.

Dat zal waarschijnlijk die lange laadtijd verklaren

[vandermark]

Ventieldopje schreef op zondag 22 mei 2016 @ 21:16:
[...]


[...]


Dat zal waarschijnlijk die lange laadtijd verklaren

Want? Ik wil weten waarom een pagina opnieuw gecached wordt? Autoptimze wordt door super cache aanbevolen, ik zie de relatie niet echt...

[RobIII]

Ventieldopje schreef op zondag 22 mei 2016 @ 21:16:
Dat zal waarschijnlijk die lange laadtijd verklaren

Ik neem aan dat de laadtijd die ik quotte is voor het genereren van de pagina (de HTML dus). Hoe lang een-of-andere optimizer nodig heeft (gehad) om een CSS file te genereren lijkt me iets dat, at best, in de CSS staat a-la:

Cascading Stylesheet:

/* Minified js/css generated in 1.437 seconds. */

De CSS is een apart request dus het lijkt me stug dat die in die tijd van de HTML meegenomen wordt. En dus: los dat eerst eens op. Ja, er kunnen (daarna) nog meer problemen (waaronder trage 'optimizers' en andere zaken zoals ontbrekende cache-headers etc.) opduiken, maar voor wat ik nu, in de topicstart zie, zit er iig een probleem in de pagina zélf; ~1.5s is echt rete-lang.

Overigens is de echte oplossing natuurlijk gewoon even kijken in je browser-console naar het netwerk/waterval diagram.

[ Voor 11% gewijzigd door RobIII op 22-05-2016 21:47 ]

[Ventieldopje]

RobIII schreef op zondag 22 mei 2016 @ 21:21:
[...]


Ik neem aan dat de laadtijd die ik quotte is voor het genereren van de pagina (de HTML dus). Hoe lang een-of-andere optimizer nodig heeft (gehad) om een CSS file te genereren lijkt me iets dat, at best, in de CSS staat a-la:

Cascading Stylesheet:

/* Minified js/css generated in 1.437 seconds. */

De CSS is een apart request dus het lijkt me stug dat die in die tijd van de HTML meegenomen wordt. En dus: los dat eerst eens op. Ja, er kunnen (daarna) nog meer problemen (waaronder trage 'optimizers' en andere zaken zoals ontbrekende cache-headers etc.) opduiken, maar voor wat ik nu, in de topicstart zie, zit er iig een probleem in de pagina zélf; ~1.5s is echt rete-lang.

Overigens is de echte oplossing natuurlijk gewoon even kijken in je browser-console naar het netwerk/waterval diagram.

De CSS laden is een aparte request maar het opnieuw minifyen als de TTL is verstreken niet Als de TTL afloopt wordt de dynamische pagina opnieuw geladen en gecached en als tevens ook de TTL voor de assets is verstreken worden die ook opnieuw geladen en geminified.

Maar goed, zonder verder toegang te hebben of te weten wat voor server je gebruikt kan ik daar weinig over zeggen maar het lijkt mij in ieder geval niet ondenkbaar.

1.5s is echt veel te lang inderdaad

[RobIII]

Ventieldopje schreef op zondag 22 mei 2016 @ 22:13:
[...]


De CSS laden is een aparte request maar het opnieuw minifyen als de TTL is verstreken niet

No shit
Punt is dat de output die TS post in de HTML van de pagina staat en dat de tijd van minifyen van CSS/JS etc. daar niet in meegenomen wordt (want: apart request). Die tijd kan (ook) lang zijn maar niets wijst daar (nu) op Het is wel iets dat nagekeken moet worden (hence console opmerking) maar je conclusie is wat voorbarig IMHO. Da pagina zélf (uitgaande van wat TS post) duurt al 1.5s en daar komt dan (potentieel) nog meer bij i.v.m. (inderdaad, potentiële) trage minifyers, ontbrekende cache-headers enz. enz. Maar, again, afgaand op wat TS post, het initiële probleem zit sowieso in de 1.5s die de pagina al nodig heeft. En dat zal wrsch. zitten in trage queries of vage plugins of... En als de caching niet (goed) werkt kan het zijn dat je dus altijd die 1.5s "betaalt" i.p.v. 1x per TTL.

[ Voor 29% gewijzigd door RobIII op 22-05-2016 23:03 ]

[André]

Ik heb de site bekeken, en zie eigenlijk niets raars, alles klopt wel aardig qua client-side code en caching instellingen. Je server is alleen rete traag in het uitleveren van de gecachede bestanden. Ergens hapert er iets flink, of de server staat op andere processen te stampen of hij hangt aan een brak DSL lijntje oid.

Zet eens een simpel HTML bestand met wat afbeeldingen online en test die eens. Dan kun je zien of het aan de PHP + Database ligt of iets anders.

[Verwijderd]

Wat voor content biedt je aan op de website waarvan je de pagina wilt cachen? Hoe vaak wil je deze cachen? Van welk moment zou je deze willen cachen?

[siteoptimo]

Ventieldopje schreef op zondag 22 mei 2016 @ 20:42:
[...]


Afbeeldingen en andere assets zorgen _juist_ voor een speedup, ook op dynamische pagina's. Het dynamisch opbouwen van de pagina is één ding maar als het eenmaal een HTML pagina is en verzonden is naar de browser moet die nog alle assets laden. Je browser laad maar een beperkt aantal assets tegelijk waardoor het vaak verstandig is meerdere assets (css / js bestanden) samen te voegen en te comprimeren.

Klopt enkel bij HTTP 1.1. Bij HTTP/2 ligt dat advies omgekeerd. Gezien HTTP/2 een feit is, kan je beter daarop focussen.

Kan je even een webpagetest dump tonen? Zal veel verklaren.

[ Voor 2% gewijzigd door siteoptimo op 23-05-2016 09:03 . Reden: Post verduidelijkt met link naar webpagetest. ]

[vandermark]

Ik heb wat tijden in wp super cache aangepast en heb het idee dat ik nu vaker een gecachde pagina krijg, ook page speed insights is positiever (consequent na vaker testen):

siteoptimo schreef op maandag 23 mei 2016 @ 08:33:
[...]
Kan je even een webpagetest dump tonen? Zal veel verklaren.

Welke bedoel je? Zoiets als dit?
http://tools.pingdom.com/fpt/#!/duzoAR/www.bartvandermark.nl

[ Voor 39% gewijzigd door vandermark op 23-05-2016 08:44 ]

[RobIII]

vandermark schreef op maandag 23 mei 2016 @ 08:42:
Welke bedoel je? Zoiets als dit?
http://tools.pingdom.com/fpt/#!/duzoAR/www.bartvandermark.nl

Zoiets of zoiets

[ Voor 10% gewijzigd door RobIII op 23-05-2016 09:27 ]

[Ventieldopje]

siteoptimo schreef op maandag 23 mei 2016 @ 08:33:
[...]


Klopt enkel bij HTTP 1.1. Bij HTTP/2 ligt dat advies omgekeerd. Gezien HTTP/2 een feit is, kan je beter daarop focussen.

Kan je even een webpagetest dump tonen? Zal veel verklaren.

offtopic:
Als webhosts HTTP/2 aan zouden bieden wel, maar dat valt tegen. Maar ja, je kan inderdaad ook dingen als RequireJS gebruiken, al is dit bij wordpress een ramp als je veel plugins hebt. Weegt vaak niet op tegen het aantal scripts in je thema. Andere optie is om gebruik te maken van een CDN gezien het maximale aantal simultane connecties per host is.

[siteoptimo]

Het ziet ernaar uit dat hij al mooi cached nu. Ik wist niet dat het om een fotosite ging, in dat geval heeft Ventieldopje overschot van gelijk, assets optimaliseren. Veel valt er echter niet meer van je afbeeldingen af te halen. Vraag eens aan je host als hij nog geen HTTP2 ondersteunt, want het zou in jouw geval zo'n groot verschil maken.

Ook duurt het te lang op dit moment vooraleer je browser echt kan beginnen renderen. Bijna 3 sconden in de webpagetest... Kijk dus even naar zaken die het renderen blokkeren. Je kan lazyloading proberen, fonts verminderen (op dit moment haal je fonts van Google fonts en laad je ook lokaal). Staat je live traffic aan bij WordFence?

offtopic:
TY voor de webpagetest RobIII, blijkbaar liggen er een heel aantal instances op WPT serieus overbelast op dit moment, ik raak er amper door...

Ventieldopje schreef op maandag 23 mei 2016 @ 09:22:
[...]

offtopic:
Als webhosts HTTP/2 aan zouden bieden wel, maar dat valt tegen. Maar ja, je kan inderdaad ook dingen als RequireJS gebruiken, al is dit bij wordpress een ramp als je veel plugins hebt. Weegt vaak niet op tegen het aantal scripts in je thema. Andere optie is om gebruik te maken van een CDN gezien het maximale aantal simultane connecties per host is.

Ik zie een aantal hosts toch echt wel de switch maken naar HTTP/2, hoewel het meer op vraag is dan een standaard. Het zou in het geval van de topicstarter wel serieus wat schelen, als ik zijn watervaldiagram bekijk.

[André]

Er wordt in de laatste comments volgens mij te veel gefocust op caching dingen en client-side code. Dat staat allemaal wel prima. Alleen de TTFB is veel te lang. Zet in het Google Analytics script de setSiteSpeedSamplerate eens op 100, dan worden bij alle bezoekers laadtijd metingen gedaan en heb je ook een beter beeld van de server-response tijden/download tijden.

Heb je al een kaal HTML bestand geprobeerd? Wordt die wel snel geserveerd?

[BramV]

Ik kijk altijd als eerste in Chrome naar netwerk load. Dus hoeveel tijd de verschillende onderdelen nodig hebben.



Google Analytics en Wordfence lijken de meeste latency te veroorzaken.


Volgens mij zijn er wel zaken te optimaliseren:
minified versie's...


De pageloading is erg lelijk...

[ Voor 9% gewijzigd door BramV op 24-05-2016 12:43 ]

[vandermark]

Dank voor alle tips & opmerkingen!
Ik heb wordfence live traffic uitgezet. De laatste googlefonts link verwijderd en belangrijkste: een nieuwe cache plugin ingezet. Ik zag dat meerdere mensen vergelijkbare problemen hebben: https://wordpress.org/sup...eshing-homepage?replies=4

Met de nieuwe plugin krijg ik consequent gecachde pagina's

[BramV]

Wat is dat blauwe loading ding wat je steeds krijgt te zien?

[vandermark]

Is iets van het thema, geeft laden vd pagina weer denk ik?

[BramV]

Heel lelijk, en ook als je soms van pagina wisselt krijg je het ook te zien. Ik zou me daar drukker over maken dan de cache... Site ziet er verder goed uit dus zonde. Het bevestigt voor mij wederom dat voor een statische site WP vaak een overkill is.

[ Voor 33% gewijzigd door BramV op 25-05-2016 11:04 ]

[Merethil]

BramV schreef op woensdag 25 mei 2016 @ 11:02:
Heel lelijk, en ook als je soms van pagina wisselt krijg je het ook te zien. Ik zou me daar drukker over maken dan de cache... Site ziet er verder goed uit dus zonde. Het bevestigt voor mij wederom dat voor een statische site WP vaak een overkill is.

Ik zou dat zelf eerder zien als smaak; zelf vind ik het er prima uitzien en ik heb liever dat een site laat zien dat 'ie bezig is (naast dat Chrome (of een andere browser natuurlijk) een laadbalkje oid laat zien). Een stuk beter dan zo'n site die niets laat zien en uiteindelijk dan verspringt, maar omdat het eens wat langer duurt je direct vijfmaal op de knop van de pagina die je wilt zien hebt lopen rammen.

Hoe dan ook, ik gok dat hij zich daar echt niet zo druk over hoeft te maken als dat jij hier nu aangeeft. Het gaat om traag laden, niet om een laadscherm.

[vandermark]

BramV schreef op woensdag 25 mei 2016 @ 11:02:
Heel lelijk, en ook als je soms van pagina wisselt krijg je het ook te zien. Ik zou me daar drukker over maken dan de cache... Site ziet er verder goed uit dus zonde. Het bevestigt voor mij wederom dat voor een statische site WP vaak een overkill is.

Merethil schreef op woensdag 25 mei 2016 @ 11:31:
[...]


Ik zou dat zelf eerder zien als smaak; zelf vind ik het er prima uitzien en ik heb liever dat een site laat zien dat 'ie bezig is (naast dat Chrome (of een andere browser natuurlijk) een laadbalkje oid laat zien). Een stuk beter dan zo'n site die niets laat zien en uiteindelijk dan verspringt, maar omdat het eens wat langer duurt je direct vijfmaal op de knop van de pagina die je wilt zien hebt lopen rammen.

Hoe dan ook, ik gok dat hij zich daar echt niet zo druk over hoeft te maken als dat jij hier nu aangeeft. Het gaat om traag laden, niet om een laadscherm.

Grappig dat er zo verschillend over gedacht wordt
Ik laat het staan, denk er net als Merethil over. Ondertussen blij met nieuwe caching plugin, website voelt stuk sneller en een 89% score bij page speed insights van Google

[Verwijderd]

vandermark schreef op donderdag 26 mei 2016 @ 12:25:
Ondertussen blij met nieuwe caching plugin, website voelt stuk sneller en een 89% score bij page speed insights van Google

Over welke nieuwe caching plugin gaat het?

[vandermark]

Verwijderd schreef op donderdag 26 mei 2016 @ 13:07:
[...]


Over welke nieuwe caching plugin gaat het?

https://wordpress.org/plugins/wp-fastest-cache/

Ik gebruik de gratis versie, die kan je instellen hoe vaak die de cache ververst en dat doet die dan

[HuHu]

Heb je wel genoeg bezoekers op je website? Als een item in de cache is verlopen, wordt deze opnieuw gemaakt bij de eerstvolgende bezoeker.

Als jij je site bezoekt en de pagina is vers aangemaakt, dan ben jij dus de eerste sinds de TTL is verlopen.

[vandermark]

HuHu schreef op donderdag 26 mei 2016 @ 13:57:
Heb je wel genoeg bezoekers op je website? Als een item in de cache is verlopen, wordt deze opnieuw gemaakt bij de eerstvolgende bezoeker.

Als jij je site bezoekt en de pagina is vers aangemaakt, dan ben jij dus de eerste sinds de TTL is verlopen.

Ik heb circa 40 unieke bezoekers per dag volgens google analytics, 95% uit NL, conform de verwachtingen. Daarnaast werkt de cache nu wel goed. In beide gevallen had ik TTL op 24 uur gezet maar bij vorige plugin bleef die maar verversen, nu niet meer.