Performance
Test su 3G simulato: cosa cambia davvero
Con 400 ms di RTT e 1,6 Mbps la home passa da un LCP di 708-1.360 ms a 2.672 ms, con 340 KB in 24 richieste. Il collo di bottiglia è la banda, non il server.
In sintesi
- Con 400 ms di RTT e 1,6 Mbps il TTFB resta 335 ms: è il resto della pagina a rallentare.
- L'LCP passa da 708-1.360 ms senza limitazione a 2.672 ms su 3G simulato.
- La pagina trasferisce 340 KB in 24 richieste, quasi tutte necessarie al primo schermo.
- Il 3G simulato misura la rete, non la CPU: senza throttling del processore il numero resta ottimista.
Un test su 3G simulato si fa limitando rete e latenza nel browser, non abbassando la banda del router: con 400 ms di RTT e 1,6 Mbps la nostra home passa da un LCP di 708-1.360 ms a 2.672 ms, mentre il TTFB resta 335 ms. Il server non c'entra: sono i 340 KB in 24 richieste a pesare.
Tre profili, tre risposte
| Profilo | RTT | Banda | LCP | Load |
|---|---|---|---|---|
| Nessuna limitazione | 0 ms | rete locale | 708-1.360 ms | 435-1.084 ms |
| 3G simulato | 400 ms | 1,6 Mbps | 2.672-2.676 ms | 2.424-3.178 ms |
| Rete veloce | 20 ms | 8 Mbps | 752-780 ms | 553-644 ms |
Il TTFB non cambia quasi nulla tra i profili: 335 ms contro 352 ms, contro 319-529 ms senza limitazione. Se il TTFB regge e l'LCP triplica, il tempo si spende dopo il primo byte, scaricando CSS, JavaScript e immagini. È la diagnosi più utile che questo test produce.
Il comando
const cdp = await page.createCDPSession();
await cdp.send("Network.enable");
await cdp.send("Network.emulateNetworkConditions", {
offline: false,
latency: 400,
downloadThroughput: 200 * 1024,
uploadThroughput: 100 * 1024,
connectionType: "cellular3g",
});
await page.goto("https://example.com/", { waitUntil: "load" });
Il codice richiede Puppeteer, Chrome e una pagina già aperta in page. downloadThroughput è in byte al secondo, non in bit: 200 × 1024 corrisponde a 1,6 Mbps. Le stesse condizioni si impostano a mano in DevTools, in Network, con il profilo "Slow 3G".
Cosa il test non dice
Il throttling di rete non rallenta il processore, quindi una pagina che impiega 1,2 s di JavaScript per idratare sembra più veloce di quanto sia su un telefono vero. Lighthouse mobile somma al limite di rete un rallentamento della CPU di quattro volte, e usa 150 ms di RTT invece di 400: il suo 3G è più gentile sulla latenza e più severo sul processore. Per un budget serve la combinazione, non una delle due.
Il limite da dichiarare
Le due run per profilo sono un campione piccolo, su una sola macchina e una sola rete: i valori assoluti si muovono di centinaia di millisecondi. In più il 3G reale non ha banda costante, e la coda dei pacchetti cambia con la cella. Il test serve a confrontare due versioni del sito nelle stesse condizioni, non a prevedere il tempo di un utente specifico.
Dove continuare
Il catalogo EneUI indicizza 111.985 componenti, i blocchi hero e il record scroll expansion hero, un hero che su 3G paga ogni immagine. Per capire cosa non caricare subito leggi lazy loading: quando peggiora, per dividere il JavaScript dividere il bundle, per il primo byte TTFB: cosa misura, e per il confronto tra architetture framework frontend a confronto.
Domande frequenti
Che differenza c'è tra 3G simulato e 3G vero?
Il simulato ha banda e latenza costanti, il vero no: la cella cambia, i pacchetti si accodano e la banda oscilla. Il simulato serve a confrontare due versioni nelle stesse condizioni, non a prevedere un singolo utente.
Perché il TTFB non peggiora con 400 ms di RTT?
Perché il TTFB misura il primo byte della risposta principale, dopo un handshake che nel nostro caso resta breve. Il tempo della rete si paga dopo, scaricando gli asset della pagina.
Quali valori usa Lighthouse per il 3G?
Lighthouse mobile simula 1,6 Mbps in download, 750 kbps in upload, 150 ms di RTT e un processore rallentato quattro volte. Il nostro test usa 400 ms di RTT per avvicinarsi a una rete mobile reale.
Quanto conta la CPU in un test mobile?
Molto, se la pagina idrata molto JavaScript. Senza rallentamento della CPU il test misura solo la rete e ti dice che il problema è la banda anche quando è il processore.
Come uso il test in CI?
Fissa un budget sull'LCP misurato nello stesso profilo di rete e confronta le versioni. Un test di rete in CI è lento e rumoroso: meglio un budget sul peso degli asset e un test manuale prima del rilascio.