Plugin performance profiler ( p3) — измеряем скорость загрузки плагинов

Plugin performance profiler ( p3) — измеряем скорость загрузки плагинов

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

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

Скорость загрузки плагинов — дело не только в количестве

Признайтесь, вы когда-нибудь задавались целью узнать скорость загрузки того или иного плагина? Перед установкой мы в лучшем случае поинтересуемся весом новобранца, посокрушаемся, дескать, вот еще один нахлебник на нашу голову и….все равно его установим. Изначально ядро движка Вордпресс вообще не обременено никакими “довесками”, а потому любой новорожденный блог загружается, как правило, очень шустро. Но вот кому он нужен в таком первозданном виде? Ни о какой функциональности блога речь, в таком случае, не идет, поскольку именно плагины добавляют массу полезных и совершенно необходимых ему функций – от удобочитаемых дат до красочных фотогалерей. Разумеется, плагин плагину рознь. Есть достаточно «тяжелые» плагины, есть криво написанные, конфликтные, не желающие уживаться с уже сформировавшимся коллективом. Если установленный вами плагин подпадает под одну из этих категорий — просто поищите ему замену.

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

Кстати, еще один довод в пользу плагинов, что называется, из собственного опыта. Недавно я нашла довольно симпатичную тему для блога и, разумеется, мне сразу же захотелось сменить надоевший дизайн. Но! Поскольку на моем блоге была проведена оптимизация и некоторые плагины заменены кодами в файлах темы, то теперь я как раб к галере прикована к используемому мною шаблону. В противном случае, мне придется либо забыть о бессмысленно потраченной сумме (оптимизацию я заказывала), либо заплатить еще раз. Что же касается скорости загрузки блога — честное слово, разницы я не заметила.

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

Рlugin performance profiler ( p3) — расскажет о каждом

К счастью, существует плагин, специально призванный заложить своих товарищей на предмет – кто сколько ест? Пишу и самой смешно – борьба за экономию начинается с установки очередного плагина! Однако, если учесть, что пребывание его в активном состоянии не превысит и получаса (в неделю, месяц…), а пользу он принесет вполне ощутимую, то установить его, конечно же, стоит. Зовут его wordpress plugin performance profiler ( p3 ), и его основная задача – определить время загрузки каждого установленного на блоге плагина, показав результаты не только в цифрах, но и в графическом варианте.

Установка плагина стандартная. Сразу после активации он появится в админке в разделе Инструменты. Но, прежде чем приступить к первому сканированию, необходимо изменить атрибуты для каталога «p3-profiler». Другими словами, выставить права доступа 777 — это если вы хотите сохранять полученные вами результаты. Для этого используем FTP Client, соединяемся с сервером и вносим необходимые изменения, открыв папку plugins. Если сохранять результаты вы не собираетесь – можно этого не делать.

Выбираем новые атрибуты для каталога

Чтобы запустить процесс сканирования, нужно нажать на кнопку Start Scan

Кнопка для запуска сканирования и в выпадающем окне выбрать либо ручное, либо автоматическое сканирование — Аuto Scan.

Автоматическое сканирование

Затем немного подождать, пока оно завершится, после чего нажать на кнопку View Results.

Результаты сканирования

Что же означают полученные результаты?

Для начала рассмотрим панель с основными результатами сканирования:

Основные результаты сканирования крайняя цифра слева – количество активных плагинов на вашем блоге; рядом – время, понадобившееся на их загрузку; процент от общей скорости загрузки блога, приходящийся на долю всех установленных плагинов – цифра правее; крайняя справа — цифра, определяющая количество запросов к базе данных.

Полученный результат оказался неожиданным. А именно — жадность плагина Contextual Related Posts, захватившего львиную долю диаграммы, свидетельствует о его ненормально высоком влиянии на загрузку блога.

Жадность плагина Related Posts

Второе место принадлежало плагину по проверке ссылок Broken Links Cheker. Как правило, в активном состоянии он находится достаточно редко, но вот это был как раз тот случай. После его деактивации процедура была повторена еще раз. Результат оказался предсказуемым.

Скорость загрузки без плагина Broken Links Cheker

В сравнение с Related Posts данный плагин — просто скромник, тем более нет никакой необходимости держать его постоянно активным. Зато прожорливость Contextual Related Posts стала еще более очевидной – противопоставив себя остальным 16-и плагинам, он занял практически всю площадь диаграммы.

Эксперимент надо было довести до конца, поэтому я деактивировала плагин Contextual Related Posts и получила просто блестящие результаты:

Результаты сканирования без плагина Related Posts

0,046 — время в секундах, которое тратится на загрузку всех плагинов при просмотре блога. Идеально, если показатель этот не превышает 0,1 секунды;

14,2 — время, затраченное на загрузку плагинов относительно общего времени загрузки сайта;

38 — количество запросов к Базе данных за время загрузки сайта.

Думаю, здесь даже комментарии излишни: это тот самый случай, когда одна паршивая овца портит все стадо. 16 плагинов честно выполняют свою работу, не тормозя загрузку блога, и только один Contextual Related Posts никуда не торопится. Вот это и есть то самое бесспорное доказательство, обещанное в начале статьи: не в количестве дело, а в качестве или в особенностях того или иного плагина, грузящего блог в несколько раз больше, чем 16 остальных. Тем более, на моем блоге он даже миниатюры не выводит.

Что еще интересного можно найти в настройках plugin performance profiler ( p3 )?

Если во вкладке «Runtime by Plugin» в круговой диаграмме навести курсор на элемент, соответствующий определенному плагину, то можно узнать время загрузки конкретного плагина ( желательно, чтобы оно не превышало доли секунды);

Вкладка Runtime by Plugin

«Detailed Breakdown» – вкладка для желающих узнать все о времени загрузки плагинов, используемой темы оформления или ядра Вордпресс (в чистом виде) относительно общего времени, затраченного на загрузку страниц (ориентир — желтая линия сверху);

Detailed Breakdown

«Summary Timeline» — время, потраченное на загрузку самого движка, темы и плагинов. На скриншоте видно, какова доля плагинов и темы оформления — она просто ничтожна;

Вкладка Summary Timeline

«Detailed Timeline» – затраты времени на загрузку страницы. Отдельно указывается время загрузки каждого плагина, темы оформления и ядра Вордпресс. При наведении курсора на точки диаграммы высвечивается адрес соответствующей страницы блога;

Вкладка Detailed Timeline

«Query Timeline» – здесь можно узнать количество обращений к Базе данных при загрузке каждой страницы блога (какая разительная разница С и БЕЗ плагина Contextual Related Posts);

Вкладка Query Timeline

«Advanced Metrics» – общие сведения о времени загрузки сайта, плагинов, использование памяти и много чего еще. С помощью переводчика от Гугл все это не будет для вас проблемой.

Поскольку мой блог предназначен, в первую очередь, для начинающих, хочу сразу оговориться: сделанные в статье выводы не стоит воспринимать, как руководство к действию. Мне данная мысль показалась достаточно интересной, и на моем блоге ей нашлось разумное подтверждение. Кто-то, опираясь на собственный опыт, возразит, и будет по-своему прав. А кому-то скорость загрузки плагинов и вовсе может показаться ерундой, внимания не заслуживающей. Вольному воля. И все же попробуйте протестировать имеющиеся у вас плагины с помощью plugin performance profiler ( p3 ) — это позволит вам принять взвешенное решение по дальнейшему их использованию.


Карта сайта


Информационный сайт Webavtocat.ru