Моя шпаргалка — плагин WP Super Cache и его настройки. WP Super Cache — настройка кэширования Поисковые и другие боты

Всем привет!

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

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

Как вы наверняка знаете, при загрузке страниц сайта браузер считывает все данные с сервера. Он последовательно прогружает html, css, js-файлы, формируя привычные для нас страницы.

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

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

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

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

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

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

Установить кэширование на ресурс с ВП можно несколькими способами:

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

Последний вариант мы и рассмотрим в сегодняшней статье. Если быть более точным, то речь пойдет о плагине WP Super Cache. Абсолютно бесплатное расширение, которое легко может быть установлено прямо из админки.

После установки модуля кэширования на сайт с WordPress скорость загрузки страниц может возрасти в 3 – 7 раз. Зависит это от нескольких факторов: “веса” шаблона, количества других плагинов, их веса, параметров хостинга и т. д.

Установка

Автоматическая установка

Установить WP Super Cache можно прямо из панели управления ВП. Переходим в “Плагины” – “Добавить новый”. Откроется каталог расширений, где в поле “Поиск” вводим название нашего плагина.

Можно также попытаться найти его во вкладках “Популярные” или “Рекомендуемые”. Как правило, такие полезные модули представлены там одними из первых.

Этот продукт очень часто обновляется. Обратите внимание на галку “Совместим с вашей версией WordPress”. При выборе расширений всегда нужно обращать внимание на нее, потому как некоторые из них могут конфликтовать с новыми версиями CMS.

Ручная установка

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

Для ручной установки мы должны перейти на страницу WP Super Cache на сайте платформы , после чего загрузить себе на компьютер архив с актуальной версией.

Теперь мы должны распаковать архив в папку /wp-content/plugins/ . Это можно сделать как с помощью файлового менеджера на хостинге / операционной системе, так и .

При работе с локальной машиной или выделенным сервером возможны проблемы с правами на файлы и каталоги. WP Super Cache не сможет записывать кэш. В этом случае вы должны будете самостоятельно выставить все параметры доступа. Это можно сделать с помощью инструментов внутри операционной системы (того же Linux) или FileZilla.

Во всех случаях после успешной установки и активации вы увидите следующее уведомление.

Настройка

Теперь мы разберемся с вопросом, как правильно настроить WP Super Cache. Мы можем воспроизвести два варианта: быструю настройку и тонкую.

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

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

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

Быстрая настройка

Для выполнения первичной быстрой настройки вы должны перейти на страницу управления во вкладку “Простые”. Обратите внимание на пункт “Статус кэширования”, после чего переключите чекпоинт на вариант “Кэширование включено”. Теперь остается подтвердить изменения, нажав кнопку “Обновить”.

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

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

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

Тонкая настройка

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

Итак, первое, что мы увидим на этой странице – метод доставки кэша. У нас есть два варианта: простой и эксперт. Первый рекомендован самими авторами плагина и подойдет для большинства хостингов. “Эксперт” может потребовать дополнительных манипуляций с хостингом и самим сайтом.

Давайте более подробно рассмотрим каждый из них:

  • Простой

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

Этот вариант будет полезен, когда сам хост работает на Nginx и нет возможности редактировать его параметры. Простой режим позволит избежать всех возможных проблем с сервером.

  • Эксперт

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

На сервере должен быть установлен Apache и вместе с ним включены следующие модули: mod_rewrite, mod_mime, mod_headers и mod_expires.

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

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

Разное

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

Разные параметры:

  • Не кэшировать для известных пользователей: рекомендованная опция, которую желательно включить. Например, если вы забудете ее включить и решите настроить что-то на своем сайте, то из-за кэша вы не сразу увидите изменения. Каждый раз придется заходить в настройки WP Super Cache и вручную удалять кэш.
  • Не кэшировать страницы с GET : позволяет отключить запись в кэш страницы с UTM-метками и параметрами GET. Как правило, эта функция не используется вебмастерами. Нужна только при определенных обстоятельствах, которые нас пока что не сильно-то интересуют.
  • Сжимать файлы кэша : дополнительное сжатие файлов при помощи gzip. На обычных хостингах вряд ли будет работать, потому что там чаще всего используются нестандартные версии Nginx или Apache. Возможность включения gzip-сжатия уточняйте в технической поддержке вашего хостинга.
  • Кэш HTTP заголовков : при включении этой опции вместо одного файла будет создаваться два – в формате PHP. В один будут записаны все заголовки (тайтлы), в другой – содержимое. В большинстве случаев эта функция не нужна. Все тайтлы регулируются самим сервером.
  • Автоперестройка кэша : оставляем функцию включенной, т. к. это позволит повысить скорость загрузки. Плюс не будет проблем с дополнительной нагрузкой на сам хост.
  • Ошибка 304 : еще один рекомендованный параметр, который надо включить. Теперь при повторном визите одного конкретного пользователя по неправильному адресу страница с ошибкой 304 будет подгружаться из кэша, лишая необходимости заново генерировать ее. Снимает нагрузку с сервера.
  • Считать известных пользователей анонимными : спорная функция. Все пользователи, которые известны вашему ресурсу (комментаторы, авторизованные и т. д.) будут получать кэш наравне с анонимами. При включении может возникнуть ряд неприятных ошибок, которые приведут к проблемам с отображением у этих самых “известных” пользователей. В большинстве случаев в этой опции нет нужды. Оставляем выключенной.
  • Гордо заявить миру, что сайт выдержит любую нагрузку : копирайт авторов плагина. Размещается в футере с обратной ссылкой на разработчиков. Включить или оставить все как есть – решайте сами. Но я бы не пихал лишние копирайты в футер, тем более что с большинством шаблонов это может конфликтовать.

