Кэширование сайта как сделать


Все, что нужно знать о кэшировании / Хабр

Доброго времени суток.

Представляю вашему вниманию перевод статьи «Everything you need to know about Caching — System Design» автора Animesh Gaitonde.

Введение


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



Так выглядит моя страница в Instagram при медленном соединении. Как видите, текст отображается, в то время как изображения еще не загрузились.

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

Кэширование работает по принципу «локализации ссылок». Кэш представляет собой локальное хранилище данных для ускорения поиска информации и восстановления данных. Основной целью кэша является уменьшение задержки чтения данных и увеличение пропускной способности приложения. Давайте рассмотрим несколько примеров из реальной жизни.

Использование кэша


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

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

Как работает кэш?


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

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

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

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

Следующая диаграмма демонстрирует процесс чтения данных из кэша:

Ключевые концепции кэша


Время жизни (Time to Live, TTL)

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

В случае с Netflix, сервер будет кэшировать наиболее часто просматриваемые или популярные шоу. Не никакой надобности хранить в кэше шоу, которые никто не смотрит.

Например: хранить в кэше сериал «Бумажный дом» рациональней, чем фильм «Индиана Джонс».

Политика удаления

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

Существует несколько политик очистки кэша, таких как «старые (наименее недавно используемые)» (Least Recently Used, LRU), «редко запрашиваемые (наименее часто используемые)» (Least Frequently Used, LFU), «последние (наиболее недавано используемые)» (Most Recently Used, MRU). Эти политики удаляют данные из кэша по определенному принципу.

Старые

Из кэша удаляются данные, которые давно не запрашивались. Как только кэш заполняется, старые данные удаляются, новые добавляются.

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

Редко запрашиваемые

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

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

Из этого кэша впоследствии удаляются редко набираемые слова. В приведенном примере, если вы будете использовать слова «feature», «features», «feather» и т.д., через какое-то время телефон перестанет предлагать вам «feat», поскольку оно будет удалено из кэша.

Последние

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

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

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

Типы кэша


Запись через кэш

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

Недостатком такого подхода является увеличение времени выполнения записи. Он не подходит для высоконагруженных систем с частыми операциями записи данных. Однако он отлично подходит для приложений, часто перечитывающих данные, хранящиеся в БД. Медленная запись компенсируется быстрым чтением и согласованностью.

Запись из кэша

Альтернативой первому подходу служит запись данных в кэш и добавление отметки об изменении данных для их последующего обновления в БД.

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

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

Запись в обход кэша

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

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

Примеры использования кэша в распределенных системах


Список открытых проектов для работы с кэшем:
  • Redis
  • Memcached
  • VoltDB
  • Aerospike DBS
  • Apache Ignite

Благодарю за внимание.

Руководство на 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.

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

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

.

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 отличается («различается») для мобильных и настольных клиентов, кеши не будут использоваться для ошибочного обслуживания мобильного контента для пользователей настольных компьютеров и наоборот.

См. Также

.

javascript - Кеширование веб-сайта - браузер кеширует страницы / js-файлы веб-сайта и не позволяет пользователю видеть обновления веб-сайта

Переполнение стека
  1. Около
  2. Товары
  3. Для команд
  1. Переполнение стека Общественные вопросы и ответы
  2. Переполнение стека для команд Где разработчики и технологи делятся частными знаниями с коллегами
  3. Вакансии Программирование и связанные с ним технические возможности карьерного роста
.

Как ускорить работу вашего веб-сайта Divi с помощью подключаемого модуля кэширования

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

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

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

Как правило, большинство плагинов предлагает две основные формы кэширования: кеширование страницы и кеширование браузера.

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

Хотя это и не стандартные функции, большинство современных подключаемых модулей кэширования предлагают комбинацию следующих функций:

  • Минификация : Обычно для файлов CSS и JS минификация удаляет ненужные символы из кода, не влияя на функциональность. Здесь удаляются такие символы, как комментарии, строки, пробелы и т. Д., Чтобы уменьшить общий размер файла и увеличить время загрузки.
  • Сжатие Gzip : один из многих методов сжатия, Gzip сжимает файлы на сервере и возвращает их (файлы меньшего размера) во время запросов.Помимо плагинов для кэширования и сжатия, сжатие Gzip можно настроить вручную, изменив код в файле .htaccess.
  • Поддержка CDN : CDN (или сеть доставки контента) позволяет хранить статический контент в нескольких облачных хранилищах. Это особенно полезно для веб-сайтов, которые регулярно публикуют контент с богатым изображением, использование CDN снимает нагрузку с одного сервера. Хотя не всем веб-сайтам необходимо использовать CDN, стоит отметить, какие плагины кэширования предлагают поддержку CDN в том случае, если это применимо к вашим конкретным потребностям или потребностям вашего клиента.


Если вы ищете дополнительную информацию о CDN, прочтите наш пост « Все, что вам нужно знать об использовании CDN с WordPress ».

.

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

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

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

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