Бенчмарк версий WordPress: как движок стал в 20 раз тяжелее за 20 лет

Современный WordPress потребляет в 20 раз больше памяти и выполняется в 12 раз дольше, чем его первая версия 2003 года. Это выяснил разработчик, проведя бенчмарк всех поколений CMS — от 1.0 до 7.0. Результаты показывают, что рост функциональности привёл к значительному увеличению нагрузки на сервер,

Бенчмарк версий WordPress: как движок стал в 20 раз тяжелее за 20 лет

Современный WordPress потребляет в 20 раз больше памяти и выполняется в 12 раз дольше, чем его первая версия 2003 года. Это выяснил разработчик, проведя бенчмарк всех поколений CMS — от 1.0 до 7.0. Результаты показывают, что рост функциональности привёл к значительному увеличению нагрузки на сервер, что критично для владельцев сайтов на дешёвом хостинге. В этой статье мы разберём, как менялась архитектура движка, какие версии стали переломными и что делать, чтобы ваш сайт оставался быстрым.

Как проводилось тестирование

Автор использовал чистую установку каждой версии WordPress без плагинов и сторонних тем — только стандартный контент: одна запись, одна страница, один комментарий. Профилирование выполнялось с помощью Xdebug и встроенного таймера PHP. Замерялись три ключевые метрики: пиковое потребление памяти (memorygetpeakusage), время выполнения скрипта (микротайминг) и количество запросов к базе данных (через Shutdown-функцию). Тесты проводились на одном и том же сервере с PHP 8.1 и MySQL 8.0, чтобы исключить влияние окружения. Такой подход гарантирует, что различия в производительности обусловлены только изменениями в коде движка, а не внешними факторами.

Почему версия 1.0 была такой быстрой?

Первая версия WordPress — это практически чистый процедурный PHP без классов и автозагрузки. Она не использует базу данных для кэширования опций, не имеет хуков и фильтров в современном понимании. Фактически, при загрузке страницы выполнялся минимум операций: подключение к БД, выборка записей и рендеринг HTML. Отсутствие абстракций делало код предсказуемым и быстрым, но негибким для расширений. Разработчики того времени сознательно жертвовали модульностью ради производительности, что было оправдано для блогов с низкой посещаемостью.

Технические подробности: рост потребления по версиям

Версия 1.0 показала 2,1 МБ памяти и 0,008 секунды выполнения. Версия 2.0 добавила систему плагинов и хуков, что увеличило память до 3,5 МБ (рост 67%). Версия 3.0 ввела мультисайтовость и обновление ядра — память подскочила до 6,8 МБ. Версия 4.0 принесла новый редактор и улучшенную работу с медиа — 9,2 МБ. Версия 5.0 с Gutenberg (редактор блоков) стала переломным моментом: 18,3 МБ памяти и 0,05 секунд. Версия 6.0 добавила Full Site Editing и ещё больше блоков — 31 МБ. Наконец, версия 7.0 (предположительно 7.0) достигла 40 МБ и 0,1 секунды. Количество запросов к БД выросло с 4 до 25. Таким образом, за 20 лет потребление памяти выросло в 19 раз, время — в 12,5 раз. Эти цифры наглядно демонстрируют, как каждое нововведение увеличивало нагрузку на сервер.

Какие версии WordPress самые ресурсоёмкие?

Самыми ресурсоёмкими оказались версии, вводившие кардинальные изменения архитектуры. Версия 5.0 с редактором Gutenberg увеличила потребление памяти почти вдвое по сравнению с 4.9 — с 9,2 до 18,3 МБ. Версия 6.0 с Full Site Editing добавила ещё 12,7 МБ. Версия 7.0, хотя и не является официальным релизом, в тестах показала 40 МБ. Если вы используете WordPress 6.x, будьте готовы к тому, что даже без плагинов он потребляет около 30 МБ оперативной памяти на страницу. Это означает, что на дешёвом хостинге с лимитом 64 МБ вы сможете запустить не более двух страниц одновременно без риска превышения лимита.

Кого затронет и как

Результаты бенчмарка в первую очередь важны для вебмастеров и владельцев сайтов на WordPress. Если вы используете дешёвый виртуальный хостинг с ограничением памяти (например, 64 МБ), современная версия может исчерпать лимит при установке нескольких плагинов. Разработчикам стоит задуматься о производительности: возможно, стоит отключать неиспользуемые блоки и использовать кэширование. Для бизнеса, работающего на WordPress, это повод пересмотреть бюджет на хостинг: слабые серверы не справятся с трафиком. В российском сегменте, где популярны дешёвые тарифы, проблема стоит особенно остро. Многие владельцы сайтов жалуются на медленную загрузку, не подозревая, что корень проблемы — в самом движке.

Как оптимизировать производительность WordPress?

Чтобы снизить нагрузку на сервер, используйте плагины кэширования, такие как WP Rocket или W3 Total Cache. Они создают статические HTML-копии страниц, уменьшая количество запросов к базе данных. Включите сжатие gzip и настройте CDN для статических файлов. Отключайте неиспользуемые блоки Gutenberg через фильтры или плагины. Регулярно обновляйте ядро и плагины — в новых версиях часто исправляют утечки памяти. Выбирайте хостинг с поддержкой PHP 8.x и достаточным объёмом оперативной памяти (минимум 128 МБ на сайт). Для высоконагруженных проектов рассмотрите VPS или выделенный сервер.

Что будет дальше

WordPress продолжает развиваться в сторону большей функциональности, что неизбежно увеличивает потребление ресурсов. Разработчики ядра осознают проблему: в последних версиях появились улучшения производительности, такие как ленивая загрузка изображений и оптимизация запросов. Однако тренд на рост сохранится. Возможно, появятся «лёгкие» сборки WordPress для простых сайтов. Пока же вебмастерам рекомендуется использовать плагины кэширования, CDN и выбирать хостинг с достаточным запасом памяти. В долгосрочной перспективе можно ожидать, что WordPress станет ещё более требовательным, особенно с внедрением полного редактирования сайта и интерактивных блоков.

Итог

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