Care backend e cel mai rapid — și de ce răspunsul rar contează.

Întreabă care backend e cel mai rapid și ți se va arăta un grafic cu bare. Timp de doisprezece ani, acel grafic a venit din TechEmpower Framework Benchmarks, care s-a arhivat în martie 2026 — parțial pentru că cifrele se îndepărtaseră de orice seamănă cu o aplicație reală. Răspunsul onest la întrebare e că alegerea limbajului aproape niciodată nu e ce face API-ul tău lent, iar ghidul acesta explică ce o face.

Ce a măsurat de fapt ultima rundă

Runda 23 din TechEmpower Framework Benchmarks, publicată în martie 2025 și ultima înainte de arhivarea proiectului. Testul Fortunes e cel mai apropiat de o aplicație din suită (citire din bază de date, sortare, randare HTML). Cifrele absolute nu sunt comparabile cu rundele anterioare: Microsoft a donat servere cu 56 de core-uri pe rețea de 40Gbps la mijlocul proiectului, ceea ce a ridicat rezultatele network-bound cu 3–4x. Citește ordinea, nu valorile.

De ce regele benchmark-urilor a încetat să fie răspunsul

Repository-ul TechEmpower a intrat în mod arhivat pe 24 martie 2026, după o rundă finală care acoperea peste 330 de implementări de framework. Criticile care au precedat asta sunt partea utilă: platforma de test aproape nu se mai schimbase de ani, rezultatele erau plafonate de harness și nu de framework-uri, iar intrările aveau voie să folosească optimizări de nivel jos pe care nicio echipă nu le-ar livra într-un produs real. Un framework putea sta în vârful graficului cu cod pe care propria lui documentație nu l-ar recomanda.

Un proiect succesor, HttpArena, încearcă aceeași treabă cu suport pentru HTTP/2 și WebSocket și cu implementări deliberat realiste. Până când are acoperire comparabilă, tratează orice grafic „cel mai rapid backend 2026” ca o ordonare aproximativă de plafoane, nu ca o predicție despre aplicația ta.

Unde se duce de fapt timpul tău de răspuns

Pe un API de business tipic, limbajul consumă milisecunde cu o cifră și tot restul consumă diferența. O interogare fără index, un pattern N+1 care lansează 200 de query-uri unde unul ar fi de ajuns, un apel sincron către un procesator de plăți sau un CRM, un cache lipsă pe un răspuns care se schimbă o dată pe oră — oricare dintre astea costă mai mult decât toată diferența dintre cel mai rapid și cel mai lent stack din tabelul de sus.

De asta rescrierea unui serviciu Node lent în Go de obicei dezamăgește. Dacă 480ms dintr-un răspuns de 500ms sunt o interogare care așteaptă o bază de date, mutarea celor 20ms rămași la 5ms e o îmbunătățire de 3% pentru o rescriere completă. Repararea interogării e o îmbunătățire de 90% pentru o după-amiază.

Ce alegem noi, de fapt, și de ce

Node.js cu TypeScript e default-ul nostru, în mare pentru un motiv care nu are legătură cu performanța: e același limbaj ca front end-ul Next.js, deci tipurile, logica de validare și utilitarele sunt partajate, nu reimplementate și ținute manual în sincron. Pentru muncă I/O-bound — care e majoritatea software-ului de business — event loop-ul e cu adevărat potrivit, iar tabelul de sus măsoară Express, nu runtime-urile mai rapide disponibile acum în același ecosistem.

Go e ce alegem când un serviciu trebuie să țină ieftin multe mii de conexiuni simultane, sau când un singur binar mic cu memorie predictibilă are valoare operațională. Python își merită locul oriunde e implicat machine learning sau tooling de date, pentru că bibliotecile sunt acolo și nimic altceva nu se apropie. Java e răspunsul corect când e deja stack-ul casei și există o echipă care îl întreține. Rust îl recomandăm rar și specific: throughput CPU susținut unde factura de hosting scalează cu eficiența.

Când limbajul e cu adevărat blocajul

Se întâmplă. Sisteme real-time cu zeci de mii de conexiuni persistente, muncă CPU per cerere cum e transformarea de imagini sau video, ingestie de date la frecvență mare, sau workload-uri unde costul de calcul e o linie materială în P&L — în acele cazuri eficiența runtime-ului e o cifră de business, nu o preferință.

Semnul e măsurarea, nu intuiția. Dacă profilarea arată CPU saturat în propriul cod și nu timp petrecut așteptând alte sisteme, limbajul contează. Altfel ai o problemă de bază de date, de caching sau de arhitectură îmbrăcată în haine de problemă de limbaj.

Criteriile care bat viteza brută

Cine va întreține asta în trei ani și dacă poți angaja acei oameni. Cât de mature sunt bibliotecile pentru integrările specifice de care ai nevoie. Cât de repede pleacă un fix când se strică ceva la ora 9. Cât costă hosting-ul la traficul tău real, nu la 600.000 de cereri pe secundă. Un stack de 4x mai lent pe un benchmark sintetic și de 2x mai rapid de modificat e alegerea comercială mai bună pentru aproape orice aplicație de business.

„Suficient de rapid” e o țintă de inginerie reală. Definește-o — să zicem 200ms la percentila 95 sub sarcina așteptată — apoi alege stack-ul cu care echipa ta o poate atinge în continuare.

Surse

Cifrele de benchmark și cronologia arhivării vin din acestea, verificate în iulie 2026.

• TechEmpower Framework Benchmarks — Runda 23 ↗

  Ultima rundă publicată a proiectului, cu peste 330 de implementări de framework pe testele plaintext, JSON, single-query, multi-query, fortunes și updates.

• TechEmpower — anunțul Rundei 23 ↗

  Publicat 17 martie 2025. Documentează schimbarea de hardware — HPE ProLiant DL360 Gen10 Plus, Xeon Gold 6330 cu 56 de core-uri, rețea Mellanox de 40Gbps — și saltul rezultat de 3–4x pe testele network-bound.

• DEV — TechEmpower Framework Benchmarks are now archived: what's next? ↗

  Consemnează arhivarea din 24 martie 2026, criticile de stagnare și de optimizări nerealiste, și HttpArena ca succesor propus.