Как проверить работает ли кэш на сайте
Обновлено: 25.06.2024
Google регулярно индексирует сайты для улучшения поиска, а вместе с тем и сохраняет копии (снимки) страниц. Веб браузеры для ускорения загрузки сайтов, также сохраняют страницы целиком или их отдельные элементы в кэше, специальной папке на вашем жестком диске. Поэтому в случае недоступности ресурсов существует несколько методов получения доступа к сохраненной копии.
Поиск Google
Просмотр кэшированной страницы в поиске Google начинается точно также, как и выполнение любого поискового запроса. Просто введите название сайта, а затем в результатах поиска, рядом с адресом ресурса кликните на стрелку и выберете пункт Сохраненная копия . После загрузки страницы, Google оповестит вас, о том, что вы просматриваете снимок страницы и о том, когда он был сделан. У вас также будет возможность просмотреть исключительно текст, а также исходный код сайта.
Интернет архив и Wayback Machine
Целый ряд организаций занимается сохранением истории интернета и наиболее известной среди них является некоммерческий Интернет Архив (Internet Archive). Он позволяет получить доступ к огромному множеству сайтов, текстов, видео, аудио, программного обеспечения и картинок, которые трудно найти где-либо еще
Отсортируйте эти данные при помощи Wayback Machine (машина прошлого). Просматривайте сохраненные копии как работающих сайтов, так и уже канувших в лету. Просто введите адрес ресурса, который хотите увидеть и сервис покажет вам все имеющиеся снимки. Выберите на календаре необходимую дату и посмотрите, как сайт выглядел в это время. Wayback Machine – это отличный инструмент для знакомства с историей интернета.
Расширения для браузера
Существуют и специальные дополнения для браузеров, позволяющие просматривать сохраненные версии страниц. Расширение Web Cache Viewer позволяет не только загрузить страницу из локального кэша на вашем компьютере, но и также автоматически найти ее при помощи сервиса Wayback Machine. Для пользователей Firefox существует аналогичное дополнение со схожим функционалом Web Archives .
Веб инструменты
Если ни один из вышеперечисленных способов вам не помог, то возможно вам помогут еще пара инструментов. Например, сайт Cached Page позволяет искать копии страниц сразу на нескольких ресурсах – поиск Google, Интернет Архив и WebCite. Также вы можете попробовать сервис Google Cache Checker , который проверяет как давно индексировался сайт и есть ли его сохраненные копии.
Эта программа проверки кэша страниц от SAS мгновенно проверяет кеш страниц. Это быстрый и простой способ проверить, включены ли страницы вашего веб-сайта в поисковый индекс Google и Яндекс. Этот инструмент сообщит вам, знает ли Яндекс и Google, что такая веб-страница существует, и добавила ли она ее в свой индекс, чтобы она стала видимой в результатах поиска.
Не стесняйтесь проверять кеш своих веб-страниц в любое время с помощью этого онлайн-инструмента проверки кеша страниц, чтобы узнать, находятся ли ваши веб-страницы в поисковом индексе.
Наша онлайн-программа чрезвычайно полезна для владельцев веб-сайтов, веб-мастеров и специалистов по поисковой оптимизации. Вам не нужно ничего загружать, и вы можете использовать ее где угодно, если вы подключены к сети. По результатам вы можете быстро и без проблем провести тщательный анализ.
Как использовать нашу программу проверки кэша страниц?
Этот бесплатный онлайн-инструмент сразу же сообщит вам, были ли ваши веб-страницы кэшированы. Чтобы использовать этот инструмент проверки кэша страниц, просто введите URL-адрес веб-страницы, которую вы хотите проверить, в отведенном для этого месте, а затем нажмите кнопку «Проверить», чтобы наша система обработала ваш запрос. Результаты будут получены всего за несколько секунд.
Этот инструмент веб-кеширования позволяет отправлять несколько URL-адресов (до 20 URL-адресов) одновременно, но вы должны вводить каждый URL-адрес в отдельной строке.
Зачем вам нужна проверять кеш?
Если вы являетесь владельцем веб-сайта или веб-мастером, этот инструмент проверки веб-кеша может оказать вам большую помощь, потому что этот анализатор кеша сообщит вам все данные вашего веб-сайта и ссылки, которые были кэшированы. Следовательно, все ссылки, которые были проиндексированы, также можно назвать кешированными URL-адресами.
Этот инструмент проверки кеша очень важен, потому что он может очень помочь вам в поисковой оптимизации. Если вы хотите перенести свой веб-сайт с одного хостинг-сервера на другой, вам нужно будет обновить адрес DNS-сервера вашего домена, и это само по себе обычно занимает от 24 до 72 часов. В течение этого периода, если пользователь хочет получить доступ к вашему веб-сайту, то что будет делать Google и Яндекс, так это направлять пользователя по кешированным ссылкам, аналогичным тому времени, когда сайт был активен. Вот почему этот инструмент для анализа кеша очень важен, поскольку он может помочь посетителям вашего сайта по-прежнему получать доступ к вашему сайту, даже если он фактически находится в автономном режиме.
SEO-специалисты могут использовать эту программу проверки кеша для создания отчетов, включающих полный анализ конкретного веб-сайта. С помощью этого инструмента он позволяет пользователю сэкономить много времени и усилий, потому что процесс очень прост, а результаты получаются мгновенно. Нет необходимости проверять веб-страницы вручную, потому что теперь вы можете анализировать свой веб-сайт и просто получать информацию о его статусе кеша по каждому URL-адресу на основе последнего времени, когда он был изменен. Вам будут предоставлены данные в реальном времени и дата каждого кеша. Это может помочь вам легко определить любые проблемы, которые могут возникнуть на ваших веб-страницах.
Подробнее о нашем анализаторе
Google и Яндекс сохранит кешированную версию сайта, при последнем сканировании вашего сайта. Вот почему в некоторых случаях кешированная версия веб-страницы будет отличаться от текущей веб-страницы, которую вы увидите, щелкнув адрес веб-сайта в результатах поиска.
Когда Google Spider сканирует и анализирует ваш веб-сайт, он делает снимок каждой веб-страницы и сохраняет их в качестве резервной копии. Таким образом, когда придет время и пользователь будет искать ключевое слово или фразу в поиске, Google будет использовать кешированную версию, чтобы увидеть, совпадает ли она с искомой фразой или нет. Для каждого результата поиска есть ссылка на кешированную версию веб-сайта, которая затем направит пользователя на кешированную веб-страницу этого конкретного веб-сайта. Это очень полезно, когда веб-сайт временно не работает из-за некоторых технических проблем.
Вам может быть интересно, действительно ли Google и Яндексе просканировал наш веб-сайт или действительно ли Google знает, что наш веб-сайт существует. Чтобы помочь вам узнать об этом используйте наш инструмент. Это предоставит вам точное время и дату, когда Google и Яндексе создал самую последнюю кэшированную версию вашего сайта.
W3 Total Cache – один из популярных бесплатных плагинов кеширования, доступных для пользователей WordPress. Огромный набор доступных опций запутает пользователей, кэширует ли плагин страницы или нет. Вот пошаговое руководство о том, как проверить, работает ли W3 Total Cache на вашем сайте WordPress или нет.
Шаг за шагом
Выполните следующие шаги, чтобы проверить кеширование:
Позвольте нам протестировать
Включить отладку кеша страниц
После установки плагина W3 Total Cache вы должны включить кеширование страниц для доставки кешированных страниц вашим посетителям, чтобы повысить скорость загрузки страниц. Но вы не сможете узнать, кэшированы ли страницы или нет, просто просмотрев свой сайт или просмотрев исходную страницу своего сайта. Чтобы проверить, работает ли кеширование, W3TC предлагает функцию отладки, чтобы найти детали кеширования веб-страницы.
Перейдите в меню «Производительность> Общие настройки» и прокрутите вниз до раздела «Отладка». Вы увидите флажки для «Кеша страницы» и других опций, предлагаемых плагином.
Включить отладку для кэширования страниц в W3TC
Установите флажок «Кэш страницы» и нажмите кнопку «Сохранить настройки и очистить кеши».
Включение кэширования для пользователей, вошедших в систему
Статьи по Теме:
Тестирование в браузере
Откройте свой сайт в новом окне браузера. Щелкните правой кнопкой мыши и выберите вариант просмотра исходного кода страницы. После окончания раздела HTML вы должны увидеть информацию об общем кэше W3, как показано на рисунке ниже.
Проверьте кеширование плагина W3 Total Cache
Кеширование отклонено для пользователей, вошедших в систему
Обязательно сбросьте настройки обратно, например, включите кеширование для пользователей, вошедших в систему, и отключите отладку для всех параметров.
Различные виды кеширования
Техника кеширования заключается в сохранении копии полученного ресурса для возврата этой копии в ответ на дальнейшие запросы. Запрос на ресурс, уже имеющийся в веб-кеше, перехватывается, и вместо обращения к исходному серверу выполняется загрузка копии из кеша. Таким образом снижается нагрузка на сервер, которому не приходится самому обслуживать всех клиентов, и повышается производительность — кеш ближе к клиенту и ресурс передаётся быстрее. Кеширование является основным источником повышения производительности веб-сайтов. Однако, кеш надо правильно сконфигурировать: ресурсы редко остаются неизменными, так что копию требуется хранить только до того момента, как ресурс изменился, но не дольше.
Существует несколько видов кешей, которые можно разделить на две основные категории: приватные кеши и кеши совместного использования. В кешах совместного использования (shared cache) хранятся копии, которые могут направляться разным пользователям. Приватный кеш (private cache) предназначен для отдельного пользователя. Здесь будет говориться в основном о кешах браузеров и прокси, но существуют также кеши шлюзов, CDN, реверсные прокси кеши и балансировщики нагрузки, разворачиваемые на серверах для повышения надёжности, производительности и масштабируемости веб-сайтов и веб-приложений.
Приватный (private) кеш браузера
Общий (shared) прокси-кеш
Кеш совместного использования — это кеш, который сохраняет ответы, чтобы их потом могли использовать разные пользователи. Например, в локальной сети вашего провайдера или компании, может быть установлен прокси, обслуживающий множество пользователей, чтобы можно было повторно использовать популярные ресурсы, сокращая тем самым сетевой трафик и время ожидания.
Цели кеширования
Первичный ключ состоит из метода запроса и запрашиваемого URI (зачастую используется только URI, поскольку целью кеширования являются только GET-запросы). Вот примеры того, что обычно записывается в кеш:
Ответы на запросы отличные от GET , если есть что-либо, подходящее для использования в качестве ключа кеша.
Управление кеш ированием
Заголовок Cache-control
Полное отсутствие кеширования
В кеше не должно сохраняться ничего — ни по запросам клиента, ни по ответам сервера. Запрос всегда отправляется на сервер, ответ всегда загружается полностью.
Кешировать, но проверять актуальность
Перед тем, как выдать копию, кеш запрашивает исходный сервер на предмет актуальности ресурса.
Приватные (private) и общие (public) кеши
Директива "public" указывает, что ответ можно сохранять в любом кеше. Это бывает полезно, если возникает потребность сохранить страницы с HTTP-аутентификацией, или такими кодами ответа, которые обычно не кешируются. Директива же "private" указывает, что ответ предназначен отдельному пользователю и не должен храниться в кеше совместного использования. В этом случае ответ может сохраняться приватным кешем браузера.
Срок действия (Expiration)
Самой важной здесь является директива "max-age=<seconds>" — максимальное время, в течение которого ресурс считается "свежим". В отличие от директивы Expires , она привязана к моменту запроса. К неизменяющимся файлам приложения обычно можно применять "агрессивное" кеширование. Примером таких статических файлов могут быть изображения, файлы стилей (CSS) или скриптов (JavaScript).
Подробнее об этом рассказывается в разделе Свежесть ресурса.
Проверка актуальности
При использовании директивы "must-revalidate" кеш обязан проверять статус ресурсов с истёкшим сроком действия. Те копии, что утратили актуальность, использоваться не должны. Подробнее об этом рассказано ниже, в разделе Валидация кеша.
Заголовок Pragma
Свежесть сохранённой копии
Однажды попав в кеш, ресурс, теоретически, может храниться там вечно. Однако, поскольку объем хранилища конечен, записи периодически приходится оттуда удалять. Этот процесс называют вытеснением данных из кеша (cache eviction). Кроме того, ресурсы могут изменяться на сервере, поэтому кеш требуется обновлять. Поскольку HTTP является клиент-серверным протоколом, сервера не могут сами обращаться к кешам и клиентам при изменении ресурса; им необходимо договориться о сроке действия сохранённой копии. До его истечения ресурс считается свежим (fresh), после — устаревшим (stale). Алгоритмы вытеснения отдают предпочтение "свежим" ресурсам. Тем не менее, копия ресурса не удаляется из кеша сразу же по истечении её срока действия; при получении запроса на устаревший ресурс кеш передаёт его дальше с заголовком If-None-Match (en-US) на случай, если копия все ещё актуальна. Если это так, сервер возвращает заголовок 304 Not Modified («не изменялось»), а тело ресурса не посылает, экономя тем самым трафик.
Вот пример того, как протекает этот процесс при использовании совместного кеша прокси:
Срок действия (freshnessLifetime) вычисляется на основании нескольких заголовков. Если задан заголовок "Cache-control: max-age=N", то срок действия равен N. Если его нет, а это бывает очень часто, проверяется заголовок Expires , и, если он есть, то срок действия берётся равным значению заголовка Expires минус значение заголовка Date. Наконец, если нет ни того ни другого, смотрят заголовок Last-Modified. Если он есть, то срок действия равен значению заголовка Date минус значение заголовка Last-modified разделить на 10.
Время устаревания (expirationTime) вычисляется следующим образом:
где responseTime — это время получения ответа по часам браузера, а currentAge — текущий возраст кеша.
Обновление статических ресурсов (Revved resources)
Чем больше ресурсов может быть взято из кеша, тем быстрее сайт реагирует на запросы и тем выше его производительность. Из этих соображений их "срок годности" имеет смысл делать как можно большим. Однако, возникает проблема с ресурсами, которые обновляются редко и нерегулярно. Как раз их кеширование даёт больше всего выгоды, но сильно затрудняет обновление. Такие ресурсы можно найти на любой веб-странице: файлы скриптов (JavaScript) и стилей (CSS) изменяются редко, но уж если это произошло, обновление надо произвести как можно быстрее.
Этот метод имеет дополнительное достоинство: одновременное обновление двух кешированных ресурсов не приводит к ситуации, при которой устаревшая версия одного ресурса используется вместе с новой версией другого. Это очень важно для сайтов с взаимосвязанными файлами стилей CSS или JS-скриптов — связь может возникнуть, например, из-за ссылок на одни и те же элементы HTML-страницы.
Номер версии, добавляемый к статическому ресурсу, не обязательно записывать в виде стандартного номера версии наподобие 1.1.3, или другого возрастающего числового значения. Это может быть что угодно, позволяющее избежать совпадений — например, дата.
Валидация кеша
Валидация кеша запускается при нажатии пользователем кнопки перезагрузки. Кроме того, она может выполняться в ходе обычного просмотра страниц, если кешированный ответ включает заголовок "Cache-control: must-revalidate". Другим фактором являются настройки кеширования браузера — можно потребовать принудительной валидации при каждой загрузке документа.
При истечении срока годности документа он либо проходит валидацию, либо повторно доставляется с сервера. Валидация может выполняться только если на сервере реализован сильный валидатор или слабый валидатор.
Заголовки ETag
Заголовок ответа ETag является непрозрачным для клиентского приложения (агента) значением, которое можно использовать в качестве сильного валидатора. Суть в том, что клиент, например, браузер, не знает, что представляет эта строка и не может предсказать, каким будет её значение. Если в ответе присутствует заголовок ETag , клиент может транслировать его значение через заголовок If-None-Match (en-US) будущих запросов для валидации кешированного ресурса.
Заголовок ответа Last-Modified можно использовать в качестве слабого валидатора. Слабым он считается из-за того, что имеет 1-секундное разрешение. Если в ответе присутствует заголовок Last-Modified , то для валидации кешированного документа клиент может выводить в запросах заголовок If-Modified-Since .
При запросе на валидацию сервер может либо проигнорировать валидацию и послать стандартный ответ 200 OK , либо вернуть ответ 304 Not Modified (с пустым телом), тем самым указывая браузеру взять копию из кеша. В последнем случае в ответ могут входить также заголовки для обновления срока действия кешированного ресурса.
Изменяющиеся ответы
Если кеш получает запрос, который можно удовлетворить сохранённым в кеше ответом с заголовком Vary , то использовать этот ответ можно только при совпадении всех указанных в Vary полей заголовка исходного (сохранённого в кеше) запроса и нового запроса.
Это может быть полезно, например, при динамическом предоставлении контента. При использовании заголовка Vary: User-Agent кеширующие сервера, принимая решение об использовании страницы из кеша, должны учитывать агент пользователя. Так можно избежать ситуации, когда пользователи мобильных устройств по ошибке получат десктопную версию вашего сайта. Вдобавок, это может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, и может также указать им на то, что здесь нет никакой подмены контента с целью поисковой оптимизации (Cloaking).
Поскольку значение заголовка User-Agent (en-US) различается ("varies") у мобильных и десктопных клиентов, закешированный мобильный контент не будет по ошибке отсылаться пользователям десктопов и наоборот.
Читайте также: