Guida all'ottimizzazione immagini mobile per pagine più veloci

Ultimo aggiornamento: June 28, 2026

L'ottimizzazione delle immagini per dispositivi mobili inizia con un vincolo: uno smartphone non dovrebbe scaricare pixel che non può visualizzare. Ridimensiona la sorgente, servi varianti responsive, tieni l'immagine più grande sopra la piega fuori dal lazy loading e pubblica file WebP o AVIF indicizzabili tramite una CDN.

Risposta rapida: come dovresti ottimizzare le immagini per il mobile?

Usa questo ordine: ridimensiona prima, codifica secondo, consegna terzo, misura alla fine. Una foto di prodotto da 4000 px mostrata a 390 px di larghezza è uno spreco anche se compressa. Il browser deve comunque scaricarla, decodificarla e ridimensionarla prima che la pagina sembri pronta.

Per la maggior parte delle pagine mobile, invia un set sorgente WebP o AVIF con larghezze intorno a 400, 800 e 1200 px. Mantieni un fallback JPEG se il tuo pubblico include browser vecchi, client di posta elettronica o feed di partner. Per una decisione più approfondita sul formato, usa il AVIF vs WebP comparison.

Le linee guida LCP di Google dicono che le pagine dovrebbero puntare a Largest Contentful Paint entro 2.5 secondi o meno al 75th percentile, suddiviso per mobile e desktop. Le immagini sono spesso l'elemento LCP, quindi l'immagine eroe merita una gestione speciale: precaricarla o priorizzarla, impostarle dimensioni reali e non lazy-loadarla.

Cosa cambia effettivamente su un telefono?

Uno smartphone cambia tre cose contemporaneamente: la larghezza del viewport, la qualità della rete e la densità del layout. Le immagini desktop spesso falliscono sul mobile perché la pagina mantiene lo stesso asset da 1600 px, ritaglia male il soggetto o ritarda l'eroe dietro JavaScript.

Ho generato un grafico sorgente 1600 x 1000 ed è stato codificato come WebP q82 a tre larghezze. Il risultato mostra perché ridimensionare batte la modifica della qualità:

Questi numeri sono illustrativi, non universali. Una foto dettagliata sarà più grande di questo grafico pulito e un logo piatto sarà più piccolo. La regola utile è stabile: far scegliere al browser tra candidati di larghezza reali invece di un file sovradimensionato.

Quali dimensioni di immagine mobile dovresti creare?

Inizia dallo slot renderizzato, non dal file della fotocamera. Ispeziona il tuo template ai breakpoint comuni e registra la larghezza CSS massima per ogni tipo di immagine.

Usa i descrittori di larghezza quando la larghezza del layout cambia:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Bottiglia d'acqua riutilizzabile su un piano cucina"
>

La guida alle immagini responsive di MDN spiega il modello di selezione srcset e sizes. La versione breve: srcset elenca i candidati, e sizes dice al browser quanto sarà largo lo slot renderizzato prima che il layout sia completo.

Per un flusso di lavoro in batch, genera larghezze dallo stesso file master. La guida al ridimensionamento in batch copre lo schema da riga di comando e la analisi approfondita della compressione delle immagini spiega perché il ridimensionamento dovrebbe avvenire prima della compressione finale.

Quando dovresti usare picture per i ritagli mobile?

Usa <picture> quando l'immagine mobile ha bisogno di un ritaglio diverso, non solo di un file più piccolo. Un hero desktop ampio può diventare inutile su uno smartphone se il soggetto si trova all'estrema sinistra o l'area di testo copre il prodotto.

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Scarpa da trail running con la suola visibile"
  >
</picture>

Usa l'art direction per:

1. Immagini eroe di prodotti dove il prodotto diventa minuscolo su mobile.
2. Banner editoriali dove un viso o un oggetto deve rimanere centrato.
3. Elenchi marketplace che richiedono miniature quadrate e immagini dettagliate ampie.
4. Immagini prima/dopo dove entrambi i lati devono rimanere leggibili.
5. Screenshot con testo piccolo che richiede un ritaglio più stretto.

Non usare <picture> come sostituto delle normali larghezze responsive. Se la composizione è la stessa, srcset più sizes è più semplice.

Come si inseriscono WebP, AVIF e JPEG nelle performance mobile?

Usa WebP come formato mobile base quando hai bisogno di un file moderno che funzioni ampiamente. Usa AVIF quando il tuo pipeline può generarlo e puoi mantenere WebP o JPEG fallback. Mantieni JPEG per email, vecchi sistemi partner e archivi sorgente che altri strumenti devono aprire.

La checklist completa per l'ottimizzazione delle immagini copre la sequenza di pubblicazione più ampia. Se devi confrontare strumenti che producono WebP e AVIF, vedi TinyPNG alternatives.

Usa uno stack <picture> quando puoi:

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Tazza di ceramica blu accanto a un quaderno">
</picture>

Come dovrebbe funzionare il lazy loading su mobile?

Lazy-load le immagini che iniziano sotto il primo viewport. Non fare lazy-load all'immagine LCP. Il lazy loading a livello browser è utile, ma non è un piano di performance di per sé.

La guida al lazy loading a livello browser di Google raccomanda loading="lazy" nativo per le immagini fuori schermo. La stessa guida avverte dal lazy-loadare immagini immediatamente visibili perché può ritardare i contenuti che gli utenti stanno aspettando.

Usa questa checklist:

1. Dare all'immagine eroe loading="eager" o omettere loading.
2. Aggiungere fetchpriority="high" all'immagine LCP più probabile.
3. Aggiungere loading="lazy" alle immagini dopo il primo schermo.
4. Impostare width e height su ogni immagine.
5. Usare CSS aspect-ratio quando il rapporto renderizzato cambia con i breakpoint.
6. Evitare l'iniezione di immagini solo tramite JavaScript per l'eroe.
7. Verificare che gli URL delle immagini CDN includano intestazioni cache lunghe.
8. Testare su un profilo mobile limitato, non solo Wi-Fi desktop.
9. Controllare l'elemento LCP in PageSpeed Insights.
10. Riassegnare dopo i cambiamenti di design, perché l'elemento LCP può cambiare.

La documentazione LCP di Google elenca elementi immagine, poster video e immagini di sfondo tra i possibili candidati LCP. Ecco perché un hero di sfondo può comunque danneggiare LCP anche se non è un <img>.

Cosa dovrebbe fare un CDN per le immagini per il mobile?

Un image CDN dovrebbe rimuovere lavori manuali ripetitivi: ridimensionare al bordo, negoziare il formato, mettere in cache varianti e mantenere stabili gli URL pubblici. Il CDN non sostituisce l'igiene della sorgente. Caricare una foto di prodotto sfocata da 900 px su un image CDN non creerà dettagli reali da 1600 px.

Cerca questi controlli:

• Trasformazioni di larghezza per slot mobile e desktop comuni.
• Output WebP e AVIF con il Content-Type corretto.
• Chiavi cache che includono larghezza, qualità e formato.
• Un modo per preservare i caricamenti originali separatamente dai derivati pubblici.
• URL pubblici stabili che Google Images può indicizzare.
• Monitoraggio dei 404 dopo deploy e migrazioni.

Per la ricerca, le migliori pratiche SEO per immagini di Google enfatizzano immagini utili e visibili vicino al testo pertinente, nomi file e alt text descrittivi e URL immagine indicizzabili. Un URL CDN va bene quando è indicizzabile, stabile e referenziato dalla pagina.

Cosa dovresti testare prima della pubblicazione?

Testa la pagina come lo riceve un visitatore mobile. Una singola esecuzione Lighthouse è utile, ma può nascondere mancanze del CDN, candidati responsive sovradimensionati e spostamenti di layout che compaiono solo nei template reali.

Un comando pratico per un audit locale:

curl -I https://cdn.example.com/images/product-card-480.webp

Poi verifica la pagina renderizzata a un viewport stretto. Se una tabella o un'immagine supera lo schermo, correggi il layout prima di festeggiare i risparmi di byte.

Checklist SEO immagini mobile e GEO

I motori di ricerca e gli answer engine hanno bisogno della stessa cosa di una persona: contesto diretto. Non seppellire le immagini in un carosello senza alcuna spiegazione nelle vicinanze e aspettarti che l'asset abbia significato da solo.

Prima di pubblicare, conferma:

1. La pagina ha una risposta chiara vicino all'inizio.
2. Ogni immagine importante ha alt text descrittivo.
3. I nomi file descrivono il soggetto visibile, non IMG_9021.
4. L'URL dell'immagine è indicizzabile senza cookie.
5. Il paragrafo circostante spiega perché l'immagine è presente.
6. L'eroe mobile non è più grande dello slot renderizzato che ne ha bisogno.
7. Le immagini del corpo usano loading="lazy" solo quando sono sotto il primo viewport.
8. Le tabelle riassumono decisioni che un lettore può riutilizzare.
9. Le affermazioni esterne linkano a fonti autorevoli.
10. I link interni puntano al prossimo flusso di lavoro reale, non a una pagina cluster casuale.

Per il passaggio specifico SEO dopo la compressione, usa image optimization for seo checklist. Per lavori su file singoli, Image Compressor, Image Converter e Image Resizer coprono i passaggi manuali comuni.

Crediti immagine

• Copertina, grafico larghezza responsive, ritaglio art-direction e grafico priorità di caricamento sono stati generati per questo articolo con ImageMagick ed esportati come WebP. Il grafico larghezza responsive utilizza l'output misurato WebP q82 dallo stesso grafico sorgente 1600 x 1000.