WordPress. Кеширование
Кеширование данных позволяет ускорить работу сайта и существенно снизить нагрузку на сервер. В ядре WordPress существует три основных вида кеширования — кеширование страниц (page cache), кеширование объектов (object cache) и транзитное кеширование (transient cache).
Кеширование страниц
Для выдачи одной страницы архива приходится проделывать много работы. Это множество запросов в базу данных — чтобы получить последние записи, настройки виджетов, настройки темы, активные плагины, название и описание сайта и так далее. Кеширование страниц (page cache) позволяет сохранить результат выдачи страницы целиком в кеш и при последующем запросе этого URL выдать страницу уже из кеша.
При изменении содержания записи или странцы, кеш страницы сбрасывается, и при последующем запросе кешируется уже новая страница с обновлёнными данными. В самом ядре WordPress кеширование страниц не реализовано, но есть все необходимое для реализации этого на уровне плагинов.
Кеширование объектов
Объектное кеширование (object cache) реализовано в самом ядре WordPress. Механизм позволяет хранить объекты произвольного типа в памяти и используется практически для всего: опции, записи, страницы, метки, категории, пользователи и многое другое.
Время жизни кеша объектов
В WordPress есть возможность использовать внешнее хранилище для кеша объектов, например Memcached или Redis, при этом кеш объектов становится постоянным. Это значит, что при следующем обращении к странице сайта, ранее закешированные значения по прежнему доступны. Для этого нужно создать файл object-cache.php в директории wp-content и реализовать в нем класс WP_Object_Cache и все перечисленные выше функции.
Транзитное кеширование
Транзитное кеширование чаще всего используется для хранения данных, когда речь идёт о запросах на внешние ресурсы, например для вывода сообщения из сети Twitter или для вывода прогноза погоды со стороннего сервиса. Подобное кеширование так же используется в ядре — при запросах на обновление тем, плагинов и ядра.
Настройка WP Super Cache кэширование WordPress
Кэширование WordPress
Настройка WP super cache плагина легче чем например, W3 Total Cache и поэтому он самый востребованный у пользователей Вордпресс (установок более 26 072 370 раз). Да, к тому же, он полностью бесплатный. Поэтому речь сегодня пойдёт именно о WP Super Cache.
Модуль активно поддерживается разработчиками Automattic, так что смело устанавливайте его. Один раз настроите его и можете забыть о нём. И так, поехали.
WP Super Cache подойдёт как для начинающих, так и для более опытных пользователей WordPress.
Плагин WP Super Cache
Кэширующий плагин генерирует статические страницы и улучшает скорость страниц сайта. Кэшированные страницы хранятся в памяти, и когда пользователь делает запрос, страницы доставляются из кэша. При этом выполнение php и запросы к базе данных пропускаются.
Для лучшей производительности вашего сайта, пожалуйста, ознакомьтесь с руководством по его правильной/рекомендуемой настройке.
WP Super Cache самый популярный плагин для кэширования страниц
Устанавливаем plugin для кэширования страниц WP
После установки и активации плагина в разделе Настройки появится новый пункт WP Super Cache.
WP Super Cache настройки плагина
Статус кэширования: Включите кеширование
Не забудьте нажать кнопку обновить. Следующая вкладка «Расширенные»:
Расширенные настройки кэширования
Отметьте как на скриншоте, а именно:
Затем поставьте галочки:
Если ваш сайт статический и редко обновляется то:
Не существует идеальных настроек очистки мусора, но ниже вы найдёте несколько распространённых сценариев. Очистка мусора отделена от других событий, которые также приводят к очистке мусора (например: добавление нового комментария или публикация записи):
Время истечения срока и сбор мусора
Допустимые имена & Запрещенные адреса
Сохраните настройки. Затем, перейдите во вкладку Общий кэш. Настройки CDN (Сеть доставки контента) пропустим, так как, это продвинутый метод, требующий базового понимания работы вашего веб-сервера или CDN.
Настройки WP Super Cache
Сохраните настройки. Всё готово.
Теперь 99% ваших посетителей будут обслуживаться статическими HTML-файлами. Один кэшированный файл может обслуживаться тысячи раз. Другим посетителям будут предоставлены пользовательские кэшированные файлы с учетом их посещения. Если они вошли в систему или оставили комментарии, эти данные будут отображаться и кэшироваться для них.
В заключение
Кэширование играет важную роль при повышении производительности и скорости сайтов, а так же их оптимизацию под высокие нагрузки. В большинстве случаев для сайтов с низкой посещаемостью это не столь важно, хотя всегда приятно когда сайт открывается намного быстрее.
Ускорение WordPress. Тотальный разбор плагинов для кэширования. Личный опыт (часть 1)
Что делать, если сайт на WordPress грузится медленно? Ответ на самом деле прост – настрой кеширование. Можно ещё заниматься оптимизацией изображений, настройкой lazy loading и прочими хитростями. Но кеширование всё равно остаётся ключевым способом ускорения любого сайта на Вордпресс. Кажется, всё просто, зайди в Google, напиши «WordPress cache», найди статью, где больше всего картинок, скачай упомянутый в статье плагин и выстави настройки согласно скриншотам. При любом раскладе твой сайт сразу начнет работать в разы быстрей.
Но дьявол, как обычно, кроется в деталях. В интернете есть самые разные обзоры и сравнения плагинов кеширования. И за столько лет кто-то же должен был выдать идеальный рецепт? Но нет. Все эти обзоры сводятся к тезису: «мы сделали 10 одинаковых сайтов, установили плагины с дефолтными настройками и смотрим, где страница загрузилась быстрее». При этом все забывают, что нюансов при оптимизации кеширования вагон и маленькая тележка. Похоже, эта статья первая, которая примет во внимание реальное поведение пользователей на сайте, вместо сравнения скорости загрузки одной страницы в тепличных условиях.
Используя бестселлеры с Themeforest или, те же конструкторы, вроде Elementor, WP Backery и прочие, сайт обречен на 5-15 секунд TTFB (time for first byte, время ответа сайта) при загрузке КАЖДОЙ страницы. С одной страницы может быть несколько сотен обращений к базе данных, выполняться большое число php-функций, подключаться множество библиотек. Естественно, что такая скорость недопустима, она влечет за собой понижение в поисковой выдаче, «отказы» посетителей, сливы бюджетов на рекламу и так далее. С этим нужно что-то делать.
Я никогда шибко оптимизацией WordPress не заморачивался, потому что в моей практике сайты, которые требуют космической скорости работы, делали не на WordPress, а на Yii2 или Laravel. Для WP я использовал околодефолтные настройки плагина WP Super Cache, подсмотренные на Stackoverflow. Правда со временем начали появляться проблемы. Что-то приходилось «колхозить», где-то пробовать другие плагины. Но каждый раз появлялись всё новые и новые «косяки».
В какой-то момент я просто устал от постоянного «колхозинга» и решил найти идеальное решение. Я занимался этим больше месяца, тестируя разные плагины, разные настройки на разных сайтах, чтобы найти идеальный рецепт.
В статье речь пойдёт о собственных наблюдениях, об особенностях каждого плагина для кеширования WordPress, о том, что заявлено, а что имеем по факту, и конечно, подборе идеальных настроек и устранении проблем. Материала получилось много, на 21 страницу, поэтому я решил разделить его на две части. Первая будет посвящена обзору и выводам, так сказать «для гуманитариев». Во второй части будут приведены настройки и доработки плагинов, а также более подробное пояснение их работы, так сказать «для технарей».
Забегая вперед, скажу, что идеального рецепта (идеальных настроек) не существует. В первую очередь необходимо четко сформулировать свои требования к функционалу и понять принципы работы того или иного плагина. Этим мы сегодня и займемся.
1. Определяем требования к функционалу
Мои требования к функционалу соответствуют классическому многостраничному корпоративному сайту с посещаемостью от 100 до 10 000 чел. в день, со своим блогом, на который ведётся реклама с UTM-метками. Также я делаю большой акцент на автоматизацию, чтобы не приходилось заниматься постоянными доработками и настроить кеширование можно было без особых усилий.
Автокеширование. Сайты приходится периодически обновлять, выкладывать новости, менять текст, картинки и т.д. Кеш-копия страниц в этом случае хранится определённое время, а после обновления страниц сайта необходимо заново создавать кеш-файлы. В этом случае часть пользователей, ровно, как и поисковых роботов, будут видеть насколько долго загружаются некоторые страницы сайта. Чтобы этого избежать, плагины предлагают механизм автоматического кеширования. В этом случае плагин самостоятельно производит обход сайта и сам создает закешированные копии страниц. Важно, чтобы этот механизм у плагина работал без сбоев.
Игнорирование части запросов URL-адреса. Большинство рекламщиков используют для отслеживания эффективности своих рекламных кампаний UTM-метки (или другие GET-параметры). В этом случае они добавляют в адрес страницы ряд запросов, которые никак не влияют на логику работы сайта. Например, у нас есть страница товара, который мы рекламируем: https://www.site.com/landing-page/, но пользователь, перешедший на неё из рекламы, увидит адрес следующего формата: https://www.site.com/landing-page/?utm_source=yandex&utm_medium=cpc&utm_campaign=promo&utm_content=banner&utm_term=i-wan-to-buy-something&yclid=93473892748392743473829.
Естественно, сайт о существовании этой страницы даже не догадывается, и кэш под неё не существует. Он будет создан в момент перехода пользователя по этой длинной ссылке. Но даже, если рекламщик не будет добавлять UTM-метки, то Яндекс Директ, Google Ads или иные рекламные системы будут подставлять свои метки для отслеживания (например, yclid, gclid). Значения таких меток будут всегда разными, соответственно, сайт будет воспринимать их как абсолютно разные страницы. В итоге, мы получаем ситуацию, когда каждый пользователь, привлеченный с помощью рекламы, видит, насколько медленно работает сайт, а хранилище кеша пухнет от кучи мусорных файлов, которые никогда больше не будут задействованы.
Поэтому, плагин кеширования должен учитывать существование некоторых GET-параметров, которые необходимо исключать из URL-адреса страницы при попытке найти подходящий кеш-файл или же создать новый.
Возможность использования PHP-функций. Это может прозвучать странно, ведь само по себе кеширование подразумевает предотвращение исполнения PHP-скриптов или работу с БД, но только не в моём случае.
В своё время на разных проектах я неоднократно сталкивался с проблемами стандартных систем аналитики, основанных на JavaScript, таких как Яндекс Метирка или Google Analytics, при анализе лидов. Та же Метрика попросту не видит части заявок, данные отображает в обезличенном виде и с задержкой. Каждый второй научился устанавливать AdBlock, который не передаёт в Метрику JavaScript-события и вырезает прочие скрипты с сайтов. Более того, оказалось, у части пользователей с мобильных устройств не работает JavaScript, который необходим для корректной работы Метрики. Как итог, мы имеем статистику с определённой погрешностью.
Поэтому я сделал свою кастомную систему для аналитики заявок на сайте, которая работает через PHP, а не через JavaScript и не позволяет никаким данным потеряться. И именно здесь появляются проблемы, когда большинство кеширующих плагинов не позволяет при первом визите пользователя запустить нужный PHP-код, который сохранит полную информацию об источнике и характеристиках визита.
2. Разбираем самые популярные плагины кеширования
Как я уже говорил выше, идеального рецепта не существует, и необходимо разобраться в логике работы того или иного плагина и выбрать наиболее подходящее решение для каждого конкретного сайта. Во второй части статьи я подробнее рассматриваю популярные плагины для кеширования WordPress, их проблемы и предлагаю методы решения этих проблем. Здесь я обобщу все плюсы и минусы каждого из плагинов.
При рассмотрении плагинов ниже будут применяться следующие обозначения:
WP Super Cache
Плюсы:
Плагин совершенно бесплатный.
Плагин может работать как в режиме mod_rewrite, так и в режиме PHP. Режим работы PHP-based позволяет исполнять PHP-скрипты в том числе на закешированных страницах.
Быстрая скорость загрузки закешированных страниц: 30-40 мс* в режиме mod_rewrite, 60-80 мс в режиме PHP.
Работа плагина не нагружает сайт, пока происходит кеширование.
Процесс автоматического фонового кеширования сайта работает стабильно.
Автоматическое фоновое кеширование не очищает сразу все файлы, давая возможность быстро получать старые кеш-копии страниц, в то время как новые еще генерируются.
Минусы:
[?] Плагин не умеет игнорировать GET-параметры в URL-адресах, в том числе массово распространенные (такие как UTM-метки, gclid, yclid и подобные), поэтому при переходе из рекламы посетители видят долгую загрузку страницы. Для решения этой проблемы требуется внесение изменений в исходный код плагина при установке, а также при каждом обновлении этого плагина.
WP Fastest Cache
Плюсы:
Бесплатная версия полностью покрывает весь функционал, который требуется от плагина кеширования.
Быстрая скорость загрузки закешированных страниц (30-40 мс*);
Работа плагина не нагружает сайт, пока происходит кеширование.
Процесс автоматического фонового кеширования сайта работает стабильно;
Автоматическое фоновое кеширование не очищает сразу все файлы, давая возможность быстро получать старые кеш-копии страниц, в то время как новые еще генерируются.
Плагин позволяет учитывать рекламные GET-параметры в адресной строке (такие как UTM-метки и gclid). Это позволяет моментально отдать пользователю уже существующую кеш-копию страницы без GET-параметров.
Плагин имеет функционал в том числе для оптимизации контента на сайте: минификация HTML/CSS/JS, объединение CSS и JS-файлов, Lazy loading изображений.
Минусы:
[?] Для исключения GET-параметров, не «зашитых» в плагине (таких как yclid) требуется внесение изменений в плагин при установке, а также при каждом обновлении этого плагина.
[?] Плагин работает исключительно с помощью mod_rewrite, поэтому для исполнения PHP-скриптов на закешированных страницах необходимо произвести доработку веб-сайта.
[!] Страницы с GET-параметрами загружаются медленней, чем страницы без них. Так, например, сайт на котором страницы без кеширования загружаются за
3 сек., с использованием WP Fastest Cache страница загружается за 30-40 мс*, но, если у страницы есть GET-параметры, её кеш-копия будет загружена за 400-500 мс. (для сравнения, скорость загрузки страниц, содержащих GET-параметры при использовании WP Super Cache: 60-80 мс*). Это не то что бы сильная проблема, если сравнивать со скоростью загрузки страниц без использования кеширующих плагинов, но об этом стоит упомянуть.
W3 Total Cache
Плюсы:
Плагин может работать как в режиме mod_rewrite, так и в режиме PHP. Режим работы PHP-based позволяет исполнять PHP-скрипты на закешированных страницах.
Плагин позволяет указать произвольный перечень GET-параметров, которые необходимо игнорировать при обработке запроса.
Феноменальная скорость загрузки страниц: 25-30 мс* в режиме mod_rewrite, 30-40 мс* в режиме PHP-based.
Феноменальная скорость загрузки страниц с GET-параметрами: 30-40 мс* в режиме mod_rewrite, 40-50 мс* в режиме PHP-based.
Плагин имеет функционал для оптимизации контента на сайте: минификация HTML/CSS/JS, объединение CSS и JS-файлов, Lazy loading изображений.
Не требует вмешательства в исходный код плагина.
Минусы:
[!] Автоматическое фоновое кеширование не обновляет кеш-файлы до тех пор, пока срок жизни кеш-файлов не истек. Это приводит к ситуации, при которой кеш-файлы уже очищены, а автоматическое кеширование довольно долго создает новые. И в этот промежуток времени посетители могут увидеть долгие загрузки. Особенно если сайт большой, а обновление поставлено раз в полчаса, то автокеширование может происходить в течение 10 минут, и всё это время пользователи будут видеть долгую загрузку части страниц. При этом во время проведения автокеширования скорость загрузки незакешированных страниц падает с 3 сек до 5-6 сек, т.к. сам плагин нагружает сайт.
Swift perfomance
Плюсы:
Плагин позволяет указать произвольный перечень GET-параметров, которые необходимо игнорировать при обработке запроса.
Плагин может работать как в режиме mod_rewrite, так и в режиме PHP. Режим работы PHP-based позволяет исполнять PHP-скрипты в том числе и на закешированных страницах.
Неплохая скорость загрузки закешированных страниц: 200-300 мс* в режиме PHP, 30-40 мс* в режиме mod_rewrite. При этом скорость загрузки страниц, содержащих GET-параметры в URL-адресе, всё равно будет 200-300 мс*, даже при использовании mod_rewrite.
Плагин имеет функционал для оптимизации контента на сайте: минификация HTML/CSS/JS, объединение CSS и JS-файлов, Lazy loading изображений, а также оптимизация и сжатие изображений.
Автоматическое фоновое кеширование не очищает сразу все файлы, давая возможность быстро получать старые кеш-копии страниц, в то время как новые еще генерируются (но не всё так просто, смотрим минусы).
Не требует вмешательства в исходный код плагина.
Минусы:
[!] Отсутствие поддержки кириллицы в URL-адресах при кешировании. Swift Perfomance создает кеш ровно по тем адресам, которые имеют страницы сайта, т.е. если у нас URL страницы выглядит как https://example.com/контакты, он не будет переводить «контакты» в URL-encoded для создания кеша. Но браузер будет обращаться именно к https://example.com/%D0%BA%D0%BE%D0%BD%D1%82%D0%B0%D0%BA%D1%82%D1%8B, поэтому страницы, содержащие кириллицу, будут загружаться всегда медленно.
[!] Некорректный механизм ручного обновления кеша. Когда мы обновляем страницу, он моментально генерирует под нее свежий кеш, пользователи не увидят долгих загрузок. Когда мы публикуем новость, она тут же появляется на странице новостей. Но как только эта новость должна попасть куда-то в другое место (например, в сайдбар других страниц), она туда не попадет ровно до тех пор, пока мы полностью вручную не обновим кеш всего сайта или не запустится механизм автокеширования. Когда мы вручную обновляем весь кеш сайта (чтобы наша новость появилась в сайдбаре на всех страницах), далеко не все страницы работают быстро. Через несколько минут после ручного запуска переобхода сайта, часть страниц уже имеют новый кеш (работают быстро), часть страниц еще отдаются со старым кешем (видим, что свежая новость в сайдбарах на этих страницах еще не появилась), но часть страниц (причем, немалая) грузится ужасно долго (8 – 12 сек. против 3-4 сек. без использования кеширования вообще).
[!] Нестабильный механизм автоматического кеширования. При первичных тестах плагин отрабатывает как надо. Но на практике вышло так, что на большинстве сайтов это «умное» автокеширование работает нестабильно. В какой-то момент созданные ранее кеш-файлы просто пропадают, плагин их удаляет или происходит какой-то рассинхрон, хотя новые копии под них ещё не были созданы, и сайт остаётся без какого-либо кеширования. Приходится запускать переобход вручную, а это ведёт к сильной нагрузке на сервер.
[!] Lite-версия Swift Perfomance вынуждает покупать подписку. В бесплатной версии Swift Perfomance нельзя выбрать высокую скорость для автокеширования, а также отсутствует возможность указать GET-параметры для исключения из URL-адреса при кэшировании.
В ходе своего исследования я также успел поработать с WP Rocket и LiteSpeed Cache, в которых разочаровался почти сразу и не посчитал нужным расписывать подробно все их преимущества и недостатки, их я упоминаю во второй части статьи.
3. Заключение
Без сомнения, наиболее высокую скорость загрузки показал плагин W3 Total Cache. Он работает быстро и в классическом режиме, и в режиме PHP, да и страницы с GET‑параметрами загружает быстрее всех. Но для меня критичной стала проблема отсутствия автоматического фонового кеширования, которое бы обновляло файлы кеша, не снося их полностью, а заменяя постепенно. Плагин, конечно, не требует доработок, и имеет все необходимые настройки, но в период обновления кеша, пользователи, попадающие на сайт, видят медленную загрузку, а при большом трафике на сайте это становится критичной проблемой. Его лучше использовать на статичных сайтах без автокеширования.
Большие надежды я возлагал на Swift Perfomance. Он имеет все необходимые настройки, не требует доработок, да и распространяется платно, а ведь платный плагин должен оправдывать вкладываемые в него средства? Но он разочаровал полностью, нестабильные механизмы автокеширования, недоработанный механизм ручного обновления кеша, высокая нагрузка на сервер при кешировании – все эти недостатки свели на нет его преимущества. Если бы я регулярно не мониторил его работу, может быть и не заметил бы этих недостатков. На текущий момент я его не использую ни на одном из проектов.
WP Super Cache был бы идеальным вариантом, если только на сайты с ним не вести рекламу. Как только на сайте появляются любые GET-параметры, необходимо дорабатывать исходный код плагина, чтобы устранить эту проблему. А при частом обновлении сайта с большим количеством страниц это становится настоящим геморроем, ведь если мы не хотим, чтобы некоторая часть пользователей с рекламы видела медленную загрузку после проведения автокеширования, то необходимо придумывать дополнительные методы обхода страниц с GET-параметрами. Чаще проще установить плагин, который всё это умеет из коробки. К недостаткам WP Super Cache можно также отнести отсутствие работы с оптимизацией контента на сайте (минификация HTML/CSS/JS, объединение CSS и JS-файлов, Lazy loading изображений, а также оптимизация и сжатие изображений), но это на любителя, плагин кеширования по факту не должен этим заниматься, все эти настройки нужно тестить, у других плагинов не все они работают адекватно.
Закрывает эти проблемы плагин WP Fastest Cache, который прекрасно умеет работать с GET-параметрами. Хотя он всё равно требует доработок. Лично мне не сложно внести небольшие изменения в код плагина, чтобы познакомить его с метками типа yclid и разрешить использовать PHP.
Вот и получается, что идеального рецепта не существует. Понимая проблемы плагинов и разобравшись в настройках из второй части статьи, каждый сам сможет подобрать себе плагин под конкретный тип сайта. Мои же рекомендации, следующие:
Рекомендации
На сайтах, на которых почти никогда не вносятся изменения (например, лендингах), рекомендую использовать W3 Total Cache без автокеширования, т.к. он показывает самую высокую скорость загрузки, отлично будет работать с рекламой и не требует доработок. Правда, если уж пришлось внести изменения на статичный сайт, нужно не забыть вручную обновить кеш.
На сайтах, где изменения вносятся часто (например, корпоративных сайтах), рекомендую использовать WP Fastest Cache, он отлично работает с фоновым автокешированием и GET-параметрами, правда не со всеми. Чтобы вести рекламу на сайт, например, из Яндекса, необходимо внести небольшое изменение в исходный код, т.к. плагин не знает метку yclid.
Если на сайт точно не планируется вести рекламу или загружать какие-либо страницы с GET-параметрами (например, блог), то можно использовать и WP Super Cache, и WP Fastest Cache, кому как удобней. WP Super Cache настроить чуть проще и быстрей.
Мне на практике для некоторых сайтов приходится использовать PHP-скрипты, с которым WP Fastest Cache работает только после доработки исходного кода. Здесь часто спасает WP Super Cache, который умеет работать с PHP из коробки. Правда всё ломается, как только на сайте появляется реклама с UTM-метками. WP Super Cache был бы универсальным кешером, если бы разработчики плагина догадались подружить его с GET-параметрами, а сейчас для этого приходится вносить изменения в исходный код плагина и придумывать варианты обхода страниц с GET-параметрами при автокешировании. Об этом нужно всегда помнить.
Если очень хочется вести рекламу на сайт, но очень не хочется дорабатывать плагины, то можно использовать W3 Total Cache с автокешированием и мириться с временной медленной загрузкой сайта в период обновления кеша. А также помнить, что чем больше страниц на сайте и выше трафик, тем выше шанс, что большое количество пользователей увидит медленную загрузку.
Подробные настройки каждого плагина и инструкции по доработке исходного кода я выложу во второй части статьи.
Это переписанная и структурированная статья из моего телеграм-канала «digital на минималках», где я делюсь опытом в бизнесе, инструкциями, рассказываю, как удешевить свои вложения в digital, рассуждаю на небанальные темы, немного бомблю и делюсь мемчиками (осторожно, нецензурная речь). Решил, что подобное объемное исследование будет интересно не только подписчикам моего канала.
