Коммиттер WordPress Core Адам Сильверстайн опубликовал предложение по добавлению автоматизированных инструментов производительности , которые будут предлагать непрерывный мониторинг проблем с производительностью, чтобы их можно было решить до того, как основные регрессии будут зафиксированы в ядре.
«Подобно нашему набору модульных тестов, автоматизированное тестирование производительности поможет защитить ядро от значительного снижения производительности за счет немедленного выявления проблем и отслеживания производительности с течением времени», — сказал Сильверстайн. «Автоматизация тестирования также означает экономию усилий участников за счет замены трудоемкого ручного процесса».
Поскольку команда Performance сосредоточена на внедрении новых функций с измеримыми преимуществами, а также на тестировании новых выпусков WordPress перед их выпуском, они случайно обнаружили то, что Сильверштейн назвал «значительным снижением производительности». Несколько примеров включают регрессию, обнаруженную до WP 6.1 в обработке theme.json, и еще одну проблему с изменениями для загрузки текстового домена.
«Автоматизированное тестирование будет обнаруживать этот тип регрессии, как только он будет введен, что значительно упростит его устранение», — сказал он.
Сильверштейн выделил проект Gutenberg как хороший пример отслеживания производительности , поскольку в каждом выпуске публикуются показатели изменения времени загрузки, времени набора текста и времени выбора блока. Команда также начала отслеживать TTFB (время до первого байта) для классических и блочных тем на панели мониторинга состояния кода, что помогает им видеть непосредственное влияние последних коммитов.
«Это делает видимым снижение производительности при рендеринге блочной темы по сравнению с классическими темами для простой страницы «привет, мир», — сказала Эмили Кларк, участник команды WordPress Performance, на последнем собрании команды. «Как команда, мы хотели бы убедиться, что мы правильно расставляем приоритеты для билетов, которые у нас есть для 6.2, которые положительно повлияют на этот показатель — особенно все, что нам нужно, чтобы получить до этапа бета-версии 1 на следующей неделе».
Несколько участников уже работали над улучшением времени отклика сервера для блочных тем с PR, которые должны появиться в версии 6.2.
«Подобно Gutenberg, ядро WordPress будет собирать набор автоматических показателей производительности вместе с существующими тестовыми прогонами (например, модульными тестами, стандартами кодирования), которые у нас уже есть для каждого нового коммита», — сказал Сильверстайн. «Эти метрики можно использовать для точного определения момента, когда регрессия производительности вводится в ядро. На таких этапах, как основной выпуск, показатели можно сравнить с предыдущим выпуском, чтобы оценить прогресс».
Silverstein предлагает WordPress начать с малого, просто запустив набор автоматических тестов для каждой основной фиксации для таких вещей, как время загрузки и общее время запроса для классических и блочных тем. В будущем команда могла бы собирать дополнительные метрики времени сервера и метрики для других контекстов за пределами домашней страницы, таких как административная и одиночная почта.
Реакция на это предложение до сих пор была положительной, поскольку единственная альтернатива — полагаться на то, что отдельные лица вручную выявляют новые узкие места в производительности и сообщают о них. Более совершенные инструменты помогут выявить эти проблемы быстрее, прежде чем они станут доступны миллионам людей.
«Учитывая, какое внимание одноранговые CMS-платформы уделяют «рекламе» своей производительности и сравнению ее с лидерами отрасли, инвестирование в инструменты, обеспечивающие оптимальную работу WordPress, имеет большой смысл», — сказал участник отдела маркетинга WordPress Дэн Сощин. «И, учитывая, сколько сайтов работает на WordPress, даже незначительный прирост производительности (в том числе незаметный для большинства людей) повышает ценность веб-хостов и снижает общую нагрузку на интернет-трафик / пропускную способность».
