Оптимизация плагина 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.
Я до этого не работал с вордпресс и не знаю, как разобраться в коде плагина, там очень много папочек.
Забудьте Visual Composer как страшный сон, если хотите действительно быстрые сайты.
Мне иногда попадают сайты, сделанные на page builder, к коим и относится Visual Composer. И беда их в том, что благодаря простоте создания страниц люди впадают в раш и используют почти все блоки, которые предоставляет тот же Visual Composer. И по нескольку раз! Ну это же круто! И то, и сё показать потенциальным клиентам. Прям благодать. Такая офигенная портянка со всем барахлом, что они могут предложить. Не делайте так! Зачем? Изучите свою аудиторию и давайте ей то, зачем она пришла и не устраивайте базарную площадь.
А зачем ему использовать свои собственные, когда родные внутренние прекрасно работают при грамотном подходе. Но в page builder не получится сделать так, чтобы он раз вжух и получил данные, а потом обработал. Все блоки Visual Composer - это шоткоды. А работает это так - перед выводом на экран в контенте ищутся шоткоты и друг за другом выполняются. Друг за другом, а не вместе весёлою гурьбой. Тут блок с 2 новостями - выстрел в базу, тут блок с 4 услугами - выстрел в базу... и так далее.
Сейчас взял главную страницу одного подобного сайта. В контенте страницы почти 100 шоткодов от Visual Composer. Да, не все они получают данные из базы, но как ни крути они генерируют блоки, на что тратиться время, я уже не говорю о тех блоках, для отображения которых нужны данные из базы - там в разы больше работы проводится.
Если Вы разберетесь в коде такого плагина, да ещё и найдете способ уменьшить количество запросов с помощью его модификации без других изменений на сайте - поверьте, он вам больше не понадобиться просто напросто.
На самом деле хороший совет дал sholex. И дело не в том, что плагин плохой, а в том, как это всё работает и другого механизма у page builder в связке с WordPress ещё не придумали. Может первопроходцем будете Вы?
Ну а мой совет, повторюсь, пересмотрите все блоки, что вы туда накидали, и уберите те, которые и даром не нужны вашей аудитории. Также изыщите возможность хотя бы часть динамических блогов, которые дёргают инфу из базы, заменить статичными. К примеру, если услуги крайне редко добавляются, то зачем динамичный блок, если можно это "сверстать" обычным. Да, больше времени уйдет на тыканья мышкой, но и запросов поуменьшится.
С таким TTFB (время до получения первого байта) пока только кеш может спасти, но представляю, как начинает дёргаться глаз при редактировании материалов на сайте
. Как говориться, за удобство надо платить - наудобничали кучу всего, получайте "награду".
Итог: когда решите сделать шустрый сайт, вы это всё руками сделаете без всяких плагинов. Но к этому приходят через время люди.