Это - тяжелые плагины или много плагинов, которые делают сайт медленным?

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

Я задаюсь вопросом, является ли замедление главным образом:

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

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

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

6
11.12.2013, 23:33
6 ответов

Общие места

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

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

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

Специфические особенности

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

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

Если Вы хотите получить ощущение того, к каким рычагам обращаются, каждая страница рассматривает использование "Инструментальных Рычагов для WordPress" плагин, который я записал для вопроса, "Где я могу Найти Список Рычагов WordPress?" Вот снимок экрана того, что плагин показывает в нижнем колонтитуле при использовании:

Screenshot of Instrument Hooks for WordPress Plugin in action

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

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

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

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

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

Long List of Plugins
(источник: mikeschinkel.com)

Все же, с другой стороны, иногда пользователи могут быть поражены, потому что один плагин делает слишком много. Например, я чувствовал что путь со Звездообразным Плагином Оценки GD. После попытки его на проекте (и хуже, пытаясь сцепить его, чтобы заставить его делать, в чем я нуждался) я решил выбросить его на, он - ухо.

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

Long List of GD Star Rating Options
(источник: mikeschinkel.com)

Так или иначе надежда это помогает.

8
19.02.2020, 22:04
  • 1
    Интересная подсказка о Переходных процессах API.. Я не услышал об этом прежде. Я думаю Ваша точка, которую увеличивает увеличение числа плагинов, возможности получения плохого/медленного крайне важно. –  allclaws 19.08.2010, 19:28
  • 2
    "Я думаю Ваша точка, которую увеличивает увеличение числа плагинов, возможности получения плохого/медленного крайне важно". Хорошо это, конечно, дает тем, кто ищет боеприпасы выравнивания для поддержки их собственной предвзятости.:) Действительность, это не количество плагинов, это - неразборчивый выбор плагинов. К сожалению, в настоящее время нет простого способа оценить их, не имея опытного пользователя, роют в код. Интересно, могли ли мы использовать StackExchange для crowdsource это? :) –  MikeSchinkel 19.08.2010, 19:37
  • 3
    Это достаточно справедливо! Я не принес (большая часть из) предвзятость к этому вопросу, но я действительно получал ответ, я надеялся на - что запись большого количества легких плагинов не обязательно плохо. То, под чем я подразумевал крайне важный, - то, что Ваше наблюдение объясняет, куда расхожее мнение (что много плагинов плохо) прибыло из, то есть, вероятность * неразборчивый выбор. –  allclaws 20.08.2010, 17:02
  • 4
    Это не были так Вы, я был обеспокоен в, но кто-то еще, кто мог бы видеть что предложение и выполнение с ним как чистое выравнивание для зла плагинов. –  MikeSchinkel 21.08.2010, 04:24

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

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

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

(Преждевременная) Оптимизация является корнем всего зла. Просто дольше не думайте о производительности при записи плагинов. Возьмите его легкий и яркий путь: WordPress не является разработанной производительностью, мудрой в конце, не делайте ошибку и попытку записать производительные плагины для него ;)

WordPress разработан с Большим Комком грязи (анти-) шаблон разработки. Сменная система является той, которая работает очень хорошо с нею. Просто не думайте, что можно оптимизировать это как сменный автор. Вы не можете. Не боритесь с ним :)

2
19.02.2020, 22:04
  • 1
    I, хотя деньги были "корнем всего зла". Нет? серьезное основание ;-) –  MikeSchinkel 19.08.2010, 09:49
  • 2
    Не думайте так, возможно, часть преждевременной оптимизации его :) en.wikipedia.org/wiki/Materialism_and_Empirio-criticism –  hakre 19.08.2010, 10:45
  • 3
    @MikeSchinkel "Из любви к деньгам является корнем всех видов зла". 1 6:10 –  hemp 20.08.2010, 00:58
  • 4
    "Wordpress не является разработанной производительностью, мудрой в конце" Создание диких операторов как этот без доказательства, или резервное копирование просто flamebait. Как насчет мы придерживаемся фактов? :) –  Viper007Bond 20.08.2010, 04:53
  • 5
    О, почему не сэкономить время и вместо этого служить, круглый Запутанный код для нашего голодного переваривает? № 13527 :) –  hakre 20.08.2010, 12:24

Можно использовать WordPress с сотней плагинов, когда дизайн плагинов прекрасен - большинство плагинов имеет плохой код, и это - проблема производительности WordPress.

0
19.02.2020, 22:04

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

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

0
19.02.2020, 22:04

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

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

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

0
19.02.2020, 22:04

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

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

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

0
19.02.2020, 22:04

Теги

Похожие вопросы