Какой плагин кэширования WordPress лучше

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

Небольшая ремарка о кэшировании

 Google недавно объявил, что все mobile-friendly сайты (а скорость — это путь к тому, чтобы быть «friendly») получают существенное преимущество в поисковой выдаче, начиная с 21 апреля. Возможно, вы уже видели тег «mobile friendly» в поисковой выдаче. И в Google Page Insights первая же панель адаптирована под мобильные устройства, а не под десктопы. Намерения Google ясны, и звучат громко для любого SEO-специалиста или вебмастера. Сейчас важно работать над производительностью как десктопной, так и мобильной версии сайта, что мы и попробовали отобразить в бенчмаркинге.

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

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

Подробности теста

Изначальная идея базировалась на использовании как простейшей темы типа twentyfourteen, так и более сложной темы, что позволит смоделировать более «реальный» сайт. Но во время проведения тестов выяснилось, что влияние плагинов на скорость загрузки сайта с темой «2014» было минимальным, и писать почти не о чем. Но есть много приёмов, позволяющих улучшить производительность «twentyfourteen», так что здесь более важна настройка сервера, а не кэширование.

Для того, чтобы сделать тестируемый пустой сайт максимально приближенным к реальности, использовалась тема Novelty от Tesla Themes. Тестируемую страницу сайта оформили с использованием графики и текста, был добавлен сайдбар и некоторые плагины (вывод новостей, фид из Twitter/Instagram). Теперь у нас страница, загрузка которой занимает относительно много времени. Да, в качестве хостинга использовался вот этот WordPress хостинг.

Плагины, которые тестировались:

  • AIO Cache
  • Alpha Cache
  • Bodi0’s Easy Cache
  • Cachify
  • Flexicache
  • Gator Cache
  • Hyper Cache
  • Hyper Cache Extended
  • Lite Cache
  • Next Level Cache
  • Really Static
  • Super Static Cache
  • W3 Total Cache
  • Wordfence Falcon
  • WP Fast Cache
  • WP Fastest Cache
  • WP Rocket
  • WP Super Cache
  • WP-Cache.Com
  • Zen Cache (formerly Quick Cache)

Остались ещё:

  • Brutal Cache — просто не работал.
  • Batcache — плагин с зависимостью от Memcache, что не использовалось в текущем тесте.
  • Autoptimize и Widget Cache также остались за бортом, поскольку они являются поддержкой для других плагинов, это не совсем самостоятельные плагины.
Статья по теме:  Продающие плагины для Вордпресс

Хостинг и инструменты бенчмаркинга

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

В качестве инструментов использовались сервисы, предлагаемые Google, GTMetrix и Yahoo. Благодаря этому стало возможным тестировать не только скорость загрузки страниц, но и другие факторы, среди которых:

  • оптимизация изображений;
  • временная задержка сервера;
  • минификация и оптимизация js- и css-кода;
  • использование кэширования в браузере;
  • размещение скриптов;
  • использование CDN, распараллеливания/доменного шардинга;
  • использование Gzip-сжатия;
  • количество HTTP-запросов.

Google PageSpeed Insights

Сервис PageSpeed Insight проверяет сайт как с точки зрения десктопного ПК, так и со стороны мобильного устройства, выдавая оценку по 100-балльной шкале. Page Speed Insights прост в использовании, но предоставляет относительно сырой результат, который не даёт полного понимания того, что может быть улучшено. Даже несмотря на то, что инструмент даёт представление о некоторых вещах, которые Google может находить важными, информация, предоставляемая GTMetrix и Yahoo, намного полнее.

При этом Google во время оценки не принимает во внимание CDN, поэтому в некоторых случаях оценка занижена.

GTMetrix и YSlow

GTMetrix и YSlow основаны на руководстве по повышению производительности ресурса от Yahoo, оценка также выводится по 100-балльной шкале. Эти инструменты гораздо более изощрены в плане проведения измерений. PageSpeed Insight даёт всего несколько подсказок о том, что может быть улучшено, в то время как GTMetrix YSlow работают с не менее чем 50 различными метриками. GTMetrix также предлагает диаграмму-водопад, препарируя процесс загрузки, а также весьма продвинутую историю загрузки. Если вы хотите понять, как повысить производительность вашего ресурса, это один из лучших инструментов.

Тайминг

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

ApacheBench

ApacheBench — отличный инструмент, который помогает определить, сколько запросов в секунду способен выдержать сайт с использованием различных плагинов. Выполнение теста проводилось с отправкой 1000 запросов по 10 различным потокам. Тест выполнялся 10 раз с фиксированием лучшего результата по каждому из плагинов.

Стоит отметить, что использование Nginx несколько снижает различие между работой сайта с плагинами/без плагинов. По этому поводу можно спорить, но в случае использования Nginx зафиксирована двукратная разница по сравнению с Apache.

Pingdom

Pingdom — хорошо известный сервис для мониторинга и тестирования. С каждым плагином проводилось 20 тестов, с фиксацией лучшего результата. Отметим, что сервер был расположен в Швеции (Стокгольм), а сервер Pingdom — в Нидерландах (Амстердам).

Webwait

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

Статья по теме:  Плагин для Вордпресс: Broken Link Checker

Итак, с описанием всё, теперь приступим непосредственно к тестам.

Google, GTMetrix и Yslow

Страницы сайта тестировались с использованием указанных сервисов, вот результат:

Как видим, некоторые плагины здесь просто никак не проявились — оценка такая же или очень близка к оценке, когда кэширование вообще не используется. Google дал лучшую оценку Supercache как для десктопа, так и для мобильного устройства. В GTmetrix и Yslow мы видим, что Fastest Cache Rocket впереди планеты всей. Мы склонны оценивать последние значения как более важные, поскольку Google Page Insight для оценки использует меньше факторов.

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

Тайминг

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

Как видите, тестируемая страница получила 96 из 100 баллов, что, вероятно, лучше, чем у 99% страниц любых сайтов. Тем не менее эта страница загружается почти 35 секунд. Корректен ли результат? Сделайте вывод сами :)

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

ApacheBench

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

Без кэширования сервер показывает результат в 18 запросов за секунду. Это довольно неплохой результат, который стал возможным благодаря использованию Nginx. На каждый запрос уходит примерно 1/500 с.

Здесь мы видим, что Hyper Cache Ext, WP Fastest Cache, WP-Cache.com и WP Rocket улучшают результат на 300% по сравнению с работой без кэширования. WP Rocket — самый быстрый и WP-Cache.com занимает второе место.

Здесь очевидно проявляется преимущество использование плагинов кэширования — вы можете держать в три раза больше запросов. Используя Nginx, хороший плагин кэширования, и, может быть, что-то вроде Varnish, вы получаете сервер, который летает.

Pingdom

Без кэширования результат — около 2,8 секунды. Использование практически любого плагина улучшает результат по крайней мере вдвое.

Webwait

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

Статья по теме:  Вордпресс редактирует (чистит) код. Что делать?

Среднее время загрузки

Медианное время загрузки

Как видим, практически неизвестный WP-Cache.com работает весьма неплохо.

Не кэшированием единым

Конечно же, далеко не всё зависит от кэширования. Важную роль играют и такие факторы, как выбор Apache, Nginx и т. п., корректность настройки, тип сервера (выделенный, VPS, шаред), количество изображений и их оптимизация, HTTP-запросы. Собственно, об этих факторах на «Хабре» знают практически все, поэтому останавливаться на них мы не будем.

Вывод

У всех плагинов, которые здесь представлены, разная функциональность. Некоторые очень просты, в то время как другие можно сравнить со швейцарским ножом. Super Cache, W3 и прочие плагины зачастую используют профи, которые знакомы с CDN и прочими премудростями. Другие пользователи предпочитают работать с более простыми плагинами вроде Lite Cache и WP-Cache.com. Кстати, WP-Cache.com, как говорилось выше, малоизвестный плагин, который показал отличные результаты.

Кто победитель?

  1. На первом месте — WP-Rocket, платный плагин, над которым работает целая команда специалистов. За установку разработчики просят $39, а за безлимитку — $199.
  2. На втором месте — WP Super Cache. Здесь результаты почти такие же, как и у лидера.
  3. На третьем месте — WP-cache.com, заслуженный призёр. Похоже на то, что над созданием этого плагина работали ничуть не менее способные разработчики, чем над WP-Rocket. Этот плагин очень прост в настройке, так что, если у вас нет желания заморачиваться с конфигурацией, рекомендуем именно его.

Вопросы/ответы

— Лично я давно пользуюсь связкой Nginx+Varnish+W3 Total Cache, и считаю это наиболее удачным решением среди всех прочих.

— Попробуйте Nginx + HHVM + Redis + MariaDB, и вообще без кеширования. На случай хабраэффекта можно складывать full-page cache в родной fastcgi_cache Nginx’а, ну или в Redis / Memcahced. При небольшом твикинге Nginx можеть забирать прям оттуда. W3TC — огромный комбайн, от него вполне можно избавиться. А вообще, на носу HTTP/2.

Какая разница между:
1. WordPress cache (ex: WP Super Cache)
2. Varnish
3. PHP opcode cache (ex: APC, x-cache)

— Если вкратце и в общих чертах, то:
  1. WP super cache складывает сгенерированный HTML-код в файлы на диск.
  2. Varnish — это кэширующий HTTP-proxy, который сгенерированные html-файлы (или любые другие) держит в оперативке (по мере необходимости), уменьшая тем самым обращения к диску.
  3. PHP-opcode cache кэширует в памяти «скомпилированные» PHP-скрипты, что избавляет от необходимости повторной «компиляции» при всех последующих к ним обращениях.

Правильно ли я понимаю, что Nginx настраивается таким образом, что он отдает пользователю кеш созданный плагином если он существует, а если кеша нет, передает запрос дальше в Apache? Что позволяет исключить Apache при загрузке страниц WordPress, которые без настройки считались бы Nginx’ом динамическими.

— Да, всё так. Можно еще Apache заменить на php-fpm.
А еще лучше на HHVM?
— А HHVM уже умеет сам ставится и перезапускаться?

А чем вот это или это не устраивает? Да, и никто же не отменял Monit, Upstart, DaemonTools, Supervisor и подобные инструменты.

Источник

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

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: