img cache és a 304
Sziasztok!
Gondoltam, megpróbálom optimalizálni az alkalmazásomat, és most a firebugban a Net fület kezdtem el nézegetni.
Észrevettem, hogy a képek bár (többnyire) be vannak gyorstárazva, de azért a net fülön látható mindegyiknél egy bejegyzés, hogy "304 Not Modified". Ez azt jelenti, hogy ilyenkor is megy kérés a szerver felé minden alkalommal?
Arra gondoltam, hogy nem vacakolok css sprite technikával, hiszen a képek úgyis gyorstárazva lesznek -- de ha még gyorstárazva is elmegy egy kérés a szerver felé képenként, akkor megfontolandó, hogy mégis sprite-olni kellene.
A sprite mellett szól az is, hogy még sűrű használat esetén is egy-egy kép mellett "200 OK" státuszt látok. Ez azt jelenti, hogy letöltötte a képet, ugye? Ezt miért nem gyorstárazta vajon? (ugyanolyan frekventáltan használt képről van szó, mint a többiről, amik viszont 304-es bejegyzéssel jelentek meg) Lehet valahogy biztosítani, hogy ezek is gyorstárazva legyenek?
Mi az esélye annak, hogyha a sprite technika miatt 1 nagy képet használok, akkor az is így fog járni és újra betöltődik néha (pedig nem is módosítom)? Ha ezt nem tudom biztosan, akkor ez a sprite ellen szól, hiszen nem lenne jó, ha a nagy képet is sokszor elkezdené betöltögetni.
Azt is észrevettem, hogyha ide-oda változtatgatom az src tagot, akkor is lesz mindig 304-es státuszú "forgalom". Ha ez tényleg egy kérés a szerver felé, akkor itt is sprite-ot érdemes használni.
Hogy is van ez pontosan? Mit javasoltok?
Köszönöm!
■ Gondoltam, megpróbálom optimalizálni az alkalmazásomat, és most a firebugban a Net fület kezdtem el nézegetni.
Észrevettem, hogy a képek bár (többnyire) be vannak gyorstárazva, de azért a net fülön látható mindegyiknél egy bejegyzés, hogy "304 Not Modified". Ez azt jelenti, hogy ilyenkor is megy kérés a szerver felé minden alkalommal?
Arra gondoltam, hogy nem vacakolok css sprite technikával, hiszen a képek úgyis gyorstárazva lesznek -- de ha még gyorstárazva is elmegy egy kérés a szerver felé képenként, akkor megfontolandó, hogy mégis sprite-olni kellene.
A sprite mellett szól az is, hogy még sűrű használat esetén is egy-egy kép mellett "200 OK" státuszt látok. Ez azt jelenti, hogy letöltötte a képet, ugye? Ezt miért nem gyorstárazta vajon? (ugyanolyan frekventáltan használt képről van szó, mint a többiről, amik viszont 304-es bejegyzéssel jelentek meg) Lehet valahogy biztosítani, hogy ezek is gyorstárazva legyenek?
Mi az esélye annak, hogyha a sprite technika miatt 1 nagy képet használok, akkor az is így fog járni és újra betöltődik néha (pedig nem is módosítom)? Ha ezt nem tudom biztosan, akkor ez a sprite ellen szól, hiszen nem lenne jó, ha a nagy képet is sokszor elkezdené betöltögetni.
Azt is észrevettem, hogyha ide-oda változtatgatom az src tagot, akkor is lesz mindig 304-es státuszú "forgalom". Ha ez tényleg egy kérés a szerver felé, akkor itt is sprite-ot érdemes használni.
Hogy is van ez pontosan? Mit javasoltok?
Köszönöm!
Észrevettem, hogy a képek bár
- ha a szerver küld Last-Modified fejlécet, legközelebb a kliens visszaküldi az értékét If-Modified-Since fejlécben
- ha a szerver küld ETAG fejlécet, legközelebb a kliens visszaküldi az értékét (vagy értékeit) If-None-Match fejlécben
Ha a fentiek alapján a szerver megállapítja, hogy neki sincs újabb példánya, akkor 304-et válaszol. Tehát azok a képek esetében amelyeket a szerver ismét elküldA fentiekből egy következtetés vonható le: nincs sok tárgyalni való a webszervered viselkedéséről, ha nem beszélhetünk vele.
Ahhoz hogy a kliens egyáltalán ne küldjön kérést a szervernek, a szerver Expires fejlécben küldhet egy jó távoli lejárati dátumot. (RFC szerint nem kellene több legyen mint plusz egy év.)
Így van. Tehát elindul a http
köszi
Már csak abban nem vagyok biztos, hogy miért bukik néha a dolog és tölti be a képet újra, pedig a többi ugyanilyet gyorstárazta. Márpedig ha a nagy spritehalmaz képet tölti be újra, az már érezhető időben is a felhasználóknak, nemcsak sávszélességben az üzemeltetőnek ;-)
HTTP header
Expire
,Last Modified
,ETag
fejléceket, akkor azzal nyújthatod a cache élettartamát. Mivel a böngésző el fogja küldeni, neki milyen verzió van meg (If-Modified-Since
,If-None-Match
,If-Unmodified-Since
), ebből tudni fogja a szerver hogy 304-et adjon vissza, vagy amennyiben módosult, akkor az megfelelő fejléccel a módosult file-t.Léteznek erre nagyon jó Apache HTTPD modulok, amivel automatizálhatod a fejlécek kiküldését. Ilyen például a mod_expires.
minden hoston?
(Ez az "If-Unmodified-Since" ez érdekes, nem tudom mire lehet jó akkor lejáratni a cache-t, ha már jóideje változatlan)
Ez működésre bírható általában a hostokon?
Nem annyira tetszik ha webszervertől függő dolgokat kell csinálnom, mert ha szervert váltok, akkor arra is oda kell figyelnem.
Köszi az infókat, próbálkozok.
Minden hoston?
Nem értem a kérdést. Hogy te milyen szolgáltatóval és milyen feltételekkel kötsz szerződést, az a te dolgod. Ha nem tudják azt nyújtani, amit te elvársz, akkor nem kell vele szerződést kötni, vagy csökkenteni kell az igényeket.
Ha te írod a webszervered, mint például Node.js, Ruby, Python esetén, akkor ezeket a fejléceket te tudod kiadni, figyelni, stb, és akkor nem függsz a szolgáltatótól. Már ha host alatt a hoszting szolgáltatót érted. Mivel HTTP esetén a
Host
az a domain neve, ami az adatot kiszolgálja.A szolgáltatás bekapcsolása nem szerver függő, elvégre tudtommal minden népszerű HTTP szerver rendelkezik mod_expire-hez hasonló szolgáltatással, már csak az a kérdés, hogy azon a szerveren be van-e kapcsolva. És nem te csinálod ezeket a dolgokat, hanem a http szerver nyújtja, amennyiben be van kapcsolva. Ha nincs, attól még a dolgok működnek, csak legfeljebb nem a legoptimálisabb módon.
Hát ha szervert váltasz, akkor egyébként is rengeteg dologra oda kell figyelni. Egyszerűen írd hozzá ahhoz a listához, amit végig kell nézni, amikor a tárhelyed elköltözik. Gondolok itt a programozási nyelv(ek), az adatbázis-kezelő(k) verziószámára, azok bekapcsolt szolgáltatásaira, jelszavakra stb.
ok
De ez azért projekt szintektől függ. Van aki mindent egy kézben tart, nagy projektet csinál, és akkor felméri, hogy tárhely szempontjából saját szervert bérel, vagy üzemeltet, felhőbe megy, vagy akármi --- van aki csak egy olcsó tárhelyszolgáltatást akar bérelni a kis projektjéhez, és nem is igazán akar (ha nem muszáj) a szerver üzemeltetéssel foglalkozni, beleértve a szerver konfigbeállításait, sőt, azt is, hogy milyen fejléceket küldözget (hacsak nem lehet egyszerűen PHP-vel megoldani).
Igazad van, ilyenkor lejjebb kell menni az igényekkel -- és ha lejjebb mentem, akkor jön az én kérdésem, hogy az Apache HTTPD modulok állítgatása olyan igény-e, amit az olcsó tárhely szolgáltatók (hosting szolgáltatók) általában képesek nyújtani? Mert ha nem, akkor nem jön számításba. Ha igen, akkor is jó lenne, ha lenne olyan megoldás, amit szervertípustól vagy beállításoktól függetlenül át lehetne költöztetni.
(Minél többet kell a "listához írni" annál nehezebb az esetleges szolgáltatóváltás, és/vagy nagyobb a költség)
Köszi az infókat!
köszönöm
Azt még nem nagyon értem, hogy egyes esetekben miért tölt le mégis újra képeket (a 200 OK az ugye ezt jelenti), hiszen a feltételek ugyanazok.
Ha Expires fejlécet akarok kiküldeni (de nem akarok szerverkonfiggal macerálni) akkor gondolom csak az marad, hogy PHP-vel szolgáljam ki a képkéréseket is, ugye?
Ez ebben az esetben nem túl megterhelő, hiszen távoli lejárati dátum megadása esetén lényegében csak egyszer kell felhasználónként lefutnia. Viszont így megúszhatom a sprite-osítást. (Vagy ez nem jó ötlet?)
optimalizálás
Részletesebben szól a 304-es fejlécről is.
Köszi, megnézem
Firefox
áhá!
Most kipróbáltam és tényleg, enterrel szinte semmi 304 nincs.
Ha nem akarsz
Azonkívül nem okoz hibát (mondjuk költözéskor), mert megvizsgálja, hogy van-e mod_expires, és ha nincs, akkor legfeljebb nem csinál semmit.
Nagyszerű, köszi!