У меня тоже по одному сайту такая фигня, пока не было времени заморачиваться. Может выберу момент и напишу в чат поддержки яндекса. Хотя сейчас не сильно много надежды на какой-то ответ.
Да, желательно. Но наверно есть в плагине кеширования возможность отключить одну страницу, что бы весь сайт не отключать, но надо выбрать нагруженную страницу. В смысле обычной записи или что у вас. Но и они скорее больше скажут вам, чем тут. Надо знать и видеть, что грузится на странице и как. Что можно в предзагрузку, а что мешает или нельзя и тд. Более информативными будут срины из монитора, по крайней мере понятно будет, тормозит что-то кроме кучи стилей и js, рекламы и счетчиков. И да, не все из стилей надо объединять, а то у некоторых просто гигантские объединенные файлы, что уже давно не актуально.
Насчет метрику обернуть, через пс по запросу выдаст кучу вариантов, кстати помнится плагин был для отложки счетчиков, включая метрику.
Если есть такие запросы у 22 плагинов, то сайт даже не дернется, не дойдет дело до контента, 0.00** надо уже начинать думать 😀. Насчет структуры, да не так все плохо, норм для большинства проектов.
Насчет плагинов согласен, есть куча не ужасных, а сверх ужасных. Например при выводе последних или рандомных или каких угодно постах перебирается вся таблица, а там может быть и не 500 и не тысяча тех же постов. Если добавить в запрос плагина или сниппеета простой интервал времени, скажем за месяц, нагрузка и скорость в разы снизятся 😎
Под такую БД в пору пару отдельных серверов ставить.
Инфа очень интересная, утром на свежую голову изучу.
Спасибо за ссылку!
Это работает на базах любых размеров, так как опция зависит от других критериев, просто проведя эксперимент и убрав ее из автозагрузки, можно действительно удивиться ;)
Выполните в базе и посмотрите, что там творится (всегда полезно сначала сделать дамп) прификс ниже стандартный:
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes'; - выведет общий размер автозагрузки, он может быть очень большим и содержать давно не нужные опции.SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10; - отсортирует по размеру 10 самых больших.
Я бы не стал так категорично про базы утверждать, сейчас на скрине ТС боту отдана кешированная версия, а она не дает картину, нет ни реальности, ни стабильности. Плюс...ну отрисовался экран, а wp и PHP дальше работает( это я упрощаю, слишком много букововк писать). Вот если бы тс привел скрин или несколько скринов из плагина Query Monitor, можно уже хоть какое-то представление получить. Скажем общий результат и с раздела запросы по компонентам. Плюс скрин с попугайчиками от PageSpeed Insights без кеша на сайте и без первого блока рекламы. Я к тому, что тут мы можем только общие рекомендации дать, инфы представленной не хватит даже на вменяемый ответ по блокам рся, так как они могут и не влиять столь серьезно на скорость. Если появится больше инфы от ТС, со скринами из плагина Query Monitor, может тема и продолжит развитие в более конкретном направлении. webinfo, все что написал, не для спора или утверждения, что это не правильно или правильно, влияет или нет, база виновата или не база и не опровергаю ваши слова или утверждаю свои как истина. От недостатка инфы, мы может всю тему превратить в бесполезные размышления, а в итоге все окажется совсем не так.
Да, но он поможет если действительно много всего... Не уверен, что он нужен для mysql 8.2+, но я не тестировал.
Есть смысл сделать вот это, о чем писал выше выставить опции автозагрузки _transient_dirsize_cache: autoload no. Вот это реально ускоряет, в некоторых случаях в десяток раз. Тут самое доступное обсуждение и есть ссылочка на патч, конечно по желанию https://core.trac.wordpress.org/ticket/54221
ну вот и причина... плагинов должно быть как можно меньше..
Не факт, все зависит не от количества, а что хотят эти плагины от базы. На скрине 25 плагинов, но как видите скорость и нагрузка норм. Объектный кеш, оптимизация запросов и тд. И это скорость для зарегистрированного. Как писал выше, ставить плагин монитор и уже смотреть, что можно сделать и на что хватит сил. Скрин с рабочего сайта, сделал для контроля небольшую стату для себя.
Тут однозначно не просто сказать, но все не плохо на 5.7.27. Если есть чего-то слишком много в базе, можно плагин добавления индексов поставить и будет все шустренько даже с условным лямом постов, товаров.
Чуть медленнее (читать как хуже) становятся запросы mysql 8.2+. Но наверняка можно оптимизировать, индексы или просто посмотреть почему данных больше становится в опциях и тд. Я не заморачивался, время пока нет.
Ставите плагин Query Monitor и курите его до полного понимания, какие плагины и сколько запросов выдают на странице, какие медленные, дублирующие и тд и тп. Находите в себе силы и грохаете то, что не можете сами исправить или нет альтернативы менее прожорливой, либо смирится.
Используйте объектный кеш, тут вам надо выбрать исходя из функционала сайта Memcache или Redis. Возможны еще манипуляции с базой, конкретно автозагрузкой, но думаю без специалиста не разберетесь, хотя там не сложно. Причем там есть один косяк, который закидывает в автозагрузку мего наполненную опцию и на некоторых сайтах это приводит к очень серьезным проблемам со скоростью. Косяк будет исправлен, но только в следующем большом релизе WP, а это не скоро. Сам проверял и использую на нескольких сайтах, существенно увеличивается скорость и падает нагрузка.
Все очень хорошо себя чувствует на php8+, но если подключить mysql 8.2+, надо разбираться, автозагрузка и некоторые другие запросы чуть медленнее становятся.
