Cloudflare Pages sau Netlify: TTFB-ul poate diferi de patru ori

În comparația regională publicată de Tech Insider, TTFB-ul raportat pentru Tokyo este de 40–55 ms pe Cloudflare Pages și 190–210 ms pe Netlify: valorile centrale diferă de aproximativ patru ori. Pentru un site Astro static cu trafic ridicat, Cloudflare are și un avantaj de cost la livrare. Pentru o aplicație cu funcții, alegerea depinde de câte cereri execută efectiv cod și de resursele consumate de acesta.

Diferența din Tokyo descrie configurațiile incluse în comparație, nu latența garantată pentru vizitatorii din România sau Republica Moldova. Nici viteza de publicare nu urmează aceeași ordine: în proba Astro din același tabel, deployul Netlify durează 47 de secunde, iar cel Cloudflare Pages un minut și opt secunde. TTFB-ul, durata buildului și factura răspund la întrebări diferite.

Ce arată TTFB-ul regional

TTFB este timpul până la primul octet al răspunsului. Pentru un fișier static, acesta reflectă în principal livrarea prin rețea și comportamentul cache-ului. Pentru HTML generat la cerere, în răspuns intră și execuția codului, precum și timpul eventualelor apeluri către baze de date sau alte servicii. De aceea, un rezultat obținut cu o pagină statică nu descrie automat o rută personalizată pentru fiecare utilizator.

Comparația citată raportează și pentru Londra intervale de 35–42 ms pe Cloudflare Pages și 95–110 ms pe Netlify. Decalajul este mai mic decât cel din Tokyo, ceea ce arată cât de mult contează regiunea măsurării. Pentru publicul din România și Moldova, valorile din Londra pot orienta alegerea, dar nu înlocuiesc o măsurare din locurile în care se află utilizatorii proiectului.

Contează și ce anume a fost cerut în test. O pagină HTML aflată deja în cache, un răspuns care declanșează o funcție și o pagină care așteaptă date externe au trasee diferite. Diferența regională este, așadar, un argument pentru livrarea statică rapidă în configurațiile raportate, nu o promisiune că orice aplicație mutată între platforme își va reduce TTFB-ul în aceeași proporție.

Buildul Astro și limitele de publicare

La un site Astro pre-randat, buildul produce paginile și activele care vor fi publicate. Durata lui afectează cât așteaptă echipa o versiune nouă, nu timpul de răspuns al unei pagini deja disponibile. Rezultatul Astro favorabil Netlify din comparația de mai sus nu stabilește un câștigător pentru alte proiecte: numărul paginilor, dependențele și modul în care se păstrează cache-ul de build pot schimba durata.

Limitele oficiale Cloudflare Pages prevăd pentru planul gratuit 500 de builduri pe lună, un singur build simultan, oprirea unui build după 20 de minute și cel mult 20.000 de fișiere într-un site. Limita de concurență se aplică la nivelul contului. Dacă mai multe proiecte publică în același timp, unele builduri vor aștepta chiar dacă fiecare proiect se încadrează separat în alocarea lunară.

Pentru un site Astro care generează multe pagini, numărul fișierelor de ieșire poate deveni decisiv înaintea traficului. Un articol, o pagină de categorie și activele asociate ocupă fișiere distincte în rezultatul publicat. Echipa care actualizează des conținutul trebuie să privească și frecvența publicărilor: o limită lunară de builduri și o coadă de builduri simultane afectează fluxul editorial în alt fel decât câteva secunde economisite la un deploy izolat.

Site Astro static: 50 GB și două milioane de cereri

Să luăm un scenariu condițional: un site Astro complet static transferă 50 GB și primește două milioane de cereri web într-o lună. Acestea sunt cereri de fișiere, nu două milioane de vizite; încărcarea unei pagini poate solicita separat HTML, CSS, JavaScript și imagini. Calculul compară tarifele pentru același volum presupus, fără să atribuie traficul unui site real.

În planurile Netlify bazate pe credite, transferul web consumă 20 de credite pe GB, cererile web două credite la 10.000 de cereri, iar un deploy reușit în producție 15 credite. Free include 300 de credite lunar, Personal include 1.000 la 9 USD pe lună, iar Pro începe de la 3.000 la 20 USD pe lună. Transferul din scenariu consumă 1.000 de credite, iar cererile încă 400. Totalul de 1.400, înainte de deployuri și alte servicii, depășește alocările Free și Personal, dar încape în alocarea inițială Pro.

Pe Cloudflare, tarifele Workers și Pages Functions arată că cererile către active statice sunt gratuite și nelimitate și că nu se percepe separat transferul de date. Astfel, traficul presupus al site-ului complet static nu generează singur o taxă de livrare. Costul mai mic al traficului nu elimină limitele de fișiere și de build ale unui proiect Pages. De asemenea, nu include servicii suplimentare pe care site-ul le-ar putea folosi.

Aplicația cu funcții: același trafic, alt consum

Păstrăm condițional cei 50 GB și cele două milioane de cereri lunare, dar presupunem că fiecare cerere invocă o funcție. La Netlify, cele 1.400 de credite calculate pentru transfer și cereri rămân punctul de plecare. Se adaugă creditele pentru deployurile de producție și pentru calculul funcțiilor, tarifat în funcție de resursele și durata execuției. Fără aceste date, faptul că traficul încape în alocarea Pro nu spune cât va consuma întreaga aplicație.

La Cloudflare, Pages Functions folosesc tarifele Workers: planul gratuit are o limită de 100.000 de cereri către cod pe zi și de 10 ms timp CPU pentru fiecare execuție. Planul plătit pornește de la 5 USD lunar și include 10 milioane de cereri și 30 de milioane de milisecunde CPU pe lună. Media celor două milioane de cereri din scenariu ar fi sub pragul zilnic gratuit, însă un vârf de trafic poate depăși pragul într-o singură zi. Pe planul plătit, numărul presupus de cereri încape în alocare; consumul CPU rămâne o variabilă separată.

Rutarea schimbă substanțial acest calcul. Dacă pagina Astro și activele sale sunt servite direct ca fișiere statice, acele accesări nu invocă funcția; numai rutele care au nevoie de logică server-side intră în bugetul de execuție Cloudflare. Dacă fiecare accesare trece mai întâi prin cod, avantajul cererilor statice gratuite nu mai descrie întregul trafic. La Netlify, cererile web și transferul consumă credite în ambele situații, iar funcțiile adaugă consum de calcul atunci când sunt executate.

Compatibilitatea Astro și alegerea platformei Cloudflare

Un proiect Astro complet static poate publica fișierele generate. O aplicație cu autentificare, rute API sau pagini randate la cerere are nevoie și de un adaptor și de o configurație server-side potrivite platformei alese. Verificarea compatibilității înseamnă, concret, să stabilești ce rute rămân pre-randate, ce rute invocă o funcție și ce servicii externe folosesc acestea. Două proiecte scrise cu același framework pot avea astfel profiluri foarte diferite de latență și cost.

Pentru proiectele noi, recomandarea Cloudflare este Workers cu Static Assets, inclusiv pentru site-uri pur statice; Pages continuă să funcționeze, dar funcțiile și optimizările noi se concentrează pe Workers. Un proiect Pages existent poate fi evaluat după limitele sale actuale. Pentru un proiect Astro pornit acum, comparația utilă include și configurația Workers: fișierele statice pot fi livrate fără script, iar aplicația cu funcții adaugă codul doar pe rutele care îl cer.

În scenariul static analizat, Cloudflare oferă costul de livrare mai mic, în timp ce Netlify poate justifica planul necesar prin fluxul de publicare dorit. În scenariul cu funcții, alegerea depinde de distribuția cererilor pe zile, de proporția celor care execută cod și de consumul fiecărei execuții. Aceste valori schimbă factura și latența aplicației fără să schimbe rezultatul unui benchmark pentru fișiere statice.

Citește și:

• Cloudflare Workers sau Vercel: traficul ieftin poate pierde la SSR
• PostgreSQL sau MySQL: stocarea schimbă câștigătorul benchmarkului
• RAG sau fine-tuning: datele noi și comportamentul cer soluții diferite