Эксперимент: разворачиваем сайт на JAMstack и сравниваем с WordPress

Эксперимент: разворачиваем сайт на JAMstack и сравниваем с WordPress

01 июня 2026
10 минут
#
Опыт экспертов

Эксперимент: разворачиваем сайт на JAMstack и сравниваем с WordPress

Мы в ispmanager опробовали бессерверный подход к веб-разработке JAMstack: развернули сайты на этой технологии и сравнили производительность с аналогичным проектом WordPress. В статье расскажем, какая технология лучше в скорости отдачи контента: JAMstack или WordPress.

Что такое JAMstack простыми словами

JAMstack – это подход к веб-разработке, когда сайт заранее собирается в статические файлы и обслуживается через CDN. Такая архитектура делает сайт быстрее, стабильнее и безопаснее, чем классические CMS. Ключевая идея JAMstack в отсутствии сервера, который рендерит страницы в момент запроса. Все страницы сайта генерируются один раз во время сборки, а не динамически при каждом запросе пользователя. Технология подходит для проектов с преимущественно статическим контентом, где важна скорость загрузки: базы знаний, Wiki, API-документация, лендинги и товарные каталоги, портфолио и резюме.

JAMstack основан на трех принципах, зашифрованных в его названии:

  • JavaScript – вся динамика реализуется на клиенте.
  • APIs – данные поступают через внешние API.
  • Markup – страницы генерируются заранее в статические HTML-файлы.

Сборка страниц и отдача контента пользователю происходит так:

Разработчик коммитит изменения → Автоматическая сборка → Генерация всех HTML-страниц → Загрузка на CDN → Пользователь получает HTML из CDN  

Ответ на запрос пользователя должен поступить почти мгновенно, ведь готовый HTML уже лежит где-то на ближайшем CDN-сервере. Мы решили проверить, действительно ли все будет работать так быстро, и проверили стрессовое тестирование JAMstack.

Выбираем платформу для JAMstack

Существует довольно много платформ с поддержкой JAMstack. Большинство из них предполагает структуру SaaS панели на сайте проекта для разработки блога, сайта и деплоя на специализированных CDN хостингах: Vercel, Netlify, AWS Amplify, Cloudflare. Ни один из вышеперечисленных проектов не подходил, поскольку нашей задачей было развернуть блог на собственном сервере с ispmanager. После долгих поисков остановились на инструменте Prismic. 

Prismic — это сервис для создания сайтов, где контент отделен от дизайна и отдается через быстрый API на статические фронтенды, например, Next.js.  

Сайты на Prismic из кусочков-слайсов. Это переиспользуемые компоненты (например, тексты, изображения, галереи), которые можно комбинировать для быстрой сборки страниц.  

Создаем сайт на JAMstack

Для нашего JAMstack-проекта в панели ispmanager был создан сайт с Node.js обработчиком последней доступной версии 25.5.0 и настроен для работы с Next.js приложениями, как описано в статье Установка Next.js в ispmanager 6.

Большинство Next.js проектов запускаются на 3000 порту, поэтому было внесено изменение в конфиг ispmanager  — порт по умолчанию 10000 заменили на 3000:

# grep NodeJsBackendBind /usr/local/mgr5/etc/ispmgr.conf
NodeJsBackendBind 127.0.0.1:3000

На prismic.io был создан аккаунт с бесплатным тарифом и развернут репозиторий нашего проекта с именем ispmanager. Там удобно показана пошаговая инструкция по развертыванию проекта и DevTool slicemachine внутри него. 

Здесь iii8 — название тестового репозитория, в нашем случае ispmanager.

Интерфейс для создания проекта в Prismic c инструкцией
Интерфейс для создания проекта в Prismic c инструкцией

 

Запускаются все эти команды внутри docroot нашего сайта — /var/www/www-root/data/www/changed.pavuk.space/

Slicemachine запускается на 9999 порту:

~/www/changed.pavuk.space/ispmanager$ npm run slicemachine

> my-prismic-site@0.1.0 slicemachine
> start-slicemachine

 Slice Machine v2.21.1  → Running at http://localhost:9999

Вот такой интерфейс для работы со слайсами нам предлагают:

Управление слайсами в графическом интерфейсе Prismic
Управление слайсами в графическом интерфейсе Prismic

После создания слайсов переходим в Review changes и кнопкой Push отправляем заготовки в панель нашего репозитория https://ispmanager.prismic.io для последующей сборки и компоновки нашего сайта.

Компоновка сайта в Prismic
Компоновка сайта в Prismic

Важно задать все переменные окружения проекта для успешной публикации сайта:

$ cat .env.local 
PRISMIC_ENDPOINT=https://ispmanager.cdn.prismic.io/api/v2
NEXT_PUBLIC_SITE_NAME=ispmanager
NEXT_SERVER_ACTIONS_ENCRYPTION_KEY=mXXeFoGrXv22HyTMl0CzcUSzKDfdVZysgXrDaF1ZO+s=

Ключ для Next.js сервера генерируем с помощью команды:

$ openssl rand -base64 32
mXXeFoGrXv22HyTMl0CzcUSzKDfdVZysgXrDaF1ZO+s=

После этого запускаем проект в dev-режиме и начинаем создавать сайт:

~/www/changed.pavuk.space/ispmanager$ npm run dev

> my-prismic-site@0.1.0 dev
> next dev

▲ Next.js 16.1.6 (Turbopack)
- Local:         http://localhost:3000
- Network:       http://164.90.xxx.xxx:3000
- Environments: .env.local

✓ Starting...
✓ Ready in 3.3s

Запуск в dev-режиме — необязательное условие, сайт можно создавать и без этого. После запуска все изменения попадут в проект автоматически.

После того как сайт закончен, его нужно собрать для работы в режиме Production:

~/www/changed.pavuk.space/ispmanager$ npm run build

> my-prismic-site@0.1.0 build
> next build

▲ Next.js 16.1.6 (Turbopack)
- Environments: .env.local

  Creating an optimized production build ...
✓ Compiled successfully in 38.8s
✓ Finished TypeScript in 16.4s    
✓ Collecting page data using 1 worker in 1627.2ms    
✓ Generating static pages using 1 worker (7/7) in 844.3ms
✓ Finalizing page optimization in 35.7ms    

Route (app)
┌ ○ /
├ ○ /_not-found
├ ƒ /api/exit-preview
├ ƒ /api/preview
└ ƒ /api/revalidate

○  (Static)   prerendered as static content
ƒ  (Dynamic)  server-rendered on demand

И уже после этого запускаем режим Production:

~/www/changed.pavuk.space/ispmanager$ npm run start

> my-prismic-site@0.1.0 start
> next start

▲ Next.js 16.1.6
- Local:         http://localhost:3000
- Network:       http://164.90.xxx.xxx:3000

✓ Starting...
✓ Ready in 1975ms

В nginx-конфиге сайта в панели ispmanager мы прописали правильный порт проксирования во всех местах:

proxy_pass http://127.0.0.1:3000;
proxy_redirect http://127.0.0.1:3000 /;
В интерфейсе ispmanager зеленые галочки означают, что все работает
В интерфейсе ispmanager зеленые галочки означают, что все работает

Важная деталь: Next.js в режиме Production — не то же самое, что чистый JAMstack. 

Мы видим, что проект использует Next.js с динамическими роутами (ƒ routes), а чистый JAMstack подразумевает полностью статическую генерацию (SSG). Таким образом, Next.js в режиме next start запускает Node.js сервер, что противоречит принципу «нет сервера». Вероятно, это связано с особенностями архитектуры Prismic.

Назовем созданный проект JAMEstack + Node.js. А для чистоты эксперимента создадим еще один проект — статичный проект без Next.js.

Создаем действительно статичный сайт на JAMstack

Попробуем использовать next export, чтобы создать полностью статический сайт, который генерирует  в директорию ou статические файлы (HTML, CSS, JS) — их можно отдавать напрямую через веб-сервер nginx или apache без Node.js.

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

Сделали мы это в корне проекта ispmanager так:

1. Удалили все динамические роуты.

$ rm -rf app/api/

2. Обновили конфиг next.config.js.

$ cat > next.config.js << 'EOF'
/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
}

module.exports = nextConfig
EOF

3. Собрали проект.

$ npm run build

4. Проверили результат.

$ ls -la out/

Назовем созданный сайт JAMEstack Static.

В дальнейшем исследовании производительности будем участвовать три сайта: 

  • JAMEstack + Node.js — сайт с динамическими элементами;
  • JAMEstack Static — статический сайт;
  • WordPress — стандартный сайт с небольшим тестовым контентом, который мы создали стандартными средствами ispmanager.

Чтобы тестирование было честным, запустили проекты на одном и том же сервере ispmanager: Digital Ocean с 2Gb RAM, 1 CPU, 50Gb disk. 

TTFB-тест — время до первого байта ответа от сервера

WordPress сайт:

# for i in {1..5}; do curl -o /dev/null -s -w "Замер $i - TTFB: %{time_starttransfer}s\n" https://jm.pavuk.space; done

Замер 1 - TTFB: 0.174238s
Замер 2 - TTFB: 0.124633s
Замер 3 - TTFB: 0.127694s
Замер 4 - TTFB: 0.113787s
Замер 5 - TTFB: 0.129179s

Среднее значение: 0.134s (134ms)

JAMstack + Node.js:

# for i in {1..5}; do curl -o /dev/null -s -w "Замер $i - TTFB: %{time_starttransfer}s\n" https://changed.pavuk.space; done

Замер 1 - TTFB: 0.062486s
Замер 2 - TTFB: 0.046602s
Замер 3 - TTFB: 0.044713s
Замер 4 - TTFB: 0.037619s
Замер 5 - TTFB: 0.042070s

Среднее значение: 0.047s (47ms)

JAMstack+Node.js сайт показывает почти в три раза более быстрый TTFB, чем WordPress, что говорит о значительно более быстром серверном отклике.

Он быстрее примерно на 65% (в ~2.8 раза), что подтверждает преимущество статической генерации и отсутствия серверной обработки при первом байте. Это напрямую улучшает восприятие скорости сайта и потенциально влияет на SEO.

JAMstack Static

# for i in {1..5}; do curl -o /dev/null -s -w "Замер $i - TTFB: %{time_starttransfer}s\n" https://rest.pavuk.space; done

Замер 1 – TTFB: 0.052369s

Замер 2 – TTFB: 0.040621s

Замер 3 – TTFB: 0.060125s

Замер 4 – TTFB: 0.041981s

Замер 5 – TTFB: 0.046601s

Среднее значение: 0.048s (48ms) сопоставимо с JAMstack+Node.js.

Тестирование с Lighthouse

Lighthouse — это инструмент аудита сайта от Google, который прогоняется в Chrome и даёт числовые оценки от 0 до 100 и конкретные рекомендации по улучшению показателей. Он проверяет четыре ключевые области:

1. Performance — как быстро загружается сайт:

  • LCP (Largest Contentful Paint);
  • CLS (Cumulative Layout Shift);
  • INP (Interaction to Next Paint);
  • TTFB и др.

2. Accessibility — насколько сайт удобен для людей с ограниченными возможностями:

  • контраст текста;
  • alt-тексты для изображений;
  • корректная навигация с клавиатуры.

3. Best Practices — безопасность и техническая корректность:

  • HTTPS;
  • отсутствие уязвимостей;
  • корректные API и ресурсы.

4. SEO — базовая поисковая оптимизация:

  • meta-теги;
  • robots.txt;
  • корректные заголовки страниц.

Тест проводился CLI-утилитой без запуска браузера с выводом результата в HTML файл:

JAMEstack+Node.js

# lighthouse https://jm.pavuk.space --chrome-flags="--headless" --output-path=./lighthouse-wordpress-report.html

Static JAMstack 

# lighthouse https://сchanged.pavuk.space --chrome-flags="--headless" --output-path=./lighthouse-wordpress-report.html

WordPress

# lighthouse https://rest.pavuk.space --chrome-flags="--headless" --output-path=./lighthouse-wordpress-report.html

Полные детальные HTML файлы отчетов Lighthouse:

JAMstack + Node.js

JAMstack Static

WordPress 

 

Скриншот с основными результатами Lighthouse для JAMstack + Node.js
Скриншот с основными результатами Lighthouse для JAMstack + Node.js 
Скриншот с основными результатами Lighthouse для JAMstack Static
Скриншот с основными результатами Lighthouse для JAMstack Static
Скриншот с основными результатами Lighthouse для WordPress
Скриншот с основными результатами Lighthouse для WordPress

First Contentful Paint (FCP)

Быстрее всего у Jamstack Static (1.1 сек.), далее WordPress (1.2 сек.) и Jamstack + Node.js сервер (1.2 сек.).

Largest Contentful Paint (LCP)

Лучший результат у WordPress (1.6 сек.) и Jamstack + Node.js сервер (1.6 сек.), Jamstack Static незначительно отстает (1.7 сек.).

Speed Index

Jamstack + Node.js сервер показывает наилучшую скорость заполнения контента (1.8 сек.), WordPress — 2.0 сек., Jamstack Static — 2.1 сек..

Все три конфигурации демонстрируют максимально возможные оценки (100/100) по всем категориям Lighthouse. Различия в скоростных метриках (FCP, LCP, Speed Index) минимальны и находятся в пределах погрешности измерений. Это говорит о высоком уровне оптимизации каждой из представленных систем.

Нагрузочное тестирование с ApacheBench

Базовый тест (100 запросов, 1 одновременный)

 Для WordPress 

# ab -n 100 -c 1 https://jm.pavuk.space/

Time taken for tests:       10.991 seconds
Requests per second:        9.10 [#/sec] (mean)
Time per request:           109.907 [ms] (mean)
Transfer rate:              772.38 [Kbytes/sec] received

Для JAMstack сайта с сервером Node.js

 
# ab -n 100 -c 1 https://changed.pavuk.space/

Time taken for tests:       3.985 seconds
Requests per second:        25.09 [#/sec] (mean)
Time per request:           39.850 [ms] (mean)
Transfer rate:              2920.93 [Kbytes/sec] received

Для Static JAMstack 

# ab -n 100 -c 1 https://rest.pavuk.space/

Time taken for tests:       3.786 seconds
Requests per second:        56.00 [#/sec] (mean)
Time per request:           17.859 [ms] (mean)
Transfer rate:              6439.06 [Kbytes/sec] received

Стрессовое тестирование (1000 запросов, 50 одновременных)

Для WordPress

# ab -n 1000 -c 50 https://jm.pavuk.space/

Time taken for tests:       119.580 seconds
Requests per second:        8.36 [#/sec] (mean)
Time per request:           5979.022 [ms] (mean)
Transfer rate:              709.90 [Kbytes/sec] received

Для JAMstack с сервером Node.js

# ab -n 1000 -c 50 https://changed.pavuk.space/

Time taken for tests:       40.512 seconds
Requests per second:        24.68 [#/sec] (mean)
Time per request:           2025.623 [ms] (mean)
Transfer rate:              2873.15 [Kbytes/sec] received

Для Static JAMstack

# ab -n 1000 -c 50 https://rest.pavuk.space/

Time taken for tests:       11.196 seconds
Requests per second:        89.32 [#/sec] (mean)
Time per request:           559.789 [ms] (mean)
Transfer rate:              10271.12 [Kbytes/sec] received

Сравнительные результаты основных тестов

 

Средний TTFB, мс
JAMstack+Node.js
47
JAMstack Static
48
WordPress
134
Performance (Lighthouse)
JAMstack+Node.js
99%
JAMstack Static
98%
WordPress
100%
FCP (Lighthouse), сек
JAMstack+Node.js
1.2
JAMstack Static
1.1
WordPress
1.2

Потребление CPU при стрессовом тесте для JAMstack сайта с сервером Node.js доходит до 47%, для WordPress сайта до 100%, а для JAMstack сайта до 15% Потребление памяти во всех трех случаях возрастает незначительно.

Таким образом, результаты тестирования демонстрируют подавляющее преимущество JAMstack (Static) архитектуры по всем ключевым метрикам:

Производительность: чистый JAMstack обрабатывает запросы в 6 раз быстрее базового WordPress и в 3.5 раза быстрее решения на Node.js при стрессовой нагрузке.

Масштабируемость: при увеличении числа одновременных подключений (с 1 до 50) пропускная способность JAMstack (Static) выросла, в то время как WordPress показал деградацию производительности.

Эффективность ресурсов: WordPress полностью утилизирует CPU (100%), становясь «узким местом» системы. JAMstack (Static) потребляет всего 15% CPU, что обеспечивает колоссальный запас прочности и снижает затраты на инфраструктуру.

Сетевая эффективность: Transfer rate у JAMstack (Static) в 14 раз выше, чем у WordPress, что свидетельствует о минимальных задержках при отдаче контента.

Переход от монолитной архитектуры WordPress к JAMstack позволяет радикально снизить нагрузку на сервер и ускорить отклик системы для конечного пользователя.

Выводы

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

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

 

#
Опыт экспертов