Декабрьское сканирование: HTTP-кэширование

Понедельник, 9 декабря 2024 г.

Пожалуйста, разрешите нам кэшировать.

По мере роста интернета с годами рос и объем сканирования Google. Хотя инфраструктура сканирования Google поддерживает эвристические механизмы кэширования (и, по сути, всегда поддерживала), количество запросов, которые могут быть возвращены из локальных кэшей, уменьшилось: 10 лет назад около 0,026% от общего числа выборок были кэшируемыми, что уже не так впечатляет; сегодня эта цифра составляет 0,017%.

Почему кэширование важно?

Кэширование — это важнейшая часть большой головоломки, которой является интернет. Кэширование позволяет страницам загружаться молниеносно при повторных посещениях, экономит вычислительные ресурсы, а значит, и природные ресурсы, а также экономит огромное количество дорогостоящей пропускной способности как для клиентов, так и для серверов.

Особенно если у вас большой сайт с редко меняющимся контентом по отдельным URL-адресам, разрешение локального кэширования может помочь вашему сайту сканироваться более эффективно. Инфраструктура сканирования Google поддерживает эвристическое HTTP-кэширование, как определено в
стандарте HTTP-кэширования, в частности через ETag ответ и If-None-Match заголовок запроса, а также Last-Modified ответ и If-Modified-Since заголовок запроса.

Мы настоятельно рекомендуем использовать ETag , так как он менее подвержен ошибкам и оплошностям (значение не структурировано, в отличие от значения Last-Modified ). И, если у вас есть возможность, установите оба: интернет скажет вам спасибо. Может быть.

Что касается того, что вы считаете изменением, требующим от клиентов обновления их кэшей, это решать вам. Наша рекомендация заключается в том, чтобы требовать обновления кэша при значительных изменениях в вашем контенте; если вы просто обновили дату авторских прав в нижней части страницы, это, вероятно, не является значительным.

ETag и If-None-Match

Сканеры Google поддерживают ETag на основе условных запросов точно так, как определено в
стандарте HTTP-кэширования. То есть, чтобы сообщить о предпочтении кэширования сканерам Google, установите значение Etag на любую произвольную строку ASCII (обычно хэш контента или номер версии, но это может быть и часть числа π, решать вам), уникальную для представления контента, размещенного по доступному URL. Например, если вы размещаете разные версии одного и того же контента по одному и тому же URL (скажем, мобильную и десктопную версии), каждая версия может иметь свое уникальное значение ETag .

Сканеры Google, поддерживающие кэширование, отправят значение ETag , возвращенное для предыдущего сканирования этого URL, в заголовке If-None-Match header. Если значение ETag
, отправленное сканером, совпадает с текущим значением, которое сгенерировал сервер, ваш сервер должен вернуть код состояния HTTP 304 (Не изменено) без тела HTTP. Эта последняя часть, отсутствие тела HTTP, является важной по нескольким причинам:

• вашему серверу не нужно тратить вычислительные ресурсы на фактическую генерацию контента; то есть вы экономите деньги
• вашему серверу не нужно передавать тело HTTP; то есть вы экономите деньги

На стороне клиента, например, в браузере пользователя или Googlebot, контент по этому URL извлекается из внутреннего кэша клиента. Поскольку передача данных не требуется, это происходит молниеносно, что радует пользователей и потенциально экономит ресурсы и для них тоже.

Last-Modified и If-Modified-Since

Аналогично ETag, сканеры Google также поддерживают Last-Modified based
условные запросы, точно так же, как определено в стандарте HTTP-кэширования. Это работает так же, как ETag с семантической точки зрения — идентификатор используется для решения, является ли ресурс кэшируемым — и обеспечивает те же преимущества, что и ETag на стороне клиентов.

У нас есть лишь пара рекомендаций, если вы используете Last-Modified в качестве директивы кэширования:

1. Дата в заголовке Last-Modified должна быть отформатирована в соответствии со
   стандартом HTTP. Чтобы избежать проблем с парсингом, мы рекомендуем использовать следующий формат даты: “День недели, DD Mon YYYY HH:MM:SSЧасовой пояс”. Например,“.
2. ” Fri, 4 Sep 1998 19:15:56 GMT Хотя это не обязательно, рассмотрите также возможность установки поля
   max-age заголовка Cache-Control , чтобы помочь сканерам определить, когда повторно сканировать конкретный URL. Установите значение поля.

max-age

на ожидаемое количество секунд, в течение которых контент останется неизменным. Например, Cache-Control: max-age=94043/If-None-Match и один для
Last-Modified/If-Modified-Since — чтобы визуализировать, как это должно работать:

Если вы хотите порадовать своих пользователей и, возможно, сэкономить немного денег на счете за хостинг, поговорите со своим хостинг-провайдером, CMS-провайдером или разработчиками о том, как включить HTTP-кэширование для вашего сайта. По крайней мере, ваши пользователи будут любить вас немного больше.

Если хотите пообщаться о кэшировании, перейдите в ближайшее
сообщество помощи Search Central, и если у вас есть комментарии о том, как мы кэшируем, оставьте отзыв в
документации о кэшировании
, которую мы опубликовали вместе с этой записью в блоге.

Опубликовано Gary Illyes

Хотите узнать больше о сканировании? Ознакомьтесь со всей серией Crawling December: