Как найти кэш сайта


10 инструментов, которые помогут найти удалённую страницу или сайт

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

Поисковые системы

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

1. Кеш Google

Чтобы открыть копию страницы в кеше Google, сначала найдите ссылку на эту страницу в поисковике с помощью ключевых слов. Затем кликните на стрелку рядом с результатом поиска и выберите «Сохранённая копия».

Есть и альтернативный способ. Введите в браузерную строку следующий URL: http://webcache.googleusercontent.com/search?q=cache:lifehacker.ru. Замените lifehacker.ru на адрес нужной страницы и нажмите Enter.

Сайт Google →

2. Кеш «Яндекса»

Введите в поисковую строку адрес страницы или соответствующие ей ключевые слова. После этого кликните по стрелке рядом с результатом поиска и выберите «Сохранённая копия».

Сайт «Яндекса» →

3. Кеш Bing

В поисковике Microsoft тоже можно просматривать резервные копии. Наберите в строке поиска адрес нужной страницы или соответствующие ей ключевые слова. Нажмите на стрелку рядом с результатом поиска и выберите «Кешировано».

Сайт Bing →

4. Кеш Yahoo

Если вышеупомянутые поисковики вам не помогут, проверьте кеш Yahoo. Хоть эта система не очень известна в Рунете, она тоже сохраняет копии русскоязычных страниц. Процесс почти такой же, как в других поисковиках. Введите в строке Yahoo адрес страницы или ключевые слова. Затем кликните по стрелке рядом с найденным ресурсом и выберите Cached.

Сайт Yahoo →

Сейчас читают 🔥

Специальные архивные сервисы

Указав адрес нужной веб‑страницы в любом из этих сервисов, вы можете увидеть одну или даже несколько её архивных копий, сохранённых в разное время. Таким образом вы можете просмотреть, как менялось содержимое той или иной страницы. В то же время архивные сервисы создают новые копии гораздо реже, чем поисковики, из‑за чего зачастую содержат устаревшие данные.

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

1. Wayback Machine (Web Archive)

Сервис Wayback Machine, также известный как Web Archive, является частью проекта Internet Archive. Здесь хранятся копии веб‑страниц, книг, изображений, видеофайлов и другого контента, опубликованного на открытых интернет‑ресурсах. Таким образом основатели проекта хотят сберечь культурное наследие цифровой среды.

Сайт Wayback Machine →

2. Arhive.Today

Arhive.Today — аналог предыдущего сервиса. Но в его базе явно меньше ресурсов, чем у Wayback Machine. Да и отображаются сохранённые версии не всегда корректно. Зато Arhive.Today может выручить, если вдруг в Wayback Machine не окажется копий необходимой вам страницы.

Сайт Arhive.Today →

3. WebCite

Ещё один архивный сервис, но довольно нишевый. В базе WebCite преобладают научные и публицистические статьи. Если вдруг вы процитируете чей‑нибудь текст, а потом обнаружите, что первоисточник исчез, можете поискать его резервные копии на этом ресурсе.

Сайт WebCite →

Другие полезные инструменты

Каждый из этих плагинов и сервисов позволяет искать старые копии страниц в нескольких источниках.

1. CachedView

Сервис CachedView ищет копии в базе данных Wayback Machine или кеше Google — на выбор пользователя.

Сайт CachedView →

2. CachedPage

Альтернатива CachedView. Выполняет поиск резервных копий по хранилищам Wayback Machine, Google и WebCite.

Сайт CachedPage →

3. Web Archives

Это расширение для браузеров Chrome и Firefox ищет копии открытой в данный момент страницы в Wayback Machine, Google, Arhive.Today и других сервисах. Причём вы можете выполнять поиск как в одном из них, так и во всех сразу.

Разработчик: Разработчик

Цена: Бесплатно

Читайте также 💻🔎🕸

Руководство на 110% по кэшу сервера и браузера (2020)

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

Если вы хотите создать гостеприимную и теплую среду на своем сайте WordPress, это должно быть быстро. Здесь нет никаких «если», «а» или «но». Без быстрой загрузки страниц и контента вы потеряете посетителей.Это факт. Но один из способов обойти это - правильно кэшировать веб-сайт.

Как показано на этой диаграмме отказов от Kissmetrics:

