Можно любить этот движок, можно ненавидеть, но факт остается фактом: больше 70% сайтов в интернете работают именно на этом движке. Да, за ним уже давно идет слава как пожирателя ресурсов серверов, но иногда приходишь на сайты веб-мастеров и с удивлением видишь пузомерки в подвале типа: «Запросов в базу – 12, памяти съедено 6 Мб и время генерации 0,3 секунды».
Как же были достигнуты такие поразительные результаты?
Все говорят в таких случаях: ставь плагины кеширования и вот они-то все страницы загенерируют и будут отдавать их. Вот только что-то теория плохо работает — сайт ускоряется, но все равно хостер жалуется на пиковые нагрузки от ботов или посетителей, как только посещалка вырастает по 1000 просмотров в день.
Версия php и настройка хостинга
Если вы не сидите в интернете и не мониторите новости мира веб-разработки и php в частности, то наверняка и не знаете, что при переходе с 7.х версии на 8.х произошел качественный скачок в производительности php за счет предварительной компиляции кода. Она была и раньше, но тут скачок произошел очень большой – до 30% ускорения! Ну и каждая версия php так же дают очень приличные приросты.
Я перевел на php 8.4 свои сайты, включил ему OPCache (по умолчанию почему-то выключено) и сразу почувствовал ускорение.
А вот за memcache и radis уже приходится платить отдельно. Пока не стал включать эти расширения на сервере.
Время генерации страниц увеличилась, но вот расход памяти в 70 Мб как бы подсказывал что здесь что-то не так!
Query Monitor как показатель здоровья сайта на WordPress
Я поставил известный плагин Query Monitor для просмотров что происходит с сайтом и удивился.
Если честно, причина простая — устал править footer.php с прописыванием скриптов для выдачи параметров. Да и это хорошо на локальном сервере при разработке, а на «боевом» сайте такие штуки делать не стоит.
И тут волосы у меня встали дыбом!
Оказывается, на каждом сайте есть ошибки и генерируют их плагины. Проблема плагинов в WordPress давно известна: они друг с другом бывают не дружат, из-за чего в критических случаях сайт вообще падает. И среди разработчиков ходит грустная шутка: ты не разработчик на WordPress если плагины не ломали сайт тебе ни разу.
И вот такие плагины выдают несовместимость с php 8.4:
Yoast SEO – в библиотеках сторонних разработчиков
Webcraftic Clearfy – в одной библиотеке и во включаемых файлах (кажется их код)
Kadence Blocks — тоже в библиотеках сторонних разработчиков
Можно приводить еще такие же плагины.
Вот и выбираешь из двух зол меньшее: где меньше косяков в плагине и меньше влияния на время генерации и утечек памяти.
И если ваш сайт был создан давно, то нужно очень внимательно смотреть можно ли отключить виновника — разметка и содержание вашего сайта может поломаться очень сильно.
Как раз на этом сайте я «тренировался» и отключал-включал плагины блоков для gutenberg чтобы как-то найти золотую середину. Пока ищу.
Лично на 2 моих проектах самое большее отжирает памяти и выдает ошибок именно Yoast SEO. Попытка его заменить на что-то другое не увенчалась успехом: они так же с ошибками, но тяжелее или простые как кирпич. Причем если хоть чуть-чуть сложнее — тут же закрывается большая часть возможностей и требуют оплаты, причем навязчиво.
Второй после него — это плагин Webcraftic Clearfy, который делает тонкую подстройку и удаляет уязвимости, скрипты миграции, эмоджи и так далее.
Думаю, вывод понятен: подстраивайте сервер и потом отключаете плагины по одному стараясь добиться вместе с этим баланса производительности — красоты.
Ну и поубирать из сайдбара лишние виджеты, которые не несут «полезности» сайту, а служат его украшению — всякие архивы, метки (это большая дыра для поисковых систем для генерации мусорных страниц!), «лучших статей» и «последних комментариев».