Il tuo menu ha un aspetto fantastico. Le animazioni dei dropdown sono fluide, gli stati hover sono curati, e il layout mobile è perfetto. Ma ogni volta che esegui un test Lighthouse, Google segnala il tuo CSS come render-blocking. Il tuo LCP è a 3,2 secondi su mobile, e la diagnostica dice che eliminare i fogli di stile render-blocking potrebbe risparmiare 800 millisecondi. Non sei sicuro di cosa significhi o come risolverlo senza rovinare il design.
Il problema non è il design. Il problema è la consegna. I browser non disegneranno nemmeno un pixel finché tutto il CSS nell’head del documento non sia scaricato e analizzato. Se il tuo menu carica un foglio di stile di 50KB, e la rete è lenta, l’intera pagina rimane bianca mentre il browser aspetta. L’immagine hero è pronta. Il titolo è pronto. Ma rimangono invisibili perché il browser sta ancora elaborando gli stili del menu.
Questo articolo spiega come il CSS blocca il rendering, quali stili del menu devono caricarsi subito, e come dividere il tuo foglio di stile affinché le parti critiche si carichino istantaneamente mentre il resto si carica dopo che la pagina è visibile.
- Tutti i file CSS esterni collegati nell'
<head>bloccano il rendering finché non finiscono di scaricarsi e analizzarsi. - Inserire il CSS critico inline (gli stili necessari per il contenuto above-the-fold) elimina il round trip di rete.
- La maggior parte del CSS del menu non è critica—solo la struttura del layout e lo spacing devono caricarsi subito.
- Gli effetti hover, le animazioni, e gli stili dei dropdown possono caricarsi dopo il disegno iniziale senza influire sull'esperienza utente.
- Un menu ben ottimizzato carica 2-5KB di CSS inline e rimanda il resto.
Come il CSS Blocca il Percorso di Rendering Critico
Il percorso di rendering critico è la sequenza di passi che un browser compie per trasformare HTML, CSS, e JavaScript in pixel visibili sullo schermo. I passi sono: scarica HTML, analizza HTML, scarica CSS, analizza CSS, costruisci l’albero di rendering, calcola il layout, disegna i pixel.
Il CSS è render-blocking per design. Il browser non disegnerà nulla finché tutti i fogli di stile nell’head del documento non siano completamente caricati e analizzati. Questo previene Flash of Unstyled Content (FOUC), dove la pagina appare con gli stili predefiniti del browser per una frazione di secondo prima che i veri stili si applichino.
Ecco la sequenza temporale per un tipico negozio Shopify con un foglio di stile menu esterno:
- Browser scarica HTML (200ms su 4G)
- Browser analizza HTML, incontra
<link rel="stylesheet" href="menu.css"> - Browser inizia a scaricare
menu.css(300ms per un file di 40KB su 4G) - Browser finisce di scaricare e analizzare
menu.css(50ms tempo di analisi su mobile mid-range) - Browser può ora iniziare a disegnare la pagina
Tempo totale al primo disegno: 550ms, solo per il CSS del menu. Aggiungi il foglio di stile principale del tema, e stai guardando oltre un secondo di ritardo prima che qualcosa appaia.
Secondo la documentazione web.dev di Google su render-blocking resources, eliminare o rimandare il CSS che non è immediatamente necessario è uno dei modi più efficaci per migliorare LCP e First Contentful Paint.
Cosa Conta come CSS Critico del Menu
Non tutti gli stili del menu devono caricarsi prima del primo disegno. Solo gli stili necessari per rendere il menu above-the-fold senza layout shift sono critici. Tutto il resto può caricarsi dopo.
Critico (deve caricarsi subito)
- Struttura del layout: Proprietà display, regole flexbox/grid, positioning per il contenitore menu.
- Spacing: Padding, margin, altezza, larghezza per riservare lo spazio corretto.
- Visibilità di base: Regole display/visibility affinché il menu appaia nel posto giusto.
- Dimensione font e line height: Previene il riflusso del testo quando il foglio di stile completo si carica.
Non-critico (può essere rimandato)
- Colori e sfondi: Il menu può rendere in colori predefiniti inizialmente senza causare layout shift.
- Effetti hover e transizioni: Questi si applicano solo all’interazione, non al carico iniziale.
- Stili dropdown: Su desktop, i dropdown sono nascosti finché l’utente non passa sopra. Su mobile, sono nascosti finché l’utente non tocca l’hamburger. Questi stili possono caricarsi dopo che la pagina è visibile.
- Icone e elementi decorativi: Chevron menu, linee divisorie, stili badge—tutti non essenziali per il rendering iniziale.
L’obiettivo è inserire inline solo abbastanza CSS per prevenire layout shift e rimandare il resto.
Inserire CSS Critico Inline: Quando e Come
Inserire CSS inline significa scriverlo direttamente in un tag <style> nell’HTML, piuttosto che collegare a un file esterno. Questo elimina il round trip di rete, che è la fonte principale del ritardo render-blocking.
Ecco un esempio di CSS inline critico per un menu di navigazione:
<style>
.menu-container {
display: flex;
align-items: center;
height: 60px;
padding: 0 20px;
}
.menu-nav {
display: flex;
gap: 24px;
}
.menu-link {
font-size: 16px;
line-height: 1.5;
text-decoration: none;
}
@media (max-width: 768px) {
.menu-nav { display: none; }
.menu-toggle { display: block; }
}
</style>
Questo è circa 300 byte. Riserva lo spazio corretto per il menu, previene layout shift, e assicura che la struttura del menu sia in posto prima che la pagina si disegni. Il resto degli stili del menu—colori, effetti hover, animazioni dropdown—caricano da un foglio di stile esterno dopo il disegno iniziale.
Quando Inserire Inline
Inserisci CSS critico inline quando:
- Il CSS è piccolo (sotto 5KB come linea guida approssimativa).
- Gli stili sono necessari per il contenuto above-the-fold su ogni pagina.
- La latenza di rete è un costo più grande del costo di parsing.
Per i menu di navigazione, inserire inline è quasi sempre la scelta giusta. Il menu appare su ogni pagina, e il sottoinsieme critico di stili è minuscolo.
Quando Non Inserire Inline
Non inserire CSS inline se:
- Il foglio di stile è grande (oltre 10KB). Inserire inline CSS grande gonfia l’HTML e può rallentare il parsing dell’HTML.
- Gli stili sono necessari solo su pagine specifiche. Inserire inline CSS specifico della pagina su ogni pagina spreca larghezza di banda.
- Il CSS cambia frequentemente. Il CSS inserito inline non è memorizzato nella cache separatamente—fa parte dell’HTML, quindi ogni richiesta HTML include il CSS.
Per le app menu con stili estesi (mega menu con immagini, animazioni complesse, multiple layout modes), inserisci inline solo la struttura del layout e rimanda il resto.
Caricare CSS Non-Critico Senza Bloccare il Render
Una volta identificato il CSS critico e inserito inline, il passo successivo è caricare il resto del CSS senza bloccare il render. Ci sono due approcci comuni.
Approccio 1: Preload e Swap
Usa <link rel="preload"> per scaricare il foglio di stile in background, poi applicalo asincronamente.
<link rel="preload" href="menu.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="menu.css"></noscript>
Il preload dice al browser di recuperare menu.css con alta priorità ma non blocca il rendering. L’evento onload cambia rel="preload" a rel="stylesheet", che applica gli stili una volta che il file finisce di scaricarsi. Il fallback <noscript> assicura che gli stili si carichino normalmente se JavaScript è disabilitato.
Questo approccio è ampiamente supportato e funziona in tutti i browser moderni.
Approccio 2: Media Query Trick
Carica il foglio di stile con una media query che non corrisponde, poi scambiala a all dopo il carico.
<link rel="stylesheet" href="menu.css" media="print" onload="this.media='all'">
L’attributo media="print" dice al browser che il foglio di stile è solo per la stampa, quindi non blocca il rendering dello schermo. Una volta che il file si carica, l’evento onload cambia la media query a all, applicando gli stili allo schermo.
Questo è un trucco, ma funziona in modo affidabile e richiede meno JavaScript rispetto all’approccio preload.
Dividere il Tuo Foglio di Stile Menu
La maggior parte delle app menu Shopify si spediscono con un singolo file CSS monolitico che include layout, colori, animazioni, breakpoint responsive, e stili icon. Per ottimizzare il percorso critico, devi dividere questo file in due parti: critica e non-critica.
Ecco un flusso di lavoro pratico.
Passo 1: Identifica i Selettori Critici
Apri Chrome DevTools, vai alla scheda Coverage (sotto More Tools), e ricarica la pagina. Chrome ti mostrerà quali regole CSS vengono usate durante il rendering iniziale. Tutto il resto è non-critico.
Per un menu di navigazione, i selettori critici tipicamente includono:
.menu-container,.menu-nav,.menu-logo- Proprietà layout:
display,flex,grid,position,width,height,padding,margin - Breakpoint responsive per il layout above-the-fold
Passo 2: Estrai il CSS Critico
Copia i selettori critici in un nuovo file, menu-critical.css. Minificalo (rimuovi spazi bianchi e commenti). Il risultato dovrebbe essere 2-5KB.
Passo 3: Inserisci il CSS Critico Inline
Converti menu-critical.css in un blocco <style> nell’<head> del tuo tema. In Shopify Liquid:
<style>
{% include 'menu-critical.css' %}
</style>
O incolla il CSS direttamente nel tag <style>.
Passo 4: Rimanda il Foglio di Stile Completo
Carica il file menu.css completo asincronamente usando uno dei metodi descritti precedentemente.
<link rel="preload" href="menu.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
Ora gli stili di layout critici si caricano istantaneamente (nessun ritardo di rete), e il resto degli stili si carica in parallelo senza bloccare la pagina.
Ottimizzazione CSS Specifica di Shopify
I temi Shopify usano il filtro file.css per caricare il CSS. Di default, questo genera un tag <link rel="stylesheet"> standard, che è render-blocking.
Per rendere un foglio di stile non-blocking, sostituisci il filtro con un tag manuale:
<link rel="preload" href="menu.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="menu.css"></noscript>
Per le sezioni di tema che caricano CSS dinamicamente, l’API Section Rendering di Shopify non applica automaticamente strategie preload. Se il tuo menu è una sezione, devi assicurare che il CSS critico sia inserito inline nel file theme.liquid principale, non nel foglio di stile della sezione stessa.
Alcune app menu Shopify, come Navi+, dividono automaticamente il loro CSS in parti critiche e non-critiche e gestiscono il caricamento asincrono per te. Se la tua app menu attuale non supporta questo, vale la pena chiedere allo sviluppatore di aggiungerlo o passare a uno strumento che già lo fa.
Misurare l’Impatto
Prima e dopo aver ottimizzato il tuo CSS del menu, misura il miglioramento con Lighthouse o PageSpeed Insights. Cerca tre metriche specifiche:
- First Contentful Paint (FCP): Il momento in cui il primo testo o immagine appare. Inserire inline CSS critico riduce FCP eliminando richieste di rete render-blocking.
- Largest Contentful Paint (LCP): Il momento in cui l’elemento visibile più grande finisce di renderizzare. Rimuovere CSS render-blocking consente all’immagine hero o al titolo di disegnarsi più velocemente.
- Cumulative Layout Shift (CLS): Una misura della stabilità visiva. Il CSS critico inserito inline correttamente riserva spazio per il menu, prevenendo che sposti il contenuto della pagina verso il basso mentre si carica.
Dovresti vedere FCP e LCP scendere di 200-600ms su mobile dopo aver rimandato il CSS menu non-critico. Se non vedi miglioramento, controlla se ci sono altri fogli di stile render-blocking (CSS tema, CSS app) che hanno ancora bisogno di ottimizzazione.
Un errore comuneAlcuni commercianti inseriscono inline l'intero foglio di stile menu per eliminare il render-blocking, ma questo si ritorce contro se il file è grande. Un foglio di stile inline di 50KB gonfia l'HTML, rallenta il parsing dell'HTML, e previene che il CSS sia memorizzato nella cache. Inserisci inline solo il sottoinsieme critico (2-5KB), e rimanda il resto.
Mobile Conta di Più
Le connessioni desktop sono veloci. Un file CSS di 40KB su banda larga aggiunge forse 50 millisecondi di ritardo. Su mobile, lo stesso file su una connessione 4G aggiunge 300 millisecondi. Su una connessione 3G lenta, può aggiungere 800 millisecondi.
I Core Web Vitals di Google sono misurati separatamente per mobile e desktop, e mobile è ponderato più pesantemente nei ranking di ricerca perché il traffico maggiore è mobile. Ottimizzare il tuo CSS menu per mobile non è opzionale—è la linea di base.
Testa il tuo negozio su un dispositivo reale su una connessione mobile reale, o usa Chrome DevTools con il throttling abilitato (Fast 3G o Slow 3G). Vedrai il vero costo del CSS render-blocking, e il miglioramento dall’inserimento inline e dal rimando diventa ovvio.
Come Appare un Buon Caricamento di CSS Menu
Un menu di navigazione ben ottimizzato carica il CSS in due stadi. Per primo, un piccolo blocco inline di CSS critico (2-5KB) che definisce struttura del layout, spacing, e breakpoint responsive. Questo si carica istantaneamente come parte dell’HTML. Secondo, il foglio di stile completo (30-50KB) con colori, effetti hover, animazioni, e stili dropdown, caricato asincronamente usando preload o il media query trick.
La pagina diventa visibile entro 1-2 secondi, anche su una connessione mobile lenta. Il menu appare nella posizione corretta senza spostare il layout. Gli stili completi si applicano una frazione di secondo dopo, impercettibilmente all’utente ma misurabilmente al calcolo LCP di Google.
Questo non è teorico. I negozi che implementano questo schema tipicamente vedono mobile LCP migliorare di 400-700 millisecondi, passando da “needs improvement” a “good” nei report Core Web Vitals. Il menu ancora guarda e funziona esattamente nello stesso modo, ma il browser non deve più aspettare il foglio di stile completo prima di disegnare la pagina.
This article is part of the larger guide on Menu and LCP: how navigation blocks your largest contentful paint.