Медленный WordPress (итоги)

Это - краткая выжимка из статьи статьи "Медленный WordPress": https://telegra.ph/Medlennyj-WordPress-02-17

При рассмотрении проблем тех или иных плагинов ниже будут применяться следующие обозначения:

• [?] - проблему можно устранить вмешавшись в исходный код плагина или с помощью внешних сервисов
• [!] - проблему устранить невозможно
• * - замеры скорости довольно субъективны, тем не менее, для наглядности был взят конкретный сайт, скорость загрузки которого составляет ~3 сек. Каждый замер проводился по 5 раз, а результаты представлены усредненные. "Скорость загрузки" - это TTFB ("Время до первого байта").

WP Fastest Cache

Плюсы:

• Бесплатная версия полностью покрывает весь функционал, который требуется от плагина кеширования
• Быстрая скорость загрузки закешированных страниц (30-40 мс*)
• Работа плагина не замедляет скорость работы сайта в случае, если кеш-копии страницы, которую пытается загрузить пользователь не существует
• Процесс автоматического фонового кеширования сайта работает крайне стабильно
• Автоматическое фоновое кеширование не очищает сразу все файлы, давая возможность быстро получать старые кеш-копии страниц, в то время как новые еще генерируются
• Плагин позволяет учитывать популярные в рекламе GET-параметры в адресной строке (такие как UTM-метки и gclid). Это позволяет моментально отдать пользователю уже существующую кеш-копию исключив из URL-адреса, связанные с рекламными кампаниями, 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_rewrit, 40-50 мс в режиме PHP-based
• Плагин имеет функционал в том числе и для оптимизации контента на сайте: минификация HTML/CSS/JS, объединение CSS и JS-файлов, Lazy loading изображений
• Не требует вмешательства в исходный код плагина

Минусы:

• [?] Периодически, даже закешированные страницы (согласно комментарию на самой странице) загружаются долго (2 сек - на тестируемом сайте). Чаще всего такое происходит на втором клике пользователя. Исправить это поможет переключение режима работы в mod_rewrite
• [!] Автоматическое фоновое кеширование не обновляет кеш-файлы до тех пор, пока срок жизни кеш-файлов не истек. Это приводит к ситуации, при которой кеш-файлы уже очищены, а автоматическое кеширование довольно долго создает новые. И в этот промежуток времени с большой долей вероятности посетители могут увидеть долгие загрузки

WP Super Cache

Плюсы:

• Плагин совершенно бесплатный
• Плагин может работать как в режиме mod_rewrite, так и в режиме PHP. Режим работы PHP-based позволяет исполнять PHP-скрипты в том числе и на закешированных страницах.
• Быстрая скорость загрузки закешированных страниц: 30-40 мс в режиме mod_rewrite, 60-80 мс в режиме PHP
• Работа плагина не замедляет скорость работы сайта в случае, если кеш-копии страницы, которую пытается загрузить пользователь не существует
• Процесс автоматического фонового кеширования сайта работает стабильно

Минусы:

• [?] Плагин не умеет игнорировать какие-либо GET-параметры в URL-адресах, в том числе массово распространенные (такие как UTM-метки, gclid, yclid и подобные) - от чего при переходе из рекламы посетители видят долгую загрузку страницы на которую они хотят попасть. Для решения этой проблемы требуется внесение изменений в исходный код плагина при установке, а также при каждом обновлении этого плагина
• [?] Для страниц, которые содержат GET-параметры в URL-адресе плагин создает отдельные кеш-файлы. Доработки из предыдущего пункта позволяют использовать 1 дополнительный кеш-файл конкретной страницы для быстрой её загрузки с любыми вариациями GET-параметров, которые мы указали в предыдущем пункте. Таким образом, создав кеш-копию для страницы example.com/my-page/?utm_source=yandex - эта же страница, но с другим набором GET-параметров (например, example.com/my-page/?utm_source=google&gclid=123) будет загружаться уже моментально у любого посетителя. Тем не менее, при следующем запуске автоматического кеширования будут удалены все кеш-копии страниц (в т.ч. дополнительные, созданные при заходе на страницы, содержащие GET-параметры, плагин создаст новые кеш-копии обычных страниц, но не дополнительные. Дополнительные кеш-копии страниц, содержащих GET-параметры в URL-адресе будут генерироваться посетителями. При этом пока дополнительные кеш-копии страниц не сгенерированы - посетители будут видеть медленную скорость загрузки таких страниц (например, переходя по рекламе). Исправить это можно отключив автоматическое кеширование - такой способ подойдет для сайтов на которых крайне редко вносятся изменения. Другой способ решения этой проблемы - реализация механизма, который будет производить обход сайта, согласно sitemap.xml добавляя к каждому URL какой-либо параметр (например, utm_source=cache_update)
• [!] Автоматическое фоновое кеширование очищает сразу все файлы, соответственно, в момент запуска процесса автоматической подготовки кеш-файлов с высокой долей вероятности посетители могут увидеть долгую загрузку страницю

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-адресах при кешировании
• [!] Нестабильный механизм автоматического кеширования. Периодически, часть страниц не попадает в обход для автоматического кеширования. Попытки ежеминутно загружать главную станицу или переключение WP Cron с "агентов" на планировщик сервера - не помогли избежать этой проблемы.

Итоги

1. Наиболее компромиссным решением для любых сайтов является WP Fastest Cache. С учетом доработок исходных файлов плагина, единственной проблемой является относительно долгая загрузка страниц (500 мс вместо 30-40 мс), которые содержат GET-параметры
2. Для статичных сайтов, на которых какие-либо изменения производятся пару раз в месяц или реже - подойдет WP Super Cache. Он также требует внесения изменений в исходный код плагина. Но, в случае, если кеш без изменений можно хранить довольно продолжительное время, этот плагин обеспечит бескомпромиссно быструю скорость работы сайта при любых условиях.
3. Для не самых больших сайтов (до 300 уникальных страниц) подойдет W3 Total Cache. Он не требует вмешательства в исходный код, обеспечивает самую высокую скорость работы веб-сайтов, построенных на базе WordPress. Тем не менее, если на довольно больших сайтах (от 300 уникальных страниц) есть потребность часто обновлять кеш (раз в час / два / три) - в момент автоматического обновления кеша очень велик шанс, что пользователь попадет на незакешированную страницу и увидит долгую загрузку.
4. Swift perfomance также не требует внесения изменений в исходный код, тем не менее, периодически кеш "отваливается" у части страниц. Побороть это у меня никак не удалось - при каждом тесте, набор страниц, которые "отвалились" - совершенно разный, переключение режима работы wp-cron.php на планировщик сервера - не помогает. Так или иначе, на крупных сайтах (от 300 уникальных страниц), на мой взгляд, Swift perfomance является более предпочтительным, нежели W3 Total Cache - т.к. в период обновления кеша, посетители сайта с меньшей долей вероятности увидят долгие загрузки.

UPD 2021.03.10

Всё же Swift perfomance не оправдал моих ожиданий. Ровно как и W3 Total Cache, Swift perfomance во время истечения срока жизни кеша сносит все кеш-файлы. Да, он создает кеш-копии чуть быстрее чем W3 Total Cache, но все равно 5-7 минут на сайте из 300 страниц посетители увидят медленную загрузку после истечения срока жизни кеш файлов. Более того, использование мульти-потокового кеширования оказывает довольно ощутимую нагрузку на сервер. Также скорость работы W3 Total Cache оказалась всё же выше, чем у Swift perfomance. Поэтому, при выборе между W3 Total Cache и Swift perfomance я рекомендую выбирать первый вариант.

Итого

• На сайтах на которых почти не вносятся изменения я использую WP Super Cache
• Там где изменения вносятся часто я использую WP Fastest Cache
• Для тех, кто не хочет вносить изменения в исходный код чужих плагинов - я рекомендую W3 Total Cache