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

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

Чтобы показать вам драматизм ситуации, я для примера провёл с помощью профилировщика PHP измерение ресурсозатратности каждой линейки семейства WordPress - это версии 1, 2, 3, 4, 5, 6 и недавняя 7.

Кому интересно, прошу под кат. Увидите, как от первых версий, на которых WordPress завоёвывал славу легковесной блоговой системы, он пришёл в конце концов к многократно утяжелённой платформе по множеству срезов измерения:

• 11-кратно - в плане времени рендеринга страницы;

• 35-кратно - в плане количества файловых подключений (зависимости);

• 36-кратно - в плане потребляемой памяти;

• 40-кратно - в плане размера исходного кода;

• 110-кратно - в плане затрачиваемых тактов препроцессора.

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

Затем продолжу рассказ отдельными параграфами по каждой измеренной мной версии знаменитой CMS с кратким рассуждением о том, как же подобное перепотребление могло произойти.

Подготовка

Исследование перечисленных версий WordPress проведены на одном и том же компьютере офисного сегмента. Чтобы в смысле железа сымитировать ситуацию, словно вы поднимаете сайт на бюджетном хостинге.

Вот моя тестовая конфигурация:

• Процессор AMD Ryzen 5 3600;

• Оперативная память 16 GB 2666 MHz;

• Жёсткий диск Seagate 1 TB 7200 об/с;

• Видеоадаптер NVIDIA GeForce GT 1030 (2 GB);

• Операционная система Windows 10 (версия 22H2);

• Другое программное обеспечение отсутствует.

Установка софта

Дополнительно я установил на компьютер следующую сборку веб-сервера. Она привлекла меня тем, что в один проход ставит на компьютер локальный веб-сервер Apache, препроцессор PHP и сервер баз данных MySQL. Для понятности, номер версии сборки равен номеру версии упакованного в неё PHP:

• XAMPP 8.2.12 for Windows x64;

• XAMPP 5.6.20 for Win32 - так как версии WordPress ниже 6.0 не заводились на сборках версий XAMPP 8+.

В процессе установки этой сборки я выбрал директорию C:\server и сразу отключил ненужные опции (прилагаю скриншот ниже):

• FileZilla FTP Server;

• Mercury Mail Server;

• Tomcat;

• Webalizer;

• Fake Sendmail.

Затем запустил контрольную панель сборки и стартовал оттуда сам веб-сервер и сервер баз данных с помощью кнопки Start (при успешном запуске она меняется на Stop). Показываю скриншот.

Создание баз данных

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

Базам были даны такие имена:

• wordpress_1

• wordpress_2

• wordpress_3

• wordpress_4

• wordpress_5

• wordpress_6

• wordpress_7

Вот как это выглядит на скриншоте:

Скачивание релизов

Далее я скачал с официального сайта WordPress все ZIP-архивы интересующих меня релизов.

Поскольку этих релизов за почти полувековую историю движка было очень много, я выбирал только начальные релизы, то есть где минорное число версии равно 0.

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

• wordpress 1.0 от 3 января 2004

• wordpress 2.0 от 31 декабря 2005

• wordpress 3.0 от 17 июня 2010

• wordpress 4.0 от 4 сентября 2014

• wordpress 5.0 от 6 декабря 2018

• wordpress 6.0 от 24 мая 2022

• wordpress 7.0 от 20 мая 2026

Как оказалось позже, никакой принципиальной необходимости не было. Начиная с линейки 2.x, авторы движка просто отсчитывали 10 минорных релизов (технические релизы не в счёт) и понимали это началом следующей линейки.

Распаковка релизов

Далее в директории C:\server\htdocs, которая теперь одновременно являлась и корнем веб-сервера, я создал следующие одноимённые директории, в каждую распаковал содержимое соответствующего релизного архива. Показываю скриншот.

Установка релизов

Ради быстрой установки распакованных релизов я просто прошёл браузером по следующим URL-ам. В каждом случае запускался автоматический установщик соответствующей версии WordPress:

• http://localhost/wordpress-1.0/wp-admin/install-config.php

  В этом релизе, написанном на очень старой версии PHP, пришлось сначала выполнить следующие замены по всем скриптовым файлам:

  • $HTTP_GET_VARS на $_GET;

  • $HTTP_POST_VARS на $_POST;

  • $HTTP_SERVER_VARS на $_SERVER;

  • $HTTP_COOKIE_VARS на $_COOKIE.

  Иначе установщик не запускался.

• http://localhost/wordpress-2.0/wp-admin/setup-config.php

• http://localhost/wordpress-3.0/

• http://localhost/wordpress-4.0/

• http://localhost/wordpress-5.0/

• http://localhost/wordpress-6.0/

• http://localhost/wordpress-7.0/

Для удобства установки я подготовил заранее следующий набор параметров, чтобы копипастить их в соответствующие поля установочной формы:

• Имя сайта: Hello World!

• Логин админа: tester

• Пароль админа: 123

• Емейл сайта: tester@example.com

Также для удобства я подготовил заранее URL-ы старта установки профилировщика, используемые чуть позже:

• http://localhost/wordpress-1.0/studyLIC-installer.php

• http://localhost/wordpress-2.0/studyLIC-installer.php

• http://localhost/wordpress-3.0/studyLIC-installer.php

• http://localhost/wordpress-4.0/studyLIC-installer.php

• http://localhost/wordpress-5.0/studyLIC-installer.php

• http://localhost/wordpress-6.0/studyLIC-installer.php

• http://localhost/wordpress-7.0/studyLIC-installer.php

Добавление профилировщика

И наконец, в каждую из директорий я добавил файл профилировщика, взятый из его репозитория. Вот понадобившийся мне файл:

• studyLIC-installer.php

Если вы ещё не знаете, для какой цели нужен этот полезный скрипт, отправляю вас прочесть статью "Профилировщик CMS-движков для вебстудий".

О точности

Хочу заранее предупредить, что числа измерений ниже в статье не являются кристально точными до байта и миллисекунды.

Дело в том, что касаемо времени, подобные замеры всегда "плавают" в некотором диапазоне, и могут зависеть как от использованного компьютерного железа, так и от числа системных процессов в операционке, проходящих сейчас в параллель с измерением. Есть также зависимость от того, был ли старт измерения сделан из холодного состояния или в "прогретом" (из повторного), то есть когда программные модули веб-сервера и препроцессора уже подгрузились в память компьютера.

Вы можете заметить это "плавание" времени, когда в браузере последовательно обновляете измеряемую страницу под профилировщиком.

То же самое и в отношении ОЗУ - небольшие скачки потребления памяти в пределах килобайтов наблюдаются при старте из холодного и прогретого состояний.

Имеется и такой нюанс касаемо ОЗУ. Версия использованного мной профилировщика разделяет с измеряемой страницей ту же область памяти, а значит хранит там свои промежуточные данные измерений и буферизирует туда же вывод измеряемой страницы. То есть в измеряемый расход ОЗУ невольно попадает часть килобайт, выделенных препроцессором под распарсенный код и промежуточные данные самого профилировщика.

Например, распарсенный код профилировщика занимает примерно 2 килобайта. Объём его промежуточных данных зависит от длины цепочки подключаемых скриптовых файлов измеряемой страницы и байтового размера генерируемой ей HTML-разметки.

Поэтому я буду ниже скриншотить цифры как есть, а в рассуждениях округлять до тысяч (килобайта по системе единиц МЭК) или миллиона (мегабайта), как бы намекая на примерность измерений профилировщиком.

Алгоритм исследования

Можно было, конечно, смоделировать нагрузку, близкую к реальным блоговым сайтам, загрузив в каждую испытуемую версию базу данных из сотен новостных постов и множества комментариев к ним.

Но меня интересовало измерить работу версий WordPress при самой минимальной нагрузке. Так сказать, только в режиме "Hello World". То есть когда сам движок при первой установке создал себе демонстрационную базу данных с единственным приветственным постом и единственным комментарием.

Поэтому в качестве подопытного URL я избрал главную страницу сайта, открываемую сразу после успешной установки движка. Итак, вот мой алгоритм:

1. Открыть в браузере URL главной страницы.

2. Сделать для отчёта её скриншот.

3. Запустить там скрипт профилировщика.

4. Сделать для отчёта дамп результата его установки.

5. Открыть тот же URL главной, только теперь под профилировщиком.

6. Сделать для отчёта дамп результатов измерения.

7. Сделать для отчёта ещё и их скриншот.

8. Повторить шаги 1-7 для каждой исследуемой версии WordPress.

А все скриншоты и дампы я решил сложить в папку reports этих репозиториев:

• на GitHub;

• на GitFlic (Россия).

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

Итак, начинаем исследование...

WordPress 1.0

Эта версия, изданная 3 января 2004 года, была всего лишь очередной модификацией линейки WordPress 0.7x, которая в свою очередь являлась форком блогового движка b2/cafelog, разработанного 22-летним корсиканцем Михелем Валдриги (Michel Valdrighi) в июне 2001 года как простенькая альтернатива сложным блоговым системам наподобие Frontier NewsPage, Blogger, TextPattern, Greymatter, Movable Type.

В силу молодости Михель не имел каких-то особых навыков в проектировании блоговых движков, поэтому разработку вёл как умел, без погружения в вопрос архитектуры проекта. Когда же ему пришлось оставить это дело по жизненным обстоятельствам, разработку подхватили 19-летний американец Мэтью Мулленвег (Matthew Mullenweg) и 42-летний британец Майк Литтл (Mike Little), но уже как собственный форк корсиканского движка.

Однако форк - это не то. Скорее всего Мэтью, как пока что основному контрибьютору кода, хотелось некоего дистанцирования от такого понятия, с которым неизбежно ассоциировалась ответвившаяся и по программному коду и по продуктовому названию линейка WordPress 0.7x. Поэтому и возникла версия 1.0, как бы знаменуя собой ключевой поворот истории, хотя из сколько-нибудь значимых новых фишек реализованными были только эти:

• человеко-понятные постоянные ссылки;

• возможность прикрепить пост к нескольким категориям;

• браузерный установщик (настройка файла wp-config.php);

• модерация комментариев.

Такой минимальный функционал как раз и определил за WordPress звание лёгкого движка. Давайте удостоверимся в том на измерительном стенде.

Замеряем версию

Для начала я открыл главную страницу, чтобы убедиться, что всё ОК. Сделал скриншот.

Теперь согласно подготовленным ранее URL-ам, запустил там же скрипт профилировщика и сделал дамп результата установки.

Так как эта версия движка была запущена на PHP 5.6.2, а профилировщик требует PHP номером выше, я применил к профилировщику межверсионный багфикс. А именно, открыл файл профилировщика в текстовом редакторе, выделил 3 начальные инструкции, требующие замены, заменил их текстом багфикса и сохранил файл назад.

Показываю эту процедуру на 2 скриншотах. Первый скрин показывает, какие 3 инструкции я выделил.

Второй скрин показывает, каким фиксом я заменил те инструкции.

Далее открыл ту же главную страницу под профилировщиком, сделал скриншот (он ниже), сделал также дамп результатов измерения.

Рассуждаем

Пока нам не с чем сравнивать, поэтому просто пройдёмся по числам скриншота. При рендеринге страницы использован всего 1 мегабайт ОЗУ, цепочка зависимостей состоит из 14 подключенных скриптовых файлов общим размером исходного кода в 255 килобайт, количество потраченных тактов препроцессора равно 4287.

Основными пожирателями памяти стали файлы:

• wp-includes/template-functions.php (+314 килобайт);

• wp-includes/functions.php (+288 килобайт);

• wp-includes/class-xmlrpc.php (+142 килобайта).

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

Теперь сравним результат со следующей линейкой...

WordPress 2.0

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

Вдобавок Мэтью совершает ещё одну ошибку, принёсшую свою долю сумятицы в стройность исходного кода. Он доверился инициативной дизайнерской группе под названием Shuttle, состоящей из участников комьюнити движка, в том что они хорошо и продуманно редизайнят админпанель WordPress за 3 месяца. Но в группе снова большинство оказалось любителей, и процесс пошёл вкось, неоднократно отодвигая результат на поздний срок. О чём Мэтью досадно выскажется позже: "то мрачный период в истории разработки WordPress, потерянный год".

А когда версия наконец вышла, то имела следующие реализованные фишки:

• новый дизайн бекенда от группы Shuttle;

• интегрирован визуальный редактор постов;

• роли пользователей;

• кастомизация шапки сайта;

• встроенное кэширование для снижения нагрузки на сайт;

• введение хелпера (файл functions.php) в тему сайта;

• интегрирован антиспамный плагин Akismet;

• исправлены сотни и сотни багов (это не шутка, именно так было анонсировано авторами).

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

Замеряем версию

Вот дамп установки профилировщика.

Эта версия движка запущена на PHP 5.6.2, поэтому я снова применил тот же межверсионный багфикс, что описывал в предыдущем параграфе.

Вот ниже скриншот и вот ссылка на дамп измерения.

Рассуждаем

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

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

Логично также, что одновременно с удвоением цепочки файловых подключений возрос и байтовый размер этой цепочки - рост с 255 до 400 килобайт. Что неизбежно потянуло за собой увеличение использованного ОЗУ, так как интерпретатор PHP парсит и хранит подгруженные файлы в памяти. А весь прирост использованного ОЗУ составил +940 килобайт в сравнении с версией WordPress 1.0.

Основными пожирателями памяти стали следующие файлы. Так сказать, запишем их рейтинг ТОП-5:

• wp-includes/functions.php (+334 килобайта);

• wp-includes/classes.php (+255 килобайт);

• wp-includes/functions-formatting.php (+196 килобайт);

• wp-includes/comment-functions.php (+143 килобайта);

• wp-includes/functions-post.php (+129 килобайт).

WordPress 3.0

Анонсируя этот тринадцатый по счёту релиз WordPress, Мэтью писал, что основными нововведениями стали новая тема Twenty Ten, функционал для централизованного управления множеством блогов из одной админпанели WordPress, новые API для пользовательских фонов, заголовков, коротких ссылок, типов записей, таксономий и вывода меню.

Однако упоминание там же о большом множестве исправленных багов (их реально оказалось много, смотрите сами - список дефектов оканчивается на 906-й позиции), а также что релиз стал кульминацией полугодовой работы 218 контрибьюторов, навевало печальную мысль, что качество и оптимальность исходного кода всё продолжает падать со времён предыдущей линейки.

Эту мысль подпитывали и события, творящиеся в сообществе WordPress. Дело в том, что примерно через 3 года после появления движка его контрибьюторы стали выражать недовольство - их коммиты проходили через ревизию Майком или Мэтью, и множество отклонялись как неудовлетворяющие виденью проекта.

Не встретив понимания со стороны автократичного Мэтью, группа недовольных контрибьюторов форкнула текущую версию WordPress под новым именем Habari и стала развивать по правилам меритократии: ревизией коммитов занимается наиболее коммитящий в текущий момент, независимо от его уровня знаний, происхождения и достатка. Проект просуществовал с февраля 2007 года почти 12 лет, пока не был брошен в 2019 году.

Но страшны ведь не творческие раздоры, сколько ответ на вопрос, какого же уровня те разработчики, кто контрибьютит в ядро движка. Не хочу кидать упрёки в чей-то персональный адрес, кто был замечен в любительском подходе, просто подчеркну, что таких случаев среди контрибьюторов WordPress было предостаточно: некоторые ребята только придя на проект впервые сталкивались как с PHP, так и с разработкой вообще.

Ну что ж, давайте измерим на стенде, к чему привёл такой совместный вклад.

Замеряем версию

Вот дамп установки профилировщика.

Эта версия движка запущена на PHP 5.6.2, поэтому я снова применил межверсионный багфикс.

Вот ниже скриншот и вот ссылка на дамп измерения.

Рассуждаем

По сравнению с предыдущей линейкой видим 10-кратное возрастание потраченных тактов препроцессора - 33 тысячи против прежних 3,3 тысячи. Ладно, это объяснимо: за 4,5 прошедших года разработки в ядро движка накидали разного функционала - вот и выросла последовательность исполняемых инструкций PHP.

В 2,5 раза выросла цепочка зависимостей - 73 подключаемых скриптовых файла общим объёмом 1,9 мегабайта против прежних 28 файлов объёмом всего 400 килобайт. Объём получился почти в 5 раз больше.

Соответственно, это потянуло за собой неизбежный рост использованного ОЗУ - 7,4 мегабайта против прежнего 1,9 мегабайта, что в 3,7 раза больше. А основными пожирателями памяти стали файлы, отображённые в следующем рейтинге ТОП-10:

• wp-includes/post.php (+526 килобайт);

• wp-includes/functions.php (+471 килобайт);

• wp-includes/formatting.php (+421 килобайт);

• wp-includes/query.php (+341 килобайт);

• wp-includes/general-template.php (+275 килобайт);

• wp-includes/link-template.php (+264 килобайта);

• wp-includes/comment.php (+223 килобайта);

• wp-includes/classes.php (+177 килобайт);

• wp-includes/comment-template.php (+177 килобайт);

• wp-includes/rewrite.php (+175 килобайт).

WordPress 4.0

После линейки 3.x, которая состояла из 10 релизов, прошло в общем 4 года и, наконец, наступил черёд линейки 4.x. Которая, к слову сказать, тоже будет состоять из 10 релизов и займёт целых 3 года разработки.

Но сейчас давайте вообразим, будто на дворе только 4 сентября 2014 года, и значит только-только вышел первый релиз линейки 4.x. Какими-то особыми изысками эта версия WordPress не запомнилась, а посвящена была бесшовной работе с контентом, удобной работе с медиа-хранилищем и видео-вставками.

Ну и отпечаталось также в анонсе, что над этой версией работало уже 275 контрибьюторов (против прежних 218), и значит, предполагая сохранение старой тенденции к лишнему потреблению ресурсов, можно ожидать, что эта версия поведёт себя пропорционально разнице участников.

Кстати, количество исправленных багов тоже немалое - список обнаруженных дефектов заканчивается на 533 позиции.

Ну что ж, давайте обратимся к измерительному стенду.

Замеряем версию

Вот дамп установки профилировщика.

Эта версия движка запущена на PHP 5.6.2, поэтому опять применил межверсионный багфикс.

Вот ниже скриншот и вот ссылка на дамп измерения.

Рассуждаем

Итак, вот сравнение прироста потребления ресурсов сайта этой версией WordPress. Напомню, увеличение численности контрибьюторов составило 1,26 раза:

• такты препроцессора выросли в 1,5 раза (50 тысяч против 33 прежних);

• цепочка зависимостей - в 1,26 раза (92 файла против 73 прежних);

• размер зависимостей - в 1,45 раза (2,8 мегабайта против 1,9 прежнего);

• использование ОЗУ - в 1,33 раза (9,8 мегабайта против 7,4 прежних);

• время рендеринга - в 1,24 раза (130 миллисекунд против 104 прежних).

В общем, можно сказать, какие-то закономерности у такого стиля совместной разработки есть.

Давайте ещё запишем ТОП-5 основных пожирателей памяти в этой версии:

• wp-includes/post.php (+565 килобайт);

• wp-includes/formatting.php (+497 килобайт);

• wp-includes/query.php (+456 килобайт);

• wp-includes/functions.php (+448 килобайт);

• wp-includes/taxonomy.php (+404 килобайта).

WordPress 5.0

Эта версия вышла 6 декабря 2018 года. Главными фишками в ней стали новая тема Twenty Nineteen и новый блочный редактор Guttenberg, работающий пока что только в режиме редактора постов.

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

Замеряем версию

Вот дамп установки профилировщика.

Эта версия движка запущена на PHP 5.6.2, поэтому снова применил межверсионный багфикс.

Вот ниже скриншот и вот ссылка на дамп измерения.

Рассуждаем

Сравнение прожорливости этой версии относительно предыдущей линейки WordPress. Как и следовало ожидать, показания коррелируют с количеством контрибьюторов:

• число участников увеличилось 1,53 раза (473 человека против 275 прежних);

• такты препроцессора выросли в 1,75 раза (87 тысяч против 50 прежних);

• цепочка зависимостей - в 2,16 раза (199 файлов против 92 прежних);

• размер зависимостей - в 1,72 раза (4,8 мегабайта против 2,8 прежних);

• использование ОЗУ - в 1,63 раза (16 мегабайт против 9,8 прежних);

• время рендеринга - в 1,55 раза (201 миллисекунда против 130 прежних).

ТОП-10 основных пожирателей памяти в этой версии:

• wp-includes/formatting.php (+864 килобайта);

• wp-includes/post.php (+630 килобайт);

• wp-includes/functions.php (+553 килобайта);

• wp-includes/class-wp-query.php (+431 килобайт);

• wp-includes/script-loader.php (+422 килобайта);

• wp-includes/general-template.php (+416 килобайт);

• wp-includes/pluggable.php (+412 килобайт);

• wp-includes/taxonomy.php (+396 килобайт);

• wp-includes/media.php (+389 килобайт);

• wp-includes/l10n.php (+376 килобайт).

WordPress 6.0

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

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

Косвенно на эту же невидимую борьбу указывала и приведённая в анонсе цитата из речи исполнительного директора Жозефы Хаден Чомфоси (Josepha Haden Chomphosy) о том, что столь длительное по времени (ведь серия релизов линейки 5 отняла 3,5 года разработки) расширение возможностей Gutenberg до полноценного редактора сайтов означало, что все проблемы, которые приходилось решать сообществу, были сложными и масштабными. И шестая версия как раз явилась примером того, как сообщество совместными усилиями решает эти сложные задачи.

Фух, ну наконец-то можно спокойно вздохнуть и ожидать хороших результатов. Что ж, тогда идём с радостным настроением к измерительному стенду.

Замеряем версию

Вот дамп установки профилировщика.

Вот ниже скриншот и вот ссылка на дамп измерения.

Рассуждаем

Ожидания не оправдались. Вчетверо выросли такты препроцессора - до 366 тысяч. Цепочка зависимостей снова увеличилась вдвое - до 403 файлов. А использование ОЗУ стало требовать уже более 2 десятков мегабайт.

ТОП-10 основных пожирателей памяти в этой версии:

• wp-includes/formatting.php (+959 килобайт);

• wp-includes/functions.php (+943 килобайта);

• wp-includes/post.php (+784 килобайта);

• wp-includes/user.php (+752 килобайта);

• wp-includes/pluggable.php (+582 килобайта);

• wp-includes/l10n.php (+521 килобайт);

• wp-includes/script-loader.php (+510 килобайт);

• wp-includes/media.php (+497 килобайт);

• wp-includes/sodium_compat/src/Compat.php (+482 килобайта);

• wp-includes/link-template.php (+468 килобайт).

WordPress 7.0

Майский анонс 2026 года седьмой линейки WordPress назвал эту версию новой эрой, закладывающей основу для использования искусственного интеллекта во всём движке. В общем, в созвучии с нынешней модой ИИ правит бал во всём...

В анонсе также сказано:

WordPress 7.0 отражает неустанные усилия и энтузиазм более чем 875 контрибьюторов из разных стран мира. В этом релизе также приняли участие более 200 новых контрибьюторов!

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

Вау, какое красивое бла бла бла. Ну тогда давайте на стенде измерим результат этой мощи и возможностей сообщества. Может и вправду симбиоз движка с ИИ улучшит положение дел.

Замеряем версию

Вот дамп установки профилировщика.

Вот ниже скриншот и вот ссылка на дамп измерения.

Рассуждаем

Это уже не смешно. 367 тысяч тактов, более полусекунды рендеринг, 496 зависимостей объёмом 10 мегабайт, более 3 десятков мегабайт ОЗУ использовано - и это только чтобы вывести главную страничку навроде простого примера Hello World.

Обескураживает также и факт, что для этой версии, которая вышла всего-то недавно, уже насчитывается 315 обнаруженных дефектов.

А вот и ТОП-10 основных пожирателей памяти:

• wp-includes/taxonomy.php (+1 мегабайт);

• wp-includes/functions.php (+1 мегабайт);

• wp-includes/formatting.php (+1 мегабайт);

• wp-includes/post.php (+811 килобайт);

• wp-includes/l10n.php (+645 килобайт);

• wp-includes/deprecated.php (+629 килобайт);

• wp-includes/html-api/class-wp-html-processor.php (+600 килобайт);

• wp-includes/script-loader.php (+578 килобайт);

• wp-includes/media.php (+569 килобайт);

• wp-includes/general-template.php (+558 килобайт).

Что же дальше?

Наверняка мир от озвученных выше цифр не рухнет, и WordPress продолжит своё пухнущее шествие под незаслуженным лозунгом "Code Is Poetry" (перевод: Код это поэзия).

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

В общем-то, это возможно, но я представляю себе, какая весомая мотивация должны быть у такого человека, чтобы воплотить мечту "Let's make WordPress great again!" (перевод: Сделаем WordPress снова великим!).