Как повысить эффективность сканирования с помощью заголовков управления кэшем

1. Заголовки Cache Control & Техническое SEO
2. Эффективность сканирования
3. Last-Modified / If-Modified-Since
4. ETag / If-None-Match
5. Когда использовать эти условные GET
6. Скорость страницы
7. Настройка времени истечения
8. Тестирование заголовков контроля кеша
9. Расширенное чтение

Еще в конце прошлого века я работал в компании Inktomi. Большинство людей помнят Inktomi как поисковик, но у него было несколько других подразделений. В одном из этих подразделений (в котором я работал) продавалось сетевое программное обеспечение, включая прокси-кэш под названием Traffic Server.

Сейчас это кажется странным, но Inktomi заработал на Traffic Server больше денег, чем на поисковой системе. Такова была экономика пре-гугл-интернета. Это был большой бизнес, пока 1) пропускная способность не стала действительно очень дешевой, и 2) почти все клиенты прекратили свою деятельность в конце 2000 - начале 2001 г. (Большая часть Inktomi была приобретена Yahoo! в 2002 г., и Сервер трафика был выпущен как проект с открытым исходным кодом в 2009 году.)

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

Одно быстрое замечание: когда я говорю о «кэшированной» странице, я не имею в виду ссылку «Кэшированный» в Google или Bing. Я имею в виду временно сохраненную версию страницы в поисковой системе, прокси-кэше или веб-браузере.

В качестве примера типичного непригодного для кэша веб-сайта приведем заголовки ответа HTTP с моего сайта, на котором установлена ​​стандартная установка Apache для моего интернет-провайдера и WordPress более или менее из коробки:

Три строки, обведенные красным, означают HTTP-фразу «Не кэшируйте это никогда, ни при каких обстоятельствах».

Немного подробнее об этих заголовках:

1. Истекает: указывает, как долго прокси-кеш или браузер может считать документ «свежим» и не должен возвращаться и получать его. Установив дату на два десятилетия назад, сервер указывает, что она никогда не должна считаться свежей.
2. Cache-control: используется для явного указания прокси-кешам или браузерам информации о кешируемости документа. «No-store» и «no-cache» говорят ему не кэшировать документ. «Must-revalidate» означает, что кеш никогда не должен обслуживать документ без предварительной проверки с сервером. «Post-check» и «pre-check» - специфичные для IE настройки, которые говорят IE всегда получать документ с сервера.
3. Pragma: это заголовок HTTP- запроса , поэтому в данном случае он не имеет значения.

Заголовки Cache Control & Техническое SEO

Так какое отношение заголовки кеша имеют к техническому SEO? Они имеют значение двумя способами:

1. Они помогают поисковым системам более эффективно сканировать сайты (потому что им не нужно загружать один и тот же контент снова и снова).
2. Они увеличивают скорость страницы и улучшают пользовательский опыт для большинства посетителей вашего сайта. Это может даже потенциально улучшить опыт для новых посетителей.

Другими словами, добавив несколько строк в конфигурацию вашего веб-сервера для поддержки кэширования, можно будет сканировать больше вашего сайта поисковыми системами, одновременно ускоряя ваш сайт для пользователей.

Давайте сначала посмотрим на эффективность сканирования.

Эффективность сканирования

Только две пары заголовков управления кэшем имеют значение для сканирования поисковой системой. Эти типы запросов называются «условными GET», потому что ответ на GET будет отличаться в зависимости от того, изменилась страница или нет.

Searchengineland.com Оказывается, поддерживают оба метода, поэтому я буду использовать его в примерах ниже.

Last-Modified / If-Modified-Since

Это наиболее распространенный и широко поддерживаемый условный GET. Он поддерживается сканерами Google и Bing (и всеми браузерами и кешами прокси, которые мне известны).

Это работает так. При первом запросе документа возвращается заголовок Last-Modified: HTTP, указывающий дату его изменения.

В следующий раз, когда документ будет запрошен, робот Google или Bingbot добавит заголовок If-Modified-Since: в запрос, содержащий дату последнего изменения, которое он получил. (В примерах ниже я использую curl и опцию -H для отправки этих заголовков HTTP.)

Если документ не был изменен после даты If-Modified-Since, сервер вернет код ответа 304 Страница не изменена и документа не будет. Клиент, будь то Googlebot, Bingbot или браузер, будет использовать версию, которую он запрашивал ранее.

Если документ был изменен после даты If-Modified-Since, то сервер возвращает ответ 200 OK вместе с документом, как если бы он отвечал на запрос без заголовка If-Modified-Since.

