caching - Zatrzymaj przeglądarkę, aby wysyłać żądania HTTP dotyczące obrazów, które powinny pozostać w pamięci podręcznej - mod_expires

Translate

Po przeczytaniu wielu artykułów i kilku pytań tutaj,W końcu udało mi się aktywować Apachemod_expiresaby powiedzieć przeglądarce, że MUSI buforować obrazy przez 1 rok.

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

I na szczęście odpowiedzi serwera wydają się być poprawne:

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 

Cóż, pomyślałem, że to zatrzyma pobieranie przeglądarki, a nawet spytanie serwera o obrazy przez 1 rok. Ale to częściowo prawda: przyczynajeśli zamkniesz i ponownie otworzysz przeglądarkę, przeglądarka NIE pobierze obrazówjuż z serwera,ale przeglądarka nadal pyta serwer o żądanie HTTP dla każdego obrazu.

Jak zmusić przeglądarkę do zaprzestania wysyłania żądań HTTP dla każdego obrazu? Nawet jeśli po tych żądaniach HTTP nie następuje pobieranie obrazu, nadal są one żądaniami wysyłanymi do serwerato niepotrzebnie zmniejsza opóźnienie i spowalnia renderowanie strony!

Powiedziałem już przeglądarce, że MUSI przechowywać obrazy w pamięci podręcznej przez 1 rok! Dlaczego przeglądarka nadal pyta serwer o każdy obraz (nawet jeśli nie pobiera obrazu) ?!


Patrząc na wykresy sieci w FireBug (menu FireBug> Sieć> Obrazy) widzę różne zachowania pamięci podręcznej (oczywiście zacząłem od pustej pamięci podręcznej przeglądarki, wymusiłem usunięcie pamięci podręcznej w przeglądarce za pomocą „Wyczyść całą historię”):

  • Gdy strona jest ładowana po raz pierwszy, wszystkie obrazy są pobierane(i to samo dzieje się, gdy wymuszam ponowne załadowanie strony, klikając przycisk odświeżania strony w przeglądarce).To ma sens!

  • Kiedy poruszam się po witrynie i wracam do tej samej stronyobrazy nie są w ogóle pobierane, a plikprzeglądarka nawet NIE pyta o serwerdla dowolnego obrazu.Ma to sens (i chciałbym zobaczyć to zachowanie również po zamknięciu przeglądarki)!

  • Kiedy zamykam przeglądarkę i otwieram ją ponownie na tej samej stronie, głupia przeglądarka i tak wysyła żądanie HTTP do serwera jeden raz na obraz: NIE pobiera obrazu, ale nadal wysyła żądanie HTTP, tak jakby przeglądarka pytała o serwer o obrazie(serwer odpowie 200 OK).To jest ten, który mnie irytuje!

Załączam również poniższe wykresy jeśli jesteś zainteresowany:

enter image description here

enter image description here

EDYCJA: właśnie przetestowałem teraz również z FireFox 11.0, aby upewnić się, że nie jest to problem z tym, że mój FireFox 3.6 jest zbyt stary. To samo się dzieje !!!Przetestowałem również witrynę Google i witrynę Stackoverflow, oba wysyłają plikCache-Control: max-age=...aleprzeglądarka nadal wysyła do serwera żądanie HTTP dla każdego obrazu po zamknięciu i ponownym otwarciu przeglądarki na tej samej stronie, po odpowiedzi serwera przeglądarka NIE pobiera obrazu (jak wyjaśniłem powyżej), ale nadal wysyła cholerne żądanie, które wydłuża czas wyświetlania strony.

EDIT2: i usunięcie plikuLast-Modifiednagłówek zgodnie z sugestiątutaj, nie rozwiązuje problemu, nie robi różnicy.

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

Wszystkie odpowiedzi

Translate

Używałeś niewłaściwego narzędzia do analizy żądań.

Poleciłbym naprawdę przydatny dodatek do FirefoksaNagłówki HTTP na żywodzięki czemu możesz zobaczyć, co naprawdę dzieje się w sieci.

I dla pewności możesz ssh / putty swój serwer i zrobić coś takiego

tail -f /var/log/apache2/access.log
Źródło
Translate

Zachowanie, które widzisz, jest zamierzone (patrzRFC7234więcej szczegółów), określone zachowanie:

Wszystkie nowoczesne przeglądarki będą wysyłały żądania HTTP do serwera dla każdego wyświetlanego elementu strony, niezależnie od stanu pamięci podręcznej. Była to decyzja projektowa podjęta na zlecenie usług internetowych (zwłaszcza sieci reklamowych), aby zapewnić, że serwery HTTP będą w stanie zachować zapis każdego wyświetlenia każdego elementu.

