allclaws
  • 0
Новичок

Тяжелые плагины или множество плагинов замедляют работу сайта?

  • 0

Я часто слышал, что наличие большого количества плагинов замедляет работу сайта WordPress. Это, конечно, имеет смысл, так как чем больше кода выполняется, тем больше времени это займет.

Мне интересно, является ли медлительность в основном:

  • в результате огромного количества плагинов? (потому что WP должен выполнить некоторую обработку, чтобы найти и загрузить каждый плагин)

  • результат наличия нескольких медленных/тяжелых плагинов?

С практической точки зрения, когда я пишу свой собственный, должен ли я объединять функциональность в меньшее количество файлов, чтобы увеличить скорость? Или нормально иметь 10-20 плагинов, каждый из которых выполняет быструю задачу?

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

    • 0
  2. Общие положения

    Эмпирическое правило « много плагинов замедляет работу сайта » является очень грубым инструментом и увековечивается теми, кто не понимает, как работают плагины, поэтому они выбирают что-то, что легко демонизировать.

    Да, плагины могут замедлить работу вашего сайта, но дело не в количестве, а в качестве и в том, чего они пытаются достичь. Я мог бы написать один-единственный плагин, который поставил бы сайт на колени (если бы у меня была на это причина), и это было бы хуже, чем 50 других хорошо написанных плагинов. Конечно, люди постоянно пишут плагины, которые ставят сайт на колени, потому что они не знают ничего лучшего.

    Я полагаю, единственная истина в том, что « много плагинов замедляют работу сайта », заключается в том, что когда у вас много плагинов, более вероятно, что вы поймаете плохой.

    Особенности

    Итак, давайте поговорим более конкретно. Плагины используют « ловушки », которые представляют собой фрагменты PHP-кода, которые проходят через определенные точки на пути выполнения, и они могут либо что-то делать, либо фильтровать значение, либо и то, и другое. WordPress начинает вызывать хуки раньше, пытаясь создать веб-страницу и сгенерировать HTML для отправки в браузер, и продолжает вызывать хуки почти до тех пор, пока не завершит работу для данной страницы.

    В зависимости от того, какие хуки использует плагин, он может вызываться только на определенных страницах, в фоновом режиме или даже почти никогда. Некоторые хуки работают только в консоли администратора. Некоторые хуки работают только на определенных страницах консоли администратора. А некоторые хуки вызываются внутренней системой псевдо-крона. OTOH, некоторые плагины могут загружать дополнительные файлы CSS или JS, и каждый из этих файлов снижает производительность из-за правила веб-производительности № 1.

    Если вы хотите получить представление о том, какие хуки вызываются на каждой странице, рассмотрите возможность использования плагина « Instrument Hooks for WordPress », который я написал для вопроса « Где я могу найти список хуков WordPress? » Вот скриншот того, что плагин отображается в нижнем колонтитуле при использовании:

    Скриншот инструментальных хуков для плагина WordPress в действии

    Но простое знание хуков не поможет вам точно узнать, есть ли проблема с плагином. Вы можете вызвать плагин 100 раз, и его вызов может быть незначительным по сравнению с другим вызовом хука, который добавляет предложение WHERE в SQL-запрос, что может привести к зависанию сайта с более чем несколькими сотнями сообщений. Или он может сделать HTTP-вызов на другой сервер. Или он может сбрасывать правила перезаписи при каждой загрузке страницы. Список грехов можно продолжить.

    Единственный реальный способ узнать наверняка, это проверить хуки плагина, просмотрев исходный код или, что еще лучше, запустить его через отладчик, такой как PhpStorm+XDEBUG.

    Ваши собственные плагины

    Не беспокойтесь о том, как организован код для повышения производительности ; беспокоиться о том, что делает ваш код. Оптимизация часто выполняемого SQL-запроса с использованием Transient API (см. Презентация о Transient API ) будет намного лучше для производительности, чем объединение кода 10 плагинов в один.

    С другой стороны, рассмотрите возможность организации кода по другим причинам. Я думаю , что длинный список плагинов может создать психологический стресс для многих пользователей; они видят такой экран, переполняются и просто хотят упростить вещи:

    Длинный список плагинов
    (источник: mikeschinkel.com )

    Но, с другой стороны, иногда пользователи могут быть перегружены тем, что один плагин делает слишком много. Например, я чувствовал то же самое с плагином GD Star Rating. Попробовав его в проекте (и, что еще хуже, пытаясь подключить его, чтобы он делал то, что мне нужно), я решил выбросить его на ухо.

    Поэтому некоторые люди (такие, как я) часто предпочитают множество небольших тесных плагинов, каждый из которых делает одну вещь и делает это хорошо (хотя было бы неплохо, если бы WordPress поддерживал функцию группировки, вроде того, как iPhone iOS 4 позволяет группировать приложения в папки. )

    Длинный список вариантов звездного рейтинга GD
    (источник: mikeschinkel.com )

    Во всяком случае, надеюсь, что это поможет.

    • 0
  3. Естественно, плагины — это только часть истории производительности, поэтому вы не можете измерить ее количеством файлов в конце. Существует больше, и вы не можете заранее сказать, что работает, поэтому то, что может быть хорошо на вашем компьютере, не работает на других.

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

    Если пользователь жалуется на производительность своего блога, вы обычно можете предложить ему купить сервер побольше, и проблемы с производительностью будут решены.

    (Pre-Mature) Оптимизация — корень всех зол. Просто больше не думайте о производительности при написании плагинов. Воспринимайте это легко и ясно: в конце концов, WordPress не разработан с точки зрения производительности, не совершайте ошибку и не пытайтесь писать для него эффективные плагины;)

    WordPress разработан с использованием шаблона Big Ball of Mud-(anti-)design-pattern. Система плагинов очень хорошо работает с ним. Просто не думайте, что вы можете так оптимизировать как автор плагина. Вы не можете. Не боритесь 🙂

    • 0
  4. Вы можете использовать WordPress с сотнями плагинов, когда дизайн плагинов в порядке — у большинства плагинов плохой код, и это проблема производительности WordPress.

    • 0
  5. все дело в наличии правильных плагинов. Например, проверьте, записывают ли ваши плагины свои собственные таблицы в базу данных, обычно это немного замедляет работу. все, что загружает много jquery или javascript, обычно также немного замедляет его. Большое количество плагинов не всегда означает падение производительности. Убедитесь, что вы используете подключаемый модуль кэширования, который также поможет.

    Я предполагаю, что вы спрашиваете об этом, потому что испытываете замедление? Спросите своего хоста, можете ли вы что-нибудь сделать, чтобы ускорить его, и убедитесь, что ваша конфигурация php настроена правильно.

    • 0
  6. Вы смотрите на 2 вещи, которые замедлят ваш сайт: 1, обработка файлов на сервере(ах), ваш php и 2, способ чтения кода при просмотре.

    Если код небрежный, браузер дважды или трижды проверит код, прежде чем представить его на экране. Если вы используете много плагинов с большим количеством запросов к базе данных и/или серверу, это может занять некоторое время, и если они не будут выполнены правильно, могут возникнуть конфликты с запросом, которые могут привести к дополнительному времени или, что еще хуже, ваш сайт не загружается и/или Сообщения об ошибках.

    rFair404 упомянул программы кэширования, которые помогут с запросами к серверу, а некоторые будут сжимать html-код, и это напомнило мне, что мне нужно сжать некоторые страницы css.

    • 0
  7. Обычно я не устанавливаю слишком много плагинов для WordPress, вместо этого я стараюсь использовать фреймворки тем, которые выполняют основную работу. Это правда, что каждый плагин увеличивает потребление ресурсов.

    Каждый плагин будет что-то делать, они должны инициализироваться, поэтому они будут запускать некоторый код, когда запрашивается страница для вашего сайта, не говоря уже о том, что так много ссылок на панели администратора WordPress, что затрудняет загрузку.

    Возможно, вы не заметите этого на виртуальном хостинге с 2-3 тысячами просмотров страниц в день, но если у вас есть сайт с 3 тысячами активных пользователей, каждый из которых запрашивает 10 страниц каждый день, это может стать проблемой.

    • 0
  8. Я бы сказал, что ответ и тот, и другой.


    Больше плагинов = больше медлительности

    Каждый включенный вами плагин, добавляющий таблицу стилей и/или файл javascript на страницу, значительно замедляет работу вашего сайта.

    Даже самые лучшие написанные плагины затормозят ваш сайт, если для каждого из них требуется таблица стилей и файл javascript, чтобы что-то делать в интерфейсе вашего веб-сайта.

    Объедините ваши файлы

    Если вы управляете сайтом WordPress, вы обязаны научиться:

    • Правильно объединяйте файлы javascript вместе
    • Правильно объединяйте файлы таблицы стилей вместе
    • Переместить вызовы javascript из верхнего колонтитула в нижний колонтитул.

    Если вы запускаете сайт wordpress и не можете делать вышеперечисленные вещи, то вам не следует запускать сайт wordpress… или, по крайней мере, вы не должны жаловаться, когда ваш сайт замедляется, когда вы загружаете больше плагинов.

    Кроме того, любой, кто работает с сайтом WordPress, должен знать, как:

    • Минимизировать файлы CSS и javascript
    • Включите сжатие сервера
    • Убедитесь, что заголовки с истекающим сроком действия снабжены скриптами и таблицами стилей.

    Плохо написанные плагины = больше медлительности

    Вот основные способы, с помощью которых автор плагина действительно может замедлить работу вашего сайта:

    1. Загрузка нескольких скриптов или таблиц стилей для одной страницы — см. выше
    2. Неправильное использование базы данных — плохо написанные запросы, модификации запросов и т. д. могут оказать серьезное влияние на веб-сайт. Отсутствие кэширования результатов, где это возможно, также может замедлить работу. Большинство людей плохо разбираются в разработке и администрировании баз данных. Когда такие люди используют базы данных, возникают проблемы.
    3. Неправильное использование wp cron — постоянные задания cron по каждому запросу пользователя поставят сервер на колени.

    Если не считать написания действительно плохого кода (полубесконечные циклы, тонны регулярных выражений там, где они не нужны и т. д.), большинство вещей не будут иметь большого эффекта, если учесть, насколько велик уже WordPress. Добавление 1% дополнительного времени обработки — это немного.


    Задачи, которые от природы медленные

    Есть некоторые вещи, которые просто медленные, независимо от того, насколько хорошо они написаны:

    1. Использование сторонних сервисов. Каждый раз, когда ваш ответ пользователю зависит от ответа какой-либо третьей стороны, ваш сайт будет работать намного медленнее.

    Конечно, при правильном выполнении (кешированные результаты, по возможности работа в фоновом режиме и т. д.) многие сторонние сервисы можно использовать без особых проблем.

    • 0

Оставить ответ

You must login to add an answer.