Оптимизация плагина Visual Composer

Подскажите на что стоит обращать внимание при изучении чужого кода плагинов. Сейчас этот плагин в определенных условиях (стартовая страница сайта nameshore.com) генерирует 420 запросов в БД. Это было установлено благодаря плагину Query Monitor.

TTFB для этой страницы составляет больше 20 сек и предположительно именно количество запросов этого плагина к БД является бутылочным горлышком. Я немного изучил эти запросы и увидел что большинство запросов ходят в несколько таблиц и достают практически все записи.

Например:

SELECT something FROM wp_table_something WHERE something.id = 3245;

И так много раз с разными номерами id.

Более того, эти запросы отправляются не через плагин, а через внутренние функции WP, вроде WP_Query. Таблица, в которую ходит плагин, состоит из пары тысяч записей.

У меня есть гипотеза, что количество запросов можно значительно уменьшить, если одним запросом полностью загрузить таблицу в PHP, и заменить вызов WP_Query на другую функцию, которая будет делать выборку из памяти процесса php.

Я до этого не работал с вордпресс и не знаю, как разобраться в коде плагина, там очень много папочек.

0
Кирилл
7.8 лет назад
  • 2
    sholex 40 sholex.by

    Забудьте Visual Composer как страшный сон, если хотите действительно быстрые сайты.

    Комментировать
  • 2
    campusboy 5000 youtube.com/c/wpplus

    Мне иногда попадают сайты, сделанные на page builder, к коим и относится Visual Composer. И беда их в том, что благодаря простоте создания страниц люди впадают в раш и используют почти все блоки, которые предоставляет тот же Visual Composer. И по нескольку раз! Ну это же круто! И то, и сё показать потенциальным клиентам. Прям благодать. Такая офигенная портянка со всем барахлом, что они могут предложить. Не делайте так! Зачем? Изучите свою аудиторию и давайте ей то, зачем она пришла и не устраивайте базарную площадь.

    Более того, эти запросы отправляются не через плагин, а через внутренние функции WP, вроде WP_Query.

    А зачем ему использовать свои собственные, когда родные внутренние прекрасно работают при грамотном подходе. Но в page builder не получится сделать так, чтобы он раз вжух и получил данные, а потом обработал. Все блоки Visual Composer - это шоткоды. А работает это так - перед выводом на экран в контенте ищутся шоткоты и друг за другом выполняются. Друг за другом, а не вместе весёлою гурьбой. Тут блок с 2 новостями - выстрел в базу, тут блок с 4 услугами - выстрел в базу... и так далее.

    Сейчас взял главную страницу одного подобного сайта. В контенте страницы почти 100 шоткодов от Visual Composer. Да, не все они получают данные из базы, но как ни крути они генерируют блоки, на что тратиться время, я уже не говорю о тех блоках, для отображения которых нужны данные из базы - там в разы больше работы проводится.

    Если Вы разберетесь в коде такого плагина, да ещё и найдете способ уменьшить количество запросов с помощью его модификации без других изменений на сайте - поверьте, он вам больше не понадобиться просто напросто.

    На самом деле хороший совет дал sholex. И дело не в том, что плагин плохой, а в том, как это всё работает и другого механизма у page builder в связке с WordPress ещё не придумали. Может первопроходцем будете Вы? smile

    Ну а мой совет, повторюсь, пересмотрите все блоки, что вы туда накидали, и уберите те, которые и даром не нужны вашей аудитории. Также изыщите возможность хотя бы часть динамических блогов, которые дёргают инфу из базы, заменить статичными. К примеру, если услуги крайне редко добавляются, то зачем динамичный блок, если можно это "сверстать" обычным. Да, больше времени уйдет на тыканья мышкой, но и запросов поуменьшится.

    С таким TTFB (время до получения первого байта) пока только кеш может спасти, но представляю, как начинает дёргаться глаз при редактировании материалов на сайте wacko . Как говориться, за удобство надо платить - наудобничали кучу всего, получайте "награду".

    Итог: когда решите сделать шустрый сайт, вы это всё руками сделаете без всяких плагинов. Но к этому приходят через время люди.

    Ксюша 7.6 лет назад

    Есть вариант

    Попробуйте отключить ultimate addons for Visual Composer. Сейчас делаем на kler.com.ua, 28% нагрузки давал сам компостер, 8% эти самые аддонсы... после отключения аддонс исчесли эти 8% и сам компостер стал 16% вместо 28%

    Работы еще ведутся, если можете еще что подсоветуйте

    Alavar 7.2 года назад

    Согласен, лучше всё делать без конструкторов страниц, но, часто попадаются клиенты, которые хотят:

    1. чтобы сайт был на вордпрессе.
    2. чтоб сами могли потом все редактировать и удалить блоки.
    3. чтобы не было путаницы в админке и всё было красиво.
      И получается, что либо писать какие-то плагины для них, либо выводить блоки в админку и т.д. что требует гораздо более весомых навыков, например, чем у меня сейчас. А ставишь им page builder, и они радуются). До того момента, как случайно зайдут в PageSpeed Insights, тогда они хотят, чтобы их сайт был как ракета, и приходится объяснять, что это совсем другие деньги.

    ПС, начинал тоже с композера, но в последствии перешел на page builder, т.к. он заметно легче. Конечно, возможностей у него поменьше, но их можно доработать тем же css.

    Комментировать
На вопросы могут отвечать только зарегистрированные пользователи. Вход . Регистрация