Il suo hero è una sezione a tutta larghezza con un'immagine di sfondo, impostata in Divi, Elementor o un altro builder. PageSpeed indica quella sezione come elemento Largest Contentful Paint, e tra gli avvisi elenca «Rilevamento richiesta LCP». Ha già compresso l'immagine. È ancora lenta.

Il peso raramente è il problema principale. Il problema è quando il browser scopre che l'immagine esiste.

Perché un'immagine di sfondo parte tardi

Un normale <img> sta nell'HTML: il browser lo individua nei primi byte e può richiederlo subito. Un'immagine di sfondo vive nel CSS. Il browser la trova solo dopo quattro passaggi:

scaricare l'HTML;
scaricare il foglio di stile che contiene la regola, spesso un file per pagina generato dal builder;
applicare gli stili e far corrispondere la regola alla sezione;
solo allora, richiedere l'immagine.

Due abitudini dei builder peggiorano le cose. Lo sfondo spesso non ha varianti di dimensione: un unico file da 1920 pixel per ogni schermo, telefoni compresi. E molti temi e plugin mettono gli sfondi in lazy load con uno script che aggiunge l'immagine quando la sezione entra nella vista. Se quello script è a sua volta ritardato fino alla prima interazione, l'hero aspetta che il visitatore si muova.

In breve

Uno sfondo viene scoperto solo dopo che il suo foglio di stile è stato scaricato e applicato.
Non ha srcset: i telefoni ricevono il file desktop.
Gli sfondi in lazy load aspettano uno script, a volte un'interazione.

Verificarlo sulla sua pagina

Nei DevTools, ispezioni la sezione hero e cerchi background-image negli stili calcolati. Annoti l'URL del file.
Nel pannello Network, con l'emulazione mobile, ricarichi e trovi quel file: guardi quanto tardi parte rispetto all'HTML e ai fogli di stile.
Controlli classi e attributi della sezione alla ricerca di un indicatore di lazy load, spesso una classe come lazyload o un attributo come data-bg.

Soluzione A (la migliore): trasformare l'hero in una vera immagine

Inserisca un <img> dentro la sezione, posizionato in modo da coprirla. L'aspetto è lo stesso, e ora il browser lo vede nell'HTML, può scegliere una larghezza dallo srcset e può dargli un'alta priorità:

HTML + CSS

<section class="hero">
  <img class="hero__bg" src="/uploads/hero-1920.webp"
       srcset="/uploads/hero-768.webp 768w, /uploads/hero-1920.webp 1920w"
       sizes="100vw" width="1920" height="900" alt="" fetchpriority="high">
  <div class="hero__content"><!-- titolo, pulsante --></div>
</section>

<style>
  .hero { position: relative; }
  .hero__bg { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; z-index: -1; }
</style>

Nella maggior parte dei builder si tratta di un modulo immagine posto nella sezione con lo stesso CSS, oppure di un blocco HTML personalizzato. L'alt vuoto la mantiene decorativa, come lo era lo sfondo.

Soluzione B: mantenere lo sfondo, ma farlo partire presto

Se il design deve restare uno sfondo:

Lo precarichi, con un preload per dispositivo se il builder usa uno sfondo diverso su mobile. Il metodo è nella nostra guida sull'immagine LCP per dispositivo.
Escluda l'hero da qualsiasi lazy load degli sfondi: nelle impostazioni del builder, nel plugin che lo aggiunge, oppure escludendo quella sezione.
Dia ai telefoni un file più piccolo: sia Divi sia Elementor permettono di impostare un'immagine di sfondo diversa per dispositivo. Carichi lì una versione in dimensioni mobile.
Inserisca la regola dell'hero nel critical CSS, così viene applicata al primo rendering invece di aspettare il foglio di stile completo.

Hero che parte presto

Una vera immagine con srcset e alta priorità, oppure uno sfondo precaricato, non in lazy load, con un file in dimensioni mobile.

Hero che parte tardi

Uno sfondo da 1920 pixel, messo in lazy load da uno script, a sua volta ritardato fino alla prima interazione.

Verificare il risultato

Pannello Network, emulazione mobile: l'immagine hero parte subito dopo l'HTML, non dopo i fogli di stile.
La sua dimensione corrisponde al dispositivo.
Compare senza muovere il mouse né scorrere.

Con Mantys Core

Mantys Core può gestire l'intero livello di performance, cache inclusa, oppure affiancarsi alla configurazione già in uso. Su un hero con immagine di sfondo, risolve il problema della scoperta:

Rileva, da rendering reali su mobile e desktop, quando l'LCP di una pagina è uno sfondo CSS, e precarica quell'immagine per quel dispositivo.
Il critical CSS di ogni pagina contiene le regole di ciò che è visibile al caricamento, così l'hero ha già il suo stile al primo rendering invece di aspettare il foglio di stile completo.

Il file in sé resta compito suo: uno sfondo ha una sola immagine per ogni schermo, quindi il peso su mobile si risolve con una vera immagine (soluzione A) o con uno sfondo per dispositivo nel suo builder.

In sintesi

Un'immagine di sfondo viene scoperta tardi: HTML, poi CSS, poi corrispondenza degli stili, poi l'immagine.
Non ha srcset, e i builder spesso la mettono in lazy load con uno script.
Soluzione migliore: una vera immagine che copre la sezione, con srcset e alta priorità.
Altrimenti: preload per dispositivo, niente lazy load sull'hero, un file in dimensioni mobile e la sua regola nel critical CSS.

Commenti

È bloccato su un problema simile? Descriva la sua configurazione e ciò che osserva. Leggiamo ogni commento e rispondiamo.

Ancora nessun commento. Condivida per primo il suo caso.