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

<p>я часто слышал, что наличие большого количества плагинов замедлит работу сайта wordpress. это, конечно, имеет смысл, поскольку чем больше кода выполняется, тем дольше он будет выполняться.</p><p>мне интересно, в основном ли медлительность:</p><ul> <li> <p>результат огромного количества плагинов? (потому что wp должен выполнить некоторую обработку, чтобы найти и загрузить каждый плагин)</p> </li> <li> <p>результат наличия нескольких медленных/тяжелых плагинов?</p> </li> </ul><p>с практической точки зрения, когда я пишу свои собственные, я должен объединить функциональность в меньшее количество файлов для увеличения скорости? или нормально иметь 10-20 плагинов, каждый из которых выполняет быструю задачу?</p>

<h2>общие положения</h2><p>практическое правило "<em> большое количество плагинов замедляет работу сайта </em>" - это очень тупой инструмент, которым увлекаются те, кто не понимает, как работают плагины, поэтому выбирают что-то, что легко демонизировать.</p><p>да, плагины могут замедлить работу вашего сайта, но это не связано с количеством, которое имеет отношение к качеству и тому, что они пытаются достичь. я мог бы написать один плагин, который бы поставил сайт на колени (если бы у меня была для этого причина), и он был бы хуже, чем 50 других хорошо написанных плагинов. конечно, люди постоянно пишут плагины, которые ставят сайт на колени, потому что они не знают ничего лучше.</p><p>я предполагаю, что единственная истина в том, что "<em> много плагинов замедляют работу сайта </em>", это то, что когда у вас много плагинов, более вероятно, что вы поймете плохой.</p><h2>конкретика</h2><p>итак, давайте поговорим подробнее. плагины используют "<em> hooks </em>", которые представляют собой биты кода php, которые запускают определенные точки вдоль пути выполнения, и они могут либо что-то делать, либо фильтровать значение, либо и то и другое. wordpress начинает вызывать хуки раньше, пытаясь создать веб-страницу и генерировать html для отправки в браузер, и продолжает вызывать хуки почти до тех пор, пока он не завершит работу для данной страницы.</p><p>в зависимости от того, какие хуки использует плагин, он может вызываться только на определенных страницах, в "<em> фоне </em>" или даже почти никогда. некоторые хуки работают только в консоли администратора. некоторые хуки работают только на определенных страницах консоли администратора. а некоторые хуки вызываются <a href="http://codex.wordpress.org/function\_reference/wp\_schedule\_event">внутренней системой псевдо-хрон</a> . otoh, некоторые плагины могут загружать дополнительные файлы css или js, и каждый из этих файлов снижает производительность из-за <a href="http://developer.yahoo.com/performance/rules.html">правила веб-производительности №1</a> .</p><p>если вы хотите понять, какие хуки вызываются на каждой странице, рассмотрите возможность использования " <a href="http://gist.github.com/523831"><strong> <em> инструментальных хуков для wordpress </em> </strong></a> "плагин, который я написал для вопроса" <a href="https://wordpress.stackexchange.com/questions/307/where-can-i-find-a-list-of-wordpress-hooks"><strong> <em> где я могу найти список wordpress hooks? </em> </strong></a> "вот снимок экрана того, что плагин показывает в нижнем колонтитуле при использовании:</p><p><img src="https://i.stack.imgur.com/ozw4l.png" alt="screenshot of instrument hooks for wordpress plugin in action"></p><p>но просто знание хуков не поможет вам точно определить, есть ли проблема с плагином. вы можете вызывать плагин 100 раз, и его вызов может быть незначительным по сравнению с другим вызовом ловушки, который добавляет предложение where к запросу sql, который может привести к сбою сайта, содержащего более нескольких сотен постов. или это может сделать http-вызов на другой сервер. или это может сбрасывать правила перезаписи при каждой загрузке страницы. список грехов продолжается.</p><p>единственный реальный способ узнать наверняка, что это - проверить хуки плагина, просмотрев исходный код или лучше запустив его через отладчик, например <a href="http://www.jetbrains.com/phpstorm/">phpstorm + xdebug</a> .</p><h2>ваши собственные плагины</h2><p>не беспокойтесь о том, как организован код <em> для целей производительности </em>; беспокоиться о том, что делает ваш код. <strong> оптимизация часто выполняемого запроса sql </strong> с использованием <a href="http://codex.wordpress.org/transients\_api">переходного api</a> (см .: <a href="http://tayloegray.com/wp-content/uploads/2010/05/transient-api-export.pdf">представление о transient api</a> ) было бы <strong> намного лучше для производительности </strong>, чем объединение кода из 10 плагинов в один.</p><p>с другой стороны, рассмотрите возможность организации вашего кода по другим причинам. я думаю <strong> длинный список плагинов может создать психологический стресс </strong> для многих пользователей; они видят такой экран, ошеломляются и просто хотят упростить вещи:</p><p> <a href="https://i.stack.imgur.com/87kg9.png"><img src="https://i.stack.imgur.com/87kg9.png" alt="long list of plugins"></a> <br> <sub>(источник: <a href="https://mikeschinkel.com/websnaps/skitched-20100819-022735.png">mikeschinkel.com</a> )</sub></p><p><em> с другой стороны </em> иногда пользователи могут быть перегружены, потому что один плагин делает слишком много. например, я чувствовал то же самое с <a href="http://www.gdstarrating.com/">плагином gd star rating</a> . попробовав его в проекте (и, что еще хуже, пытаясь подключить его к тому, чтобы он делал то, что мне нужно), я решил выбросить его на ухо.</p><p>поэтому некоторые люди (например, я) часто предпочитают множество маленьких жестких плагинов, каждый из которых выполняет одну задачу и делает это хорошо (хотя было бы хорошо, если бы wordpress поддерживал функцию группировки, например, как <a href="http://reviews.cnet.com/8301-19512\_7-20008918-233.html">iphone ios 4 позволяет группировать приложения в папки</a> .)</p><p> <a href="https://i.stack.imgur.com/iwoes.png"><img src="https://i.stack.imgur.com/iwoes.png" alt="long list of gd star rating options"></a> <br> <sub>(источник: <a href="https://mikeschinkel.com/websnaps/gd-star-rating-front-page-20100819-023643.png">mikeschinkel.com</a> )</sub></p><p>в любом случае, надеюсь, это поможет.</p>