… посетителям просто не хватает терпения ждать. Ну так что ты делаешь?

Для начала вы получите надежный план веб-хостинга. Затем, может быть, на всякий случай накиньте поверх него CDN. И, конечно же, оптимизируйте изображения до и после того, как они окажутся внутри WordPress.

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

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

Кэширование веб-сайта? Что это такое?

Итак ... что такое кеширование веб-сайтов?

Вы сделали все возможное, чтобы оптимизировать свой сайт WordPress для повышения скорости и безопасности, но тем не менее, скорость загрузки отстает. Итак, вы открываете свой любимый инструмент для тестирования скорости (например, Google PageSpeed ​​Insights) и видите такие предложения по оптимизации:

👍 Если Google говорит вам использовать кеширование веб-сайтов, тогда вам лучше это сделать.Нажмите, чтобы твитнуть. Прежде всего, конечно, вам нужно понять, что такое кеширование веб-сайтов. Итак, давайте разберем это:

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

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

  1. Посетитель загружает ваш URL в свой браузер.
  2. Браузер отправляет на ваш сервер запрос, в котором говорится: «Привет, я хотел бы сейчас увидеть этот веб-сайт». Это называется HTTP-запрос .
  3. Затем сервер собирает запрошенные материалы и отправляет их. Здесь происходит замедление, , особенно если ничего не было сделано для минимизации скриптов, файлов Gzip, оптимизации размеров изображений и так далее.
  4. Как только файлы будут переданы, браузер отобразит веб-сайт.Этот процесс будет повторяться всякий раз, когда посетитель перейдет на новую страницу. Как вы понимаете, все эти запросы к серверу могут вызвать перегрузку системы и серьезно снизить производительность, если ваш контент не оптимизирован по скорости.

Вот почему производительность является такой общей проблемой среди разработчиков WordPress. 😠 Первое впечатление, которое вы производите на посетителя, имеет большое значение, поэтому, если загрузка занимает слишком много времени, вы можете непреднамеренно (и, возможно, навсегда) отключить кого-то от вашего бренда.Нажмите, чтобы твитнуть всего за одно посещение.

Вот почему вам нужно кеширование сайта. Проще говоря, вот как работает этот процесс:

  1. Посетитель загружает ваш URL в свой браузер.
  2. Браузер отправляет на ваш сервер запрос, в котором говорится: «Привет, я хотел бы сейчас увидеть этот веб-сайт».
  3. Затем сервер думает: «Я только что отправил эту страницу другому посетителю, и с тех пор ничего не изменилось, поэтому я просто отправлю ту же самую страницу этому парню». Вот что такое кеширование сайта. Все ваши изображения и контент, скрипты и текстовые файлы превращаются в статический HTML-файл и отправляются посетителю. Затем последующие посетители получают копию этого файла, сохраненную на вашем сервере. Это избавляет сервер от необходимости повторять один и тот же процесс снова и снова.
  4. Как только файлы будут переданы, браузер отобразит веб-сайт.
  5. Кэш «сбрасывается» при обновлении страницы или по истечении лимита кеша. (Что я немного объясню.) И HTTP-запрос и обработка начинается снова.

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

Преимущества веб-кэширования

Есть и другие преимущества, которые ваш веб-сайт получит от кеширования. Фактически, у веб-кеширования есть несколько преимуществ:

  • Чем быстрее сайт, тем выше производительность поиска.
  • страницы, которые загружаются быстро, улучшают общее впечатление ваших посетителей. Хотя есть и другие факторы, они могут превратить настороженного посетителя в платящего покупателя.
  • Меньше времени, затрачиваемого на обработку HTTP-запросов, означает, что на вашем хостинг-сервере сохраняется больше памяти. Если вы платите за дополнительные вычислительные мощности, это может сэкономить вам (или вашему клиенту) деньги на услугах веб-хостинга.
  • Кэширование веб-сайтов - полезный инструмент для сайтов WordPress, которые также испытывают большие скачки трафика.

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

Кэширование сервера и кеширование браузера

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

Обычно, когда мы говорим о процессе кэширования веб-сайтов (как описано выше), мы обычно называем это наиболее полным.И есть множество способов поставить эту систему кэширования на место. Один из способов - обновить заголовки на вашем сервере Apache. Плагины WordPress - другое. И вы также можете использовать CDN.

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

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

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

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

