ugrás a tartalomhoz

img cache és a 304

zzrek · 2011. Feb. 22. (K), 13.49
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!
 
1

Észrevettem, hogy a képek bár

kuka · 2011. Feb. 22. (K), 14.35
É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?
Igen. Alapból a feltételes kérés így működik:
  • 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üld
  • a fent említett ellenőrzéseiből az derült ki, hogy a szerver példánya újabb
  • a fent említett ellenőrzések nem végezhetőek el, mert a kliens nem küldött feltételes fejlécet: mert nem kapott (dinamikusan generált tartalomhoz a szerver nem társít ETAG-et, a Last-Modified meg nem mérvadó), vagy kapott de valamiért azt már nem találta érvényesnek (hibás Content-Length miatt előzőleg nem mentette gyorsítótárba, ürült a gyorsítótár, beállítás megköveteli hogy elavulástól függetlenül is néha kérjen friss változatot)

A 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.)
2

Így van. Tehát elindul a http

bb0072 · 2011. Feb. 22. (K), 15.19
Így van. Tehát elindul a http kérés újra, de ha 304-es fejléc van, akkor a kép ismételt letöltése nem történik meg. A sprite technika itt is időt takarít meg, mivel még a 304-es kérést sem indítja el, csak egyszer.
5

köszi

zzrek · 2011. Feb. 22. (K), 16.43
Köszi a válazt!
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 ;-)
7

HTTP header

Poetro · 2011. Feb. 22. (K), 17.02
Azért töltődik le időnként újra mert túl rövid a cachelési ideje a böngészőnek. Amennyiben megadsz 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.
8

minden hoston?

zzrek · 2011. Feb. 22. (K), 20.07
Biztos valami ilyen lehet. Mondjuk az egyik fájl már lejárt és ezért kéri be újra.
(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.
9

Minden hoston?

Poetro · 2011. Feb. 22. (K), 20.31
Ez működésre bírható általában a hostokon?

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.

Nem annyira tetszik ha webszervertől függő dolgokat kell csinálnom

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.

ha szervert váltok, akkor arra is oda kell figyelnem

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.
11

ok

zzrek · 2011. Feb. 22. (K), 21.52
OKé, értem.
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!
4

köszönöm

zzrek · 2011. Feb. 22. (K), 16.39
Köszi az infókat, sejtettem hogy valami ilyesmi van.
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?)
3

optimalizálás

bb0072 · 2011. Feb. 22. (K), 15.21
Optimalizáláshoz ez igen hasznos olvasmány: http://developer.yahoo.com/performance/rules.html

Részletesebben szól a 304-es fejlécről is.
6

Köszi, megnézem

zzrek · 2011. Feb. 22. (K), 16.43
Köszi, megnézem!
10

Firefox

janoszen · 2011. Feb. 22. (K), 21.08
A Firefoxszal vigyázz, mert ha az F5-öt nyomogatod, akkor kikényszeríted az egyébként cachelt tartalmak újrakérdezését, ami a 304-hez vezet. Ahhoz, hogy valós képet kapj, a címsorban nyomj entert az oldalra.
12

áhá!

zzrek · 2011. Feb. 22. (K), 21.55
Áhá, köszi, gondolom a "refresh" ikon is ilyen akkor, jó tudni!

Most kipróbáltam és tényleg, enterrel szinte semmi 304 nincs.
13

Ha nem akarsz

bb0072 · 2011. Feb. 23. (Sze), 11.32
Ha nem akarsz szerverkonfigurációval vesződni, meg problémákat költözéskor, és mindemellett a szolgáltatód engedélyezi a .htaccess használatát, akkor írj bele egy ilyet:

<IFModule mod_expires.c>
	<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
		FileETag -INode MTime
		ExpiresActive on
 		ExpiresDefault "access plus 2 months"
	</FilesMatch>
</IFModule>
Ez minden statikus file-ra módosítási időtől függő etag-ot tesz, valamint 2 hónappal előre állítja az elévülési időt. Saját projektemben azért az MTime-ot használom az INode helyett, mert a requestek kiszolgálása több szerverre van bízva, és különböző szervereken különböző a file-hoz tartozó inode.

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.
14

Nagyszerű, köszi!

zzrek · 2011. Feb. 23. (Sze), 15.09
Nagyszerű, köszi!