Page Size Checker

Incolla qualsiasi URL nel campo Page URL qui sopra e fai clic su controlla. Il checker della dimensione della pagina recupera l'URL, legge gli header della risposta e restituisce la dimensione del documento HTML grezzo, la dimensione di trasferimento gzip o brotli, il tempo di risposta in millisecondi, i valori di Content-Encoding e Cache-Control e un conteggio di ogni CSS, JS, immagine, font e iframe esterno dichiarato. Stima il peso totale della pagina utilizzando le mediane del Web Almanac 2024 (mediana 2,4 MB, p75 5 MB) e contrassegna se sei leggero, medio o gonfio. Chrome DevTools mostra gli stessi numeri nella scheda Rete, ma devi caricare la pagina, svuotare la cache, ricaricare forzatamente e leggere su più pannelli. Questo strumento fornisce la stessa risposta in due secondi rispetto a qualsiasi URL pubblico.

La dimensione della pagina è la somma di ogni byte che il browser scarica per rendere la pagina: il documento HTML più ogni file CSS, file JS, immagine, font, video e asset iframe. Il numero più utile è la dimensione di trasferimento compresso, poiché è quello che attraversa la rete. Per calcolare manualmente, apri Chrome DevTools, passa a Rete, ricarica forzatamente con la cache disabilitata e leggi la barra in basso dove Chrome stampa le richieste e il totale di byte trasferiti. Il checker sopra esegue la stessa aritmetica per il documento HTML direttamente e stima il peso totale dagli asset dichiarati utilizzando le mediane del Web Almanac 2024, quindi non devi aspettare che ogni sotto-risorsa finisca.

Usa il campo sopra. Rilascia l'URL in Page URL, fai clic su controlla e leggi la scheda di risposta. Il checker segnala i byte del documento HTML, i byte di trasferimento gzip, il tempo di risposta, la codifica, gli header della cache e l'inventario delle richieste di asset per tipo. Confronta il totale stimato rispetto alle mediane del Web Almanac 2024 e etichetta la pagina in verde, ambra o rosso. Per un audit di rendering più approfondito, esegui google-crawler-simulator che esegue JavaScript e mostra il DOM post-rendering, quindi esegui alt-text-checker sull'inventario di immagini. La combinazione ti dice esattamente quali asset comprimere, rinviare o rimuovere per primo.

Punta a un peso totale inferiore a 1,5 MB sulle pagine di landing e conversione. Il Web Almanac 2024 ha misurato la mediana della pagina a 2,4 MB e il p75 a 5 MB, con il p90 sopra 9 MB. Le pagine inferiori a 1 MB superano la soglia LCP di 2,5 secondi l'82% delle volte su 4G mobile. Le pagine superiori a 3 MB la superano solo il 38% delle volte. All'interno del budget, mantieni l'HTML sotto 100 KB compresso, JS sotto 300 KB compresso, CSS sotto 60 KB compresso e la singola immagine più grande sotto 200 KB. Il checker contrassegna le pagine che superano queste soglie. Ricontrolla dopo ogni distribuzione perché gli script di terze parti e i plugin CMS aggiungono regolarmente peso senza che nessuno se ne accorga.

LCP misura quanto tempo impiega l'elemento visibile più grande a eseguire il rendering. Sulla maggior parte delle pagine, quell'elemento è un'immagine hero, una cornice video di un banner o un grande blocco di titolo. Le pagine pesanti ritardano LCP perché i CSS e JS di blocco del rendering nella head ritardano il paint in seguito, l'immagine LCP stessa è spesso non ottimizzata e la contesa della rete affama la richiesta LCP della larghezza di banda. La soglia di Google è di 2,5 secondi. I dati dell'HTTP Archive 2024 mostrano che le pagine superiori a 3 MB non la superano il 62% delle volte su dispositivi mobili. Correggi LCP eseguendo il preload dell'immagine hero, servendola come AVIF o WebP, rinviando JS non critico con defer o async e riducendo il CSS critico. Riesegui il checker dopo ogni modifica.

Entrambi sono algoritmi di compressione del testo applicati al livello HTTP. Gzip è lo standard web dagli anni '90 ed è supportato da ogni browser. Brotli è stato rilasciato da Google nel 2015 e si spedisce nel 96% dei browser a partire dal 2026. Brotli comprime il testo in media del 15-25% più piccolo di gzip per HTML, CSS e JS, con il divario più ampio su markup altamente ripetitivo. La maggior parte dei CDN (Cloudflare, Fastly, CloudFront) abilita brotli per impostazione predefinita per il testo statico e torna a gzip per i client più vecchi. Il checker segnala il Content-Encoding effettivo che il tuo server ha restituito. Se mostra gzip o vuoto, cambia il tuo CDN a brotli per un calo immediato del 15-25% nel peso del testo senza modifiche al codice.

Affronta prima le categorie più pesanti. Le immagini sono di solito la voce più grande: converti foto hero in AVIF con fallback WebP (AVIF è mediamente il 50% più piccolo di JPEG con la stessa qualità), ridimensiona alle dimensioni di visualizzazione effettive e carica con lazy loading qualsiasi cosa sotto la piega con loading="lazy". JavaScript è il prossimo: suddividi il codice per percorso, rinvia gli script di terze parti fino dopo il primo paint e rimuovi le dipendenze inutilizzate. CSS: purga i selettori inutilizzati con PurgeCSS o JIT di Tailwind, inline CSS critico nella head e carica il resto in modo asincrono. Font: sottoinsieme ai glifi che usi e auto-host con font-display: swap. Un tipico audit di bloat riduce il peso totale del 40-60% al primo passaggio.

Sì, gravemente. Su una connessione 4G veloce (12 Mbps), il download di una pagina di 5 MB richiede circa 3,5 secondi prima che inizi il rendering. Su una connessione 3G lenta (1,6 Mbps), la stessa pagina richiede 25 secondi. Google Lighthouse simula un profilo "Slow 4G" precisamente perché le reti mobili reali sono più lente del marketing del vettore suggerisce. Il Web Almanac 2024 ha rilevato che il 53% degli utenti mobili abbandona le pagine che impiegano più di 3 secondi per caricarsi. Le pagine pesanti esauriscono anche i piani dati misurati in una singola visita. Punta a meno di 1 MB sui modelli mobile-first e abbina il checker con google-crawler-simulator per confermare che il bot mobile vede lo stesso payload leggero.

Usa AVIF come formato principale con fallback WebP per il 4% dei browser che mancano del supporto AVIF. AVIF comprime le foto il 50% più piccolo di JPEG a qualità visiva equivalente e il 20-30% più piccolo di WebP. Per un hero JPEG da 400 KB, la versione AVIF in genere pesa 90-130 KB. Usa l'elemento <picture> con <source type="image/avif"> e <source type="image/webp"> quindi un fallback JPEG <img>. Per le icone e la grafica semplice, usa SVG: si ridimensiona infinitamente, pesa meno di 5 KB per la maggior parte delle icone e si comprime bene con brotli. Evita PNG eccetto per gli screenshot che hanno bisogno di trasparenza senza perdita. Sostituisci GIF con un MP4 senza audio con autoplay o WebM, che pesa il 90% in meno.

Sì. Un peso completo di un font da Google Fonts o Adobe Fonts spesso pesa 80-120 KB perché include ogni glifo latino, cirillico, greco e vietnamita più l'intero set di punteggiatura. La maggior parte dei siti utilizza solo il latino base. Il sottoinsieme riduce il file a 18-25 KB, un risparmio del 75-85% per font. Strumenti come glyphhanger o Fontsource gestiscono il sottoinsieme automaticamente. Auto-host il file sottoinsiemato con font-display: swap in modo che il testo si renda immediatamente in un font di fallback e si ridipinga quando il font personalizzato si carica. Limita i pesi totali a due o tre (uno corpo, uno titolo, uno display opzionale). Ogni peso aggiuntivo è altri 18-25 KB più una richiesta di blocco del rendering a meno che non sia precaricato.

Esegui uno strumento di purga CSS rispetto alla tua build di produzione. PurgeCSS scansiona i modelli HTML e JS alla ricerca di nomi di classe e cancella qualsiasi selettore nel tuo CSS che non viene mai referenziato. Il compilatore JIT di Tailwind lo fa automaticamente. Per CSS scritto a mano, framework come Next.js, Astro e SvelteKit eseguono un passaggio di purga al momento della build. I risparmi sono di solito drammatici: un sito Bootstrap che spedisce il framework completo da 200 KB può scendere a 8-15 KB dopo la purga. Inline CSS critico per il contenuto sopra la piega nella head (in genere 10-15 KB) e carica il resto con <link rel="stylesheet" media="print" onload="this.media='all'">. Ricontrolla con il checker di dimensioni, quindi esegui h1-checker per confermare che l'HTML più leggero ha ancora una struttura di intestazione valida.

Il lazy loading rinvia il download di asset off-screen fino a quando l'utente non scorre vicino a loro. L'attributo HTML nativo loading="lazy" funziona su <img> e <iframe> nel 95% dei browser e non richiede zero JavaScript. Su una lunga pagina di articoli con 30 immagini, il lazy loading in genere rinvia 25 di loro, riducendo il payload iniziale del 60-80% e abbassando LCP di 1-2 secondi. Applicalo a ogni immagine e iframe sotto la piega, ma mai all'immagine LCP stessa, poiché il lazy loading dell'hero ritarda la metrica che stai cercando di migliorare. Combina con conversione di formato di immagine (AVIF o WebP) per guadagni composti. Il checker contrassegna le pagine con conteggi di immagini alti; se vedi 40+ immagini su una singola pagina, il lazy loading è il tuo maggiore guadagno disponibile.

La dimensione del documento HTML è i byte della risposta HTML stessa: il markup che il server ha restituito prima che il browser recuperasse qualsiasi sotto-risorsa. Il peso totale della pagina è la somma del documento HTML più ogni file CSS, file JS, immagine, font, video e iframe che la pagina carica. Una pagina può avere un documento HTML da 8 KB e un peso totale di 6 MB se carica immagini e script pesanti. Oppure può avere un documento da 250 KB pieno di contenuto inline e un totale di 400 KB. Il checker segnala la dimensione del documento HTML direttamente dalla risposta e stima il peso totale dagli asset dichiarati utilizzando le mediane del Web Almanac 2024. Il numero del documento HTML è più importante per il budget di crawl; il peso totale è più importante per LCP.

Gli header cache-control dicono al browser per quanto tempo mantenere un asset prima di richiederlo nuovamente. Un header di cache-control: public, max-age=31536000, immutable dice al browser di mantenere il file per un anno e di non rivalutare mai. I visitatori ripetuti scaricano zero byte per quell'asset. Il checker segnala il valore Cache-Control sulla risposta HTML in modo da poter verificare la configurazione del tuo CDN. L'HTML stesso di solito dovrebbe essere a breve cache (300-600 secondi) poiché il contenuto viene aggiornato di frequente. Gli asset statici (JS, CSS, font, immagini) con nomi file con hash dovrebbero essere messi in cache per un anno perché un cambio di contenuto crea un nuovo nome file. Senza un corretto caching, ogni caricamento di pagina è un caricamento a freddo.

Content-Encoding è l'header della risposta HTTP che dice al browser come il corpo è stato compresso. I valori comuni sono gzip, br (brotli), deflate, zstd o vuoto (non compresso). Il checker segnala qualsiasi cosa il tuo server abbia restituito. Se mostra gzip su una risposta di testo, stai risparmiando il 70-80% della larghezza di banda rispetto a non compresso. Se mostra br, risparmi un ulteriore 15-25% in più rispetto a gzip. Se è vuoto su una risposta HTML, CSS o JS superiore a 5 KB, il tuo server o CDN è mal configurato e ogni visitatore paga il peso completo non compresso. I formati binari (JPEG, PNG, WebP, AVIF, MP4) sono già compressi a livello di formato e in genere restituiscono Content-Encoding vuoto.