Gdyby przeglądarki nie wysyłały tych żądań, serwer nigdy nie zostałby powiadomiony, że obraz został wyświetlony użytkownikowi. W przypadku sieci reklamowych byłoby to katastrofalne. Na początku sieci reklamowe „zhakowały” ten problem, wyświetlając ten sam obraz reklamy przy użyciu losowo generowanych nazw (np. „Coke_ad_1_98719283719283.gif”). Jednak w przypadku dostawców usług internetowych praktyka ta spowodowała ogromny wzrost transferów danych, ponieważ każdy z ich użytkowników ponownie pobierał te identyczne obrazy reklam, omijając wszelkie serwery pamięci podręcznej / proxy, które działał ich dostawca usług internetowych.

Tak więc osiągnięto rozejm: przeglądarki zawsze wysyłały żądania HTTP, nawet w przypadku elementów z pamięci podręcznej, które nie wygasły. Serwery odpowiadałyby kodami stanu HTTP 304 („niezmodyfikowane”). Dzięki temu serwery mogą rejestrować fakt, że obraz został wyświetlony klientowi. W rezultacie sieci reklamoweogólnieprzestałem używać losowych nazw obrazów do ominięcia serwerów pamięci podręcznej sieci.

Dało to sieciom reklamowym to, czego chciały - zapis każdego wyświetlanego obrazu - i dało dostawcom usług internetowych to, czego chcieli - obrazy z możliwością buforowania i zawartość statyczną.

Dlatego też niewiele można zrobić, aby uniemożliwić przeglądarkom wysyłanie żądań HTTP dotyczących elementów strony zapisanych w pamięci podręcznej.

Ale jeśli spojrzysz na inne dostępne rozwiązania po stronie klienta, które pojawiły się wraz z HTML5, istnieje możliwość zapobiegania ładowaniu zasobów

  1. Manifest pamięci podręcznej(pomimo swoich problemów)
  2. IndexedDB(ładne funkcje asynchroniczne, umożliwia przechowywanie obiektów blob)
  3. Lokalny magazyn(nie asynchroniczne)
Źródło
Translate

Istnieje różnica między „ponownym ładowaniem” a „odświeżeniem”. Samo przejście do strony z przyciskami wstecz i dalej zwykle nie inicjuje nowych żądań HTTP, ale naciśnięcie klawisza F5 w celu „odświeżenia” strony spowoduje, że przeglądarka dwukrotnie sprawdzi pamięć podręczną. Jest to zależne od przeglądarki, ale wydaje się być normą dla FF i Chrome (tj. Przeglądarek, które mają możliwość łatwego obserwowania ruchu sieciowego). Wciśnięcie F6, enter powinno skupić pasek adresu URL, a następnie „przejść” do niego, co powinno załaduj ponownie stronę, ale nie sprawdzaj dwukrotnie zasobów na stronie.

Aktualizacja: wyjaśnienie zachowania nawigacyjnego wstecz i do przodu. Nazywa się „Back Forward Cache” lubBFCachew przeglądarkach. Podczas nawigacji za pomocą przycisków Wstecz / Dalej intencją jest pokazanie Ci dokładnie takiej strony, jaka była, gdy ją widziałeś na własnej osi czasu. Żadne żądania serwera nie są wysyłane podczas korzystania z funkcji wstecz i dalej, nawet jeśli nagłówek pamięci podręcznej serwera mówi, że określony element wygasł.

Jeśli zobaczysz (200 OK BFCache) w panelu sieci programisty, oznacza to, że serwer nigdy nie został trafiony - nawet po to, aby zapytać, czy został zmodyfikowany od tego czasu.

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

Źródło
Translate

Jeśli wymuszę odświeżenie za pomocą F5 lub F5 + Ctrl, wysyłane jest żądanie. Jeśli jednak zamknę przeglądarkę i ponownie wprowadzę adres URL, NIE zostanie wysłane żadne żądanie. Sposób, w jaki przetestowałem, czy żądanie jest wysyłane, czy nie, polegał na użyciu punktów przerwania na początku żądania na serwerze, nawet jeśli żądanie nie jest wysyłane, nadal pojawia się w Firebug jako po 7 ms oczekiwania, więc uważaj na to.

Źródło
Translate

To, co tu opisujesz, nie odzwierciedla mojego doświadczenia. Jeśli treść jest obsługiwana za pomocą dyrektywy no-store lub wykonujesz jawne odświeżanie, to tak, spodziewam się, że wróci do serwera źródłowego, w przeciwnym razie powinna zostać zapisana w pamięci podręcznej po ponownym uruchomieniu przeglądarki (zakładając, że jest dozwolona i może pisać plik pamięci podręcznej).

Patrząc na twoje wodospady bardziej szczegółowo (co jest trudne, ponieważ są trochę małe i rozmyte), przeglądarka wydaje się robić dokładnie to, co powinna - tomawpisy dla obrazów - ale to tylko się ładujez lokalnej pamięci podręcznejnie z serwera pochodzenia - sprawdź nagłówek „Date” w odpowiedzi (dlaczego myślisz, że zajmuje to milisekundy zamiast sekund?). Dlatego mają inny kolor.

Źródło
Translate

Po tym, jak spędziłem sporo czasu na poszukiwaniu rozsądnej odpowiedzi, poniższy link uznałam za najbardziej przydatny i odpowiada on na zadane tutaj pytanie.

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

