Cloudflare Workers sau Vercel: traficul ieftin poate pierde la SSR

Cloudflare Workers este o alegere atractivă pentru un API cu multe cereri ușoare. Dacă produsul depinde de pagini Next.js randate pe server, Vercel poate justifica un cost mai mare prin resursele disponibile funcției și printr-un traseu de implementare mai direct. Alegerea depinde de munca făcută la fiecare cerere, nu doar de volumul traficului.

Două aplicații cu același număr de vizitatori pot avea facturi și timpi de răspuns foarte diferiți. Un răspuns JSON scurt consumă puțin calcul; o pagină personalizată poate combina randare, acces la date și reguli de cache. Pentru comparație contează cererile care execută cod, timpul de CPU, memoria, traficul livrat și munca necesară pentru a menține aplicația.

Ce intră în factura fiecărei platforme

Tarifele Cloudflare Workers stabilesc pentru planul Free un plafon de 100.000 de cereri pe zi și 10 milisecunde de CPU pentru o invocare. Workers Paid costă cel puțin 5 USD pe lună și include 10 milioane de cereri și 30 de milioane de milisecunde CPU lunar; peste aceste cote, tarifele sunt de 0,30 USD pentru un milion de cereri și 0,02 USD pentru un milion de milisecunde CPU. În acest model, transferul de date nu are o taxă separată. Plafonul gratuit echivalează cu aproximativ trei milioane de cereri într-o lună de 30 de zile, dar o zi aglomerată nu poate folosi cota rămasă din alte zile.

Costul Workers Paid poate fi estimat pornind de la taxa de bază și adăugând separat cererile și CPU-ul care depășesc cotele incluse. Aceasta este o formulă pentru codul Worker invocat, nu pentru toate accesările site-ului: activele statice servite direct sunt gratuite, în timp ce accesările servite din cache-ul unui Worker rămân cereri facturabile. Cache-ul poate reduce CPU-ul fără să elimine automat costul cererilor.

Prețurile Vercel afișează Pro la 20 USD pe lună, cu un credit lunar de utilizare de 20 USD, un loc de dezvoltator inclus și locuri suplimentare la 20 USD pe lună fiecare. Funcțiile au componente de consum pentru invocări, CPU activ și memorie alocată; livrarea prin CDN și alte servicii au propriile condiții de tarifare. Creditul acoperă consum eligibil, însă nu transformă abonamentul sau locurile suplimentare în costuri gratuite.

Prin urmare, factura Vercel se estimează din abonament, accesul echipei și consumul serviciilor, ținând cont de creditul aplicabil. O comparație bazată doar pe prețul unui milion de invocări ar omite memoria unei funcții SSR și ar trata greșit vizitele servite din cache ca pe pagini randate din nou.

API ușor: când volumul favorizează Workers

Un endpoint care verifică un parametru și întoarce un răspuns mic este profilul în care Workers are cel mai clar argument economic. Dacă fiecare invocare consumă puțin CPU, echipa poate folosi cotele incluse și poate calcula simplu costul volumului suplimentar. Această concluzie privește o sarcină precisă; un API care generează documente, transformă imagini sau face mult calcul nu păstrează neapărat aceeași economie.

Contează și diferența dintre calcul și așteptare. Pe Workers, timpul petrecut în așteptarea unei cereri de rețea nu intră în timpul CPU facturat. Vercel folosește, la rândul său, CPU activ pentru funcțiile Fluid Compute, dar ține cont și de memoria alocată. Dacă endpointul așteaptă o bază de date, numărul de invocări nu explică singur factura și nici timpul perceput de utilizator. Amplasarea bazei de date față de funcție poate influența răspunsul mai mult decât codul care construiește JSON-ul.

Pentru acest profil, comparația utilă pornește de la cererile care ajung efectiv la cod și de la CPU-ul mediu al acelor cereri. Traficul static trebuie ținut separat. În special pe un site mixt, cu API și pagini publice, totalul accesărilor poate exagera consumul de calcul și poate ascunde ruta care produce costul.

SSR Next.js: de ce cererea ieftină poate avea un rezultat mai slab

Workers poate randa aplicații Next.js pe server, inclusiv prin streaming, dar compatibilitatea traseului de implementare devine parte a deciziei. Ghidul Cloudflare pentru Next.js recomandă vinext ca opțiune implicită și îl descrie ca produs beta; OpenNext rămâne documentat pentru aplicațiile existente care nu pot migra încă din cauza unui decalaj de compatibilitate. Pentru un produs deja lansat, rutele, dependențele, regenerarea conținutului și comportamentul cache cer verificări în aplicația proprie.

