Yoast и основные участники WordPress, спонсируемые Google, предлагают добавить в проект группу производительности для повышения производительности ядра, измеряемой метриками Google Web Vitals .
«Пользователи ожидают и предпочитают быстрые впечатления (сознательно или иначе)», – сказал Ари Статопулос, постоянный основной участник, спонсируемый Yoast. «Исследования показывают, что быстрые веб-сайты могут улучшить взаимодействие с пользователем, повысить вовлеченность, улучшить SEO, повысить конверсию и быть более экономичными и экологически чистыми».
Нет сомнений в том, что пользователи ожидают повышения производительности и могут извлечь из этого выгоду, но на любом сайте WordPress действует ряд переменных. С точки зрения производительности ядра Статопулос сказал, что WordPress не выдерживает конкуренции.
«По сравнению с другими платформами (например, Wix, Shopify, Squarespace) WordPress отстает», – сказал он. «Другие платформы в среднем быстрее – и становятся все быстрее – чем веб-сайты WordPress (см. Отчет Core Web Vitals от The HTTP Archive ), и активно инвестируют (и продвигают ) основную производительность как функцию [ 1 , 2 ]. ”
HTTP Archive, который предоставляет общий набор данных для тех, кто проводит исследования производительности сети, обнаружил, что только 21,5% оцениваемых сайтов имеют хорошие показатели Core Web Vitals по состоянию на сентябрь 2021 года. Хотя этот процент со временем растет, конкуренты, которые уже опережают конкурентов. Сайты WordPress также быстро улучшают свои оценки. Статопулос описал это как «увеличивающийся разрыв» между WordPress и другими платформами.
Одна из основных проблем заключается в том, что владельцы сайтов WordPress имеют большую свободу использовать любые темы и плагины, которые они хотят, на своих сайтах, что затрудняет работу с производительностью по сравнению с размещенными платформами, указанными для сравнения. В предложении говорится, что «достижение разумных уровней производительности должно быть не территорией подключаемых модулей, а частью ядра» и что конечные пользователи не должны становиться экспертами по производительности.
«Достижение высокого уровня производительности требует, чтобы технические соображения были« встроены »во весь стек; и поскольку это часто не относится к темам / плагинам, решения для повышения производительности ограничиваются решениями для повышения производительности по сравнению с неэффективным поведением (например, буферизацией вывода) », – сказал Статопулос.
Предложение вызвало сильный отклик со стороны участников, консультантов по SEO и представителей хостинговых компаний, которые предложили помощь и предложения.
Ведущий разработчик WordPress Марк Джакит, который проявляет особый интерес к этой теме, сказал, что самые большие проблемы, которые он видит сегодня, связаны с производительностью внешнего интерфейса и конвейером ресурсов:
WordPress не имеет (прямой) поддержки для отложенной загрузки стилей. У него нет системы для критических стилей темы. Для JavaScript, он не имеет никакой поддержки defer, async, type=”module”или nomodule. По умолчанию все скрипты загружаются в заголовок. Сам WordPress запихивает свой дополнительный код для эмодзи и библиотеку блоков в заголовок. WordPress внедряет JS-код и стили, которые полностью избегают конвейера ресурсов и напрямую прикрепляются к wp_head и wp_footer. Плагины просто блокируют специальные теги скриптов, которые сложно изменить. К тому времени, как вы добавили на свой сайт 10 плагинов, ваши шансы на загрузку jQuery (в заголовке) при каждой загрузке страницы чрезвычайно высоки. Никто не заинтересован в том, чтобы быть хорошим гражданином (включая сам WordPress), потому что всегда есть кто-то, кто загрязняет окружающую среду хуже, чем вы. «Если jQuery уже поставлен в очередь чем-то другим, думаю, мне лучше его использовать».
Резюме Джаквита описывает более широкую проблему экосистемы и завершается отрезвляющим предупреждением.
«Это огромная проблема, и для ее решения потребуется много усилий, силы воли и времени», – сказал он. «Это того стоит. Если производительность веб-интерфейса WordPress продолжит снижаться, проект перестанет быть жизнеспособным вариантом для любого сайта, который заботится о своей поисковой выдаче ».
Один из консультантов по производительности WordPress, Эроан Бойер, предложил добавить специальный инструмент на экран «Состояние сайта», который бы показывал, сколько JS и CSS загружено на каждый тип страницы (первая страница, сообщение, страница, CPT) и откуда они возникли.
«Я много работал над установлением происхождения данного скрипта или таблицы стилей в контексте подключаемого модуля AMP», – сказал инженер Google Уэстон Рутер. «Я не знаю, подойдет ли реализация в подключаемом модуле AMP для ядра, но меня интересует это пространство.
«Если мы сможем соотнести происхождение данной разметки с (негативным) влиянием на производительность страницы, тогда мы сможем выделить проблемные темы и плагины, чтобы обеспечить некоторую ответственность за то, что добавляется во внешний интерфейс».
Инженер Gutenberg Риад Бенгелла в августе опубликовал исследование, посвященное влиянию производительности плагинов на редактор . Основными нарушителями среди популярных плагинов были WooCommerce, Yoast SEO и Jetpack. Это еще один аспект производительности, который больше влияет на пользователей WordPress, чем на посетителей сайта. Веб-разработчик Такис Буйурис предложил создать структуру производительности, которой могли бы следовать разработчики плагинов, чтобы не создавать продукты, которые негативно влияют на производительность ядра, как во внешнем интерфейсе, так и в админке.
Пока что предложение не получило каких-либо серьезных возражений, и участники, похоже, готовы помочь любым возможным способом. Статопулос сказал, что следующим шагом будет создание канала Slack, расписания встреч и места на make.wordpress.org. Как только инфраструктура будет создана, участники могут приступить к тестированию производительности, определению критериев успеха и определению приоритетных проектов для улучшений Core Web Vitals.