Źródło
Translate

Jeśli jest to kwestia życia lub śmierci (jeśli chcesz zoptymalizować ładowanie strony w ten sposób lub jeśli chcesz maksymalnie zmniejszyć obciążenie serwera, bez względu na wszystko), to JEST to obejście.

Użyj HTML5Lokalny magazyndo buforowania obrazów po pierwszym żądaniu.

  • [+]Możesz uniemożliwić przeglądarce wysyłanie żądań HTTP, które w 99% zwróciłyby 304 (Not Modified), bez względu na to, jak bardzo użytkownik próbuje (F5, ctrl + F5, po prostu ponownie odwiedza stronę itp.)

  • [-]W tym celu musisz włożyć dodatkowe wysiłki w obsługę javascript.

  • [-]Obrazy są przechowywane w base64 (nie możemy przechowywać danych binarnych), dlatego za każdym razem są dekodowane po stronie klienta. Który jestzwykledość szybko i nie jest to wielka sprawa, ale nadal jest to dodatkowe użycie procesora po stronie klienta i należy o tym pamiętać.

  • [-]Pamięć lokalna jest ograniczona. Możesz dążyć do wykorzystania ~ 5 MB danych na domenę (uwaga: base64 dodaje ~ 30% do oryginalnego rozmiaru obrazu).

  • [?]Wspierany przezwiększośćprzeglądarek.http://caniuse.com/#search=localstorage

Przykład

Test

Źródło
Translate

To, co widzisz w Chrome, nie jest zapisem rzeczywistych żądań HTTP - to zapis żądań zasobów. Chrome robi to, aby pokazać, że strona faktycznie żąda zasobu. Jednak ten widok tak naprawdę nie wskazuje, czy żądanie jest wysyłane. Jeśli zasób jest buforowany, Chrome w rzeczywistości nigdy nie utworzy podstawowego żądania HTTP.

Możesz to również potwierdzić, najeżdżając kursorem myszy na fioletowe segmenty na osi czasu. Zasoby w pamięci podręcznej będą miały rozszerzenie(from cache)w podpowiedzi.

Aby zobaczyć rzeczywiste żądania HTTP, musisz spojrzeć na niższy poziom. W niektórych przeglądarkach można to zrobić za pomocą wtyczki (np. Live HTTP Headers).

W rzeczywistości jednak, aby sprawdzić, czy żądania nie są wysyłane, musisz sprawdzić dzienniki serwera lub użyć serwera proxy do debugowania, takiego jak Charles lub Fiddler. Będzie to działać na poziomie HTTP, aby upewnić się, że żądania nie występują w rzeczywistości.

Źródło
Translate

Walidacja pamięci podręcznej i odpowiedź 304

Istnieje wiele sytuacji, w których program Internet Explorer musi sprawdzić, czy zapis w pamięci podręcznej jest prawidłowy:

  • Wpis w pamięci podręcznej nie ma daty ważności, a dostęp do zawartości jest uzyskiwany po raz pierwszy w sesji przeglądarki

  • Wpis w pamięci podręcznej ma datę ważności, ale wygasł

  • Użytkownik zażądał aktualizacji strony, klikając przycisk Odśwież lub naciskając klawisz F5

Jeśli zapis w pamięci podręcznej ma datę ostatniej modyfikacji, IE wysyła ją w nagłówku If-Modified-Since komunikatu żądania 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

Serwer sprawdza nagłówek If-Modified-Since i odpowiednio reaguje. Jeśli treść nie została zmieniona od określonej daty / godziny, odpowiada kodem statusu 304 i komunikatem odpowiedzi zawierającym tylko nagłówki:

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

Odpowiedź można szybko pobrać, ponieważ nie zawiera treści i powoduje, że IE odczytuje wymagane dane z pamięci podręcznej. W efekcie jest to przekierowanie do lokalnej pamięci podręcznej przeglądarki.

Jeśli żądany obiekt faktycznie zmienił się od daty / godziny w nagłówku If-Modified-Since, serwer odpowiada kodem statusu 200 i dostarcza zmodyfikowaną wersję zasobu.

Źródło
Translate

To pytanie ma lepszą odpowiedźtutajna stronie wymiany stosów webmasterów.

Więcej informacji, które są również cytowane w powyższym linku, jest nahttpwatch

Według artykułu:

Istnieje wiele sytuacji, w których program Internet Explorer musi sprawdzić, czy zapis w pamięci podręcznej jest prawidłowy:

  • Wpis w pamięci podręcznej nie ma daty ważności, a dostęp do zawartości jest uzyskiwany po raz pierwszy w sesji przeglądarki
  • Wpis w pamięci podręcznej ma datę ważności, ale wygasł
  • Użytkownik zażądał aktualizacji strony, klikając przycisk Odśwież lub naciskając klawisz F5

    Wprowadź kod tutaj

Źródło
Leave a Reply
You must be logged in to post a answer.
O autorze