Расширенные

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

Что входит в расширенные параметры:

  • Включить динамическое кэширование : подойдет для страниц с динамическим содержимым. Также будет полезно, если вы постоянно правите настройки или код шаблона. Отключаем, т. к. для обычных блогов и сайтов в нем нет никакой нужды.
  • Поддержка мобильных устройств : включаем, только если на проекте используется своя отдельная мобильная тема. Она создается либо с помощью функционала шаблона, либо с помощью плагинов. Однако спешу заметить, что по большей части эта функция не используется.
  • Убрать поддержку UTF-8 из файла.htaccess : опять же отключаем. Опция нужна только в том случае, если в htaccess отображаются некорректные символы.
  • Очистить все файлы кэша при публикации или обновлении : удобная функция. Когда вы постоянно редактируете записи или страницы, автоматическое очищение кэша может лишить вас необходимости делать это вручную.
  • Дополнительная сверка кэша : отключаем опцию, т. к. она может нарушить работу вашего ресурса. В обычных условиях в ней нет никакого смысла.
  • Обновлять страницу при добавлении нового комментария: в обычных условиях некоторые пользователи не будут видеть новых комментариев. Эта функция позволит вам избежать таких проблем. Теперь при добавлении нового комментария кэш страницы будет обновляться.
  • Создать список страниц в кэше: абсолютно ненужная функция. Посмотреть список можно в разделе “Состояние кэша”.
  • Жесткая блокировка файлов: не особо полезная настройка, которая будет актуальна только для очень слабых хостингов. Отключаем.
  • Поздняя инициализация: параметр, который будет полезен разработчикам. Для обычных пользователей будет создавать дополнительные проблемы. Отключаем.
  • Секретный ключ: нужен для просмотра страницы в обход кэша. Работает это так: https://сайт.ру/?donotcachepage=ВАШКЛЮЧ.

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

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

Просроченные страницы и очистка мусора

Задаем время жизни кэша. То есть если таймаут будет составлять 1 800 секунд, то это значит, что каждые полчаса файлы будут генерироваться заново – кэш будет обновляться. Рекомендуемое значение – 1 час. Но вы можете установить значение самостоятельно, исходя из мощности вашего сервера. Чем мощнее сервер, тем меньше время жизни.

Здесь же настраивается планировщик – инструмент, который осуществляет удаление просроченных файлов. Как правило, таймер планировщика составляет ⅓ от жизни кэша. Но вы можете изменить это значение по своему желанию.

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

Допустимые типы записей и адреса

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

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

Чуть ниже вы можете увидеть поля для настройки конкретных файлов, которые не будут учитываться WP Super Cache. Далее следуют поисковые боты, запросы которых также запрещены для кэширования. По умолчанию здесь все настроено. Дополнительные манипуляции могут потребоваться только в крайнем случае.

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

Заключение

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

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

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

О других читайте в нашем обзоре.

Если вы хотите самостоятельно разобраться с WP Super Cache, да и вообще с созданием сайтов на WordPress, я рекомендую вам . В нем будут рассмотрены все основные аспекты разработки собственного проекта для заработка, его оптимизации и дальнейших перспектив. Опытные вебмастера зарабатывают от 100 до 500 тысяч рублей в месяц. Чем вы хуже? Скорее переходите по ссылке, чтобы узнать все подробности.

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

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

Чем дело кончилось?

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

Спасение нашлось в обсуждениях к одной из статей Евгения Версуса , где автор комментария очень подробно, а главное, по русски, объяснил, что нужно делать. Не поверите. Целого года нерабочего состояния такого важного плагина, как WpTouch Mobile, можно было не допустить, благодаря всего трем простым действиям.

Если у вас такая же проблема, то решить ее можно так:

1. Заходим в настройки плагина WP Super Cache. В разделе «Плагины» , в самом низу страницы проверяем наличие плагина WPTouch. Если нет, то включаем его.

2. На странице плагина переходим во вкладку «Расширенные» (вторая по счету вкладка). Поставьте галочку, если ее нет напротив «Поддержка мобильных устройств».

3. Скроллим страницу вниз, находим раздел «Поисковые и другие боты» . Копируем этот список:

iPhone
iPod
Android
BB10
BlackBerry
webOS
IEMobile/7.0
IEMobile/9.0
IEMobile/10.0
MSIE 10.0
iPad
PlayBook
Xoom
P160U
SCH-I800
Nexus 7
Touch

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

4. Для собственного спокойствия можно проделать стандартную процедуру очистки кэша: раздел «Состояние кэша» — Обновить статистику кэша — Удалить весь кэш.

Все, оба плагина работают без конфликтов, и проверить это можно сразу же, на страницах проверки мобильных страниц в Google:

Поисковые системы подтвердили, что все в порядке. Заходим в свой смартфон и проверяем, насколько удобно сайт выглядит для других пользователей. На самом деле, мой сайт отображается в смартфоне так, как это видит Яндекс, а не Google, в следующий раз нужно будет разобраться и поискать причину. Главное, что в Google сегодня появилась долгожданная запись о том, что сайт оптимизирован для мобильных устройств.