По сути, вы говорите браузеру пользователя удалить сохраненную копию веб-страницы (кешированную страницу), чтобы вы могли увидеть только что обновленную версию.

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

Но процесс тот же. Между браузером и сервером существует новый слой, на котором сохраняется копия вашей веб-страницы. Когда срок действия кэшированной копии истекает или пользователь очищает кэшированное содержимое, процесс начинается заново.Вот почему браузер выдает предупреждение пользователям: «Некоторые сайты могут загружаться медленнее при следующем посещении». Когда кеш очищается, серверу необходимо заново сгенерировать статическую HTML-страницу… что требует времени.

Методы веб-кэширования

Полностраничное кэширование и кеширование объектов

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

Кэширование всей страницы

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

📈 Если вашему веб-сайту необходимо регулярно обрабатывать большие объемы трафика или он имеет тенденцию получать большие всплески трафика (например, в праздничные дни), полностраничное кеширование определенно полезно. Нажмите, чтобы твитнуть

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

Кэширование объектов

С другой стороны, кэширование объекта - это когда только часть веб-страницы сохраняется для будущего использования. Поскольку кэш объектов может быть запрограммирован на постоянное хранение, это означает, что кэширование все еще может использоваться, когда посетители переходят со страницы на страницу, если один и тот же «объект» существует в разных местах.Это особенно полезно, если на всем веб-сайте используются одни и те же громоздкие и ресурсоемкие элементы или код.

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

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

Как использовать кеширование браузера в WordPress

Наш следующий шаг - заняться фактическим использованием и внедрением этих различных видов кэширования веб-сайтов в WordPress. Начнем с кеширования браузера:

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

Есть несколько предложений из Кодекса WordPress, которые вы должны здесь использовать.

Контроль кеширования HTTP

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

Для этого откройте файл .htaccess в корне вашего веб-сайта. Kinsta предлагает ввести следующий код после строки # END WordPress :


Набор заголовков Cache-Control" max-age = 84600, public "

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

Истекает заголовки

Еще одно обновление, которое вы можете сделать, - это указать , когда истечет срок хранения кэшированного содержимого . Это может показаться излишним - и в большинстве случаев так оно и есть, - но некоторые браузеры будут искать и директивы max-age, и Expires, поэтому лучше всего просто включить обе из них здесь.

Откройте файл .htaccess еще раз. Опять же, где-нибудь после строки кода # END WORDPRESS вставьте следующее:

## ИСКЛЮЧАЕТ КЭШЕР ЗАГОЛОВКИ ##

ExpiresActive On
ExpiresByType image / jpg "доступ на 1 год"
ExpiresByType image / jpeg "доступ на 1 год"
ExpiresByType image / gif "доступ на 1 год"
ExpiresByType image / png "доступ 1 год"
ExpiresByssType доступ 1 месяц "
Приложение ExpiresByType / pdf" доступ 1 месяц "
Приложение ExpiresByType / javascript" доступ 1 месяц "
Приложение ExpiresByType / x-javascript" доступ 1 месяц "
Приложение ExpiresByType / x-shockwave-flash" доступ 1 месяц "
ExpiresByType изображение / значок x «доступ на 1 год»
ExpiresDefault «доступ на 2 дня»

## ИСКЛЮЧАЕТ КЭШЕР ЗАГОЛОВКИ ##

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

ETags

Наконец, ETags должны быть отключены во время этого процесса . Тег объекта (или ETag) позволяет браузерам кэшировать веб-страницы по своему усмотрению. Однако, когда вы отключите их в файле .htaccess, вы сообщаете браузерам, чтобы они игнорировали их правила и следовали тем, которые вы указали в директивах Cache-Control и Expires Headers.

В вашем .htaccess введите следующий код:

# TN - BEGIN Отключить ETags
FileETag Нет
# TN - END Отключить ETags

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

Как использовать кеширование сервера в WordPress

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

Плагины WordPress

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

  • Используйте только один плагин кеширования за раз .
  • Прежде чем выбрать плагин, хорошенько оцените его качество . Если вы не будете осторожны, плагин кеширования может еще больше замедлить работу вашего сайта.
  • Кроме того, просмотрите список запрещенных подключаемых модулей вашего веб-хостинга . Для некоторых плагин запрещен из-за того, что он влияет на производительность вашего сайта.Для других это связано с тем, что ваш план веб-хостинга уже включает кеширование сервера. Так что обязательно проверьте.
  • Используйте плагин кеширования, который предоставляет необходимое количество функций и элементов управления . Итак, если вы хотите реализовать кеширование объектов, ваш плагин должен позволять вам это делать.
  • Кроме того, просмотрите результаты вашего сайта WordPress после установки плагина. Подтверждает ли ваш инструмент тестирования скорости, что плагин кеширования работал? Ваш сайт загружается быстрее? И вы все еще видите предложение «использовать кеширование»?

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

Вот несколько предложений по плагинам кеширования, которые вы можете использовать:

Автоматическая оптимизация


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

Кэш-активатор


Плагин Cache Enabler поступает от KeyCDN и предоставляет своим пользователям возможности полностраничного кэширования. Просто включите его и дайте возможность плагину генерировать статические HTML-версии ваших веб-страниц. Кроме того, вы можете минимизировать HTML и CSS, а также конвертировать изображения в WebP, когда это возможно (все методы, которые помогают ускорить работу сайтов WordPress). Этот плагин предлагает связать его с Autoptimize.

Оптимизация скорости страницы Hummingbird


Плагин Hummingbird - это не просто плагин для кеширования страниц.Он также поддерживает кеширование браузера и Gravatar (последнее отлично подходит, если вы ведете блог или новостной сайт с большим количеством комментариев). Кроме того, Hummingbird делает все, что вы ожидаете от плагина оптимизации WordPress: минификацию, сжатие Gzip и оптимизацию изображений.

Кэш LiteSpeed ​​


Для тех из вас, кто ищет плагин WordPress, с помощью которого можно реализовать кэширование объектов и браузеров, плагин LiteSpeed ​​Cache сделает это. Он также выполняет некоторые другие изящные задачи по оптимизации скорости, такие как минификация, отложенная загрузка изображений и интеграция с CDN.

W3 Общий кэш


W3 Total Cache - один из самых популярных плагинов кэширования WordPress, и не зря. Прежде всего на вашем сервере минимизируются файлы, скрипты и контент. Интеграция с CDN также обеспечивает улучшенное управление медиафайлами и файлами тем для более быстрой доставки. Кроме того, доступны всевозможные варианты кеширования: страницы, сообщения, каналы, скрипты, объекты базы данных и фрагменты.

WP Самый быстрый кэш


Еще один плагин для кэширования с высокой загрузкой и высоким рейтингом - WP Fastest Cache.С его помощью вы можете комбинировать файлы CSS, а также файлы JavaScript. Минификация файлов включена, как и сжатие Gzip. И, конечно же, этот плагин обрабатывает кеширование всей страницы, а также кеширование браузера от вашего имени. Однако, если вы хотите контролировать, когда очищается кеш или для каких ресурсов, вы можете вручную управлять им.

WP супер кэш


Наконец, мы подошли к WP Super Cache, самому популярному плагину кэширования, доступному в репозитории WordPress.И что делает этот плагин таким загружаемым? Во-первых, он предоставляет вам три режима кеширования: экспертный, простой и WP-cache, в зависимости от вашего уровня комфорта. Самое лучшее в этом то, что каждый параметр дает вам конфигурации, необходимые для правильного кэширования ваших веб-страниц. Вам просто решать, какой вариант лучше всего подходит для вашего сайта.

CDN

Если вы действительно не хотите добавлять на свой сайт еще один плагин WordPress, не переживайте. Вместо этого вы можете использовать сеть доставки контента (CDN) .

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

Недавно я писал о том, что такое CDN и что он делает для веб-сайта WordPress. В это руководство я включил рекомендации для следующих сетей CDN:

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

Кэширование сервера с помощью Varnish


Есть еще один вариант, который следует рассмотреть, если вы хотите использовать кеширование сервера на своем сайте WordPress, и эта рекомендация исходит прямо из Кодекса WordPress:

Тайник с лаком.

