Poniedziałek, 9 grudnia 2024 r.
Pozwól nam na użycie pamięci podręcznej.
Wraz z rozwojem internetu zwiększała się ilość indeksowania wykonywanego przez Google. Infrastruktura Google do indeksowania obsługuje heurystyczne mechanizmy buforowania, ale tak było zawsze. Tymczasem liczba żądań, które można zwrócić z lokalnych pamięci podręcznych, zmniejszyła się: 10 lat temu około 0,026% z całości pobierania było buforowane, co już wtedy nie było zbyt imponujące; obecnie ten odsetek wynosi 0,017%.
Dlaczego buforowanie jest ważne?
Buforowanie jest kluczowym elementem w wielkiej układance, jaką jest internet. Pamięć podręczna umożliwia błyskawiczne wczytywanie stron podczas ponownych wizyt, oszczędza zasoby obliczeniowe, a tym samym zasoby naturalne, a także pozwala zaoszczędzić ogromną ilość przepustowości zarówno klientom, jak i serwerem.
Dotyczy to zwłaszcza dużych witryn z rzadko zmienianymi treściami pod poszczególnymi adresami URL. W takim przypadku buforowanie na poziomie lokalnym może pomóc w bardziej efektywnym indeksowaniu witryny. Infrastruktura Google do indeksowania obsługuje heurystyczne przechowywanie w pamięci podręcznej HTTP zgodnie ze standardem buforowania HTTP, w szczególności za pomocą nagłówka odpowiedzi ETag i żądania If-None-Match oraz nagłówka odpowiedzi Last-Modified i żądania If-Modified-Since.
Zdecydowanie zalecamy używanie wartości ETag, ponieważ jest ona mniej podatna na błędy (ta wartość nie jest uporządkowana, w przeciwieństwie do wartości Last-Modified). Jeśli masz taką możliwość, ustaw je obie: internet Ci za to podziękuje. Być może.
Zmiana, jaką uznasz za wymagającą od klientów odświeżenia ich pamięci podręcznych, zależy tylko od Ciebie. Zalecamy wymaganie odświeżenia pamięci podręcznej w przypadku istotnych zmian w treściach. Jeśli zaktualizowana została tylko data praw autorskich na dole strony, nie jest to prawdopodobnie istotna zmiana.
ETag i If-None-Match
Roboty Google obsługują żądania warunkowe oparte na ETag zgodnie z definicją w standardzie buforowania HTTP.
Aby zasygnalizować preferencje dotyczące pamięci podręcznej robotom Google, ustaw wartość Etag na dowolny ciąg znaków ASCII (zwykle hasz treści lub numer wersji, ale może to być też fragment liczby π – to zależy od Ciebie), który jest unikalny dla reprezentacji treści hostowanej przez adres URL do którego jest uzyskiwany dostęp.
Jeśli na przykład hostujesz różne wersje tej samej treści pod tym samym adresem URL (np. wersję mobilną i komputerową), każda z nich może mieć swoją własną unikalną wartość ETag.
Roboty Google, które obsługują buforowanie, prześlą wartość ETag zwróconą podczas poprzedniego indeksowania tego adresu URL w polu If-None-Match header. Jeśli wartość ETag przesłana przez robota jest zgodna z bieżącą wartością wygenerowaną przez serwer, serwer powinien zwrócić kod stanu HTTP 304 (nie zmodyfikowano) bez treści HTTP. Ten ostatni element, czyli brak treści HTTP, jest ważny z kilku powodów:
- serwer nie musi zużywać zasobów obliczeniowych na generowanie treści, co oznacza, że oszczędzasz pieniądze;
- serwer nie musi przesyłać treści HTTP, co oznacza oszczędność pieniędzy.
Po stronie klienta, takiego jak przeglądarka użytkownika lub Googlebot, treści pod tym adresem URL są pobierane z wewnętrznej pamięci podręcznej klienta. Ponieważ nie wymaga to przesyłania danych, odbywa się to błyskawicznie, co cieszy użytkowników i może im też zaoszczędzić trochę zasobów.
Last-Modified i If-Modified-Since
Podobnie jak w przypadku ETag roboty Google obsługują też żądania warunkowe Last-Modified based zgodnie z definicją w standardzie buforowania HTTP. Z punktu widzenia semantyki działa to tak samo jak ETag – do określenia, czy zasób można zapisać w pamięci podręcznej, używany jest identyfikator. Rozwiązanie to zapewnia te same korzyści co ETag po stronie klientów.
Jeśli używasz dyrektywy Last-Modified do przechowywania w pamięci podręcznej, mamy dla Ciebie kilka zaleceń:
-
Data w nagłówku
Last-Modifiedmusi być sformatowana zgodnie ze standardem HTTP. Aby uniknąć problemów z analizą, zalecamy użycie tego formatu daty: „Dzień tygodnia, DD Mon YYYY HH:MM:SS Strefa czasowa”, np. „Fri, 4 Sep 1998 19:15:56 GMT”. -
Chociaż nie jest to wymagane, warto też ustawić pole
max-agenagłówkaCache-Control, aby pomóc robotom w określaniu, kiedy ponownie zindeksować dany adres URL. Ustaw wartość polamax-agena oczekiwaną liczbę sekund, przez które treści mają pozostać niezmienione, np.Cache-Control: max-age=94043.
Przykłady
Jeśli myślisz podobnie jak ja, zrozumienie, jak działa heurystyka, może być trudne. Jednak pokazanie przykładowego łańcucha żądań i odpowiedzi wydaje się pomocne. Oto 2 łańcuchy: jeden dla ETag/If-None-Match, a drugi dla Last-Modified/If-Modified-Since, aby zilustrować, jak to działa:
ETag/If-None-Match |
Last-Modified/If-Modified-Since |
|
|---|---|---|
Odpowiedź serwera na indeksowanie: to odpowiedź, z której robot może zapisać pola nagłówka warunku wstępnego ETag i Last-Modified.
|
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT ETag: "34aa387-d-1568eb00" ... |
HTTP/1.1 200 OK Content-Type: text/plain Date: Fri, 4 Sep 1998 19:15:50 GMT Last-Modified: Fri, 4 Sep 1998 19:15:56 GMT Cache-Control: max-age=94043 ... |
Następne żądanie warunkowe robota: żądanie warunkowe jest oparte na wartościach nagłówka warunku wstępnego zapisanych z poprzedniego żądania. Wartości są wysyłane z powrotem do serwera w nagłówkach żądań If-None-Match i If-Modified-Since na potrzeby walidacji.
|
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-None-Match: "34aa387-d-1568eb00" ... |
GET /hello.world HTTP/1.1 Host: www.example.com Accept-Language: en, hu User-Agent: Googlebot/2.1 (+http://www.google.com/bot.html) If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
Odpowiedź serwera na żądanie warunkowe: ponieważ wartości nagłówka warunku wstępnego wysyłane przez robota są sprawdzane po stronie serwera, serwer zwraca robotowi kod stanu HTTP 304 (bez treści HTTP). Będzie się to działo w przypadku każdego kolejnego żądania, dopóki nie wystąpi niepowodzenie weryfikacji warunków wstępnych (zmiana daty ETag lub Last-Modified po stronie serwera).
|
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:52 GMT Vary: Accept-Encoding If-None-Match: "34aa387-d-1568eb00" ... |
HTTP/1.1 304 Not Modified Date: Fri, 4 Sep 1998 19:15:50 GMT Expires: Fri, 4 Sep 1998 19:15:51 GMT Vary: Accept-Encoding If-Modified-Since: Fri, 4 Sep 1998 19:15:56 GMT ... |
Jeśli zależy Ci na zadowoleniu użytkowników i chcesz zaoszczędzić trochę na opłacie za hosting, skontaktuj się z dostawcą hostingu lub CMS albo z programistami, aby dowiedzieć się, jak włączyć buforowanie HTTP w swojej witrynie. Jeśli nie odniesiesz żadnych innych korzyści, to przynajmniej użytkownicy będą Cię nieco bardziej lubić.
Jeśli chcesz porozmawiać o przechowywaniu w pamięci podręcznej, odwiedź najbliższe Forum pomocy Centrum wyszukiwarki. Jeśli masz uwagi na temat sposobu, w jaki przechowujemy dane w pamięci podręcznej, zostaw komentarz na temat dokumentacji dotyczącej przechowywania w pamięci podręcznej, którą opublikowaliśmy razem z tym wpisem na blogu.