Pamięć podręczna odgrywa ważną rolę w działaniu niemal każdej aplikacji webowej na poziomie pracy z bazami danych, serwerami WWW, a także po stronie klienta.

W tym artykule postaramy się zrozumieć buforowanie klienta. W szczególności przyjrzymy się, jakie nagłówki HTTP są używane przez przeglądarki i serwery internetowe i co one oznaczają.

Ale najpierw dowiedzmy się Dlaczego w ogóle potrzebujesz buforowania po stronie klienta?.

Strony internetowe składają się z wielu różnych elementów: obrazów, plików css i js itp. Niektóre z tych elementów są wykorzystywane na kilku (wielu) stronach serwisu. Buforowanie po stronie klienta oznacza zdolność przeglądarek do zapisywania kopii plików (odpowiedzi serwera), aby nie pobierać ich ponownie. Pozwala to znacznie przyspieszyć przeładowywanie strony, zaoszczędzić na ruchu, a także zmniejszyć obciążenie serwera.

Istnieje kilka różnych nagłówków HTTP do kontrolowania procesów buforowania po stronie klienta. Porozmawiajmy o każdym z nich.

Nagłówki HTTP do kontrolowania buforowania klienta

Najpierw przyjrzyjmy się, jak serwer i przeglądarka współdziałają przy braku buforowania. Dla jasnego zrozumienia starałem się wyobrazić sobie i zwizualizować proces komunikacji między nimi w formie czatu tekstowego. Wyobraź sobie przez kilka minut, że serwer i przeglądarka to osoby, które ze sobą korespondują :)

Bez pamięci podręcznej (w przypadku braku buforowania nagłówków http)

Jak widzimy, za każdym razem, gdy wyświetli się obraz cat.png, przeglądarka ponownie pobierze go z serwera. Myślę, że nie trzeba wyjaśniać, że jest to powolne i nieskuteczne.

Nagłówek odpowiedzi ostatniej modyfikacji i nagłówek żądania if-Modified-Since.

Pomysł jest taki, że serwer dodaje nagłówek Last-modified do pliku (odpowiedzi), który przekazuje przeglądarce.

Przeglądarka wie teraz, że plik został utworzony (lub zmodyfikowany) 1 grudnia 2014 r. Gdy następnym razem przeglądarka będzie potrzebować tego samego pliku, wyśle ​​żądanie z nagłówkiem if-Modified-Since.

Jeżeli plik nie został zmodyfikowany, serwer wysyła do przeglądarki pustą odpowiedź ze statusem 304 (Not Modified). W takim przypadku przeglądarka wie, że plik nie został zaktualizowany i może wyświetlić kopię, którą zapisał ostatnim razem.

Zatem korzystając z opcji Last-modified oszczędzamy na ładowaniu duży plik, wysiadając z pustą szybką odpowiedzią od serwera.

Nagłówek odpowiedzi Etag i nagłówek żądania If-None-Match.

Zasada działania Etag jest bardzo podobna do Last-modified, jednak w przeciwieństwie do niego nie jest powiązana z czasem. Czas jest rzeczą względną.

Pomysł jest taki, że podczas jego tworzenia i za każdym razem, gdy ulega zmianie, serwer oznacza plik specjalnym znacznikiem o nazwie ETag, a także dodaje do pliku nagłówek (odpowiedź), który wysyła do przeglądarki:

ETag: „686897696a7c876b7e”

Teraz przeglądarka wie, że plik obecna wersja ma ETag równy „686897696a7c876b7e”. Następnym razem, gdy przeglądarka będzie potrzebować tego samego pliku, wyśle ​​żądanie z nagłówkiem If-None-Match: „686897696a7c876b7e”.

Jeśli brak dopasowania: „686897696a7c876b7e”

Serwer może porównać etykiety i jeśli plik nie został zmodyfikowany, wysłać do przeglądarki pustą odpowiedź ze statusem 304 (Not Modified). Podobnie jak w przypadku opcji Last-modified, przeglądarka zorientuje się, że plik nie został zaktualizowany i będzie mogła wyświetlić kopię z pamięci podręcznej.

Tytuł wygasł

Zasada działania tego nagłówka różni się od opisanych powyżej Etag i Last-modified. Za pomocą opcji Expired określana jest „data ważności” („okres ważności”) pliku. Te. Przy pierwszym ładowaniu serwer informuje przeglądarkę, że nie planuje zmieniać pliku przed datą określoną w polu Wygasł:

Następnym razem przeglądarka, wiedząc, że „data ważności” jeszcze nie nadeszła, nawet nie będzie próbowała wysłać żądania do serwera i wyświetli plik z pamięci podręcznej.

Ten typ pamięci podręcznej jest szczególnie przydatny w przypadku ilustracji artykułów, ikon, faviconów, niektórych plików css i js itp.

Nagłówek kontroli pamięci podręcznej z dyrektywą dotyczącą maksymalnego wieku.

Zasada działania kontroli pamięci podręcznej: maksymalny wiek jest bardzo podobna do zasady Wygasłe. Tutaj określana jest również „data ważności” pliku, ale jest ona podawana w sekundach i nie jest powiązana z konkretnym czasem, co w większości przypadków jest znacznie wygodniejsze.

Na przykład:

• 1 dzień = 86400 sekund
• 1 tydzień = 604800 sekund
• 1 miesiąc = 2629000 sekund
• 1 rok = 31536000 sekund

Np:

Kontrola pamięci podręcznej: maksymalny wiek = 2629000;

Nagłówek Cache-control ma inne dyrektywy oprócz max-age. Rzućmy okiem na najpopularniejsze z nich:

publiczny
Faktem jest, że żądania mogą być buforowane nie tylko przez klienta końcowego użytkownika (przeglądarkę), ale także przez różne pośrednie proxy, sieci CDN itp. Zatem dyrektywa publiczna pozwala absolutnie każdemu serwerowi proxy na wykonywanie buforowania, podobnie jak przeglądarka.

prywatny
Dyrektywa tak stanowi ten plik(odpowiedź serwera) jest specyficzna dla użytkownik końcowy i nie powinny być buforowane przez różne pośrednie serwery proxy. Jednocześnie umożliwia buforowanie do klienta końcowego (przeglądarki użytkownika). Dotyczy to na przykład strony wewnętrzne profil użytkownika, żądania w ramach sesji itp.

Umożliwia określenie, że klient powinien za każdym razem wysyłać żądanie do serwera. Czasami używany z nagłówkiem Etag opisanym powyżej.

brak sklepu
Poucza klienta, że ​​w żadnym wypadku nie powinien zatrzymywać kopii wniosku ani jego części. Jest to najbardziej rygorystyczny nagłówek, zastępując wszelkie pamięci podręczne. Został wynaleziony specjalnie do pracy z poufnymi informacjami.

należy ponownie zweryfikować
Ta dyrektywa instruuje przeglądarkę, aby wysłała obowiązkowe żądanie do serwera w celu ponownej weryfikacji treści (na przykład, jeśli używasz eTag). Faktem jest, że http w określonej konfiguracji pozwala pamięci podręcznej przechowywać treści, które są już nieaktualne. must-revalidate zobowiązuje przeglądarkę do sprawdzania w każdych okolicznościach aktualności treści poprzez wysłanie żądania do serwera.

Ponowna weryfikacja proxy
Działa to tak samo, jak must-revalidate, ale dotyczy tylko buforujących serwerów proxy.

s-maxage
Praktycznie nie różni się od max-age , z tą różnicą, że ta dyrektywa jest brana pod uwagę tylko przez pamięć podręczną różnych serwerów proxy, a nie przez samą przeglądarkę użytkownika. List " S-” pochodzi od słowa „ S hared” (np. CDN). Ta dyrektywa jest przeznaczona specjalnie dla sieci CDN i innych pośrednich pamięci podręcznych. Określenie go zastępuje wartości dyrektywy max-age i nagłówka Expired. Jeśli jednak nie budujesz sieci CDN, jest mało prawdopodobne, że kiedykolwiek będziesz potrzebować s-maxage.

Jak mogę sprawdzić, jakie nagłówki są używane w witrynie?

Możesz przeglądać nagłówki żądań http i nagłówki odpowiedzi w debugerze swojej ulubionej przeglądarki. Oto przykład tego, jak to wygląda w przeglądarce Chrome:

To samo można zobaczyć w każdej szanującej się przeglądarce lub snifferze http.

Konfigurowanie buforowania w Apache i Nginx

Nie będziemy powtarzać dokumentacji dotyczącej konfiguracji popularnych serwerów. Zawsze możesz to obejrzeć i. Poniżej podamy kilka przykładów z życia wziętych, aby pokazać, jak wyglądają pliki konfiguracyjne.

Przykład konfiguracji Apache do kontroli wygaśnięcia

Dla różnych typów plików ustalamy różne „daty ważności”. Jeden rok na obrazy, jeden miesiąc na skrypty, style, pliki PDF i ikony. Na wszystko inne – 2 dni.

ExpiresActive On ExpiresByType image/jpg „dostęp plus 1 rok” ExpiresByType image/jpeg „dostęp plus 1 rok” ExpiresByType image/gif „dostęp plus 1 rok” ExpiresByType image/png „dostęp plus 1 rok” ExpiresByType tekst/css „dostęp plus 1 miesiąc" Aplikacja ExpiresByType/pdf "dostęp plus 1 miesiąc" ExpiresByType tekst/x-javascript "dostęp plus 1 miesiąc" ExpiresByType image/x-icon "dostęp plus 1 rok" ExpiresDefault "dostęp plus 2 dni"

Przykładowa konfiguracja Nginx do kontroli wygasania

Dla różnych typów plików ustalamy różne „daty ważności”. Tydzień na obrazy, jeden dzień na style i skrypty.

Serwer ( #... lokalizacja ~* \.(gif|ico|jpe?g|png)(\?+)?$ ( wygasa 1w; ) lokalizacja ~* \.(css|js)$ ( wygasa 1d; ) #... )

Przykładowa konfiguracja Apache do kontroli pamięci podręcznej (maksymalny wiek i publiczna/prywatna/bez pamięci podręcznej)

Przykład konfiguracji Nginx do kontroli pamięci podręcznej plików statycznych

Wreszcie

„Buforuj wszystko, co można zapisać w pamięci podręcznej” to dobre motto dla programisty internetowego. Czasami możesz poświęcić zaledwie kilka godzin na konfigurację i jednocześnie znacząco poprawić komfort korzystania z Twojej witryny, znacznie zmniejszyć obciążenie serwera i zaoszczędzić na ruchu. Najważniejsze, aby nie przesadzić i skonfigurować wszystko poprawnie, biorąc pod uwagę charakterystykę zasobu.

• Buforowanie htaccess zapisuje zawartość strony internetowej komputer lokalny kiedy użytkownik ją odwiedza;
• Korzystanie z pamięci podręcznej przeglądarki — webmaster instruuje przeglądarki, jak traktować zasoby.

Kiedy przeglądarka renderuje stronę internetową, musi załadować logo, plik CSS i inne zasoby:

Pamięć podręczna przeglądarki „pamięta” zasoby, które przeglądarka już pobrała. Gdy odwiedzający przejdzie na inną stronę w serwisie, logo, pliki CSS itp. nie należy pobierać ponownie, ponieważ przeglądarka już je „zapamiętała” (zapisał). Z tego powodu ładowanie strony internetowej przy pierwszej wizycie trwa dłużej niż przy kolejnych wizytach.

Gdy korzystasz z buforowania, pliki stron internetowych będą przechowywane w pamięci podręcznej przeglądarki. Przy kolejnych wizytach strony będą ładować się znacznie szybciej. Stanie się tak również w przypadku innych stron korzystających z tych samych zasobów.

Jak włączyć buforowanie przeglądarki

• Zmodyfikuj nagłówki żądań zasobów, aby używać buforowania;
• Zoptymalizuj strategię buforowania.

Zmiana nagłówków żądań

Dla większości ludzi jedynym sposobem buforowania htaccess witryny jest dodanie kodu do pliku .htaccess na serwerze WWW.

Plik .htaccess kontroluje wiele ważnych ustawień Twojej witryny.

Buforowanie przeglądarki poprzez plik .htaccess

Poniższy kod informuje przeglądarkę, co ma buforować i jak długo ma to „pamiętać”. Należy dodać na początku pliku .htaccess:

## WYGASZA cachowanie ## ExpiresActive On ExpiresByType image/jpg „dostęp 1 rok” ExpiresByType image/jpeg „dostęp 1 rok” ExpiresByType image/gif „dostęp 1 rok” ExpiresByType image/png „dostęp 1 rok” ExpiresByType tekst/css „dostęp 1 miesiąc” ExpiresByType tekst/ html „dostęp 1 miesiąc” ExpiresByType aplikacja/pdf „dostęp 1 miesiąc” ExpiresByType tekst/x-javascript „dostęp 1 miesiąc” ExpiresByType aplikacja/x-shockwave-flash „dostęp 1 miesiąc” ExpiresByType image/x-icon „dostęp 1 rok” WygasaDomyślnie „dostęp 1 miesiąc”## WYGASZA cachowanie ##

Zapisz plik .htaccess, a następnie odśwież stronę internetową.

Jak ustawić czas pamięci podręcznej dla różnych typów plików

Powyższy kod określa przedziały czasowe. Na przykład 1 rok (1 rok) lub 1 miesiąc (1 miesiąc). Są one powiązane z typami plików. Powyższy kod stwierdza, że ​​pliki .jpg (obrazy) powinny być buforowane przez rok.

Jeśli chcesz to zmienić tak, aby obrazy JPG również były buforowane przez miesiąc, po prostu zamieniłbyś „1 rok” na „1 miesiąc”. Powyższe wartości buforowania htaccess są optymalne dla większości stron internetowych.

Alternatywna metoda buforowania dla .htaccess

Opisana powyżej metoda nazywa się „ Wygasa", pomaga większości początkujących w buforowaniu. Gdy już oswoisz się z buforowaniem, możesz wypróbować inną metodę buforowania o nazwie Cache-Control, która daje więcej opcji.

Możliwe, że metoda Expires nie będzie działać na Twoim serwerze, w takim przypadku możesz spróbować użyć Cache-Control.

Kontrola pamięci podręcznej

Ta metoda pozwala uzyskać większą kontrolę nad buforowaniem stron w przeglądarce, ale wielu osobom łatwiej jest określić wszystkie ustawienia jednorazowo.

Przykładowe użycie w pliku .htaccess:

#1 miesiąc dla większości zasoby statyczne Zestaw nagłówków Cache-Control „max-age=2592000, publiczny”

Powyższy kod ustawia nagłówek Cache-Control w zależności od typu pliku.

Jak działa kontrola pamięci podręcznej?

Rozważ powyższą linię kodu buforującego w przeglądarce htaccess:

#1 miesiąc dla większości zasobów statycznych

Ta linia to tylko uwaga. Plik .htaccess ignoruje linie zaczynające się od znaku #. Ta uwaga jest zalecana, ponieważ możesz mieć ich wiele różne zestawy dane jako rozwiązanie do buforowania plików:

Wspomniany powyżej wiersz mówi, że: „ jeśli plik jest jednego z tych typów, to coś z nim zrobimy...»

Najważniejszą rzeczą w tej linii jest to, że zawiera listę Różne rodzaje akta ( CSS, JS, JPG, PNG itp. ) i że do tych typów plików należy zastosować instrukcje dotyczące buforowania. Na przykład, jeśli nie chcesz, aby pliki JPG były buforowane przez określony czas, możesz usunąć „ JPG„. Jeśli chcesz dodać HTML, musisz wskazać w tym wierszu „ HTML«:

Zestaw nagłówków Cache-Control „max-age=2592000, publiczny”

Linia wspomniana powyżej ustawia rzeczywiste nagłówki i wartości:

• Część " Zestaw nagłówków Kontrola pamięci podręcznej» — ustawia tytuł;
• Zmienny " maksymalny wiek = 2592000„-wskazuje, jak długo zajmie proces buforowania (w sekundach). W tym przypadku buforujemy przez jeden miesiąc (2592000) sekund;
• Część " publiczny” podaje, że jest ona publicznie dostępna.

Ta linia pamięci podręcznej htaccess zamyka instrukcję i kończy blok kodu.

Ogólny problem z buforowaniem

Jeśli tworzysz listę obrazów, które będą przechowywane w pamięci podręcznej przez rok lub dłużej, pamiętaj, że jeśli wprowadzisz zmiany na swoich stronach, mogą one nie być widoczne dla wszystkich użytkowników. Ponieważ użytkownicy będą uzyskiwać dostęp do plików zapisanych w pamięci podręcznej, a nie do istniejących. Jeśli istnieje plik, który okresowo edytujesz ( na przykład - plik CSS), możesz rozwiązać problem pamięci podręcznej, korzystając z odcisku palca adresu URL.

Odcisk palca adresu URL

Uzyskanie nowego (nie buforowanego) zasobu plikowego jest możliwe, jeśli istnieje unikalna nazwa. Na przykład, jeśli plik CSS ma nazwę „main.css”, możemy zamiast tego nadać mu nazwę „main_1.css”. Następnym razem, gdy zmienimy jego nazwę, możemy nadać plikowi nazwę „main_2.css”. Jest to przydatne w przypadku plików, które zmieniają się okresowo.

HTML5 umożliwia tworzenie aplikacji internetowych, które będą działać nawet bez połączenia z Internetem.

Ulepszone buforowanie strony

Notatka: IE10+, Chrome, Firefox, Opera i Safari obsługują tę technologię.

HTML5 zwiększa możliwości buforowania przeglądarki. Teraz strony internetowe mogą być w pełni dostępne dla użytkowników nawet bez połączenia z Internetem.

Korzystanie z buforowania HTML5 zapewnia następujące korzyści:

• Umożliwia użytkownikom przeglądanie stron internetowych nawet bez połączenia z Internetem.
• Zwiększona prędkość ładowania strony - strony są przechowywane lokalnie na komputerze użytkownika i dlatego będą ładować się znacznie szybciej.
• Zmniejszone obciążenie serwera - serwer nie będzie musiał przetwarzać części żądań użytkowników.

Przykład użycia buforowania HTML5

...Zawartość dokumentu...

Deklarowanie buforowania HTML5

Aby móc korzystać z mechanizmu buforowania na swoich stronach internetowych, musisz dodać do tagu manifest i określ ścieżkę do jako jego wartość specjalny plik, który deklaruje parametry buforowania.

Jeśli ten atrybut nie został ustawiony na stronie internetowej, a odnośnik do niego nie znajduje się w pliku pamięci podręcznej, strona nie zostanie zapisana w pamięci podręcznej.

Plik pamięci podręcznej może mieć dowolne rozszerzenie (na przykład.appcache lub.mf), ale musi mieć specjalny typ MIME: „text/cache-manifest”.

W niektórych przypadkach serwer WWW może potrzebować dodatkowa personalizacja do obsługi danego typu MIME. Na przykład, aby skonfigurować serwer WWW Apache, musisz dodać następujący kod do pliku .htaccess:

AddType tekst/manifest pamięci podręcznej .appcache

Zawartość pliku pamięci podręcznej

Plik pamięci podręcznej jest normalny plik tekstowy, który informuje przeglądarkę, które pliki mają być buforowane.

Plik może zawierać trzy sekcje:

• MANIFEST CACHE – ta sekcja określa łącza do plików, które muszą być buforowane. Przeglądarka automatycznie buforuje wszystkie wymienione pliki natychmiast po pierwszym pobraniu.
• SIEĆ - ta sekcja określa pliki wymagające stałe połączenie Do internetu. Przeglądarka nie będzie buforować plików wymienionych w tej sekcji.
• FALLBACK - jeśli z jakiegoś powodu pliki określone w tej sekcji będą niedostępne, użytkownicy zostaną automatycznie przekierowani do innego określonego pliku.

Sekcja MANIFESTU CACHE musi być obecna we wszystkich plikach pamięci podręcznej. Może brakować sekcji SIEĆ i AWARIA.

Przykładowy plik pamięci podręcznej:

MANIFEST CACHE #Ta sekcja zawiera listę plików, które będą buforowane. Index.html flower.png SIEĆ #Ta sekcja zawiera listę plików wymagających połączenia z Internetem login-page.php FALLBACK #Jeśli plik mob.html nie jest dostępny, użytkownik zostanie przekierowany do offline.html /mob .html /offline.html #Jeśli którykolwiek z plików HTML nie jest dostępny, użytkownik zostanie przekierowany do offline.html *.html /offline.html

Notatka: strona internetowa zawierająca łącze do pliku pamięci podręcznej będzie automatycznie buforowana, więc dołączenie jej do samego pliku pamięci podręcznej jest opcjonalne, ale nadal zalecane.

Notatka: Niektóre przeglądarki mogą mieć ograniczenie rozmiaru zawartości buforowanej w jednej witrynie.

Aktualizowanie plików buforowanych

Po zapisaniu plików w pamięci podręcznej przeglądarka będzie nadal wyświetlać ich wersję w pamięci podręcznej, nawet jeśli zmienisz zawartość tych plików na serwerze.

Aby zaktualizować zawartość buforowaną, musisz wykonać jedną z następujących czynności:

• Wyczyść pamięć podręczną w przeglądarce użytkownika
• Zaktualizuj zawartość pliku pamięci podręcznej
• Programowo odśwież pamięć podręczną przeglądarki (przy użyciu JavaScript)

Aby zaktualizować zawartość pliku można zastosować następujący trik: zamiast bezpośrednio aktualizować zawartość pliku można dodać do niego komentarz wskazujący datę modyfikacji i/lub wersję pliku oraz w w przyszłości zmieniaj tylko treść tego komentarza, gdy chcesz odświeżyć zawartość pamięci podręcznej.

Czasami konieczne jest uniemożliwienie przeglądarce buforowania strony, ponieważ informacje na niej są aktualizowane za każdym razem. Może to być generowanie danych według wybranych filtrów lub inna treść, która za każdym razem jest tworzona w nowy sposób. Krótko mówiąc, czasami konieczne jest uniemożliwienie podstępnemu programowi buforowania strony. Dzisiaj dowiemy się, jak to wdrożyć różne sposoby, Z za pomocą PHP lub HTML lub .htaccess.

Zakaz buforowania stron w formacie HTML

Można to zrobić za pomocą metatagów. Teraz przyjrzymy się różnym opcjom zakazu buforowania.

Zakaz buforowania przez przeglądarkę i serwer proxy

Wyłącz buforowanie stron, tylko przeglądarka

Ustawianie buforowania na określony czas, dla przeglądarki

Za pomocą poniższego kodu możemy powiedzieć przeglądarce, jak długo dokument ma być przechowywany w pamięci podręcznej. Następnie pamięć podręczna zostanie zaktualizowana.

Ustawianie buforowania na określony czas dla serwera proxy

Praktycznie tak samo jak w poprzednim kodzie, jedynie wskazanie jest specyficzne dla serwera proxy.

Zapobiegaj buforowaniu stron za pomocą PHP

Praktycznie wszystko jest tak samo jak w przypadku HTML, tyle że informacje wyświetlimy poprzez nagłówki nagłówków. Oto jak zaimplementować bezwzględną odmowę pamięci podręcznej:

", data("H:i:s"), ""; ?>

Możesz także zezwolić na buforowanie przez określony czas. Na przykład zezwólmy na buforowanie tylko na 1 godzinę.

", data("H:i:s"), ""; ?>

Zapobiegaj buforowaniu stron za pomocą .htaccess

Aby pomysł był łatwiejszy w realizacji, wszystko można zrobić na poziomie konfiguracji Serwer Apache. Wcześniej musimy się upewnić, że niezbędne moduły są sprawne. Otwarcie plik konfiguracyjny Apache i zobacz następujący obrazek:

LoadModule wygasa_module moduły/mod_expires.so LoadModule nagłówki_module moduły/mod_headers.so ... AddModule mod_expires.c AddModule mod_headers.c

Teraz w pliku .htaccess faktycznie zabraniamy buforowania danych wyjściowych. Jak wiemy, plik .htaccess zostanie rozesłany do katalogu, w którym się znajduje, oraz do wszystkich podkatalogów.

# Nagłówek Cache-Control Nagłówek dołącza kontrolę pamięci podręcznej „bez przechowywania, bez pamięci podręcznej, należy ponownie sprawdzić”# Nagłówek Wygasa Wygasa Aktywny w dniu Wygasa Domyślnie „teraz”

Należy pamiętać, że całkowity zakaz buforowania zwiększa obciążenie serwera. Dlatego baw się tym ostrożnie! Jeszcze lepiej, ustaw konkretny czas, przez który możesz buforować dokumenty. Na przykład ustawmy buforowanie na 1 godzinę:

# Nagłówek Cache-Control Nagłówek dołącza kontrolę pamięci podręcznej „publiczny”# Nagłówek Wygasa Wygasa Aktywny W dniu Wygasa Domyślnie „dostęp plus 1 godzina”

Wniosek

Włączając zewnętrzny CSS i JavaScript, chcemy ograniczyć do minimum niepotrzebne żądania HTTP.

W tym celu pliki .js i .css dostarczane są z nagłówkami, które zapewniają niezawodne buforowanie.

Ale co zrobić, gdy jeden z tych plików ulegnie zmianie w trakcie programowania? Wszyscy użytkownicy mają starą wersję w swojej pamięci podręcznej - dopóki pamięć podręczna nie będzie przestarzała, będzie wiele skarg na zepsutą integrację części serwera i klienta.

Właściwe buforowanie i wersjonowanie całkowicie eliminują ten problem i zapewniają niezawodną, ​​przejrzystą synchronizację wersji stylów/skryptów.

Proste buforowanie ETag

Najprostszym sposobem buforowania zasobów statycznych jest użycie ETag.

Wystarczy włączyć odpowiednie ustawienia serwera (dla Apache jest to domyślnie włączone) - i dla każdego pliku w nagłówkach zostanie podany ETag - hash zależny od czasu aktualizacji, rozmiaru pliku i (w przypadku i-węzłów systemy plików) i-węzeł.

Przeglądarka buforuje taki plik i przy kolejnych żądaniach określa nagłówek If-None-Match z ETag buforowanego dokumentu. Po otrzymaniu takiego nagłówka serwer może odpowiedzieć kodem 304 - po czym dokument zostanie pobrany z pamięci podręcznej.

To wygląda tak:

Pierwsze żądanie do serwera (czyszczenie pamięci podręcznej) GET /misc/pack.js HTTP/1.1 Host: strona internetowa

Ogólnie rzecz biorąc, przeglądarka zwykle dodaje kilka nagłówków, takich jak User-Agent, Accept itp. Są przycięte dla zwięzłości.

Odpowiedź serwera Serwer odpowiada dokumentem z kodem 200 i ETag: HTTP/1.x 200 OK Kodowanie treści: gzip Typ zawartości: tekst/javascript; charset=utf-8 Etag: "3272221997" Zakresy akceptacji: bajty Długość zawartości: 23321 Data: piątek, 02 maja 2008 17:22:46 GMT Serwer: lighttpd Następne żądanie przeglądarki Przy następnym żądaniu przeglądarka dodaje If-None -Match: (buforowany ETag): GET /misc/pack.js HTTP/1.1 Host: site If-None-Match: "453700005" Odpowiedź serwera Serwer wygląda - tak, dokument się nie zmienił. Oznacza to, że możesz wystawić kod 304 i nie wysyłać dokumentu ponownie. HTTP/1.x 304 Niezmodyfikowane Kodowanie treści: gzip Etag: „453700005” Typ zawartości: tekst/javascript; charset=utf-8 Zakres akceptacji: bajty Data: wtorek, 15 kwietnia 2008 10:17:11 GMT

Alternatywą jest to, że jeśli dokument uległ zmianie, serwer po prostu wysyła 200 z nowym ETagiem.

Kombinacja Last-Modified + If-Modified-Since działa w podobny sposób:

1. serwer wysyła datę ostatniej modyfikacji w nagłówku Last-Modified (zamiast ETag)
2. przeglądarka buforuje dokument i przy następnym żądaniu tego samego dokumentu wysyła datę wersji zapisanej w pamięci podręcznej w nagłówku If-Modified-Since (zamiast If-None-Match)
3. serwer sprawdza daty i jeśli dokument się nie zmienił, wysyła tylko kod 304, bez treści.

Metody te działają niezawodnie i dobrze, ale przeglądarka nadal musi wysyłać żądanie dla każdego skryptu lub stylu.

Inteligentne buforowanie. Wersjonowanie

Ogólne podejście do wersjonowania – w skrócie:

1. Wersja (lub data modyfikacji) jest dodawana do wszystkich skryptów. Na przykład http://strona/ mój.js zamieni się w http://site/ my.v1.2.js
2. Wszystkie skrypty są przechowywane w pamięci podręcznej przeglądarki
3. Podczas aktualizacji skryptu wersja zmienia się na nową: http://site/ my.v2.0.js
4. Adres się zmienił, więc przeglądarka ponownie zażąda pliku i zapisz go w pamięci podręcznej
5. Stara wersja 1.2 będzie stopniowo wypadać z pamięci podręcznej

Twarde buforowanie

Twarde buforowanie- rodzaj młota, który całkowicie przybija do serwera żądania dotyczące dokumentów z pamięci podręcznej.

Aby to zrobić, po prostu dodaj nagłówki Expires i Cache-Control: max-age.

Na przykład, aby buforować przez 365 dni w PHP:

Header("Wygasa: ".gmdate("D, d M Y H:i:s", czas()+86400*365)." GMT"); header("Kontrola pamięci podręcznej: max-age="+86400*365);

Możesz też trwale buforować zawartość za pomocą mod_header w Apache:

Po otrzymaniu takich nagłówków przeglądarka przechowuje dokument przez długi czas w twardej pamięci podręcznej. Dalszy dostęp do dokumentu będzie możliwy bezpośrednio z pamięci podręcznej przeglądarki, bez konieczności kontaktowania się z serwerem.

Większość przeglądarek (Opera, Internet Explorera 6+, Safari) NIE buforuj dokumentów, jeśli adres zawiera znak zapytania, ponieważ są uważane za dynamiczne.

Dlatego do nazwy pliku dodajemy wersję. Oczywiście przy takich adresach trzeba skorzystać z rozwiązania typu mod_rewrite, przyjrzymy się temu w dalszej części artykułu.

P.S Ale Firefox buforuje adresy ze znakami zapytania...

Automatyczne rozpoznawanie nazw

Przyjrzyjmy się, jak automatycznie i przejrzyście zmieniać wersje bez zmiany nazw samych plików.

Nazwa z wersją -> Plik

Najprościej jest zamienić nazwę wraz z wersją na oryginalną nazwę pliku.

Na poziomie Apache można to zrobić za pomocą mod_rewrite:

RewriteEngine na RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 [L]

Ta reguła przetwarza wszystkie pliki css/js/gif/png/jpg, usuwając wersję z nazwy.

Na przykład:

/images/logo.v2.gif -> /images/logo.gif
/css/style.v1.27.css -> /css/style.css
/javascript/script.v6.js -> /javascript/script.js

Ale oprócz wycięcia wersji musisz także dodać do plików nagłówki twardego buforowania. Używa się do tego dyrektyw mod_header:

Dodaj nagłówek „Wygasa” „Poniedziałek, 28 lipca 2014 r. 23:30:00 GMT” Dodaj nagłówek „Kontrola pamięci podręcznej” „max-age=315360000”

Całość implementuje następującą konfigurację Apache:

RewriteEngine on # usuwa wersję i jednocześnie ustawia zmienną wskazującą wersjonowanie pliku RewriteRule ^/(.*\.)v+\.(css|js|gif|png|jpg)$ /$1$2 # hard cache wersjonowane pliki Nagłówek dodaje „Wygasa” „Poniedziałek, 28 lipca 2014 23:30:00 GMT” env=VERSIONED_FILE Nagłówek dodaje „Cache-Control” „max-age=315360000” env=VERSIONED_FILE

Ze względu na sposób działania modułu mod_rewrite RewriteRule należy umieścić w głównym pliku konfiguracyjnym httpd.conf lub w plikach dołączonych (dołączonych) ale w żadnym wypadku w .htaccess , w przeciwnym razie komendy Header zostaną uruchomione jako pierwsze, zanim zostanie on zainstalowany PLIK WERSJI zmienny.

Dyrektywy nagłówkowe mogą znajdować się gdziekolwiek, nawet w .htaccess - to nie ma znaczenia.

Automatyczne dodanie wersji do nazwy pliku na stronie HTML

Sposób umieszczenia wersji w nazwie skryptu zależy od systemu szablonów i ogólnie od sposobu dodawania skryptów (stylów itp.).

Na przykład, jeśli używasz daty modyfikacji jako wersji i silnika szablonów Smarty, linki można ustawić w następujący sposób:

Funkcja wersji dodaje wersję:

Funkcja smarty_version($args)( $stat = stat($GLOBALS["config"]["site_root"].$args["src"]); $wersja = $stat["mtime"]; echo preg_replace("! \.(+?)$!", ".v$wersja.\$1", $args["src"]); )

Wynik na stronie:

Optymalizacja

Aby uniknąć niepotrzebnych wywołań statystyk, możesz przechowywać tablicę z listą aktualnych wersji w osobnej zmiennej

$versions["css"] = array("group.css" => "1.1", "other.css" => "3.0", )

W tym przypadku kod HTML jest po prostu podstawiony Obecna wersja z tablicy.

Możesz skrzyżować oba podejścia i podczas programowania stworzyć wersję według daty modyfikacji - ze względu na przydatność, a w środowisku produkcyjnym - wersję z tablicy, ze względu na wydajność.

Możliwość zastosowania

Ta metoda buforowania działa wszędzie, w tym w JavaScript, CSS, obrazach, filmach Flash itp.

Przydaje się przy każdej zmianie dokumentu, jednak przeglądarka powinna mieć zawsze aktualną, aktualną wersję.