… Det er en problemstilling jeg ofte hører. Specielt i forbindelse med folk, der har hostet deres websider hos Meebox – ikke at der er noget galt i det, jeg har selv alle mine sider hos dem, og er godt tilfreds 🙂 Der er bare lige nogle ting man skal være opmærksomme på, når man sidder og redigerer sine sider.
For at aflaste serverne, og få dit site til at køre hurtigere, har Meebox implementeret caching på deres servere. Det er dog en caching, der gør at det er din computer, som gemmer en kopi af hjemmesiden på din computer. Altså er det en client-side caching-mekanisme. Det er rigtig smart, da det netop minimerer antallet af forespørgsler til serveren, og dermed hvor meget pres serverne kommer under.
Edit: Som Lucas pointerer i kommentarerne herunder, så gemmer serveren også en HTML-cache af siden. Når jeg skriver “client-side”, så hentyder jeg til at browseren også gemmer en kopi. Browseren skal dog stadig spørge serveren om der er kommet en ny version – med mindre serveren sender en “expires”-værdi tilbage, som fortæller browseren hvornår den skal spørge efter en ny version.
Det er dog ikke helt optimalt, når man sidder med udvikling, da det så kan tage tid, før ens browser-cache bliver nulstillet, og det er ikke specielt fedt at skulle nulstille sin cache manuelt, hver gang man har opdateret siden.
Heldigvis er der råd for dette problem, og det er faktisk utroligt simpelt. Jeg benytter selv Google Chrome, hvor det ikke tager mere end 2 klik med musen, før du er klar til at kunne se dine ændringer med det samme. Jeg er ret sikker på, at samme funktionalitet findes i Firefox (evt. med FireBug-plugin’et), men jeg har ikke prøvet det. Og derudover kan jeg kun anbefale Chrome 🙂
For kunne udvikle effektivt på Meebox serverne, og omgå deres caching-mekanismer, så skal du gøre følgende:
- Åben Google Chrome
- Tryk på CTRL + Shift + I (Windows) eller CMD + Shift + I (OS X) – bemærk at det er et i, og ikke et L.
Når du trykker her, kommer Google Developer Tools frem – det er et ikke mindre end genialt værktøj, når man sidder med webudvikling.
En anden måde at åbne Developer Tools på, er at højreklikke et sted på webside og trykke på “Vis detaljer om element”. Det giver samme effekt, nemlig at Developer Tools-vinduet kommer frem:
- Det næste du skal gøre, er at trykke på tandhjulet nede i højre hjørne:
- Efter du har trykket der, ændrer Developer Tools sig, og der kommer et overlay frem. Her skal du se i toppen, under “General”. Ud for den øverste checkboks til venste står der “Disable Cache (while DevTools is open)”. Marker denne boks. Du kan nu refreshe siden ved hjælp af CTRL + R, og dine opdateringer skulle gerne kunne ses.
Når du har fuldt de 4 hutige skridt, er Google Chrome så smart, at den husker dine indstillinger. Det betyder, at næste gang du vil have caching deaktiveret, så åbner du blot Google Developer Tools igen, og så bliver caching automatisk slået fra.
Jeg synes personligt at det er lidt irriterende at have DevTools-vinduet liggende i bunden af browser-vinduet, så derfor plejer jeg at have det i et selvstændigt vindue. For få DevTools i et selvstændigt vindue, skal du trykke på ikonet nederst til venstre:
Ved at have Developer Tools i et selvstændigt vindue, kan du nu bare minimere det, og så har du caching slået fra i den aktuelle tab – smart, ikke?
Ved at bruge dette lille trick, kommer du ud over “problemet” med Meebox’ (og andre hosts / hjemmesiders) caching.
En anden metode man kan benytte, i Google Chrome, er at trykke på CTRL + F5 (Windows) eller CMD + SHIFT + R (OS X – Tak til Heine Larsen 🙂 ). Dette vil også efterspørge ikke-cachede filer fra serveren. Bemærk at CTRL + R ikke efterspørger ikke-cachede filer.
Du skal dog være opmærksom på, at denne metode ikke (altid) virker ved server-side caching! Server-side caching, er når der bliver genereret en statisk fil på serveren som refereres til, i stedet for fx at HTML-koden genereres via PHP. De forskellige caching-systemer som Varnish mv., som webhosts normalt bruger, er reelt set også server-side caching-systemer, da de genererer en statisk HTML-fil. De adlyder dog også de headers som browseren sender, hvilket betyder at hvis man beder browseren efterspørge en ikke-cached fil, så vil man få det.
Ved at disable caching i Google Chrome Developer Tools beder Chrome rent faktisk serveren om at generere HTML’en fra ny, og på den måde undgå at modtage de statiske HTML-filer o.lign. – det er dog op til serveren / systemet at håndtere dette, hvilket betyder at serveren sagtens kan vælge blot at ignorere dette, og stadig sende den statiske HTML-fil tilbage, i stedet for at regenere den.
Uanset hvad, så kan dette trick hjælpe en del af vejen – men som altid når man sidder med udvikling på ens sites, er det smart at sørge for at udviklingen sker på et test-site, hvor alt client- og server-side caching er slået fra. Efterfølgende kan man så uploade sine filer til ens rigtige side, og nulstille serverens cache. Det er vigtigt at huske på, at fordi du har slået din cache fra, har dine brugere det ikke nødvendigvis. Hvis en bruger har været inde på din side før, og de har en cached version af fx din CSS-fil, så vil de ikke nødvendigvis få den nye fil med det samme.
Hvis du sidder i fx WordPress og har kodet dit tema / plugin selv, så benytter du forhåbentlig funktionerne wp_enqueue_style og wp_enqueue_script (hvis ikke, så se at komme i gang!). Disse funktioner har begge to en parameter der hedder $ver – dette er et versionsnummer, som sættes på når filen loades, fx:
http://eksempel.dk/wp-content/themes/mit-tema/css/min-css-fil.css?ver=3.5.2
Hvis ikke man manuelt angiver et versionsnummer, så bliver ens WP-version blot sat på. Det smarte er så, at din browser cacher filerne ud fra URL’en, dvs at de følgende to requests ikke er ens:
http://eksempel.dk/wp-content/themes/mit-tema/css/min-css-fil.css?ver=3.5.2
http://eksempel.dk/wp-content/themes/mit-tema/css/min-css-fil.css?ver=1.0
, altså, hvis du manuelt angiver et versionsnummer på URL’en når din CSS eller JavaScript-fil indlæses, så kan du tvinge browseren til at refreshe filen. Men nu ingen gode ideer med at gøre noget i stil med dette:
wp_enqueue_style( ..., ..., ..., time() );
da dette vil forhindre browseren i at cache filen – og det er ikke smart for din load-tid 🙂
Jeg håber i kunne bruge dette lille trick – det er i hvert fald et af dém jeg bruger oftest, når jeg sidder med webudvikling 🙂
Der findes også en udemærket plugin til Chrome der hedder Cache Killer. Du får en lille knap i Google Chrome, hvor du kan slå denne plugin til og fra som det passer dig.
Der er til tider at developer tools, ikke kan fjerne cache fra nogle enkelte dokumenter (Dette sker ved meget specifikke mime-types).
Dog, efter min mening, burde der være en nem mulighed, fra en hosts side at slå diverse cache-proxies fra, nogle sider fungere f.eks. ikke særlig godt med cache-proxies så som squid cache, varnish etc.
Det burde være en ‘opt-in’ og ikke en ‘opt-out’ funktion på webhoteller 🙂
Hej Lucas!
Fedt – det kendte jeg faktisk ikke. Det kunne godt tænkes at jeg lige skulle tage et kig på det 🙂
Jeg ved faktisk at man ved Meebox kan slå caching fra via htaccess – jeg mener dog kun at dette er muligt på Pro-hotellerne, og ikke de billige.
Dog lagde jeg her forleden mærke til, at der er mulighed for at slå Varnish-cache fra via cPanel – også på de billige hoteller.
Men jeg er helt enig – det burde i hvert fald fremgå tydeligt, hvordan man omgår cachingen, da det giver anledning til en del problemer (hence dette indlæg :-)). Selve ideen synes jeg dog er rigtig fin, idet at det aflaster serverne en hel del – men selvfølgelig (som alt andet cache) giver nogle uhensigtsmæssigheder.
/ Lars
Og caching proxies der bliver brugt af webhosts, er ikke client side caching, det er server side caching, så det er serveren der gemmer en kopi af siden. Du kan omgå denne caching ved at sende “cache-control: no-cache” header, hvilket vil få VCL reglen i varnish / squid til at lave en bypass til dens backend (hvilket er selve webserveren). Client-side caching aflaster meget meget lidt. Da browseren stadig vil lave et request for at tjekke om CSS filen er opdateret, dette kan gøres via last-modified header eller ETag header som er et fingerprint af filen.
Hvis der blev brugt en client-side cache, så ville det betyde, at hver gang filen blev opdateret, så ville browseren finde ud af det med det samme, men lige så snart du har en server-side cache, så vil browseren hente det som serveren sender, og siden serveren cacher filerne, betyder det at du ikke får de nye ændringer.
Når jeg siger client side caching, så hentyder jeg primært til at browseren også gemmer sin lokale kopi af HTML’en, og kun spørger serveren efter last-modified/ETag. Men det kan godt være at det ikke er præcist nok 🙂
Rent request-mæssigt er det klart at serveren ikke bliver voldsomt aflastet, da browseren stadig skal spørge om der er kommet en ny version eller ej – dog er det forholdsvist tydeligt at se fra brugerens synspunkt, at det hjælper en del.
Sad tidligere på natten og hyggede mig med caching på et site, og der fik jeg HTML-filerne serveret fra serveren på omkring 600ms, men med en browser-cached fik jeg svar efter ~50ms, og så kunne eksekveringen i browseren fortsætte. Men det kan sagtens tænkes at det performance-boost man ser client-side, ikke nødvendigvis betyder det store server-side.
Helt korrekt, med forskel på client side og server side caching.
Dog de caching proxies som webhosts bruger (Varnish etc), er server side cache, hvilket er problemet her.
Hvis man tjekker headers på din side f.eks:
ETag: "3e7388-3171-4e1eb18c845a2"
Last-Modified: Sat, 20 Jul 2013 05:55:56 GMT
X-Varnish: 84795429 84795375
Via: 1.1 varnish
X-Cache: HIT
X-Cache-Hits: 4
Du har ETag og Last-Modified som er det client side caching bruger (sammen med cache-control, hvilket ikke er sat i dette tilfælde)
X-Varnish ID, og X-Cache-Hit er selve server side caching.
Jeg kan se, at på denne side, så cacher varnish siden i 25 sekunder, og statiske filer i ca 30 minutter.
Jeg arbejder som performance engineer til dagligt, så kender de forskellige caching systemer, både gode og dårlige ting 😛
Nu ved jeg ikke hvordan Unixy cpanel varnish cache virker (det som din side bruger) – men headeren “X-Cacheable: YES” bliver sendt ved alle filer der er cacheable, jeg tror egentligt at hvis man i htaccess gør følgende:
Header set X-Cacheable "NO"
Så burde det resultere i den ikke cacher filerne, har dog ikke testet det 🙂
Tak for uddybningen 🙂 Det er også begrænset hvad jeg kender til caching som sådan – det er udelukkende hvad jeg lige kan huske ud fra et kursus jeg havde på datalogi for et par år siden + hvad end jeg har læst mig til sidenhen 🙂
Kan også godt se, at jeg mangler at få optimeret mine headers her på siden. Det kommer dog ikke som nogen overraskelse, da jeg ikke har brugt mere end maks 10 minutter på at sætte W3TC op tidligere i dag, og jeg er ikke sikker på hvad jeg kan styre af Meebox’ Varnish-cache 🙂
Edit:
Ifølge Meebox’ vidensbase kan man disable deres cache i htaccess via kommandoen “CacheDisable /” – om din metode virker skal jeg ikke kunne sige, jeg har ikke haft brug for at teste det, da jeg altid har slået caching fra i Chrome Dev Tools 🙂
Kan CTRL+ F5 et par gange ikke gøre det samme?
Hej Lars
Jo – det ser ud til at Chrome også sender “Cache-Control: no-cache”-headeren med, når man bruger CTRL + F5 – dog ikke når man fx bruger CTRL + R.
/ Lars
Godmorgen,
Det er korrekt omkring caching og problemer ift. udvikling. Det er imidlertid hammer smart til “daglig drift”, og jeg skrev faktisk selv tidligere om, hvorfor det er så smart i “Derfor er det en god idé at cache din hjemmeside”.
Som du skriver, kan det være enormt frustrerende når man udvikler. Vi har stadig nogle servere som kører med Litespeed, og der er det korrekt at du slår cachen fra i .htaccess filerne med:
CacheDisable /
DisableCache /
De servere som kører Apache har en Varnish cache foran. Der har vi fået lavet sådan, at du i dit cPanel (under Meebox Varnish Cache) kan slå Varnish fra på et eller flere af dine domæner (bemærk at der går et par minutter, før end det slår igennem).
Hvad angår client-side caching, fungerer din guide og Lucas’ værktøj udemærket.
Vh Anders.
Lige endnu et tip, hvis man sidder på en Mac: CMD + SHIFT + R
Ovenstående lærte jeg faktisk først den anden dag – og det utrolig brugbart når man sidder er frustreret over ens style.css ikke opdaterer.
Fedt! 🙂 Jeg kunne ikke lige huske genvejstasten på Mac, men jeg tilføjer den lige til artiklen 🙂