caching - Zastavte prohlížeč a zadávejte HTTP požadavky na obrázky, které by měly zůstat v mezipaměti - mod_expires

Translate

Po přečtení mnoha článků a několika otázek zdeNakonec se mi podařilo aktivovat Apachemod_expiresříct prohlížeči, že MUSÍ ukládat obrázky do mezipaměti po dobu 1 roku.

<filesMatch "\.(ico|gif|jpg|png)$">
  ExpiresActive On
  ExpiresDefault "access plus 1 year"
  Header append Cache-Control "public"
</filesMatch>

A naštěstí se odpovědi serveru zdají být správné:

HTTP/1.1 200 OK 
Date: Fri, 06 Apr 2012 19:25:30 GMT 
Server: Apache 
Last-Modified: Tue, 26 Jul 2011 18:50:14 GMT 
Accept-Ranges: bytes 
Content-Length: 24884 
Cache-Control: max-age=31536000, public 
Expires: Sat, 06 Apr 2013 19:25:30 GMT
Connection: close
Content-Type: image/jpeg 

Myslel jsem, že to zastaví prohlížeč, aby stahoval a dokonce se dotazoval serveru na obrázky po dobu 1 roku. Ale je to částečně pravda: příčinapokud zavřete a znovu otevřete prohlížeč, prohlížeč NENÍ stáhne obrázkyze serveru,ale prohlížeč stále požádá server o požadavek HTTP pro každý obrázek.

Jak vynucuji, aby prohlížeč přestal dělat požadavky HTTP pro každý obrázek? I když tyto požadavky HTTP nejsou následovány stahovaným obrázkem, stále se jedná o požadavky odeslané na serverže zbytečně zvyšuje latenci a zpomaluje vykreslování stránky!

Už jsem prohlížeči řekl, že MUSÍ uchovávat obrázky v mezipaměti po dobu 1 roku! Proč prohlížeč stále dotazuje server na každý obrázek (i když obrázek nestáhne) ?!


Při pohledu na síťové grafy ve FireBugu (nabídka FireBug> Síť> Obrázky) vidím různá chování při ukládání do mezipaměti (samozřejmě jsem začal s úplně prázdnou mezipamětí prohlížeče, vynutil jsem vymazání mezipaměti v prohlížeči pomocí „Vymazat celou historii“):

  • Když se stránka načte poprvé, stáhnou se všechny obrázky(a totéž se stane, když vynucuji opětovné načtení stránky kliknutím na tlačítko pro načtení stránky v prohlížeči).To dává smysl!

  • Když procházím web a vrátím se na stejnou stránkuobrázky nejsou staženy vůbec aprohlížeč NEZAJÍMÁ ani dotaz na serverpro některý z obrázků.To dává smysl (a chtěl bych vidět toto chování i při zavřeném prohlížeči)!

  • Když zavřu prohlížeč a znovu ho otevřu na stejné stránce, hloupý prohlížeč stejně odešle požadavek HTTP na server pro každý obrázek: NEODSTAVUJE obrázek, ale stále vytvoří požadavek HTTP, je to jako prohlížeč se zeptá server o obrázku(server odpoví 200 OK).To mě dráždí!

Pokud máte zájem, připojuji také níže uvedené grafy:

enter image description here

enter image description here

EDIT: právě testováno nyní také s FireFox 11.0, jen aby se ujistil, že to není problém mého FireFox 3.6, který je příliš starý. Totéž se děje !!!Také jsem testoval web Google a web Stackoverflow, oba posílajíCache-Control: max-age=...aleprohlížeč stále odešle požadavek HTTP na server pro každý obrázek, i když je prohlížeč zavřen a znovu otevřen na stejné stránce, po odpovědi serveru prohlížeč NENÍ stáhne obrázek (jak jsem vysvětlil výše), ale stále dělá ten zatracený požadavek, který zvyšuje čas na zobrazení stránky.

EDIT2: a odstraněníLast-Modifiedzáhlaví, jak je navrženotady, problém nevyřeší, nezmění se.

This question and all comments follow the "Attribution Required."

Všechny odpovědi

Translate

Pro analýzu požadavků jste použili nesprávný nástroj.

Doporučil bych opravdu užitečný doplněk FirefoxuŽivé hlavičky HTTPtakže můžete vidět, co se v síti skutečně děje.

A pro jistotu můžete na serveru ssh / putty udělat něco podobného

tail -f /var/log/apache2/access.log
Zdroj
Translate

Chování, které vidíte, je zamýšlené (vizRFC7234více podrobností), zadané chování:

Všechny moderní prohlížeče budou odesílat požadavky HTTP na server pro každý zobrazený prvek stránky, bez ohledu na stav mezipaměti. Jednalo se o návrhové rozhodnutí učiněné na žádost webových služeb (zejména reklamních sítí), aby se zajistilo, že servery HTTP budou schopny udržovat záznamy o každém zobrazení každého prvku.

