Подавляющее большинство сайтов и блогов работают на виртуальном хостинге, что не требует специализированных знаний по управлению сайтом, и это, несомненно, плюс, особенно для начинающих сайтостроителей. Но есть и отрицательная сторона – жесткие ограничения по нагрузке на сервер, что сказывается на работе сайта. При увеличении нагрузки сайт использует весь выделенный лимит и чаще всего начинает выдавать ошибку 500. Это значит, что сайт не справляется с обработкой всех запросов. Причиной такой ошибки может стать превышение лимита операций ввода-вывода, превышение установленного объема памяти, которое выделено для работы аккаунта.
Но это все последствия, а настоящих причин – две. Это высокая посещаемость и неоптимизированная работа скриптов. Лекарство существует, и это кэширование. Самый популярный в настоящее время плагин кэширования – плагин WP Super Cache. Последствия его работы – реальное снижение нагрузки на виртуальный хостинг.
Как установить плагин? Папка wp-content должна быть доступной для записи (права на запись 777).
Установка стандартная, поэтому перейдем сразу к описанию настроек и работы плагина. После того, как WP Super Cache установлен, необходимо перейти в раздел «Настройки WP Super Cache» плагина и включить кэширование во вкладке «Кэш». После включения кэширования файл wp-config.php будет немного изменен – плагин пропишет нужные директивы.
Далее войдите в «Настройки» и галочкой отметьте «Использовать mod_rewrite для обслуживания кэша». Так будет включен алгоритм кэширования файлов. Также нужно отметить пункт «». Это позволит плагину кэшировать самые посещаемые страницы сайта, то есть – давать более быстрый доступ к ним.
Здесь нужно быть особо внимательным – если сайт чрезмерно нагружает CPU, то применение сжатия еще больше увеличит нагрузку, потому что сервер, кроме выполнения команд скриптов перед кэшированием, будет еще и сжимать файлы после кэширования, а это требует увеличения времени и памяти. В таком случае сжатие кэша лучше не применять. Если сайт превысил лимит операций ввода-вывода, но нагрузка CPU нормальная, сжатие кэша целесообразно будет включить, эта функция увеличит быстродействие за счет того, что время отдачи файлов уменьшится и сократится их размер.
Дальше отметьте пункт «Поддержка мобильных устройств» и «Обновлять страницу при добавлении нового комментария». Первое действие позволит работать закэшированным страницам с мобильными браузерами, а второй означает, что плагин будет кэшировать страницу с новым комментарием заново. Это позволит посетителям всегда видеть перед собой самую последнюю версию страницы.
Теперь нажмите кнопку «Обновить» и сохраните все настройки.
Также необходимо обновить правила модуля «mod_rewrite».
Плагин WP Super Cache запишет новые правила в файл.htaccess, находящийся в корне сайта. Эти новые правила будут отвечать за кэширование браузера и правильную отдачу страниц.
Плагин запишет их в файл.htaccess — они отвечают за правильную отдачу закэшированных страниц и браузерное кэширование.
Установите Cache Timeout равной «0».
Этот момент весьма важен в настройках плагина. Многие начинающие вебмастера, устанавив плагин WP Super Cache, надеются на сокращение нагрузки на хостинг, однако часто этого не происходит из-за того, что сайт большой, а время жизни страниц, которые уже закэшированы, маленькое. Из-за такого несоответствия WordPress будет постоянно очищать кэш и удалять из него просроченные страницы, что и приведет к значительному увеличению нагрузки на хостинг.
Применение кэша оправдано только для хостов с маленьким размером выделенного объема — плагин WP Super Cache будет чистить только просроченный кэш, чтобы пространство не заполнялось ненужными файлами. Если Ваша цель – снижение нагрузки, то необходимо свободное место для кэша, которое должно составлять объем всех файлов плюс 15-20%, при этом периодическая проверка актуальности кэша должна быть отключена. Запас пространства позволяет WP Super Cache кэшировать все страницы сайта, но не удалять закэшированный вариант страницы. То есть, отдача уже готовой, закэшированной страницы ускорит работу сайта за счет того, что будут не нужны лишние операции по вводу-выводу, обращения к БД и исчезнет лишняя нагрузка с процессора.
Форма, в которую введены названия поисковых роботов, нужно оставить без изменений. Плагин в этом случае будет отдавать уже закэшированный список роботов, что снижает нагрузку, которую создают боты при запросе.
Далее. Следует перейти в «Общий кэш» и выставить время обновления для общего кэша. Автоматическая чистка кэша может быть отключена, так как сайту с большим объемом свободного места кэш чистить нет необходимости.
Отслеживать создание нового кэша можно по-разному – в настройках плагина по уровню информированности или при помощи сообщений на e-mail, в которых будет указано время начала и конца операции. Опция «Общий кэш» позволяет за один заход сделать кэширование всех страниц сайта, что выделяет плагин WP Super Cache среди других подобных плагинов.
То есть — посетителям отдаются уже закэшированные, то есть – заранее подготовленные, варианты страниц сайта. При отдаче таких страниц задействуется значительно меньше ресурсов, чем при динамическом их формировании. Во время самых больших нагрузок на ваш хостинг (время нагрузок можно узнать у хостера) заранее подготовленный кэш значительно уменьшит нагрузки и убережет сайт от ошибок.
И не забудьте после проведения всех настроек плагина сделать папку wp-content сайта CMOD 755, то есть доступной для записи только вам.
В данной статье я покажу на примере универсальные настройки плагина WP Super Cache.
Данный бесплатный модуль является одним из самых популярных кеширующих плагинов на WordPress. Однако не все знают как его настроить для удобной работы.
Довольно часто клиенты просят донастроить свои сайты и блоги. Выполняя эту работу, я обращаю внимание на полное отсутствие в настройках WP Super Cache: насколько понимаю - поставили плагин и думают что все уже работает. Давайте исправим положение и проведем минимальные манипуляции.
Клик для увеличения
На закладке "Настройки" начинаем по порядку.
Клик для увеличения
Обратите внимание, что мы запрещаем кеширование для известных пользователей, т.е. для тех, кто залогинен и "завсегдатаев". Теперь вы будете видеть сайт в режиме "реального времени", а пользователи будут получать закешированные странички.
Клик для увеличения
Включаем поддержку мобильных устройств и обновляем кеш страницы, если кто-то добавил к ней комментарий. Далее остается нажать кнопку "Обновить, чтобы изменения данного блока настроек вступили в силу:
Клик для увеличения
Если используете плагины, преобразующие шаблон для мобильных гаджетов, то может понадобиться включить их совместимость на страничке "Плагины":
Клик для увеличения
Далее добавляем необходимые строки в файл.htaccess, чтобы плагин работал эффективно. Для этого достаточно нажать соответствующую кнопку и применить изменения, когда появится информация по вносимым изменениям:
Клик для увеличения
Теперь настраиваем время жизни кеша на сайте, а так же время, когда мусор будет удаляться. 86400 секунд, это 60 сек * 60 мин * 24 ч = сутки или 86400 сек . Данное время можете выставить самостоятельно, в зависимости от частоты обновления вашего сайта. На новостниках это может быть ежечасно, а на сайтах с редким обновлением информации, можно и раз в неделю-месяц.
Клик для увеличения
После этого активируем изменеия в настройках плагина для данного блока, нажав на кнопку:
И в последнем блоке настроек мы говорим плагину не включать кеширование на Главной (Домашней) странице сайта. Если у вас контент меняется чаще, чем вы выставили время жизни копии, то это нужно сделать обязательно. После этого нажимаем "Сохранить".
Клик для увеличения
С настройками все. Теперь немного об использовании плагина в работе.
Полезности
Если на сайте были внесены изменения в общей структуре или отдельных блоках, то необходимо сбросить кеш, чтобы изменения увидели все посетители сайта. Например: внесли изменения в сайдбар или еще какие-то работы по визуальному изменению сайта.
Клик для увеличения
Если же вам нужно на время отключить работу плагина, то не обязательно его деинсталировать. Достаточно сбросить кеш (предыдущий шаг) и на соответствующей вкладке выбрать пункт:
Клик для увеличения
А удостовериться в работе плагина вы можете следующим образом: вылогиньтесь из админки, либо откройте свой сайт в другом браузере, нажмите сочетание клавиш CTRL+U и в самом низу увидите следующее:
1. Установите и активируйте плагин WP Super Cache . Для этого нужно сделать следующее:
После активации плагина появится следующее сообщение:
2. Если у вас уже правильно настроенные постоянные ссылки (ЧПУ) — переходите на страницу управления плагина нажав по тексту «страницу управления» в сообщении, или перейдя в Настройки -> WP Super Cache.
В случае если у вас не настроенные постоянные ссылки — прочитайте в WordPress. Без этого плагин не сможет работать. Если Вы не сделали этого раньше, тогда сейчас это сделать нужно обязательно .
3. В панели управления плагина переходим на вкладку «Настройки» . На этой вкладке находятся расширенные настройки плагина. Они делятся на три группы:
После того как Вы установили необходимые параметры, нажмите кнопку «Обновить» . После обновления страницы появится следующее сообщение:
Прокрутите страницу вниз, пока не увидите желтый блок, с большим количеством непонятного текста 😉 Прокрутите страницу до конца желтого блока и нажмите кнопку «Обновить правила mod_rewrite» .
Если изменения в .htaccess прошли успешно, Вы увидите зеленый блок вместо желтого.
4. Теперь нам нужно настроить «Просроченные страницы & Очистка мусора» . В этих настройках нужно указать время жизни кэшированных страниц. Я рекомендую устанавливать значение « 0» . С таким значением у кэша не будет время жизни, и он будет до тех пор, пока Вы не удалите его вручную.
После того как Вы укажите время жизни кэша, не забудьте сохранить изменения нажав кнопку « Изменить время жизни копии» . Этих настроек достаточно для правильной работы плагина, и если Вы выполнили все настройки выше, значит плагин уже активирован и работает на вашем сайте.
Также после настроек работы плагина можно создать автоматически кэш-копии всех страниц и записей сайта. Это значит, что Вы сделаете кэширование для всего сайта заранее , и посетителям сайта будут выдаваться уже заранее кэшированные страницы. В противном случае кэширование страниц будет происходить после первого посещения страницы.
Создать кэш-копии всех страниц и записей можно на вкладке «Общий кэш» , перейдя в которую нужно всего лишь нажать кнопку «Создать общий кэш сейчас» .
Я надеюсь что этот урок помог Вам разобраться с установкой и настройкой плагина кэширования WP Super Cache . Если Вы установили и настроили данных плагин, то уже и сами оценили все реальные преимущества кэширования, и скорость загрузки вашего сайта стала в разы быстрее .
Если у вас есть какие-либо вопросы, не стесняйтесь и задавайте их в комментариях.
Приветствую Вас, друзья! В первой части урока мы говорили с Вами о том что такое кэширование, и какая от него польза будет польза на сайте. В этой части урока мы приступим непосредственно к настройке кэширования с помощью плагина WP Super Cache. Установка и настройка плагина WP Super Cache 1. Установите и активируйте плагин WP Super Cache. Для этого нужно сделать следующее: Перейдите в Плагины -> Добавить новый В поле поиска введите WP Super Cache и найдите плагин Установите и активируйте плагин Подробнее о способах установки плагинов рекомендую почитать в специальном уроке. После активации плагина появится следующее сообщение: 2. Если у вас уже правильно настроенные постоянные ссылки (ЧПУ) -…
100
Есть такой вид технических проблем на сайте, которые решаются за несколько минут, а поиск этого решения может занять недели и даже месяцы. Моя проблема не могла решиться почти год, с тех пор, как в консоли сайта появилось предупреждение о том, что установленные на сайте плагины и кэширования 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 сегодня появилась долгожданная запись о том, что сайт оптимизирован для мобильных устройств.
Вот из таких маленьких радостей и состоит счастье вебмастера 😀. Сегодня удачный день.
[Наука на будущее]: выучить английский язык, сделать адаптивную версию сайта 😀 😀.
Просто приведу 2 примера, до и после установки и настройки плагина
То есть, вы сами видите грубый расчёт, без плагина страница генерируется 879 миллисекунд
, а с плагином — 84 миллисекунды
. Разница в 10 раз! Ещё остались сомнения в том, нужно ли его устанавливать?
Особо рекомендую к использованию на , и если ваш сайт по типу информационный
: блог или статейник — основное содержание почти не меняется.
Есть и противопоказания, но они больше условные: например, если ваш сайт почти не содержит постоянного содержимого, например предоставляет некоторый сервис, динамически изменяемые в php блоки и тому подобное. Правда, и тут можно найти выход, настроив тип кеширования Legacy или PHP и включив Enable dynamic caching
в настройках. Так что, пути выхода есть:) Однако, я лично думаю, что для таких сайтов лучше обходиться объектным кешированием, например, на основе , что тоже будет довольно эффективно.
Принцип работы прост: плагин создаёт статичные html и php файлы – копии страниц WordPress и сохраняет их в кеш: /wp-content/cache/supercache/ . Потом, при заходе пользователя на какую-либо страницу сайта, WordPress, вместо того, чтобы создать страницу с нуля, отдаёт браузеру заранее сохранённую копию html-страницы из кеша или собирает её максимально быстро из готовых php-файлов. Думаю, вполне очевидно, что такой вариант выходит экономнее по затратам ресурсов сервера и быстрее в плане скорости загрузки страницы.
Конечно, кеш отдаётся не всегда. При настройках по умолчанию, кеш не отдаётся для:
Но, так как доля этих пользователей незначительна, WP Super Cache
является очень эффективным кеширующим инструментом.
Скачать плагин вы можете из официального репозитория https://wordpress.org/plugins/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 на видео:
Если на данном этапе вы видите ошибку
значит, у вас не настроены ЧПУ (человеко-понятные урлы). Переходите по ссылке 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
Поддержка мобильных устройств. (Требуется внешний плагин или тема. Смотрите ЧаВо для дополнительной информации)
Отключить. В наш век адаптивного дизайна вопрос становится неактуальным. Включите, если же ваша тема подразумевает отдельную выдачу для мобильных, либо вы пользуетесь одним из следующих плагинов:
Когда все пункты пройдены, сохраняем их.
Если вы выбрали способ кеширования mod_rewrite
, то плагин потребует обновить .htaccess
Прокручиваем страницу вниз и обновляем
Теперь нужно настроить правила очистки устаревшего кеша
Также, вы можеет поставить 0, и тогда старый кеш не будет очищаться. Это может быть полезным, скажем, если Вы стремитесь к тому, чтобы дата создания страницы соответствовала дате создания её закешированной копии. Однако, помните, что если Вы вносите изменения в дизайн сайта, либо устанавливаете новый плагин, который вносит в изменения в дизайн страницы, изменения не будут приняты, пока кеш не будет очищен. Я лично рекомендую не обнулять очистку кеша, а ставить время жизни кеша побольше.
Чтобы запретить плагину кэшировать запросы от поисковых ботов и других сетевых роботов, введите их названия в поле ниже (по одному в строке). Если копия страницы уже существует в кэше Super Cache, то она все равно будет отправлена боту.
Стираем и оставляем поле пустым, сохраняем.
Несущественны, поэтому оставляете как есть.
Этот раздел важен в свете того, что Google и другие поисковые системы теперь учитывают скорость загрузки страниц как один из факторов ранжирования сайта в поиске.
Обычно, WP Super Cache создаёт кеш только той страницы, которую кто-то посетил. И это, по сути, правильно. Но что, если этим кто-то является бот поисковика? Никакого положительного эффекта от кеширующего плагина он не увидит. И раздел настроек Общий кеш
позволяет избежать этого недоразумения, предсоздавая закешированные копии всех страниц сайта ещё до их посещения кем-либо.
wget -r -l 3 -nd --wait=5 --delete-after http://example.comТакую конструкцию можно отправить в :
- В консоль пишем crontab -e
- Конструкция ниже обходит сайт каждый час, поддерживая страничный кеш свежим: 0 * * * * wget -r -l 3 -nd --wait=5 --delete-after http://example.com
Раздел хорошо описан на русском языке, поэтому распишу только основные настройки:
Теперь сохраняете данные или создаёте кеш прямо сейчас.
Общий объём кеша будет зависеть от количества записей, страниц, рубрик (категорий), меток (тегов). Дисковое пространство — это, как правило, самый дешёвый и легко масштабируемый ресурс на хостинге и сервере, и если у вас не сильно посещаемый проект (до 10-20 тысяч уникальных пользователей в сутки), а страничный кеш выходит большим, то вы вполне можете брать обычный дешёвый жёсткий диск hdd, на честном хостинге разницу с ssd вряд ли заметите, зато сэкономите бюджет. Если больше, hdd тоже будет хорошо себя показывать, но тут я бы порекомендовал посоветоваться с системными администраторами на предмет оптимизации сервера, либо написать мне .
На этом необходимый минимум по настройке WP Super Cache завершён. Далее будет идти информация для продвинутых вебмастеров и системных администраторов, а также некоторая информация, касаемо часто возникающих вопросов.
Если у вас магазин на основе WooCommerce, и вы хотите использовать WP Super Cache, то вам нужно исключить следующие страницы из процесса кеширования:
Это можно сделать в разделе Расширенные example.com/wp-admin/options-general.php?page=wpsupercache&tab=settings , просто отметив Страницы (is_page)
Такой вариант подойдёт, если у вас мало записей в Страницах. Если же их много, то лучше не отмечать Страницы (is_page) , а добавить части адресов служебных страниц в раздел чуть ниже, как на примере
Добавляем служебные страницы WooCommerce в список исключений
Вы можете самостоятельно проверить, как работает плагин, довольно просто.
Для начала, открываете браузер в режиме инкогнито или в приватном режиме. Для 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 , а лучше тестируйте работу плагина и сайта в режиме инкогнито браузера.
Итак, плагин у нас установлен и настроен правильно. Как проверить правильность работы рассказано выше, а теперь перейдём к настройке сервера. Это будет актуальным, если у вас собственный VDS/VPS или выделенный сервер.
Этот пункт касается тех, у кого сервер настроен в режиме работы LAMP (Linux, Apache, Mysql, PHP). Если во фронтенде или в роли основного вебсервера установлен NGINX, советую перейти к разделу ниже
Если вы дошли до этого пункта и выбрали в настройках плагина режим mod_rewrite , то по сути ничего делать и не нужно. Но, в целях оптимизации работы (.htaccess загружается каждый раз при загрузке сайта, apache2.conf только 1 раз во время рестарта сервера), или если обработка правил.htaccess на вашем сервере отключена, вы можете скопировать данные из.htaccess и перенести их в конфигурационный файл, где объявляются настройки вашего сайта (например, в Debian он может располагаться в /etc/apache2/vhosts/сайт.conf).
# BEGIN WPSuperCache
Пример конфигурационного файла . Вы можете вставить в него код из.htaccess
#user "example" virtual host "example.com" configuration file
Итак, у вас свой виртуальный или выделенный сервер, и вам хочется, чтобы 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
Допустим, Вы хотите проверить страницу http://example.com/mypage , правильно ли видит NGINX её расположение в кеше. Для этого надо:
Порой возникают небольшие проблемы, которые довольно просто решаются
:
A2enmod headers && a2enmod expires
Потом перезагружаете Апач
Service apache2 restart
Убедитесь, что вы нажимаете именно на кнопку Создать общий кеш сейчас . Через 10 секунд перезагрузите страницу, вы увидите процесс создания кеша. Заодно проверьте каталог /wp-content/cache/supercache/имя_домена/структура_сайта/
Если кеш всё равно не создаётся, и у вас простой хостинг — напишите в службу поддержки, они помогут решить вопрос.
Если у вас свой сервер или vps/vds, и кеш не создаётся, проверьте, есть ли у WordPress права писать в каталог /wp-content/cache/ . Это можно сделать, скажем, с помощью Far Manager :
Периодически возникает необходимость подчистить кеш. Допустим, вы внесли изменения в рабочий код сайта и хотите, чтобы они немедленно вступили в силу.
Для этого есть 3 варианта
Не забудьте сбросить кеш браузера, например, Ctrl + F5 для конкретной страницы во фронтенде или Ctrl + Shift + Delete для Google Chrome
Плагин удаляется так же, как и любой другой — через панель управления http://example.com/wp-admin/plugins.php , деактивацию плагина и его последующего удаления.
Учтите, что даже простая деактивация плагина удаляет его кеш и сбрасывает все настройки на начальные, поэтому после повторной активации вам придётся проводить настройку заново
Если хотите удалить его вручную:
Меня часто спрашивают, какой плагин лучше выбрать, W3 Total Cache или WP Super Cache? Отвечу по пунктам:
Выбирайте WP Super Cache, если:
Пользуйтесь плагинами страничного кеширования в WordPress, даже если ваш сайт малопосещаемый, возможно, это поможет ему ранжироваться выше.
WP Super Cache
— самый простой, проверенный и распространённый инструмент из подобных, который при должной настройке сможет удерживать работоспособным любой нагруженный проект на WordPress даже при внезапных всплесках посещаемости.