Вот из таких маленьких радостей и состоит счастье вебмастера 😀. Сегодня удачный день.

[Наука на будущее]: выучить английский язык, сделать адаптивную версию сайта 😀 😀.

Эффективность WP Super Cache

Просто приведу 2 примера, до и после установки и настройки плагина

То есть, вы сами видите грубый расчёт, без плагина страница генерируется 879 миллисекунд , а с плагином — 84 миллисекунды . Разница в 10 раз! Ещё остались сомнения в том, нужно ли его устанавливать?
Особо рекомендую к использованию на , и если ваш сайт по типу информационный : блог или статейник — основное содержание почти не меняется.
Есть и противопоказания, но они больше условные: например, если ваш сайт почти не содержит постоянного содержимого, например предоставляет некоторый сервис, динамически изменяемые в php блоки и тому подобное. Правда, и тут можно найти выход, настроив тип кеширования Legacy или PHP и включив Enable dynamic caching в настройках. Так что, пути выхода есть:) Однако, я лично думаю, что для таких сайтов лучше обходиться объектным кешированием, например, на основе , что тоже будет довольно эффективно.

Обзор плагина WP Super Cache

Принцип работы прост: плагин создаёт статичные html и php файлы – копии страниц WordPress и сохраняет их в кеш: /wp-content/cache/supercache/ . Потом, при заходе пользователя на какую-либо страницу сайта, WordPress, вместо того, чтобы создать страницу с нуля, отдаёт браузеру заранее сохранённую копию html-страницы из кеша или собирает её максимально быстро из готовых php-файлов. Думаю, вполне очевидно, что такой вариант выходит экономнее по затратам ресурсов сервера и быстрее в плане скорости загрузки страницы.
Конечно, кеш отдаётся не всегда. При настройках по умолчанию, кеш не отдаётся для:

  1. Залогиненных пользователей;
  2. Пользователей, которые только что оставили комментарий на сайте;
  3. Пользователей, которые просматривают защищённую паролем запись.

Но, так как доля этих пользователей незначительна, WP Super Cache является очень эффективным кеширующим инструментом.

Где скачать WP Super Cache

Скачать плагин вы можете из официального репозитория https://wordpress.org/plugins/wp-super-cache/

Как установить плагин WP Super Cache

Можно либо распаковать архив в директорию плагинов /wp-content/plugins/ , либо воспользоваться загрузчиком плагинов в админке http://example.com/wp-admin/plugin-install.php?tab=upload

Если у вас свой виртуальный или выделенный сервер, обязательно выставите на распакованные файлы, каталоги, и /wp-content/ , чтобы кеш смог записываться

Также, более простым вариантом будет зайти в http://example.com/wp-admin/plugin-install.php , вбить в поиск WP Super Cache и установить найденный плагин

Сигналом об удачной установке будет надпись:

Настройка WP Super Cache

После установки плагин нужно настроить. Это не займёт много времени. Самые основные моменты я опишу сначала, про тонкую настройку — чуть дальше.

Процесс установки и настройки WP Super Cache на видео:

Если на данном этапе вы видите ошибку


значит, у вас не настроены ЧПУ (человеко-понятные урлы). Переходите по ссылке http://example.com/wp-admin/options-permalink.php и выберите любой вариант, кроме первого

Теперь с ходу вас может огорошить сообщением

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

Включаем кеширование

И тут же чуть ниже проверяем

В принципе, всё, плагин работает и уже кеширует страницы:)
Но делает он в этом варианте не совсем эффективно. Приступим к тонкой настройке

Тонкая настройка кеширования