În rezultatele SSR publicate de Vercel pentru testele dezvoltatorului Theo Browne din octombrie 2025, configurația Next.js pe Fluid Compute a avut o medie de 0,534 secunde, față de 1,895 secunde pentru configurația Workers. Funcția Vercel din acel test avea 2 vCPU și 4 GB RAM, iar Workerul folosea CPU partajat și 128 MB RAM. Diferența descrie aplicația și configurațiile testate, nu o proprietate fixă a oricărei pagini găzduite pe cele două platforme.

Ulterior, analiza tehnică Cloudflare a descris ajustări ale infrastructurii și ale testelor și a raportat rezultate apropiate de Vercel în probele reluate, cu excepția celei bazate pe Next.js. Reluarea a schimbat și condițiile de măsurare, inclusiv configurația funcției Vercel și locul din care au fost trimise cererile. Valorile inițiale și concluzia ulterioară nu sunt, așadar, două măsurători identice între care se poate alege un câștigător universal.

Distincția importantă este între calculul JavaScript izolat și pagina completă. O rută SSR poate executa componente, poate solicita date și poate construi un răspuns diferit pentru fiecare utilizator. Paritatea într-o probă CPU nu garantează paritate pentru această rută. În plus, testul istoric folosea un traseu Next.js diferit de vinext, opțiunea recomandată acum pentru Workers. Pentru o aplicație dominată de SSR, Vercel oferă un punct de plecare mai direct; economia Workers merită evaluată împreună cu compatibilitatea și timpul de randare al paginilor reale.

Trafic imprevizibil: vârful nu seamănă cu media

Workers Paid are un model ușor de urmărit când cresc invocările dinamice: cererile și CPU-ul peste cotele incluse adaugă cost. Pe planul gratuit, plafonul zilnic este mai relevant decât media lunară. Un val concentrat într-o singură zi poate atinge limita, chiar dacă restul lunii a avut trafic redus.

Pe Vercel, efectul unui vârf depinde de câte accesări sunt rezolvate prin livrarea conținutului existent și câte pornesc o funcție. O pagină publică servită din cache și un cont personalizat randat la fiecare accesare nu pun aceeași presiune pe calcul. CDN-ul poate absorbi o parte a cererilor fără o nouă invocare a funcției, dar livrarea conținutului are propriile condiții de utilizare. De aceea, un vârf de vizitatori nu trebuie confundat cu un vârf de randări SSR.

Pentru un produs cu trafic neregulat, contează distribuția cererilor, nu doar totalul lor. Dacă majoritatea accesărilor primesc active statice sau răspunsuri reutilizate, costul funcțiilor poate rămâne limitat. Dacă fiecare accesare generează o pagină personalizată, cresc atât consumul de calcul, cât și importanța timpilor de răspuns la încărcare.

Echipă cu multe locuri: costul accesului și al compatibilității

La trafic modest, structura echipei poate conta mai mult decât tariful cererilor. Workers Paid are o taxă de bază la nivel de cont, iar Vercel Pro include un loc de dezvoltator și taxează locurile suplimentare. Rolurile de vizualizare gratuite de pe Vercel ajută când un coleg trebuie doar să urmărească proiectul; ele nu înlocuiesc accesul necesar celor care îl configurează și publică.

Mai există timpul de întreținere. Pentru un API simplu, mutarea codului și păstrarea lui funcțională pot reprezenta o sarcină relativ restrânsă. Pentru un produs Next.js care folosește intens SSR, regenerarea paginilor și pachete dependente de mediul Node.js, validarea unui alt traseu de implementare poate deveni muncă recurentă la actualizări. Aceasta este o cheltuială operațională chiar dacă nu apare ca linie în factura platformei.

Alegerea urmează astfel ruta dominantă a produsului. Workers are sens economic când cererile sunt numeroase și ușoare; Vercel devine mai convingător când randarea Next.js și fluxul de implementare cântăresc mai mult. Pentru o echipă care trebuie să decidă între ele, estimarea facturii din trafic dinamic și CPU trebuie pusă alături de timpul SSR și de compatibilitatea rutelor proprii.

Citește și:

• OBS sau Streamlabs: widgeturile pot costa mai mult decât editorul simplu
• WordPress sau Squarespace: portofoliul simplu poate evita luni de mentenanță
• Cursor sau GitHub Copilot: acceptarea codului nu alege singură câștigătorul