Медленный WordPress (часть 3)
Это продолжение статьи "Медленный WordPress (часть 2)", первая часть доступна по ссылке: https://telegra.ph/Medlennyj-WordPress-02-17
Сейчас у меня на нескольких сайтах работает колхоженный WP Fastest Cache, еще на нескольких - Swift perfomance. Продолжаю периодически мониторить.
Fastest Cache работает без нареканий, за час успевает обновить кеш на 100 страницах, при этом посетители ВСЕГДА получают кешированные файлы, а страницы грузятся быстро. Единственный минус - нужно всегда держать в голове, что при обновлении плагина - нужно вносить изменения в исходники плагина.
Swift perfomance тоже не плох. Умное кеширование, правда, оказалось недостаточно умным. Да, когда мы обновляем страницу - он моментально генерирует под нее свежий кеш, пользователи не увидят долгих загрузок. Когда мы публикуем новость - она тут же появляется на странице новостей. Но вот, если эта же новость должна попасть куда-то в другое место (например, в сайдбар других страниц) - она туда не попадет ровно до тех пор, пока мы полностью вручную не обновим кеш всего сайта.
Полный обход сайта при работе в несколько потоков (multi thread) swift perfomance осуществляет достаточно быстро. 700 страниц за 20 минут - спокойно. Также, судя по всему, для обхода сайта Swift perfomance собирает ссылки на главной странице, так что кеш для страниц, куда пользователи тыкнут с большей вероятностью, будет создан буквально за пару минут.
Тем не менее, когда мы вручную обновляем весь кеш сайта (чтобы, допустим, наша новость появилась в сайдбаре на всех страницах) – далеко не все страницы работают быстро. И тут я не смог понять логики работы Swift performance. Через несколько минут после ручного запуска переобхода сайта – часть страниц уже имеют новый кеш (работают быстро), часть страниц еще отдаются со старым кешем (видим, что свежая новость в сайдбарах на этих страницах еще не появилась), но часть страниц (причем, не малая) грузится ужасно долго (8 – 12 сек. против 3-4 без использования вообще какого-либо плагина кеширования). При этом, используя WP Fastest Cache даже в случае отсутствия закешированных файлов (например, удалили их вручную) время загрузки страниц, не имеющих кеш-копии - не увеличивается (в сравнении со временем загрузки без использования какого-либо плагина для кеширования).
Также, в отличие от WP Fastest Cache бесплатная версия которого более чем удовлетворяет все мои потребности, Lite-версия Swift perfomance попросту вынуждает покупать подписку:
- В бесплатной версии Swift perfomance нельзя выбрать высокую скорость для автокеширования
- Отсутствует возможность указать GET-параметры для исключения из URL-адреса при кеширвоании
Итого
Безусловным лидером для меня остался плагин "WP Fastest Cache" - именно его в ближайшее время я установлю на все сайты. Тем не менее, если ты готов пойти на небольшие компромиссы ради того, чтобы не править исходники чужих плагинов при каждом их обновлении я рекомендую использовать "Swift perfomance".
Еще стоит отметить, что когда WP Fastest Cache обрабатывает URL-адреса с GET-параметрами, делает он это не очень быстро. Так например, на одном из сайтов URL вида https://example.com/?utm_source=yandex WP Fastest Cache загружает за 500 мс, в то время как все описанные выше плагины кеширования отдавали закешированную копию страницы за 50-150 мс. Тем не менее, с учетом описанных ранее косяков других плагинов, для меня 500 мс в рекламных заходах является вполне себе компромиссом.
Хотя, например, в лендингах (или других сайтах, на которых явно не планируется обновлять контент) можно использовать WP Super Cache с отключенным сборщиком мусора и без автокеширования. Но как только появляется необходимость обновлять или публиковать контент - с WP Super Cache всё идет по бороде.