webinfo#: Ну это немного неполные показатели. FCP - это немного не TTFB, но судя по картинке, с ответом сервера всё более или менее нормально, и всякие "базы" тут ни при чём.
Я бы не стал так категорично про базы утверждать, сейчас на скрине ТС боту отдана кешированная версия, а она не дает картину, нет ни реальности, ни стабильности. Плюс...ну отрисовался экран, а wp и PHP дальше работает( это я упрощаю, слишком много букововк писать). Вот если бы тс привел скрин или несколько скринов из плагина Query Monitor, можно уже хоть какое-то представление получить. Скажем общий результат и с раздела запросы по компонентам. Плюс скрин с попугайчиками от PageSpeed Insights без кеша на сайте и без первого блока рекламы. Я к тому, что тут мы можем только общие рекомендации дать, инфы представленной не хватит даже на вменяемый ответ по блокам рся, так как они могут и не влиять столь серьезно на скорость. Если появится больше инфы от ТС, со скринами из плагина Query Monitor, может тема и продолжит развитие в более конкретном направлении.
webinfo, все что написал, не для спора или утверждения, что это не правильно или правильно, влияет или нет, база виновата или не база и не опровергаю ваши слова или утверждаю свои как истина. От недостатка инфы, мы может всю тему превратить в бесполезные размышления, а в итоге все окажется совсем не так.
GRAFLEKX#: Имеется ввиду, как пример, Index WP MySQL For Speed?
Да, но он поможет если действительно много всего... Не уверен, что он нужен для mysql 8.2+, но я не тестировал.
Есть смысл сделать вот это, о чем писал выше выставить опции автозагрузки _transient_dirsize_cache: autoload no. Вот это реально ускоряет, в некоторых случаях в десяток раз. Тут самое доступное обсуждение и есть ссылочка на патч, конечно по желанию https://core.trac.wordpress.org/ticket/54221
ну вот и причина... плагинов должно быть как можно меньше..
Не факт, все зависит не от количества, а что хотят эти плагины от базы. На скрине 25 плагинов, но как видите скорость и нагрузка норм. Объектный кеш, оптимизация запросов и тд. И это скорость для зарегистрированного. Как писал выше, ставить плагин монитор и уже смотреть, что можно сделать и на что хватит сил. Скрин с рабочего сайта, сделал для контроля небольшую стату для себя.
GRAFLEKX#: А на каком мускуле без ухудшений, не тестировали?
Тут однозначно не просто сказать, но все не плохо на 5.7.27. Если есть чего-то слишком много в базе, можно плагин добавления индексов поставить и будет все шустренько даже с условным лямом постов, товаров.
GRAFLEKX#: Проще говоря, я не понял, с mysql 8.2+ становится хуже или лучше?
Чуть медленнее (читать как хуже) становятся запросы mysql 8.2+. Но наверняка можно оптимизировать, индексы или просто посмотреть почему данных больше становится в опциях и тд. Я не заморачивался, время пока нет.
Ставите плагин Query Monitor и курите его до полного понимания, какие плагины и сколько запросов выдают на странице, какие медленные, дублирующие и тд и тп. Находите в себе силы и грохаете то, что не можете сами исправить или нет альтернативы менее прожорливой, либо смирится.
Используйте объектный кеш, тут вам надо выбрать исходя из функционала сайта Memcache или Redis. Возможны еще манипуляции с базой, конкретно автозагрузкой, но думаю без специалиста не разберетесь, хотя там не сложно. Причем там есть один косяк, который закидывает в автозагрузку мего наполненную опцию и на некоторых сайтах это приводит к очень серьезным проблемам со скоростью. Косяк будет исправлен, но только в следующем большом релизе WP, а это не скоро. Сам проверял и использую на нескольких сайтах, существенно увеличивается скорость и падает нагрузка.
Все очень хорошо себя чувствует на php8+, но если подключить mysql 8.2+, надо разбираться, автозагрузка и некоторые другие запросы чуть медленнее становятся.
Ростислав Шацкий#: Допилил возможность проверить данные ip кликнув по нему🔥 Для проверки ip зацепил халявный api от ipapi.co
Хорошее дело, можно в итоге полезный плагин сделать. А в этом апи подсеть или диапазон не определят, скажем накинулась бетерика и сразу ее в бан. Города наверно не слишком нормально это апи определяет. Может не все писать а только прямые.
SeVlad#: Для начала нужно точно узнать источник проблем, а не грешить на первое похожее. Иначе может быть только хуже.
Так там на сайте стоит Woo, еще какие-то плагины, которые короткими ссылками оперируют в своих функциях, наверно появляться где-то на страницах. Поэтому пс и подхватывают. Но тут уже надо самому ТС анализировать и корректировать разными способами. Каноникал даже гуглу не указ давно, подхватит то, что посчитает нужным или...;)
В принципе, все, что потенциально не нужно в коде, зачем оно там, а лишнего, я считаю, больше десятка. Опять же мое мнение и я удаляю. 😎
Думаю ТС не углублялся в тему, за него... могут пс выдавать в разных ситуациях короткую. Надо не забывать, что она в WP передается в заголовке, проверить просто через консоль браузера "Сеть".
Ну это немного неполные показатели. FCP - это немного не TTFB, но судя по картинке, с ответом сервера всё более или менее нормально, и всякие "базы" тут ни при чём.
Я бы не стал так категорично про базы утверждать, сейчас на скрине ТС боту отдана кешированная версия, а она не дает картину, нет ни реальности, ни стабильности. Плюс...ну отрисовался экран, а wp и PHP дальше работает( это я упрощаю, слишком много букововк писать). Вот если бы тс привел скрин или несколько скринов из плагина Query Monitor, можно уже хоть какое-то представление получить. Скажем общий результат и с раздела запросы по компонентам. Плюс скрин с попугайчиками от PageSpeed Insights без кеша на сайте и без первого блока рекламы.
Я к тому, что тут мы можем только общие рекомендации дать, инфы представленной не хватит даже на вменяемый ответ по блокам рся, так как они могут и не влиять столь серьезно на скорость. Если появится больше инфы от ТС, со скринами из плагина Query Monitor, может тема и продолжит развитие в более конкретном направлении.
webinfo, все что написал, не для спора или утверждения, что это не правильно или правильно, влияет или нет, база виновата или не база и не опровергаю ваши слова или утверждаю свои как истина. От недостатка инфы, мы может всю тему превратить в бесполезные размышления, а в итоге все окажется совсем не так.
Имеется ввиду, как пример, Index WP MySQL For Speed?
Да, но он поможет если действительно много всего... Не уверен, что он нужен для mysql 8.2+, но я не тестировал.
Есть смысл сделать вот это, о чем писал выше выставить опции автозагрузки _transient_dirsize_cache: autoload no. Вот это реально ускоряет, в некоторых случаях в десяток раз. Тут самое доступное обсуждение и есть ссылочка на патч, конечно по желанию https://core.trac.wordpress.org/ticket/54221
ну вот и причина... плагинов должно быть как можно меньше..
Не факт, все зависит не от количества, а что хотят эти плагины от базы. На скрине 25 плагинов, но как видите скорость и нагрузка норм. Объектный кеш, оптимизация запросов и тд. И это скорость для зарегистрированного. Как писал выше, ставить плагин монитор и уже смотреть, что можно сделать и на что хватит сил. Скрин с рабочего сайта, сделал для контроля небольшую стату для себя.
А на каком мускуле без ухудшений, не тестировали?
Тут однозначно не просто сказать, но все не плохо на 5.7.27. Если есть чего-то слишком много в базе, можно плагин добавления индексов поставить и будет все шустренько даже с условным лямом постов, товаров.
Проще говоря, я не понял, с mysql 8.2+ становится хуже или лучше?
Чуть медленнее (читать как хуже) становятся запросы mysql 8.2+. Но наверняка можно оптимизировать, индексы или просто посмотреть почему данных больше становится в опциях и тд. Я не заморачивался, время пока нет.
Ставите плагин Query Monitor и курите его до полного понимания, какие плагины и сколько запросов выдают на странице, какие медленные, дублирующие и тд и тп. Находите в себе силы и грохаете то, что не можете сами исправить или нет альтернативы менее прожорливой, либо смирится.
Используйте объектный кеш, тут вам надо выбрать исходя из функционала сайта Memcache или Redis. Возможны еще манипуляции с базой, конкретно автозагрузкой, но думаю без специалиста не разберетесь, хотя там не сложно. Причем там есть один косяк, который закидывает в автозагрузку мего наполненную опцию и на некоторых сайтах это приводит к очень серьезным проблемам со скоростью. Косяк будет исправлен, но только в следующем большом релизе WP, а это не скоро. Сам проверял и использую на нескольких сайтах, существенно увеличивается скорость и падает нагрузка.
Все очень хорошо себя чувствует на php8+, но если подключить mysql 8.2+, надо разбираться, автозагрузка и некоторые другие запросы чуть медленнее становятся.
Аккуратнее с .htaccess, не "наломайте дров"
Можно бекапчик добавить файла и проблем меньше)
Допилил возможность проверить данные ip кликнув по нему🔥 Для проверки ip зацепил халявный api от ipapi.co
Хорошее дело, можно в итоге полезный плагин сделать. А в этом апи подсеть или диапазон не определят, скажем накинулась бетерика и сразу ее в бан. Города наверно не слишком нормально это апи определяет. Может не все писать а только прямые.
Для начала нужно точно узнать источник проблем, а не грешить на первое похожее. Иначе может быть только хуже.
Так там на сайте стоит Woo, еще какие-то плагины, которые короткими ссылками оперируют в своих функциях, наверно появляться где-то на страницах. Поэтому пс и подхватывают. Но тут уже надо самому ТС анализировать и корректировать разными способами. Каноникал даже гуглу не указ давно, подхватит то, что посчитает нужным или...;)
В принципе, все, что потенциально не нужно в коде, зачем оно там, а лишнего, я считаю, больше десятка. Опять же мое мнение и я удаляю. 😎
вам бы определится кто и где кого индексирует
покажите скрин где поисковики индексируют
Думаю ТС не углублялся в тему, за него... могут пс выдавать в разных ситуациях короткую. Надо не забывать, что она в WP передается в заголовке, проверить просто через консоль браузера "Сеть".
Поэтому лучше убрать и забыть.