Black Friday = Pricewatch Bekijk onze selectie van de beste Black Friday-deals en voorkom een miskoop.

[HTML] Client side cache probleem

Pagina: 1
Acties:

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 30-10 14:12
Hoi,

Om de performance van mijn website op orde te hebben wil ik de publieke pagina's (en ook css en javascript) met statische content enkele dagen laten cachen, middels de bekende expires-HTTPheader.

Als je inlogt op het CMS dan blijf je op dezelfde pagina, maar wordt er een extra balk met opties getoond. Ook wordt het javascript en de stylesheet een beetje uitgebreid. De URL blijft verder wel helemaal hetzelfde.

Het probleem is dat langs deze weg statische pagina's toch veranderd zijn, maar dat de client dit niet merkt, omdat die zijn pagina uit de cache haalt. De gebruiker blijft dus dezelfde pagina zien, zonder de extra balk met opties.

Natuurlijk kan ik cache uitzetten, omdat er feitelijk geen statische pagina's zijn. Maarja, dan gooi ik wel een hoop snelheidswinst weg.

Compromis zou zijn om caching voor gebruikers met een IP op de whitelist (die dus mogen inloggen in het CMS) uit te zetten. Maar dan zondig ik tegen mijn opgelegde principe dat het CMS de pagina exact zo moet tonen als een gebruiker em 'ervaart'. Concreet: Het zou zuur zijn als een beheerder besluit een bepaalde video niet op de pagina te plaatsen, omdat hij vind dat de pagina er te traag door wordt. Voor gebruikers zal de pagina echter een stuk minder traag zijn omdat hun browser de cache zal aanspreken.

Ok, ik voel wel aan dat ik een beetje aan het pielen ben in de marges, maar wil toch graag jullie mening horen:

Is er een andere slimme truuk waar ik niet opkom, of zonee voor welke optie zouden jullie gaan?

  • H004
  • Registratie: Maart 2006
  • Laatst online: 28-05 19:55
Ik vind dat je inderdaad aan het 'pielen met marges' bent. Gewoon gzippen die hap en zorgen dat al je javascripts, images en stylesheets wel netjes gecached worden. Die 2kb extra die ge-gzipte html inneemt per request is met de huidige internetverbindingen niet eens merkbaar. En je toont filmpjes, dus je doelgroep heeft sowieso bandbreedte genoeg.

Op de performance letten is zeker geen slecht idee, maar je moet het niet té ver willen doortrekken imo.

  • ValHallASW
  • Registratie: Februari 2003
  • Niet online
De 'slimme truc' is server-side caching voor je semi-statische pagina's, en het gebruik van een extra stylesheet/javascript voor je ingelogde gebruikers. Dan heb je nog wel voor alle html-pagina's een request (maar die kan je snel afhandelen omdat je het toch als html hebt staan), en de js/css laat je wel client-side cachen.

Je kunt trouwens ook client-side caching toestaan maar checken met de if-modified-since header... dan geef je voor de niet-ingelogde gebruikers een 'niet veranderd' melding en voor de ingelogde gebruikers wel?

[ Voor 24% gewijzigd door ValHallASW op 21-06-2008 20:43 ]


  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
Of gewoon een redirect uitvoeren naar dezelfde pagina met een datetime GET parameter.
Vanwege de parameter zal de pagina niet meer uit de cache gehaald worden...

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 30-10 14:12
Bedankt voor jullie feedback!

Natuurlijk werk ik al met meerdere server side cache layers (document cache en template cache).

Javascript en CSS middels een aparte stylesheet is nu niet mogelijk omdat mijn framework automatisch alle scripts samenvoegt tot 1 script, en die vervolgens minified (en natuurlijk ook cachet), CSS idem + daar worden alle niet-repeatende images automatisch omgezet naar een enkele CSS-Sprite. Denk daarom dat ik beter de stylesheet een afwijkende (cache-)naam kan geven als je bent ingelogd oid... Goed idee iig!

If-modified-since gebruik ik al, net als etags. Alleen ik vermoed dat indien je een file eerder een expires ver in de toekomst hebt gegeven, de client geen nieuwe request zal doen maar de pagina direct uit zijn eigen cache zal halen. Daarmee is deze techniek niet waterdicht. Klopt dat?

Datetime GET parameter vind ik ranzig en wil ik als het even kan vermijden.

  • Gomez12
  • Registratie: Maart 2001
  • Laatst online: 17-10-2023
xilent_xage schreef op zondag 22 juni 2008 @ 10:29:
Alleen ik vermoed dat indien je een file eerder een expires ver in de toekomst hebt gegeven, de client geen nieuwe request zal doen maar de pagina direct uit zijn eigen cache zal halen.
De client doet geen nieuwe request want jij hebt gezegd dat de client dit niet hoeft te doen totdat de expires is verlopen.

Daarom zet ik op mijn websites altijd geen expires headers op de html zelf ( of 1tje van 5 minuten ) wel op de css / js / plaatjes.

De css / js /plaatjes krijgen in de html dan ook allemaal een versienr meegegeven ( automatische nummering gebaseerd op last modified date ) zodat als ik iets wijzig in de css deze gelijk een ander versienr meekrijgt, daardoor wordt het een nieuwe aanroep.

In jouw geval zou ik zelf een extra parameter meegeven of iemand de pagina via cms / niet via cms benadert. Dan krijg je gewoon een nieuw document vanuit je cms wat de browser weer los mag cachen...
Pagina: 1