Hyper Cache, плагин кэширования WordPress для снижения нагрузки на хостинг и ускорения сайта, установка и настройка.
Опубликовано: 23.08.2018
Всем привет. 
Эта статья будет про плагин кеширования Hyper Cache, его настройку, установку и разъяснение, зачем и почему он обязательно нужен на wordpress блоге. Если вы владеете своим сайтом или блогом, а хостинг ругается на чрезмерную нагрузку от вашего аккаунта на сервер, либо скорость загрузки сайта низкая, то вы попали куда надо. Эта статья вам, надеюсь, поможет. 
Это я так решил размять пальцы и вспомнить, как писать статьи. 
Как работает типичный wordpress сайт без кэширования на обычном хостинге.
Чтобы понять причину, нужно понять принцип работы сайта на любом хостинге. Как-то на эту тему я уже писал статью , но там было немного про другое, так что, здесь будет некое дополнение и взгляд с другой стороны.
А происходит всё примерно так: далее последует моя интерпретация работы сайта на хостинге без углубления в технические дебри, но, возможно, с разъяснением сути проблемы.
Итак, типичный сайт на wordpress состоит из множества файлов, скриптов и прочей ереси, которая у вас и у меня на экране монитора отображается в структурированное, в понятном браузеру формате HTML, и, как-то оформленное нечто. В зависимости от бюджета и фантазии вебмастера более или, соответственно, менее красивое и навороченное в дизайне . Всё это снабжено неким смыслом в виде текстов, картинок, или даже аудио сопровождения.
И вот теперь, самое интересное: суть и смысл в виде всех текстов, ссылок и т.п. находится в одном месте вашего хостинга – в базе данных сайта MySQL. А всё остальное, как картинки, скрипты, стили, тема сайта, оболочка, сам движок wordpress и прочий файловый хлам «лежит» в другом месте – в файловом менеджере на жестких дисках сервера вашего аккаунта хостинга и работает на другом, непонятном для браузера языке PHP. 
Конечно, в реальности, всё это расположено, где-то в одном месте, то есть под одной крышей, но если провести аналогию с компьютером, то тексты на диске C:, а файлы на диске D: и всё распихано по разным папкам и подпапкам, да ещё и в архивах – как-то так, наверное, для наглядности.
Но если вы уловили смысл этой наглядности, то теперь понимаете, почему для wordpress-а существуют определенные технические требования к хостингу – не каждый хостинг сможет его обслужить и не на каждом он сможет, вообще, работать. 
А теперь представим, что вы, или ваш посетитель открыл какую-то статью на вашем сайте. Что вы/он(а) видите и что происходит на самом деле?
Вы/читатель видите статью на вашем сайте в привычном для Интернета виде. А для отображения этого привычного вида серверу хостинга пришлось изрядно потрудиться, выполнив миллиарды операций за доли секунды. Ему пришлось получить ваш запрос, обработать его, отправить вам через Интернет в браузер нужные файлы сайта, отвечающие за красоту, дизайн и функции, загрузить туда же картинки и приправить всё это смыслом из текста и ссылок, вытянутых из других своих недр базы данных MySQL.
Если же сказать более грамотно технически, то все файлы движка вордпресса работают на языке PHP, а браузер понимает только HTML. Вот и приходиться движку и серверу, выполняя запрос собирать пазл из кусков кода PHP и данных MySQL, переводя всё это в HTML формат, чтобы браузер мог его правильно отобразить. То есть готовая HTML страница каждый раз генерируется на сервере снова, снова и снова… 
Даже при простом обновлении окна браузера с сайтом или переходе по какой-то ссылке.
И так при каждом запросе, при каждом открытии страницы, статьи, главной и т.д. Огромная масса работы, процессов PHP, выполненных команд и функций сервера, из которых и складывается нагрузка вашего аккаунта на сервер хостинга.
Чем больше сайт/база данных/посещаемость/сложнее дизайн/больше плагинов, тем больше действий приходится выполнять серверу и тем больше нагрузка на него от сайта.
А если к этому добавить ещё активность поисковых роботов, которые точно так же нагружают сервер своими запросами, да ещё и всяких «редисок», которые пытаются вломиться к вам на сайт ради забавы, или конкретной цели напакостить, то получается, что в один «прекрасный» момент вы получите сообщение о превышении допустимой нагрузки. Знакомая картина… 
И вот теперь после разъяснения сути проблемы мы и перейдем к её решению.
Что делает плагин кеширования Hyper Cache, как снижает нагрузку на хостинг и почему он нужен?
Вообще, есть два пути снижения нагрузки на сервер – ничего не писать и «забить» на сайт, оставив его в одностраничном виде с посещаемостью в полтора землекопа в сутки, 
либо переехать на другой тариф или выделенный сервер.
Последние варианты вам будет очень навязчиво предлагать техподдержка хостинга 
при каждом удобном и неудобном случае, невзирая на то, что это уже гораздо затратнее, как по финансам, так и по времени на обслуживание. Поскольку эти варианты, например мне, не подходят, то я и пришел к варианту с плагином кеширования, который пока справляется со своими задачами.
Суть кеширования очень проста, но от этого не менее действенна, плюс на глаз ни вы, ни ваш посетитель не заметите разницы. И вот в чем она.
Плагин кеширования делает одну очень простую вещь – он создает под каждую запрошенную посетителем страницу или статью сайта отдельный, готовый html файл – статичную html страницу, которую и отдает уже всем последующим посетителям на тот период времени, который задан в его настройках. Первый пришел – страница сгенерировалась и сохранилась в кэш, откуда потом она и выдается всем следующим.
На первый взгляд может показаться, что здесь добавилась ещё одна задача, но, несмотря на это, в итоге, суммарная нагрузка на сервер хостинга падает в разы и вы уже можете спать спокойно, не переживая за работу сайта. 
Суть здесь в том, что в каждой такой страничке уже есть всё необходимое для её привычного отображения вместе с текстами и оформлением, и всё это отдаётся сервером уже не склеенное из кусочков пазла PHP+MySQL, а готовое целиком и полностью.
Для наглядности пара картинок, как работает сайт без кэширования
и как с включенным кэшированием.
Думаю, разница очевидна – отпадает связка PHP+MySQL. А значит, отпадает существенная часть процессов, вызывающих ту самую нагрузку на сервер. 
Единственный нюанс здесь в том, что при включении такого кеширования растет занимаемое дисковое пространство от сайта на сервере, так как для каждой страницы создается её статичная html копия. Но, например, для моего сайта размер кэша равен 30-45 Мб, что некритично для моего тарифа и дискового места.
Плагин кэширования Hyper Cache – как установить на Вордпресс блог, настроить и почему именно он?
Начну с последнего – почему именно Hyper Cache? Когда-то, давным-давно, я уже пробовал подобные ему плагины, но они вызвали больше проблем и конфликтов, чем пользы, поэтому я тогда от них отказался до недавнего времени (где-то до полугода) в пользу Hyper Cache, так как мой хостинг меня просто достал 
своими напоминаниями с разводами на дорогие тарифы из-за нагрузки. Но про хостинг, это отдельная история и не сейчас – если интересно, то не пропустите , 
поделюсь своим горьким опытом.
Плагин Hyper Cache можно скачать с , либо из , либо прямо из админки найти по названию. Скачать, установить.
Прежде чем активировать, нужно включить кэширование в самом движке wordpress через добавление одной строчки кода в файл wp-config.php, который расположен в корневой папке сайта. Не меняйте в этом файле ничего лишнего 
, так как можете угробить сайт! 
Лучше сделайте резервную копию этого файла перед изменением! 
Надо добавить эту строку кода:
define(‘WP_CACHE’, true);
в любом месте до строки:
/** Абсолютный путь к каталогу WordPress. */
Я влепил сразу после:
/** Название базы данных WordPress */
И получилось так:
/** Название базы данных WordPress */
define(‘WP_CACHE’, true);
define(‘DB_NAME’, ‘noname’);
Далее возвращаемся в админку и активируем плагин. Если никаких «ругательств» в настройках плагина Настройки – Hyper Cache не появилось, значит все нормально и можно переходить дальше.
Если вылезло предупреждение, то, возможно, надо установить права на папку wp-content или wp-content/plugins/hyper-cache не ниже 700. Если такое случилось, то плагин просто не смог создать свою рабочую папку кэша wp-content/cache/hyper-cache из-за ограничения в правах. После создания рабочей папки с кэшем можно права вернуть на первоначальные, но не ниже 700 для папки кэша.
После активации крайне желательно плагин настроить под свои потребности, так как настройки по умолчанию тоже рабочие, но там есть много нюансов, на которых остановлюсь подробнее .
Идём в раздел админки Настройки – Hyper Cache, где будет такая картина с моими настройками. Эта и все последующие картинки кликабельны и откроются в полном размере в новой вкладке.
Вкладка Главные – это основные настройки плагина Hyper Cache.
Disable translations – если плохо владеете английским, то снимите здесь галочку – сможете видеть частичный кривоватый перевод настроек плагина.
Далее по пунктам:
Кэшированные страницы, будут действительны в течение ( в оригинале Cached pages will be valid for) – 48 часов, это срок кеширования страниц в часах. Хотите дольше – ставьте больше, меньше – соответственно. Если поставите 0, то это включит кэш навсегда.
Включить сжатие (Enable compression) – ДА, но нужно проверить, чтобы не было «крокозяблов» на сайте. Если они появились, значит надо снять чекбокс.
Enable on - the - fly compression - сжатие налету, ДА. Если включено, то идет сжатие ещё не кэшированных страниц прямо налету.
Когда обновлена домашняя страница, обновятся остальные (When the home is refreshed, refresh even the) – у скольких последних записей очистится кэш при обновлении главной. У меня выставлен 0.
Если обновится главная, то не факт, что надо обновить кэш последних записей, поэтому я решил для себя так.
Когда записи отредактированы (When a post is edited) – отмечены пункты очистить кэш архивов, рубрик, тэгов, но не главной. Если запись изменилась, например вы присвоили ей новую рубрику, тэг, или дату, то логично всё обновить.
При написании комментария (When a post receives a comment) – здесь у меня очистится всё. Нужно экспериментировать, согласно частоте комментирования на вашем сайте. Если комментарии появляются часто, то постоянная очистка кэша создаст лишнюю нагрузку, поэтому экспериментируйте. 
Папка кэша (Cache folder) – этот параметр я не трогал и вам не советую, если только вы наверняка не знаете, что делаете, так как можно полностью «грохнуть» сайт. Об этом предупреждает надпись в графе этого пункта. Папка кэша, которую плагин создаст автоматически, будет по адресу wp-content/cache/hyper-cache. Если же вы сами решите создать свою папку и там окажутся рабочие файлы сайта или движка, то при перезаписи кэша они могут быть удалены плагином со всеми вытекающими печальными последствиями для сайта – учтите это! 
Далее эта функция будет выполняться через (Next autoclean will run in) – самоочистка от устаревших файлов для меньшей потери дискового пространства, ДА. Здесь при включенном пункте будет виден остаток времени до следующего удаления просроченных файлов. Рекомендуется включить, чтобы не отдавать поисковым роботам документ с просроченным сроком годности. В противном случае они могут получить старый пост, а не его обновлённый вариант, например.
Разрешение кеширования браузерами (Allow browser caching) – ДА, 24 часа. Полезный пункт, который даёт разрешение на сохранение части сайта в кэше уже браузера посетителя, что также существенно снижает нагрузку на сервер и ускоряет загрузку страницы при последующих заходах. Здесь можно экспериментировать и выставлять время больше, но не сильно, так как при сильном завышении периода этого кеширования посетитель может не увидеть обновления сайта, а вы на это никак не сможете повлиять.
HTTPS – актуально, если вы используете безопасный протокол связи HTTPS. Поэтому у меня выставлен пункт про стандартный кэш. Если у вас протокол https, то, возможно, нужно выбрать другие настройки.
Use readfile() – НЕТ. Включение PHP функции отправки файла взамен стандартной. У меня пока всё работает и так, потом я хотел попробовать включить эту функцию, но забыл и оставил, как есть выключенную 
Служит ботам со страницами с закончившимся сроком действия (Serve expired pages to bots) – НЕТ. Отдавать поисковикам просроченные старицы или нет. Рекомендуется отдавать актуальные страницы, поэтому я здесь галку снял.
Следующий раздел настроек на вкладке Исключения выглядит у меня так:
Здесь остановлюсь лишь на некоторых пунктах, так как на остальных есть понятные пояснения.
Не кэшируйте домашнюю страницу – НЕТ, то есть если снять галку, то главная кэшируется и наоборот. Для снижения нагрузки лучше снять, то есть кэшировать.
Не кэшировать “стр.404″ – НЕТ, то есть кэшировать. Здесь смысл в том, что часть взлома сайтов идёт через обращение именно к странице 404 «Не найдено». А поскольку таких обращений может быть очень много при атаках на сайт, то отключенное кеширование может создать большую нагрузку на движок и сервер, да и «редиска» сможет увидеть, что искало, поэтому пускай любуется на кэш. 
Последующие пункты отключены, но в пунктах: Точный адрес URI исключить и (Начиная с) адреса URI исключить можно задать конкретные адреса вашего сайта для отключения их кеширования – ну мало ли для чего, но такая функция предусмотрена.
Куки исключить – эта функция может пригодиться, когда при кешировании не сработает какой-то плагин или скрипт, например, опроса на сайте . Можно по имени куки отключить кэширование чего-то конкретного с ними связанного. У меня установлен плагин Заплати лайком в его «бесплатной» версии и я думал, что с кэшем он будет работать некорректно, но всё обошлось, и настройка не пригодилась.
Устройства (пользовательские) исключить – НЕТ. Настройка для исключения кэширования под конкретные устройства, заходящие на сайт. Идентификация происходит по User-agent и если он совпадет с указанным, то пользователь получит «живую» страницу. Возможно, этим есть смысл пользоваться для определенного количества трафика, например, с планшетов, или телевизоров, но только в том случае, если такой процент посетителей невысок, чтобы не вызвать лишней нагрузки.
Don ‘ t serve cached pages to comment authors – ДА, включить. Интересная и важная настройка, которая не переведена, но звучит примерно так: Не отдавать кэшированные страницы комментаторам. Отвечает за включение и отключения кэшированной страницы для авторов комментариев.
Дело в том, что если комментатор оставил комментарий, который «Ожидает проверки», то при выключенной настройке он может не увидеть эту надпись. Правда, надпись у поля настройки говорит, что плагин Hyper Cache может работать с комментариями даже на кэшированной странице, благодаря маленькому скрипту, добавленному к такой странице, но я настройку включил. Попробуйте, может можно и наоборот, особенно, если у вас большой поток новых комментариев. 
Третья вкладка настроек Мобильный под этот трафик выглядит так:
Режим работы – здесь я выбрал стандартный кэш, хотя можно выбрать отдельное кеширование или отключить его вообще. Здесь есть смысл выбирать другое, отдельное кеширование, если у вас на сайте для мобильного трафика используется другая тема сайта и другой дизайн, например, плагин, генерирующий мобильный дизайн. Поскольку у меня дизайн отзывчивый и под мобильные устройства 
, то я не делал отдельного кеширования.
Мобильная тема – у меня настройка включена для активной темы сайта. Можно выбрать заведомо тему с отзывчивым адаптивным дизайном, которая есть в каждом сайте на вордпрессе – Twenty Fourteen, например. Подойдёт для тех ситуаций, когда основная тема не адаптивная, но нужно, чтобы для мобильных пользователей отдавался дизайн под их устройства. Но по тем же причинам, что указаны выше, я здесь ничего не трогал.
Тем более, что пару месяцев назад мой сайт таки прошел на совместимость с мобильными устройствами 
, а совсем недавно, буквально за пару дней до написания этого опуса, меня осенило 
и я довел «до ума» свой шаблона под мобилы, о чём собираюсь написать статью 
. Но, вы же знаете, как я собираюсь 
, поэтому – не пропустите , мало ли, вдруг пригодится.
Мобильные агенты пользователей – здесь, в списке, я ничего не трогал и всё оставил как есть, хотя, можно что-то добавить или убавить при необходимости.
В последней вкладке настроек CDN я ничего не указывал и включал, так как это мне не нужно.
Естественно, после каждого изменения настроек не забывайте нажимать синюю кнопку Сохранить, чтобы новые настройки вступили в силу. 
Также в настройках плагина есть важные синие кнопки:
Удалить весь кэш – полное стирание всего содержимого папки кэша. Может понадобиться для просмотра изменений где-то на сайте или простой очистке папки кэша.
Очистка архивов и домашней – будет очищен кэш главной страницы и архивов, если надо посмотреть что-то на « морде » сайта, не удаляя остальной кэш.
Вычисление размера кэша – по нажатию этой кнопки плагин вам выдаст размер папки со всем кэшем в мегабайтах.
Импортировать настройки – здесь можно загрузить уже сохраненные настройки поверх существующих. Удобно, когда надо использовать одинаковые настройки на нескольких своих сайтах, например. Нажал и в один клик всё настроено, как надо, но я этой кнопкой не пользовался. 
После настройки останется лишь проверить работу плагина Hyper Cache, чтобы убедиться, что контент выдается уже из кэша. Для этого надо выйти из админки, либо открыть сайт в другом браузере, или в окне с режимом Инкогнито и посмотреть исходный код страницы, нажав Ctrl+U в любом браузере. Если в самом низу кода вы увидите строку вида:
<!– hyper cache gzip 2015-10-01 10:47:24 –>
то вас можно поздравить, так как плагин Hyper Cache работает, а эта строка говорит о том, что страница выдана уже из кэша. 
Но надо упомянуть об одном нюансе, который возник у меня и может возникнуть у вас 
. Так у меня перестал работать редирект в плагине WP No External Links – внешние ссылки перестали открываться. Пришлось отключить редирект и оставить только оборачивание ссылок в noindex. Но в свете всякого «зоопарка» от поисковиков, отключение редиректа это только к лучшему. На этом косяки от работы кэширования у меня, вроде, закончились.
Выгода от установки и настройки плагина Hyper Cache очевидна – это снижение нагрузки на хостинг и увеличение скорости загрузки сайта, что стразу добавит вам несколько баллов в . А это уже в свою очередь положительно скажется на ранжировании сайта, так как поисковики любят быстрые сайты. Но самое главное, что хостинг перестал присылать свои гневно-навязчивые уведомления о превышении нагрузки .
На этом у меня всё, спасибо, что дочитали. 
P.S. Напоследок, вам для настроения, это эпичное видео про облака с . Приятного просмотра! 
Пройдись по кнопочкам, расскажи о статье друзьям - это к деньгам!