Это ускоритель веб-приложений с открытым исходным кодом (или кэширующий обратный прокси-сервер HTTP), который работает с WordPress, но не находится внутри CMS. Все, что вам нужно сделать, это загрузить файлы с веб-сайта, а затем установить их так, чтобы они располагались перед вашим веб-сервером.Как только они будут запущены, Varnish обещает ускорить ваш веб-сайт в 300–1000 раз по сравнению с обычной скоростью доставки.

Завершение

Вы уже знаете, насколько важна скорость для вашего сайта WordPress и насколько хорошо посетители ее воспринимают. (Конечно, это не единственный фактор принятия решений для них, но он, безусловно, помогает произвести на них хорошее первое впечатление.) Имея системы кэширования веб-сайтов на уровне сервера и браузера, вы можете только еще больше сократить время загрузки. .Просто нужно найти правильный метод реализации или инструмент, чтобы все сделать правильно.

Если вас по-прежнему беспокоит скорость вашего сайта и вы хотите тратить на это меньше времени, узнайте, что может предложить WP Buffs. Наши быстрые планы позаботятся обо всех потребностях вашего веб-сайта в кешировании и многом другом, избавляя вас от необходимости управлять им самостоятельно. Или ознакомьтесь с нашей программой white-label, если у вас есть клиентские сайты, которым требуется постоянная поддержка.

Хотите оставить отзыв или присоединиться к беседе? Добавляйте свои комментарии 🐦 в Twitter.

СохранитьСохранить

СохранитьСохранить

.

кэшированных веб-страниц ⏳ Просмотр старых версий любой веб-страницы

Google Web Cache
Google регулярно сохраняет версии веб-страниц на своих серверах. Эти страницы называются «кэшированной версией» веб-страницы и являются теми, которые Google использует для их обработки и вычислений, поэтому они могут быстрее отвечать на каждый запрос пользователя без необходимости искать нужные ключевые слова на всех страницах, доступных в Интернете. Веб-страницы на серверах Google позволяют узнать, как каждая веб-страница выглядела в последней сохраненной версии, даже если опубликовавший ее веб-сайт находится в автономном режиме.Google просто хранит последнюю копию каждой страницы.

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

WebCite
Webcitation.org - это система для сохранения веб-страниц по запросу, поэтому авторы могут цитировать или делать ссылки на содержимое других страниц в своих собственных работах и ​​быть уверенными, что они будут доступны в будущем.Если на желаемую веб-страницу когда-то ссылалась статья, и автор сохранил снимок страницы, то ее можно будет найти.

.

Как найти мульти-кэш - Официальный блог

Что такое мульти-кэш?

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

Выполните следующие действия, чтобы найти свой первый мульти-кэш:

1. Перейти к перечисленным координатам.

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

Вы можете найти полные координаты следующего этапа, спрятанные где-нибудь в первом месте.

Пример: наклейка с напечатанными на ней координатами, спрятанная где-то в этом месте.

Вас могут попросить найти число, слово или другую подсказку.Вам нужно будет это записать, прежде чем переходить к следующему этапу.

Пример : Второе число на табличке в этом месте - это «X» в конечных координатах тайника: N 47 ° 37,38X W 122 ° 19,197

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

Пример: Подсчитайте количество флагов перед зданием ООН, чтобы найти «X» в наборе координат для следующего этапа: N 45 ° 29.468X шир. 114 ° 23,1543

2. Перейдите ко второму набору координат

После того, как вы собрали информацию, необходимую на первом этапе, вы можете переходить к следующему этапу. Введите координаты, полученные на первом этапе, в свой GPS (или добавьте путевую точку с помощью приложения геокешинга) и перейдите к новому местоположению.

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

3. Продолжайте эти шаги, пока не найдете физический тайник

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

Связанные

.

HTTP-кеширование - веб-технологии для разработчиков

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

Тайники различных типов

Кэширование - это метод, который сохраняет копию данного ресурса и возвращает ее по запросу.Когда веб-кеш имеет запрошенный ресурс в своем хранилище, он перехватывает запрос и возвращает его копию вместо повторной загрузки с исходного сервера. Это позволяет достичь нескольких целей: снизить нагрузку на сервер, который не должен обслуживать всех клиентов сам, и повысить производительность за счет того, что он находится ближе к клиенту, т. Е. Требуется меньше времени для передачи ресурса обратно. Для веб-сайта это важный компонент в достижении высокой производительности. С другой стороны, он должен быть правильно настроен, поскольку не все ресурсы остаются неизменными навсегда: важно кэшировать ресурс только до тех пор, пока он не изменится, а не дольше.

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