Pokud prohlížeče tyto požadavky neprovedly, server by nikdy nebyl upozorněn, že se uživateli zobrazil obrázek. Pro reklamní sítě by to bylo katastrofické. Hned na začátku to reklamní sítě „hackly“ tím, že zobrazovaly stejný obrázek reklamy pomocí náhodně generovaných názvů (např. „Coke_ad_1_98719283719283.gif“). U poskytovatelů internetových služeb však tato praxe způsobila obrovský nárůst datových přenosů, protože každý z jejich uživatelů znovu stahoval tyto identické reklamní obrázky a obcházel všechny mezipaměti / proxy servery, které jejich ISP provozoval.

Bylo tedy dosaženo příměří: Prohlížeče vždy odesílaly požadavky HTTP, a to i pro prvky v mezipaměti, jejichž platnost nevypršela. Servery by odpověděly stavovými kódy HTTP 304 („nezměněno“). To umožňuje serverům zaznamenat skutečnost, že se obrázek zobrazil klientovi. Ve výsledku reklamní sítěobvyklepřestal používat randomizované názvy obrázků k obejití serverů mezipaměti sítě.

To poskytlo reklamním sítím to, co chtěly - záznam každého zobrazeného obrázku - a poskytovatelům internetu to, co chtěli - obrázky umožňující ukládání do mezipaměti a statický obsah.

Proto není mnoho, co můžete udělat, abyste zabránili prohlížečům v odesílání požadavků HTTP na prvky stránky v mezipaměti.

Pokud se ale podíváte na další dostupná řešení na straně klienta, která přišla s html5, existuje prostor, který zabrání načítání prostředků

  1. Manifest mezipaměti(navzdory svým gotchas)
  2. IndexedDB(pěkné asynchronní funkce, umožňuje ukládání objektů blob)
  3. Místní úložiště(ne asynchronní)
Zdroj
Translate

Je rozdíl mezi „načtením“ a „obnovením“. Pouhá navigace na stránku pomocí tlačítek zpět a vpřed obvykle nevyvolává nové požadavky HTTP, ale konkrétně stisknutí klávesy F5 k „obnovení“ stránky způsobí, že prohlížeč zkontroluje svou mezipaměť. Toto je závislé na prohlížeči, ale zdá se, že je to norma pro FF a Chrome (tj. Prohlížeče, které mají schopnost snadno sledovat jejich síťový provoz.) Stisknutím klávesy F6, Enter by se měl zaměřit řádek s adresou URL a poté na něj „přejít“, což by mělo znovu načtěte stránku, ale ne dvakrát zkontrolujte aktiva na stránce.

Aktualizace: objasnění chování při navigaci tam a zpět. Říká se tomu „Back Forward Cache“ neboBFCachev prohlížečích. Při navigaci pomocí tlačítek zpět / vpřed je záměrem ukázat vám přesně takovou stránku, jaká byla, když jste ji viděli na své vlastní časové ose. Při použití zpět a vpřed se nevydávají žádné požadavky na server, i když záhlaví mezipaměti serveru říká, že konkrétní položka vypršela.

Pokud na panelu vývojářské sítě uvidíte (200 OK BFCache), pak server nebyl nikdy zasažen - ani když se zeptáte if-modified-since.

http://www.softwareishard.com/blog/firebug/firebug-tip-what-the-heck-is-bfcache/

Zdroj
Translate

Pokud vynucuji obnovení pomocí F5 nebo F5 + Ctrl, odešle se žádost. Pokud však zavřu prohlížeč a znovu zadám adresu URL, odešle se ŽÁDNÝ požadavek. Způsob, jakým jsem testoval, zda je požadavek odeslán nebo ne, byl pomocí zarážek při požadavku zahájení na serveru, i když požadavek není odeslán, stále se ve Firebugu zobrazuje jako čekající 7 ms, takže na to dávejte pozor.

Zdroj
Translate

To, co zde popisujete, neodráží mé zkušenosti. Pokud je obsah obsluhován direktivou no-store nebo provedete explicitní aktualizaci, pak ano, očekával bych, že se vrátí zpět na původní server, jinak by měl být uložen do mezipaměti přes restarty prohlížeče (za předpokladu, že je to povoleno a může psát soubor mezipaměti).

Při pohledu na vodopády trochu podrobněji (což je složité, protože jsou trochu malé a rozmazané) se zdá, že prohlížeč dělá přesně to, co by měl - topoložky pro obrázky - ale ty se jen načítajíz místní mezipamětine od původního serveru - v odpovědi zkontrolujte záhlaví „Datum“ (proč si myslíte, že to trvá milisekundy místo sekund?). Proto jsou barevně odlišeny.

Zdroj
Translate

Poté, co jsem strávil značný čas hledáním rozumné odpovědi, jsem považoval níže uvedený odkaz za nejužitečnější a odpovídá na zde položenou otázku.

https://webmasters.stackexchange.com/questions/25342/headers-to-prevent-304-if-modified-since-head-requests

Zdroj
Translate

Pokud jde o život nebo smrt (Pokud chcete optimalizovat načítání stránky tímto způsobem nebo pokud chcete co nejvíce snížit zátěž na serveru bez ohledu na to, co jde), pak existuje řešení.

Použijte HTML5místní úložištědo mezipaměti obrázky poté, co byly poprvé požadovány.

  • [+]Prohlížeči můžete zabránit v odesílání požadavků HTTP, které by v 99% vrátily 304 (beze změny), bez ohledu na to, jak moc se uživatel snaží (F5, ctrl + F5, jednoduše znovu navštívit stránku atd.)

  • [-]Tomu musíte věnovat další úsilí v podpoře javascriptů.

  • [-]Obrázky jsou uloženy v base64 (nemůžeme ukládat binární data), proto jsou pokaždé dekódovány na straně klienta. Který jeobvykledocela rychlé a není to velký problém, ale stále je to nějaké další využití CPU na straně klienta a měli byste mít na paměti.

  • [-]Místní úložiště je omezené. Můžete se zaměřit na použití ~ 5 MB dat na doménu (Poznámka: base64 přidává ~ 30% k původní velikosti obrázku).

  • [?]Podporovánovětšinaprohlížečů.http://caniuse.com/#search=localstorage

Příklad

Test

Zdroj
Translate

To, co vidíte v prohlížeči Chrome, není záznam skutečných požadavků HTTP - je to záznam požadavků na aktiva. Chrome to dělá, aby vám ukázal, že stránka ve skutečnosti stránku požaduje. Tento pohled však ve skutečnosti neindikuje, zda je požadavek odeslán. Pokud je dílo uloženo do mezipaměti, Chrome ve skutečnosti nikdy nevytvoří podkladový požadavek HTTP.

Můžete to také potvrdit umístěním kurzoru nad fialové segmenty na časové ose. Zdroje v mezipaměti budou mít(from cache)v nápovědě.

Chcete-li zobrazit skutečné požadavky HTTP, musíte se podívat na nižší úroveň. V některých prohlížečích to lze provést pomocí pluginu (například Live HTTP Headers).

Ve skutečnosti však k ověření, že se požadavky ve skutečnosti neprovádějí, musíte zkontrolovat protokoly serveru nebo použít ladicí proxy jako Charles nebo Fiddler. To bude fungovat na úrovni HTTP, aby se ujistil, že požadavky se ve skutečnosti nedělají.

Zdroj
Translate

Ověření mezipaměti a odpověď 304

Existuje řada situací, kdy aplikace Internet Explorer potřebuje zkontrolovat, zda je položka v mezipaměti platná:

  • Položka v mezipaměti nemá žádné datum vypršení platnosti a k obsahu se přistupuje poprvé v relaci prohlížeče

  • Položka v mezipaměti má datum vypršení platnosti, ale vypršela

  • Uživatel požádal o aktualizaci stránky kliknutím na tlačítko Obnovit nebo stisknutím klávesy F5

Pokud má položka v mezipaměti datum poslední úpravy, IE ji odešle do záhlaví If-Modified-Since zprávy požadavku GET:

GET /images/logo.gif HTTP/1.1
Accept: */*
Referer: http://www.google.com/
Accept-Encoding: gzip, deflate
If-Modified-Since: Thu, 23 Sep 2004 17:42:04 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1;)
Host: www.google.com

Server zkontroluje záhlaví If-Modified-Since a odpoví odpovídajícím způsobem. Pokud se obsah od zadaného data / času nezměnil, odpovídá stavovým kódem 304 a zprávou odpovědi, která právě obsahuje záhlaví:

HTTP/1.1 304 Not Modified
Content-Type: text/html
Server: GWS/2.1
Content-Length: 0
Date: Thu, 04 Oct 2004 12:00:00 GMT

Odpověď lze rychle stáhnout, protože neobsahuje žádný obsah a způsobí, že IE načte data, která vyžaduje z mezipaměti. Ve skutečnosti je to jako přesměrování do mezipaměti místního prohlížeče.

Pokud se požadovaný objekt skutečně změnil od data / času v záhlaví If-Modified-Since, server odpoví stavovým kódem 200 a dodá upravenou verzi prostředku.

Zdroj
Translate

Tato otázka má lepší odpověďtadyna webmasters stack-exchange site.

Další informace, které jsou také citovány ve výše uvedeném odkazu, jsou zapnutyhttp hodinky

V souladu s článkem:

Existuje řada situací, kdy aplikace Internet Explorer potřebuje zkontrolovat, zda je položka v mezipaměti platná:

  • Položka v mezipaměti nemá žádné datum vypršení platnosti a k obsahu se přistupuje poprvé v relaci prohlížeče
  • Položka v mezipaměti má datum vypršení platnosti, ale vypršela
  • Uživatel požádal o aktualizaci stránky kliknutím na tlačítko Obnovit nebo stisknutím klávesy F5

    zde zadejte kód

Zdroj
Leave a Reply
You must be logged in to post a answer.
O autorovi