ETag / If-None-Match

Запросы If-None-Match работают аналогичным образом. При первом запросе документа возвращается заголовок Etag :. ETag - это обычно хэш нескольких атрибутов файла.

Второй запрос включает в себя заголовок If-None-Match:, содержащий это значение ETag. Если это значение соответствует ETag, который был бы возвращен, сервер возвращает заголовок 304 Page Not Modified.

Если ETag не совпадает, то возвращается нормальный ответ 200 OK.

ETag / If-None-Match определенно поддерживается Bing, но неясно, поддерживает ли его Google. Основываясь на анализе файлов журнала, который я сделал, я почти уверен, что веб-запросы Googlebot не поддерживают его. (Впрочем, возможно, что другие сканеры Google его поддерживают. Я все еще исследую это и опубликую последующую статью, если / когда получу больше информации.)

Одна распространенная проблема с поддержкой ETag / If-None-Match возникает на сайтах, которые распределяют нагрузку между различными внутренними серверами. Часто ETag генерируется из чего-то, что варьируется от сервера к серверу, например, из-за inode файла, что означает, что ETag будет отличаться для каждого внутреннего сервера.

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

В общем, я рекомендую реализовать Last-Modified / If-Modified-Since вместо ETag / If-None-Match, потому что он поддерживается более широко и имеет меньше проблем, связанных с ним.

Когда использовать эти условные GET

Условные GET должны быть реализованы на любых статических веб-ресурсах, включая HTML-страницы, XML-карты сайтов, файлы изображений, внешние файлы JavaScript и внешние файлы CSS.

• Для Apache модуль mod_cache должен быть установлен и настроен. Если сервер по-прежнему не поддерживает условные GET, проверьте строку CacheDisable в файле httpd.conf или в файле .htaccess.

Для динамических программно сгенерированных файлов заголовки HTTP, связанные с условными GET, должны отправляться из кода страницы. Чтобы определить, стоит ли это того, нужно выполнить некоторые предварительные расчеты конверта по двум факторам.

1. Требуется ли столько ресурсов (например, обращений к внутренним базам данных), чтобы определить, изменилась ли страница по сравнению с генерацией самого файла?
2. Изменяется ли страница по сравнению с частотой сканирования страниц поисковыми системами?

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

Скорость страницы

Я также рекомендую устанавливать время истечения для статических ресурсов, которые не меняются часто, таких как изображения, файлы JavaScript, файлы CSS и т. Д.

Это позволяет браузерам хранить эти ресурсы и повторно использовать их на других страницах вашего сайта без необходимости загружать их с веб-сервера без необходимости.

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

Есть два способа установить время истечения, используя заголовки управления кешем HTTP.

1. Истекает: <дата>, которая указывает дату, до которой ресурс может быть сохранен.
2. Cache-control: max-age = <секунд>, который указывает количество секунд, в течение которых ресурс может быть сохранен.

Время истечения может быть установлено максимум один год, согласно спецификации HTTP. Я рекомендую установить его как минимум на несколько месяцев.

Настройка времени истечения

Для Apache требуется установка mod_expires пометить и создать несколько строк ExpiresDefault или ExpiresByType. Кэш-контроль также требует mod_headers ,

IIS7 можно настроить с помощью диспетчера IIS или некоторых инструментов командной строки. Увидеть эта ссылка Больше подробностей.

Для ресурсов, которые генерируются динамически, эти заголовки могут быть добавлены программно, как и любой другой заголовок. Просто убедитесь, что Expires: дата в правильном формате или это, вероятно, будет проигнорировано.

Другие источники

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

Тестирование заголовков контроля кеша

• Redbot.org , написано " mnot «Это лучший инструмент для проверки кэша, который я знаю. Я использую это все время при оценке сайтов.
• Microsoft имеет очень полезный инструмент для просмотра заголовков, которые доступны здесь.

Я также большой поклонник использования локон -Я из командной строки посмотреть каталог заголовков.

Расширенное чтение

• Google-х статья о скорости страницы на использование кэширования.
• Yahoo, статья о лучших практиках для ускорения веб-сайта содержит некоторую информацию о кешировании (нажмите на категорию «Сервер»): [[[]]]
• Bing описывает их поддержку условных GET и содержит несколько полезных ссылок Вот ,
• Mnot имеет отличный, думал, что немного устарела, обзор кеширования это очень полезно.

Мнения, выраженные в этой статье, принадлежат автору гостя и не обязательно относятся к Search Engine Land. Штатные авторы перечислены Вот ,

Похожие

Комментарии