<p>естественно, плагины - это только одна часть истории производительности, поэтому вы не можете измерить их по количеству файлов в конце. существует больше, и вы не можете заранее сказать, что работает, поэтому то, что может быть хорошо на вашем компьютере, не на других.</p><p>вместо того, чтобы искать производительность, вы должны определить другие и собственные критерии для принятия решений. например, для плагинов вы можете предпочесть поместить отдельные функции в отдельные плагины, чтобы не смешивать вещи. это не всегда может повлиять на производительность с точки зрения скорости или использования памяти, но задача состоит в том, чтобы все было легко соединять, чтобы было легче разрабатывать и использовать плагины. не стоит забывать, что когда выйдет новая версия wordpress, из десяти могут выйти только два плагина, а не один большой постоянно. и, наконец, пользователю нужно всего три из десяти плагинов, поэтому ему нужно меньше памяти.</p><p>если пользователь жалуется на производительность своего блога, вы можете предположить, что он может просто купить сервер побольше, и проблемы с производительностью будут решены.</p><p>(предварительно зрелый) оптимизация - корень всего зла. просто больше не думайте о производительности при написании плагинов. подумайте об этом легким и ярким способом: wordpress в конце концов не спроектирован с точки зрения производительности, не допускайте ошибок и попробуйте написать для него эффективные плагины;)</p><p>wordpress разработан с использованием <a href="http://www.laputan.org/mud/mud.html#bigballofmud">шаблона "большой шарик грязи"</a> . система плагинов хорошо работает с ней. только не думайте, что вы можете оптимизировать так много, как автор плагина. ты не можешь не борись с этим :)</p>

<p>вы можете использовать wordpress с сотнями плагинов, когда дизайн плагинов в порядке - у большинства плагинов плохой код, и это является проблемой производительности wordpress.</p>

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

<p>вы смотрите на 2 вещи, которые замедляют ваш сайт: 1 - обработку файлов на сервер (ы), ваш php и 2 - способ чтения кода при просмотре.</p><p>если код небрежный, браузер дважды или трижды проверит код перед тем, как отобразить его на экране. если вы используете много плагинов с большим количеством запросов к базе данных или серверу, это может занять некоторое время, и если они сделаны неправильно, могут возникнуть конфликты с запросом, которые могут вызвать дополнительное время или хуже, ваш сайт не загружается и/или сообщения об ошибках.</p><p>rfair404 упомянул программы кеширования, которые будут помогать с запросами к серверу, а некоторые будут сжимать html-код, и это напоминает мне, мне нужно сжать некоторые css-страницы.</p>