Не и в реално приложение. В чист HTTP тест на едно процесорно ядро Bun 1.3.14 обслужи 122 170 заявки в секунда, а Node.js 24.18 - 47 734, или около 2,6 пъти повече. Но услуга с маршрутизация, валидиране и база данни измери по 12 000 заявки в секунда и при Bun, и при Node.js, и при Deno, защото темпото зададе базата данни. „3 пъти по-бърз" е резултат от бенчмарк, не обещание за вашия сайт.
Какво всъщност мерят бързите числа
Бенчмарк, публикуван през юли 2026, е пуснат с фиксирани версии (Node 24.18.0, Bun 1.3.14, Deno 2.9.1) на Linux настолен компютър с 12 ядра. Абсолютните стойности зависят от тази машина, затова гледайте съотношенията:
- Празен JSON endpoint, едно ядро: Bun 122 170 заявки в секунда, Node.js 47 734. Deno 2.9.1 водеше със 133 093.
- Студен старт на hello-world скрипт: Bun 11 ms, Node.js 21 ms.
JSON.stringifyвърху 3,3 MB: Bun 5,5 ms, Node.js 13,6 ms.- Инсталиране на 585 пакета със студен кеш:
bun install5,8 секунди, npm 11,8 секунди. - Памет в покой: Bun 36 MB, Node.js 49 MB.
BullMQ пусна собствен бенчмарк на опашки на Bun 1.3.3 и Node.js 24.13. Работата, зависеща от процесора, беше с 33% по-бърза на Bun. Обработката на задачи, която чака Redis, беше само с 12% по-бърза. Колкото повече една задача чака нещо извън процеса, толкова по-малко значи средата за изпълнение.
Къде разликата изчезва
Независим тест на скъсител на URL с маршрутизация, валидиране и база данни даде по 12 000 заявки в секунда и на трите среди. Същият автор откри втори проблем: популярният инструмент за натоварване autocannon е написан на Node.js и стига тавана си при около 65 000 заявки в секунда на машина с 12 ядра. Всяко сравнение с него не може да различи две бързи среди, а много статии с „Bun винаги е първи" са мерени така.
Рецензирано изследване от 2025 за HTTP, зависещ от входа и изхода, е намерило според Strapi 27 500 заявки в секунда за Bun и 28 200 за Node.js. Проучване в GitHub на Bun, споменато там, е измерило Bun зад Node.js (11 800 срещу 16 200) при натоварване с много заделяне на обекти, преди поправка да стесни разликата. Bun може да изгуби, когато горещият път създава много краткоживущи обекти.
Кога Bun си струва
- Услугата върши много JSON или друга процесорна работа на заявка.
- Времето за стартиране има значение, например при краткотрайни задачи или контейнери, които се свиват до нула.
- CI ви губи минути за
npm install. Можете да ползватеbun installи да продължите да работите с Node.js. - Искате вграден тест runner и пакетиране без допълнителни пакети.
Кога Node.js е по-сигурният избор
- Зависите от нативни добавки или от агент за мониторинг, който първо поддържа Node.js.
- Горещият ви път създава много обекти или приложението е тежко на framework; докладите показват по-висока памет при Bun.
- Искате версията с дългосрочна поддръжка, която предполага всяко ръководство за хостинг и всеки пазар на кадри.
Тествайте с вашето натоварване за 20 минути
- Пуснете истинското приложение с истинската база данни на машината, на която ще работи, не на лаптопа.
- Ползвайте инструмент за натоварване, който не е на Node.js, например
oha:oha -z 15s -c 200 http://127.0.0.1:3000/realen-marshrut. - Пуснете всяка среда по три пъти и вземете медианата. Следете паметта наред със заявките в секунда.
- Сменете само ако разликата остава при включена база данни.
Средата си избирате сами на облачен сървър, където имате root достъп. Cloud VPS Mini (1 vCPU, 1 GB RAM, от 14,99 € на месец) стига за пробно API. При 1 GB RAM гледайте колоната за памет, преди да решите.
Въпроси
По-бърз ли е Bun от Node.js за обикновен уебсайт?
Обикновено не толкова, че да се усети. Ако всяка заявка чака база данни или външно API, средата е малка част от времето за отговор.
Мога ли да ползвам Bun само като пакетен мениджър?
Да. bun install работи и в проект, който продължава да върви на Node.js, а инсталациите са мястото, където печалбата е ясна и рискът е нисък.
Защо по-старите статии показват по-голяма разлика?
Много от тях сравняват стари версии на Node.js, ползват инструмент за натоварване с таван или тестват празен endpoint. Бенчмарковете на среди остаряват бързо, затова проверявайте версиите във всяка статия, включително в тази.