Частный кеш браузера

Частный кеш предназначен для одного пользователя. Возможно, вы уже видели «кеширование» в настройках вашего браузера. Кэш браузера содержит все документы, загруженные пользователем по протоколу HTTP. Этот кеш используется, чтобы сделать посещенные документы доступными для навигации назад / вперед, сохранения, просмотра в качестве источника и т. Д. Без необходимости дополнительной поездки на сервер. Это также улучшает автономный просмотр кэшированного содержимого.

Общие кеши прокси

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

Цели операций кеширования

HTTP-кеширование необязательно, но обычно желательно повторное использование кэшированного ресурса. Однако обычные HTTP-кеши обычно ограничиваются кэшированием ответов на GET и могут отклонять другие методы. Первичный ключ кеша состоит из метода запроса и целевого URI (часто используется только URI, поскольку только GET-запросы являются целями кэширования).Распространенные формы кэширования записей:

  • Успешные результаты поискового запроса: ответ 200 (OK) на запрос GET , содержащий такой ресурс, как HTML-документы, изображения или файлы.
  • Постоянные перенаправления: ответ 301 (перемещен навсегда).
  • Ответы об ошибках: страница результатов 404 (не найдено).
  • Неполные результаты: ответ 206 (частичное содержимое).
  • Ответы, отличные от GET , если определено что-то подходящее для использования в качестве ключа кэша.

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

Управление кешированием

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

Нет кеширования

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

 Cache-Control: без магазина 
Кэш, но перепроверить

Кэш отправит запрос на исходный сервер для проверки перед освобождением кэшированной копии.

 Управление кешем: без кеширования 
Частные и публичные тайники

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

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

 Cache-Control: частный Cache-Control: общедоступный 
Срок действия

Самая важная директива здесь - " max-age = ", которая определяет максимальное время, в течение которого ресурс будет считаться свежим.В отличие от Expires , эта директива относится ко времени запроса. Для файлов в приложении, которые не изменятся, обычно можно добавить агрессивное кеширование. Сюда входят, например, статические файлы, такие как изображения, файлы CSS и файлы JavaScript.

Для получения дополнительной информации см. Также раздел «Свежесть» ниже.

 Cache-Control: max-age = 31536000 
Проверка

При использовании директивы « must-revalidate » кэш должен проверять состояние устаревших ресурсов перед их использованием, а истекшие ресурсы не должны использоваться.Дополнительные сведения см. В разделе «Проверка» ниже.

 Cache-Control: необходимо повторно проверить 

Pragma - это заголовок HTTP / 1.0, он не определен для HTTP-ответов и поэтому не является надежной заменой для общего заголовка HTTP / 1.1 Cache-Control , хотя он ведет себя так же, как Cache-Control: no-cache , если поле заголовка Cache-Control опущено в запросе. Используйте Pragma только для обратной совместимости с HTTP / 1.0 клиентов.

Свежесть

После того, как ресурс сохранен в кэше, теоретически он может обслуживаться кешем вечно. Кеши имеют ограниченное хранилище, поэтому элементы периодически удаляются из хранилища. Этот процесс называется вытеснение кеша . С другой стороны, некоторые ресурсы на сервере могут измениться, поэтому кеш следует обновить. Поскольку HTTP - это протокол клиент-сервер, серверы не могут связываться с кешами и клиентами при изменении ресурса; они должны сообщить время истечения срока действия ресурса.До истечения этого срока ресурс - свежих ; по истечении времени ресурс устаревший . Алгоритмы вытеснения часто отдают предпочтение свежим ресурсам над устаревшими. Обратите внимание, что устаревшие ресурсы не удаляются и не игнорируются; когда кэш получает запрос на устаревший ресурс, он пересылает этот запрос с If-None-Match , чтобы проверить, действительно ли он еще свеж. Если это так, сервер возвращает заголовок 304 (Not Modified), не отправляя тело запрошенного ресурса, что экономит часть полосы пропускания.

Вот пример этого процесса с прокси с общим кешем:

Срок действия свежести рассчитывается на основе нескольких заголовков. Если указан заголовок « Cache-Control: max-age = N », то время жизни свежести равно N. Если этот заголовок отсутствует, что очень часто случается, проверяется, если Expires заголовок присутствует. Если заголовок Expires существует, то его значение за вычетом значения заголовка Date определяет срок действия актуальности.Наконец, если ни один заголовок отсутствует, ищите заголовок Last-Modified . Если этот заголовок присутствует, то время жизни кэша равно значению заголовка Date минус значение заголовка Last-modified , деленное на 10.
Время истечения срока действия рассчитывается следующим образом:

 expirationTime = responseTime + freshnessLifetime - currentAge 

, где responseTime - время получения ответа в соответствии с браузером.

Возобновленные ресурсы

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

Веб-разработчики изобрели метод, который Стив Содерс назвал оборотов [1] . Нечасто обновляемые файлы именуются особым образом: в их URL, обычно в имени файла, добавляется номер ревизии (или версии). Таким образом, каждая новая ревизия этого ресурса рассматривается как отдельный ресурс, который никогда не изменяет , и срок действия которого может истечь в очень далеком будущем, обычно один год или даже больше.Чтобы иметь новые версии, все ссылки на них должны быть изменены, что является недостатком этого метода: дополнительная сложность, о которой обычно заботится цепочка инструментов, используемая веб-разработчиками. Когда редко меняются ресурсы, они вызывают дополнительное изменение часто изменяемых ресурсов. Когда они читаются, читаются и новые версии остальных.

Этот метод имеет дополнительное преимущество: обновление двух кэшированных ресурсов одновременно не приведет к ситуации, когда устаревшая версия одного ресурса используется в сочетании с новой версией другого.Это очень важно, когда на веб-сайтах есть таблицы стилей CSS или сценарии JS, которые имеют взаимные зависимости, то есть они зависят друг от друга, поскольку ссылаются на одни и те же элементы HTML.

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

Проверка кеша

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

Повторная проверка запускается, когда пользователь нажимает кнопку перезагрузки. Он также запускается при обычном просмотре, если кэшированный ответ включает заголовок « Cache-Control: must-revalidate ». Другой фактор - это настройки проверки кеша на панели настроек Advanced-> Cache . Существует возможность принудительно выполнять проверку каждый раз при загрузке документа.

ETags

Заголовок ответа ETag представляет собой значение , непрозрачное для агента-пользователя , которое может использоваться в качестве надежного валидатора. Это означает, что пользовательский агент HTTP, такой как браузер, не знает, что представляет эта строка, и не может предсказать, каким будет ее значение. Если заголовок ETag был частью ответа для ресурса, клиент может выдать If-None-Match в заголовке будущих запросов - для проверки кэшированного ресурса.

Заголовок ответа Last-Modified может использоваться как слабый валидатор. Он считается слабым, потому что имеет разрешение всего 1 секунду. Если в ответе присутствует заголовок Last-Modified-, то клиент может выдать заголовок запроса If-Modified-Since для проверки кэшированного документа.

Когда делается запрос проверки, сервер может либо игнорировать запрос проверки и ответ с нормальным 200 OK , либо он может вернуть 304 Not Modified (с пустым телом), чтобы указать браузеру использовать его кешированную копию.Последний ответ также может включать заголовки, обновляющие срок действия кэшированного документа.

Различные ответы

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

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

Это может быть полезно, например, для динамического обслуживания контента. При использовании заголовка Vary: User-Agent кэширующие серверы должны учитывать пользовательский агент при принятии решения о том, следует ли обслуживать страницу из кеша. Если вы предоставляете мобильным пользователям различный контент, это может помочь вам избежать того, что кеш может по ошибке обслуживать настольную версию вашего сайта для мобильных пользователей. Кроме того, он может помочь Google и другим поисковым системам обнаружить мобильную версию страницы, а также сообщить им, что маскировка не предназначена.

 Варьируется: User-Agent 

Поскольку значение заголовка User-Agent отличается («различается») для мобильных и настольных клиентов, кеши не будут использоваться для ошибочного обслуживания мобильного контента для пользователей настольных компьютеров и наоборот.

См. Также

.

Смотрите также

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Одноклассники
Вы можете оставить комментарий, или ссылку на Ваш сайт.

Оставить комментарий