Переходим на вкладку Настройки (http://example.com/wp-admin/options-general.php?page=wpsupercache&tab=settings)

Статус кэширования

Включить кеширование Отмечаем. Если снять галочку, кеширование выключится. То есть, грубо говоря, этот пункт включает и выключает кеширование, то есть делает то же самое, что и включение/отключение кеширования на странице http://example.com/wp-admin/options-general.php?page=wpsupercache&tab=easy

Метод доставки кеша


Тут есть 2 варианта на выбор:

Простой В данном случае, кеш будет обслуживать PHP. Вариант, когда сервер работает на + PHP-FPM, и нет возможности вносить изменения в конфигурацию NGINX. Также, может понадобиться, если на сайте используется отдельная тема для мобильных девайсов. В остальных случаях, выбирайте режим Эксперт. Эксперт Использовать mod_rewrite для обслуживания кешированных файлов. Выбираем этот пункт как наиболее быстрый и удобный для сервера.

Разное

Не кэшировать страницы для известных пользователей. (Рекомендовано) Включать однозначно. Если отключить, для известных пользователей (их 3 типа, указывались выше) будет генерироваться отдельный кеш, который ещё и всплыть наружу может, если теоретически. Ещё вы не будете видеть тулбар админа на страницах, что очень неудобно, когда нужно отредактировать страницу, сбросить кеш или ещё что-то в этом духе. Не кешировать страницы с параметрами GET (?x=y в конце URL)

Если отметить, то будет принимать во внимание параметры запроса и не кешировать её, если URL будет с параметрами навроде http://example.com/post?utm_source=twitter . Можно включить, можно отключить, смотрите по вашим потребностям. Чаще всего, его отключают. Сжимать файлы кэша чтобы ускорить работу. (Рекомендовано)

Отключить. В дополнение к обычному html будет создавать сжатую в gzip копию. Если экономите дисковое пространство — отключайте. Если у вас сервер на чистом , либо без gzip, что встречается довольно редко — включите. Можете включить и посмотреть, будет мешать — отключите. Будет глючить на вашем хостинге — отключите. Кеш HTTP заголовков с содержимым страницы. Отключить. Включать, если есть проблемы с отдачей . Заголовками HTTP должен заведовать , а не плагин кеширования. При включении кеш страницы будет создаваться не в виде одной единой HTML-страницы, а в виде двух php-файлов, один из которых содержит заголовки, а второй — HTML-копию сгенерированной страницы. Ошибка 304. Данная ошибка возникает тогда, когда страница не была изменена со времени прошлого запроса. Включать обязательно. Будет отдавать 304 заголовок повторно зашедшему пользователю, если страница не изменилась, что означает, что его браузер не будет выкачивать страницу с сервера, а воспользуется сохранённой локально копией, что очень полезно и эффективно.

Если включен режим Эксперт , то есть в работе используется mod_rewrite , то этот пункт будет неактивным, ибо включен по умолчанию.

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

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

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

Расширенные

Включить динамическое кеширование. Требует «PHP» или упрощенного режима кеширования. (Смотрите ЧаВо или код примера в wp-super-cache/plugins/dynamic-cache-test.php). Отключать. Эта опция будет полезна тем, кто изменяет код шаблонов, вставляя в них динамическое содержимое. Он работает, исполняя динамический код на странице перед тем, как выдать её браузеру пользователя.
На пример такого шаблона можно посмотреть тут /wp-content/plugins/wp-super-cache/plugins/dynamic-cache-test.php Поддержка мобильных устройств. (Требуется внешний плагин или тема. Смотрите ЧаВо для дополнительной информации) Отключить. В наш век адаптивного дизайна вопрос становится неактуальным. Включите, если же ваша тема подразумевает отдельную выдачу для мобильных, либо вы пользуетесь одним из следующих плагинов:

  • Jetpack’s Mobile Theme Module
  • WPTouch
  • WordPress Mobile Edition
  • WordPress Mobile Pack
Убрать поддержку UTF-8 из файла.htaccess . Требуется только если вы видите странные символы или пунктуация некорректна. Требует обновления правил rewrite Отключить. Необходимо включать, только если вы видите странные символы или некорректные знаки пунктуации, что случается крайне редко. Очистить все файлы кеша при публикации или обновлении страницы или записи. Очищает весь кеш, когда запись или страница публикуется или обновляется. Я отключил, так как не вижу смысла сбрасывать весь кеш из-за одной страницы. Вы смотрите по вашей ситуации. Дополнительная сверка кэша (очень редко может нарушить работу кэширования). Отключить Обновлять страницу при добавлении нового комментария к ней На ваше усмотрение Создать список страниц в кэше (выводится на этой странице) Отключить. Список страниц в кеше можно посмотреть в разделе Состояние кеша «Поздняя» инициализация. Плагин будет отображать кэшированные страницы после загрузки WordPress. Опция полезна при режиме совместимости. Отключить НЕ КЕШИРОВАТЬ СТРАНИЦУ секретный ключ: Ключ, с помощью которого можно обойти кеш. Например, чтобы увидеть главную страницу в обход кеша, зайдите на страницу http://example.com/?donotcachepage=(ключ вставите свой)

Когда все пункты пройдены, сохраняем их.

Модуль Mod Rewrite

Если вы выбрали способ кеширования mod_rewrite , то плагин потребует обновить .htaccess

Прокручиваем страницу вниз и обновляем

Просроченные страницы, Очистка мусора

Теперь нужно настроить правила очистки устаревшего кеша

  • Таймаут кэширования — выставляется время жизни кеша в секундах, сколько времени он остаётся актуальным. Хорошим тоном будет начать с 1 часа (3600 секунд). Вы подбирайте время, исходя из принципа, как часто обновляется контент на сайте: чем реже, тем большее число можно ставить. Например, в статейниках вполне можно оставлять 86400 секунд, что соответствует 24 часам.

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

  • Планировщик — как часто проверять устаревание кеша. Можно выбрать Таймер — тогда кеш будет проверяться постоянно с интервалом в указанное число секунд, а можно выбрать Часы — тут указывается чёткое время (час и минута) по UTC, в которое с регулярностью Интервал будет проходить проверка актуальности кеша.
  • Электронные адреса для уведомлений — отсылать ли уведомления на email администратора сайта об очистке мусора.

Поисковые и другие боты

Чтобы запретить плагину кэшировать запросы от поисковых ботов и других сетевых роботов, введите их названия в поле ниже (по одному в строке). Если копия страницы уже существует в кэше Super Cache, то она все равно будет отправлена боту.

Стираем и оставляем поле пустым, сохраняем.

Остальные настройки

Несущественны, поэтому оставляете как есть.

Общий кеш

Этот раздел важен в свете того, что Google и другие поисковые системы теперь учитывают скорость загрузки страниц как один из факторов ранжирования сайта в поиске.
Обычно, WP Super Cache создаёт кеш только той страницы, которую кто-то посетил. И это, по сути, правильно. Но что, если этим кто-то является бот поисковика? Никакого положительного эффекта от кеширующего плагина он не увидит. И раздел настроек Общий кеш позволяет избежать этого недоразумения, предсоздавая закешированные копии всех страниц сайта ещё до их посещения кем-либо.

wget -r -l 3 -nd --wait=5 --delete-after http://example.com

Такую конструкцию можно отправить в :

  1. В консоль пишем crontab -e
  2. Конструкция ниже обходит сайт каждый час, поддерживая страничный кеш свежим: 0 * * * * wget -r -l 3 -nd --wait=5 --delete-after http://example.com

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

  • Обновлять кеш каждые 120 минут — кеш будет считаться актуальным 2 часа. Вы ставите своё время. Чем реже обновляется сайт, тем большее время можно поставить.
  • Предварительный режим (очистка мусора работает не полностью, опция рекомендована к включению.) — включить, в объяснении, думаю, не нуждается.
  • Предзагрузка тегов, категорий и других таксономий. — включить. Будут предзагружены категории, теги и другие таксономии.

Теперь сохраняете данные или создаёте кеш прямо сейчас.

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

На этом необходимый минимум по настройке WP Super Cache завершён. Далее будет идти информация для продвинутых вебмастеров и системных администраторов, а также некоторая информация, касаемо часто возникающих вопросов.

Если у вас магазин на основе WooCommerce, и вы хотите использовать WP Super Cache, то вам нужно исключить следующие страницы из процесса кеширования:

  • Корзина (Cart)
  • Мой аккаунт (My Account)
  • Оформление заказа (Checkout)

Это можно сделать в разделе Расширенные example.com/wp-admin/options-general.php?page=wpsupercache&tab=settings , просто отметив Страницы (is_page)

Такой вариант подойдёт, если у вас мало записей в Страницах. Если же их много, то лучше не отмечать Страницы (is_page) , а добавить части адресов служебных страниц в раздел чуть ниже, как на примере

Добавляем служебные страницы WooCommerce в список исключений

Как проверить работу WP Super Cache самостоятельно

Вы можете самостоятельно проверить, как работает плагин, довольно просто.
Для начала, открываете браузер в режиме инкогнито или в приватном режиме. Для Firefox это делается с помощью Ctrl + Shift + P , для Google Chrome или Яндекс Браузера — Ctrl + Shift + N .
Теперь откройте исходный код страницы (Ctrl + U) и посмотрите в самый конец, там вы увидите примерно следующее

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

Если вы заглянете в исходный код страницы под админом, то увидите что-то навроде

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

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

Для этого, жмёте F12 , откроется консоль, там вы переходите в раздел Network Doc или Сеть HTML и перезагружаете страницу (Ctrl + F5). По завершению, ищете верхнюю строчку и время отклика, оно должно занимать в норме 100-300 миллисекунд или 0.1-0.3 секунды. Может и больше, если ваш хостинг в США, а вы в России, континентальную удалённость нужно учитывать. Но вообще, чем меньше это значение, тем лучше.
Ради интереса можете временно выключить WP Super Cache и сравнить значения до и после установки плагина.

И ещё маленький совет — кеш браузера иногда будет путать вас, поэтому полностью сбрасывайте его с помощью Ctrl + F5 , а лучше тестируйте работу плагина и сайта в режиме инкогнито браузера.

Настройка сервера для WP Super Cache

Итак, плагин у нас установлен и настроен правильно. Как проверить правильность работы рассказано выше, а теперь перейдём к настройке сервера. Это будет актуальным, если у вас собственный VDS/VPS или выделенный сервер.

htaccess (Apache) и WP Super Cache

Этот пункт касается тех, у кого сервер настроен в режиме работы LAMP (Linux, Apache, Mysql, PHP). Если во фронтенде или в роли основного вебсервера установлен NGINX, советую перейти к разделу ниже

Если вы дошли до этого пункта и выбрали в настройках плагина режим mod_rewrite , то по сути ничего делать и не нужно. Но, в целях оптимизации работы (.htaccess загружается каждый раз при загрузке сайта, apache2.conf только 1 раз во время рестарта сервера), или если обработка правил.htaccess на вашем сервере отключена, вы можете скопировать данные из.htaccess и перенести их в конфигурационный файл, где объявляются настройки вашего сайта (например, в Debian он может располагаться в /etc/apache2/vhosts/сайт.conf).

# BEGIN WPSuperCache RewriteEngine On RewriteBase / #If you serve pages from behind a proxy you may want to change "RewriteCond %{HTTPS} on" to something more sensible AddDefaultCharset UTF-8 RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^+ RewriteCond %{HTTP:Profile} !^+ RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond %{HTTPS} on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html.gz" [L] RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^+ RewriteCond %{HTTP:Profile} !^+ RewriteCond %{HTTP:Accept-Encoding} gzip RewriteCond %{HTTPS} !on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html.gz" [L] RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^+ RewriteCond %{HTTP:Profile} !^+ RewriteCond %{HTTPS} on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index-https.html" [L] RewriteCond %{REQUEST_METHOD} !POST RewriteCond %{QUERY_STRING} !.*=.* RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$ RewriteCond %{HTTP:X-Wap-Profile} !^+ RewriteCond %{HTTP:Profile} !^+ RewriteCond %{HTTPS} !on RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html -f RewriteRule ^(.*) "/wp-content/cache/supercache/%{SERVER_NAME}/$1/index.html" [L] # END WPSuperCache # BEGIN WordPress RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] # END WordPress

Пример конфигурационного файла . Вы можете вставить в него код из.htaccess

#user "example" virtual host "example.com" configuration file ServerName example.com AddDefaultCharset UTF-8 AssignUserID example example DirectoryIndex index.html index.php DocumentRoot /var/www/example/data/www/example.com ServerAdmin ServerAlias www.example.com SetHandler application/x-httpd-php SetHandler application/x-httpd-php-source php_admin_value sendmail_path "/usr/sbin/sendmail -t -i -f " php_admin_value upload_tmp_dir "/var/www/example/data/mod-tmp" #php_admin_value session.save_path "/var/www/example/data/mod-tmp" php_admin_value session.save_handler "memcache" php_admin_value session.save_path "tcp://127.0.0.1:11211" php_admin_value open_basedir "/var/www/example/data:." CustomLog /var/www/httpd-logs/example.com.access.log combined ErrorLog /var/www/httpd-logs/example.com.error.log php_admin_flag engine on Options -ExecCGI # После этой строки вставляются данные из.htaccess

NGINX и WP Super Cache

Итак, у вас свой виртуальный или выделенный сервер, и вам хочется, чтобы WP Super Cache выжимал по максимуму. Но, из коробки этот плагин предлагает настройки только под php и htaccess . И здесь я опишу, как можно настроить конфигурационный файл NGINX под оптимальную работу с WP Super Cache. Это может пригодиться, скажем, если у вас сервер собран в виде LEMP (Linux, NGINX (EngineX), Mysql, PHP), и вместо в бекенде php-fpm .

Хочу заметить, что в данной конфигурации кеш NGINX включать не нужно, так как NGINX будет брать статичные страницы из кеша WP Super Cache напрямую, минуя интерпретатор PHP. И, на мой взгляд, удобнее именно эта конфигурация, так как управлять кешем из админпанели WordPress удобнее, нежели чем из консоли кешем NGINX.

Если для сайта включен кеш NGINX, и отключить его нельзя, то плагин WP Super Cache лучше не использовать, так как увеличения производительности Вы не заметите, а двойное кеширование будет только мешать.

WooCommerce и другие подобные плагины, которые используют переменные GET в URL, требуют, чтобы при обработке PHP передавались параметры $args:

Try_files $wpsupercache $uri $uri/ /index.php?$args

Однако, WP Super Cache может работать неправильно при использовании /index.php?$args .
В таком случае, могу посоветовать выбрать другой кеширующий плагин, например, W3 Total Cache.

В примере будет 3 варианта конфигурации, в зависимости от режима работы WordPress: обычный сайт, WordPress Multisite с сайтами в подкаталогах и WordPress Multisite с сайтами на поддоменах. По умолчанию, включен первый режим. Если у вас Miultisite, просто раскомментируйте нужные строчки.

Ниже пример конфигурационного файла + php-fpm с возможностью заменить бекенд на с комментариями:

### user "example" virtual host "example.?p=1915 server { ### Если Multisite поддомены, для domain mapping замените строку ниже на: server_name example.com *.example.com; server_name example.com www.example.com; ### Если Multisite поддомены, раскомментируйте строку ниже для domain mapping #server_name_in_redirect off; ### Если Multisite поддомены, для domain mapping замените строку ниже на: listen 80 default_server; listen 1.2.3.4:80; # Укажите вместо 1.2.3.4 IP своего сервера charset UTF-8; disable_symlinks if_not_owner from=$root_path; index index.html index.php; root $root_path; set $root_path /var/www/example/data/www/example.com; access_log /var/log/example.com.access.log ; error_log /var/log/example.com.error.log warn; #error_log /var/log/example.com.debug.error.log debug; include /etc/nginx/vhosts-includes/*.conf; ### Если gzip не включен глобально, включим его тут # gzip on; # gzip_disable "msie6"; # gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; ### Разрешаем доступ для Let"s Encrypt location ~ /\.well-known { allow all; } ### Запрещаем доступ к файлам и каталогам с точкой в начале названия, например, .htaccess, .git location ~ /\. { deny all; } ### Запрещаем доступ к файлам с расширением.php в каталогах загрузок, например, /wp-content/uploads location ~* /(?:uploads|languages|files)/.*\.php$ { deny all; } ### Если Multisite в режиме подкаталогов, например http://example.com/wpsubsite/, просто раскоментируйте блок ниже ### #if (!-e $request_filename) { # rewrite /wp-admin$ $scheme://$host$uri/ permanent; # rewrite ^(/[^/]+)?(/wp-.*) $2 last; # rewrite ^(/[^/]+)?(/.*\.php) $2 last; #} ### Устанавливаем новую переменную $cache_uri, которой присваиваем запрос из предустановленной переменной $request_uri set $cache_uri $request_uri; ### POST запросы не кешируются if ($request_method = POST) { set $cache_uri "null cache"; } ### Запросы с параметрами в URL не кешируются if ($query_string != "") { set $cache_uri "null cache"; } ### Не кешировать запросы URL, содержащие следующие части (как правило, админка и служебные, sitemap yoast) if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|+-sitemap(+)?.xml)") { set $cache_uri "null cache"; } ### Не использовать кеш для авторизованных пользователей и последних комментаторов if ($http_cookie ~* "comment_author|wordpress_+|wp-postpass|wordpress_logged_in") { set $cache_uri "null cache"; } ### фавикон не логировать location = /favicon.ico { log_not_found off; access_log off; } ### robots.txt может генерироваться движком WordPress location = /robots.txt { try_files $uri /index.php; } ### Определим расположение кеша # ${http_host}${cache_uri} может не содержать слеша, потому что ${cache_uri} уже может начинаться со слеша. У вас может быть иначе. Проверьте с помощью add_header set $wpsupercache /wp-content/cache/supercache/${http_host}/${cache_uri}/index.html; ### Ещё будем пробовать искать версию для https set $wpsupercache_ssl /wp-content/cache/supercache/${http_host}/${cache_uri}/index-https.html; ### Если у вас сайт на SSL/TLS, то есть, работает по HTTPS, то вместо index.html у вас будут генерироваться index-https.html if ($scheme = "https") { set $wpsupercache /wp-content/cache/supercache/${http_host}/${cache_uri}/index-https.html; } ### Проверочный заголовок, если раскомментируете, увидите, что располагается в переменной $wpsupercache #add_header X-wpsc "$wpsupercache" always; ### Можно отлавливать переменные в заголовках. Подробнее http://сайт/nginx # add_header X-uri "$uri" always; # add_header X-cache-uri "$cache_uri" always; # add_header X-$http_host "$http_host" always; ### Переходим к работе с бекендом ### ### Ниже будут 2 варианта настройки, php5-fpm и Apache. #### ### По умолчанию, всё настроено под первый вариант. ### ### Чтобы включить Apache, закомментируйте всё, что идёт ниже до блока Apache ### ### 1. PHP-FPM ### # Статичные файлы не логируем, выставляем http заголовок Expires на год location ~* ^.+\.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ { expires 365d; log_not_found off; access_log off; } # Основной запрос, в котором мы пытаемся сначала получить закешированную версию страницы # Если кеша нет, тогда отправляемся к WordPress, чтобы он его нам создал location / { try_files $wpsupercache $wpsupercache_ssl $uri $uri/ /index.php?$args ; } # Наш бекенд - php-fpm location ~ \.php$ { try_files $uri =404; include fastcgi_params; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_index index.php; fastcgi_param SERVER_NAME $http_host; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # Тут, в зависимости от того, как установлен FastCGI, выбирайте или TCP, или сокет # TCP #fastcgi_pass 127.0.0.1:9000; # Сокет fastcgi_pass unix:/var/www/php5-fpm/example.com.sock; # Тут укажите путь до сокета php-fpm конкретного пользователя или сайта } ### 2. Apache. Если у вас в бекенде Apache, расскоментируйте всё, что ниже закомментировано одинарной решёткой, и закомментируйте всё, что выше до блока 1.PHP-FPM ### ### Статичные файлы не логируем, выставляем http заголовок Expires на год #location ~* ^.+\.(jpe?g|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf)$ { # expires 365d; log_not_found off; access_log off; # try_files $uri $uri/ @apache ; #} #location / { # try_files $wpsupercache $uri @apache ; #} ### php скрипты отправляем сразу в бекенд #location ~ [^/]\.ph(p\d*|tml)$ { # try_files /does_not_exists @apache; #} ### Отправляем запросы к бекенду (Apache или php-fpm) ### Если у вас в бекенде Apache, раскомментируйте блок ниже #location @apache { ### Apache ### #proxy_pass http://127.0.0.1:8080; #proxy_redirect http://127.0.0.1:8080 /; #proxy_set_header Host $host; #proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; #proxy_set_header X-Forwarded-Proto $scheme; #} }

Учтите, что Apache тут висит на порту 8080

Перезагружаем NGINX

Nginx -t && nginx -s reload

Как проверить правильность URI файлов кеша WP Super Cache

Допустим, Вы хотите проверить страницу http://example.com/mypage , правильно ли видит NGINX её расположение в кеше. Для этого надо:


Устранение ошибок в работе WP Super Cache

Порой возникают небольшие проблемы, которые довольно просто решаются
:

A2enmod headers && a2enmod expires

Потом перезагружаете Апач

Service apache2 restart

WP Super Cache не создает общий кэш

Убедитесь, что вы нажимаете именно на кнопку Создать общий кеш сейчас . Через 10 секунд перезагрузите страницу, вы увидите процесс создания кеша. Заодно проверьте каталог /wp-content/cache/supercache/имя_домена/структура_сайта/

Если кеш всё равно не создаётся, и у вас простой хостинг — напишите в службу поддержки, они помогут решить вопрос.

Если у вас свой сервер или vps/vds, и кеш не создаётся, проверьте, есть ли у WordPress права писать в каталог /wp-content/cache/ . Это можно сделать, скажем, с помощью Far Manager :


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

Не забудьте сбросить кеш браузера, например, Ctrl + F5 для конкретной страницы во фронтенде или Ctrl + Shift + Delete для Google Chrome

Как правильно удалить WP Super Cache

Плагин удаляется так же, как и любой другой — через панель управления http://example.com/wp-admin/plugins.php , деактивацию плагина и его последующего удаления.

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

Если хотите удалить его вручную:

  1. Отключить кеширование и очистить кеш (желательно 3 способом)
  2. Деактивировать плагин
  3. Удалить из define("WP_CACHE", true);
  4. Удалить из.htaccess правила, добавленные в секцию #WPSuperCache
  5. Удалить /wp-content/advanced-cache.php и /wp-content/wp-cache-config.php
  6. Удалить /wp-content/cache/
  7. Удалить /wp-content/plugins/wp-super-cache/

W3 Total Cache или WP Super Cache

Меня часто спрашивают, какой плагин лучше выбрать, W3 Total Cache или WP Super Cache? Отвечу по пунктам:

Выбирайте WP Super Cache, если:

  • Если у вас информационный сайт — статейник, блог и тому подобное;
  • Вы не особо разбираетесь или не хотите разбираться в тонкостях работы и настроек сайтов и плагинов. WP Super Cache проще в настройке, но от этого он не менее эффективен в работе;
Выбирайте W3 Total Cache, если:
  • Если у вас сервис или сайт, у которого большая аудитория — авторизованные пользователи — сервис, где основной сервис внутри, для доступа к которому нужно авторизоваться, форум, соцсеть и тому подобное;
  • Вы — программист или пытливый человек, которому нравится возиться и разбираться в тонкой настройке кеширования, контролировать подобные тонкости.

В заключение

Пользуйтесь плагинами страничного кеширования в WordPress, даже если ваш сайт малопосещаемый, возможно, это поможет ему ранжироваться выше.
WP Super Cache — самый простой, проверенный и распространённый инструмент из подобных, который при должной настройке сможет удерживать работоспособным любой нагруженный проект на WordPress даже при внезапных всплесках посещаемости.

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

Мое мнение о плагине только положительное так, как плагин на отлично справляется со своими функциями и при этом имеет гибкие и понятные настройки. Популярность плагина равна более 7 мнл. скачиваний и рейтингу в 4,5★.

Скачать плагин можно с официальной страницы на WordPress.org .

Назначение и принцип работы плагина WP Super Cache

Плагин WP Super Cache является бесплатным, основная его функция — это увеличение скорости загрузки сайта, за счет создания кэшированных страниц. Но как же работает этот чудо плагин? Давайте разберем принцип работы кэш-плагинов, на примере WP Super Cache.

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

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

Принцип загрузки сайта с плагином WP Super Cache. Веб-страницы, к которым обращались пользователи, кэшируются или, по-другому, создаются их полные кэш-копии в формате.php или.html . А сами копии сохраняются в папку:

/wp-content/cache/supercache/domen.ru

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

Настройка WP Super Cache

Настройка модуля Mod Rewrite

Данный модуль после включения работает не правильно и требует обновится:

Рисунок 12. Некорректные правила модуля Mod Rewrite

Для этого кликаем по кнопке Обновить и идет в самый конец правил mod_rewrite :

Рисунок 13. Обновление правил mod_rewrite

После обновления новые правила подсветятся зеленым фоном:

Рисунок 15. Обновленные правила mod-rewrite

Это означает, что правила mod_rewrite успешно встроены в файл htaccess. Остается проверить их наличие.

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

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

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

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

Если очень надо то можно и подождать пока появится страница, но уверен в 50% случаев пользователь ее закроет и вернется обратно в поиск. Тоже самое происходит, когда на ресурс переходят роботы или асессоры и как результат не подобаемая скорость работы сайта может плачевно повлиять на его позиции в ТОПе, ведь какой с него там толк, когда статьи все равно не сможет прочитать пользователь.

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

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

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

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

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

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

И ниже я продемонстрирую на подопытном сайте, как за счет правильных настроек WP Super Cache легко повлиять на скорость загрузки данной площадки.

Что умеет плагин кэширования и как его настроить

Итак, первым делом нам надо скачать плагин WP Super Cache, установить и активировать его работу на wordpress сайте, для этого воспользуйтесь этой ссылкой .

После того как вы активировали плагин его надо включить, для чего переходим в «Настройки» далее «WP Super Cache» и отмечаем пункт «Кэширование включено (Рекомендовано)» во вкладке «Кэш» и нажимает «Обновить».

Теперь можно проверить работу кэширования для чего жмем «Проверить».

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

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

Ниже я постараюсь более детально со всеми ними вас ознакомить, так как там можно найти много полезного.

Кэш

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

Настройки

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

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

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

После внесения изменений надо нажать кнопку «Обновить» после чего должно появиться сообщение, что требуется «Обновить правила Mod_Rewrite» для чего спускаемся вниз страницы и жмем соответствующую кнопку.

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

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

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

Что мне еще понравилось в опциях WP Super Cache, так это возможность указать какие страницы не стоит подвергать кэшированию.

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

https: //сайт/wordpress/kak-nastroit-wp-super-cache.html

https://сайт/wordpress/kak-nastroit-wp-super-cache.html

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

На этой вкладке будет отображаться статистика количества кэшированных страниц, для чего стоит нажать ссылку «Обновить статистику».

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

Общий кэш

На этой вкладке у пользователя появится возможность закэшировать не определенную страницу, а весь сайт целиком, то есть каждая запись занесется в папку кэша.

Результаты работы плагина

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

Скорость сайта я буду проверять сервисами: pr-cy.ru/speed_test и webwait.

Значения когда не стоит WP Super Cache

Показания в pr-cy.ru

Для главной страницы:

Для внутренней страницы:

Показания в webwait.com

Для главной страницы:

Для внутренней страницы:

Когда был установлен и настроен плагин

Показания в pr-cy.ru

Для главной:

Для внутренней:

Показания в webwait.com

Для главной:

Для внутренней:

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

Немного новостей...

По итогам прошлого месяца больше всех комментариев на блоге оставила Юлия (int-net-partner.ru ), но она не превысила порог минимального их числа, поэтому победитель не был определен.

Внимательно читайте условия конкурса « » и выигрывайте ценные призы.

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

Понравилась статья? Поделиться с друзьями: