Сколько RAM нужно для Eleventy (11ty)

MAATRIX

Если вы выбираете Eleventy именно потому, что устали от тяжёлых сборщиков — вопрос про RAM у вас, скорее всего, риторический: «наверное, хватит и минимума?». И в большинстве случаев это правда. Eleventy (11ty) — редкий генератор статики, который не тащит за собой Vite, Rollup или Webpack по умолчанию: это просто Node.js-скрипт, который читает шаблоны и данные, рендерит HTML и кладёт файлы на диск. Но «просто скрипт» не значит «нулевая память» — на большом количестве страниц, тяжёлых данных или подключённом image-плагине потребление всё равно растёт, и об этом стоит знать заранее, а не после падения деплоя.

Почему у Eleventy другой профиль памяти, чем у Astro или Next.js

У большинства современных генераторов статики сборка — это в первую очередь работа бандлера: граф зависимостей, транспиляция, tree-shaking, минификация JS-бандлов. Именно это чаще всего съедает память у Astro, Gatsby или Next.js на этапе build. У Eleventy бандлера в базовой конфигурации нет вообще — он не собирает JS/CSS для клиента, не проходит через Rollup. Его задача уже. Он берёт шаблоны (Nunjucks, Liquid, Handlebars, EJS, Markdown, чистый JS) и данные (JSON, JS-модули, front-matter), рендерит их в HTML-файлы через собственный движок и всё.

Отсюда два следствия:

• Базовое потребление памяти на сборке заметно ниже, чем у бандлер-ориентированных генераторов — часто счёт идёт на десятки-сотни МБ, а не на гигабайты, даже на сайтах среднего размера.
• Память всё равно может вырасти, если в проект добавляются тяжёлые зависимости поверх ядра: обработка изображений (@11ty/eleventy-img), сборка CSS через PostCSS/Sass как отдельный шаг, или сотни-тысячи страниц с объёмными данными в памяти одновременно.

То есть Eleventy честно даёт вам низкий потолок по умолчанию, но не отменяет законы физики: если вы сами добавите в пайплайн Sharp для обработки картинок на 2000 фотографий, память вырастет так же, как выросла бы у любого другого инструмента с той же нагрузкой.

Сколько RAM нужно на сборку (`eleventy` build)

Для типового проекта цифры скромные, но стоит смотреть на них по сценариям.

Небольшой блог/лендинг (до 50-100 страниц, Markdown + Nunjucks-шаблоны, без обработки картинок в сборке): сборка проходит уверенно на 512 МБ-1 ГБ RAM. Сам процесс Node.js для такого объёма редко превышает 100-200 МБ пиковой памяти — можно проверить у себя командой ниже.

# посмотреть пиковое потребление памяти процессом сборки
/usr/bin/time -v npx @11ty/eleventy 2>&1 | grep "Maximum resident"

Средний сайт-документация (300-1000 страниц, данные из JSON/YAML, несколько коллекций, пагинация): здесь Eleventy держит в памяти дерево всех страниц и данные для генерации коллекций и pagination — на таком объёме разумно закладывать 1-2 ГБ. Узкое место обычно не сам рендеринг, а объём данных, которые вы грузите в global data files (_data/*.js) — если там тяжёлые запросы к API или большие JSON-файлы, они целиком лежат в памяти на протяжении всей сборки.

Сайт с @11ty/eleventy-img — отдельная история, как и у любого генератора с обработкой изображений. Плагин использует Sharp под капотом, который декодирует и ресайзит картинки по одной, но при параллельной обработке большого количества исходников (особенно 4K-фото) память заметно растёт. На каталоге из сотен изображений закладывайте 2-4 ГБ и рассмотрите ограничение параллелизма плагина, если сервер скромный.

Крупный сайт (тысячи страниц, множество коллекций, кросс-ссылки между записями): здесь Eleventy начинает вести себя ближе к «обычным» генераторам по памяти, потому что весь граф контента и коллекций нужно держать в памяти для корректной генерации связей. Реалистичный ориентир — 2-4 ГБ, у отдельных проектов больше — это зависит от сложности данных, не только от числа файлов.

Ориентировочная таблица (это именно ориентир, не измеренный бенчмарк — конкретные цифры у вас будут отличаться в зависимости от шаблонизатора, данных и плагинов):

Если сборка всё же падает по памяти на скромном VPS, можно поднять лимит heap для Node — это не увеличивает физическую RAM, но иногда сдвигает границу с «упало сразу» на «упало позже», если проблема в пике, а не в постоянной нехватке:

NODE_OPTIONS="--max-old-space-size=1536" npx @11ty/eleventy

Если и это не спасает — либо тариф маловат для объёма проекта, либо стоит временно подключить своп-файл как страховку на время build, пока не мигрируете на конфигурацию побольше.

Сколько RAM нужно для раздачи готового сайта

После npx @11ty/eleventy (или eleventy --input=... --output=_site) у вас на диске лежит папка _site/ — чистый HTML/CSS/JS без Node.js в рантайме. Никакого постоянно работающего процесса, который ест память, Eleventy на проде не оставляет — это его прямое преимущество перед SSR-фреймворками.

_site/
├── index.html
├── posts/
│   ├── first-post/index.html
│   └── second-post/index.html
├── css/style.css
└── favicon.ico

Раздать такую статику может Nginx на 512 МБ RAM без всякого напряжения — сам процесс Nginx под чистую статику потребляет единицы-десятки МБ, а основная нагрузка на память приходится на файловый кэш ОС, который Linux использует автоматически и который не нужно настраивать отдельно. Реалистичный минимум для продакшен-сервера с Eleventy-сайтом — 1 ГБ RAM с учётом ОС, SSH-сессии, логов и cron-задач, но сама раздача файлов узким местом не станет даже на этом объёме.

Пример конфига Nginx под статику Eleventy:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/_site;
    index index.html;

    location / {
        try_files $uri $uri/ $uri.html =404;
    }

    location ~* \.(css|js|svg|woff2?)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

Если трафик серьёзный или вы хотите разгрузить сервер ещё сильнее — статику Eleventy отлично кладёт CDN, тогда вопрос RAM на сервере перестаёт быть темой разговора: сервер лишь изредка отдаёт файлы источнику CDN. Подробнее о том, как это настроить, — в статье про настройку CDN перед сервером.

Dev-режим и `--serve`: сколько ест локальная разработка

Отдельный вопрос — не деплой, а повседневная разработка с --serve (или --watch), когда Eleventy следит за файлами и пересобирает страницы на лету через BrowserSync.

В этом режиме память растёт по двум причинам: во-первых, сам процесс держит в памяти состояние watcher'а и кэш скомпилированных шаблонов; во-вторых, BrowserSync поднимает собственный веб-сервер и WebSocket-соединение для live-reload. На типовом проекте это добавляет условно 100-300 МБ сверх памяти обычной сборки — для локальной машины разработчика или тестового VPS с 1-2 ГБ RAM это не проблема, но если вы держите dev-сервер постоянно запущенным на продакшен-сервере (что вообще не рекомендуется) — учитывайте эту добавку.

# dev-сервер с автопересборкой и live-reload
npx @11ty/eleventy --serve --watch

Для CI/CD и продакшена --serve не нужен вообще — используйте обычную сборку и раздачу статики отдельным веб-сервером, это и безопаснее, и легче по памяти.

Какой VPS выбрать под Eleventy

Итоговая конфигурация зависит от того, где происходит сборка (на сервере или в CI) и что ещё крутится на этом же VPS.

Практический совет: даже для Eleventy, при всей его лёгкости, разумно выносить сборку в CI/CD (GitHub Actions, GitLab CI) и деплоить на сервер уже готовый _site/. Это не столько про экономию памяти — Eleventy и так скромен — сколько про то, чтобы продакшен-сервер вообще не занимался ничем, кроме раздачи файлов, и не зависел от Node.js, npm-зависимостей и версии пакетов на проде. Если у вас несколько статических сайтов на одном VPS, разница особенно заметна: сервер обходится минимальным тарифом, а вся возня со сборкой уходит в CI бесплатно или почти бесплатно.

Если вы ещё не определились с генератором и сравниваете варианты — у нас есть статьи по установке Hugo и по настройке статического сайта на VPS в целом, а если рассматриваете более «навороченный» генератор с собственным рантаймом — сравнение по памяти есть и для Astro.

Типичные проблемы с памятью и как их решить

Сборка падает с JavaScript heap out of memory на большом количестве страниц. Обычно это либо очень тяжёлые global data files (десятки МБ JSON, которые целиком грузятся в память), либо параллельная обработка изображений через eleventy-img на слабом VPS. Решения по приоритету: (1) проверить, не грузите ли вы в data files больше данных, чем реально используете на страницах, (2) ограничить конкурентность обработки картинок, (3) как временная мера — настроить своп-файл, пока не увеличите тариф.

Память растёт линейно с числом страниц, хотя проект вроде небольшой. Проверьте свои _data-файлы и layout'ы — если в каждом layout'е через require() или import подтягивается что-то тяжёлое, это может неожиданно попадать в память многократно при рендере множества страниц. Часто причина в неоптимальной работе с внешними API прямо во время сборки — лучше кэшировать результат в файл, а не ходить в сеть на каждую страницу.

--serve держит память постоянно занятой на сервере разработки. Это ожидаемо — BrowserSync и watcher рассчитаны на длительную работу. Если сервер используется несколькими разработчиками одновременно и памяти не хватает, разумнее раздать каждому свой контейнер или процесс с ограничением через systemd/docker, чем держать один общий dev-сервер с непредсказуемой нагрузкой.

После сборки память не освобождается. Это нормальное поведение Node.js — как только процесс eleventy завершается, память освобождается ОС автоматически, дополнительных действий не требуется. Если после сборки free -h показывает занятую память — проверьте ps aux | grep eleventy, иногда watch-режим случайно остаётся висеть в фоне после отладки.

Частые вопросы