La maggior parte delle guide sui Core Web Vitals ti dà 12 cose da sistemare. È opprimente. Non farai tutti e 12. Non farai nulla.
Ecco cosa funziona davvero. Sistemare tre cose. Ottenere l’80% dei risultati. Proseguire con la tua vita.
Quello che imparerai
Questa guida ti mostra come dare priorità ai fix dei Core Web Vitals senza sprecare tempo. Imparerai quali metriche contano di più per il tuo tipo di sito. Imparerai i tre fix che fanno la differenza. Imparerai a misurare i risultati in circa 15 minuti.
Questo non è teoria. È quello che funziona per le piccole aziende e le agenzie che non hanno un ingegnere della performance a tempo pieno.
101: Perché i Core Web Vitals contano veramente
I Core Web Vitals misurano la velocità di caricamento del tuo sito e quanto stabile appare. Google li utilizza come fattore di ranking. Ancora più importante, i siti lenti perdono clienti.
Ci sono tre metriche:
Largest Contentful Paint (LCP) misura la velocità di caricamento. Tiene traccia del tempo necessario per la visualizzazione del contenuto principale. Buono è sotto 2,5 secondi. La maggior parte dei siti di piccole aziende raggiunge 3,5-4,5 secondi.
Interaction to Next Paint (INP) misura la reattività. Tiene traccia di quanto velocemente il tuo sito reagisce quando qualcuno fa clic o tocca. Buono è sotto 200 millisecondi. I siti pesanti di JavaScript spesso raggiungono 400-600 millisecondi.
Cumulative Layout Shift (CLS) misura la stabilità visiva. Tiene traccia di quanto la tua pagina salta durante il caricamento. Buono è sotto 0,1. I siti con annunci o immagini caricate lentamente spesso raggiungono 0,3 o superiore.
La maggior parte dei siti non supera almeno uno di questi. Il sito medio di una piccola azienda ne fallisce due.
La ricerca di HubSpot del 2024 ha riscontrato che il 75% degli utenti non scorre mai oltre la prima pagina dei risultati di ricerca. I Core Web Vitals sono un elemento di differenziazione quando la qualità del contenuto è uguale. Se il tuo concorrente ha lo stesso contenuto ma si carica più velocemente, occupa un ranking più alto.
Il problema dei consigli attuali
Cerca l’ottimizzazione dei Core Web Vitals. Troverai guide complete. Elencano 12-15 tattiche. Coprono ogni caso limite.
Sono corretti. Sono anche inutili.
Un proprietario di taqueria non ha tempo per implementare 15 ottimizzazioni della performance. Un’agenzia che gestisce 30 siti client non può controllare manualmente ogni file JavaScript.
Le guide complete mancano il punto. Hai bisogno di sapere cosa sistemare per primo. Hai bisogno di sapere cosa muove davvero i tuoi numeri.
Gli strumenti SEO tradizionali peggiorano le cose. Ti danno dump di dati. Ricevi 100 problemi senza priorità. Ricevi gergo tecnico senza contesto. Passi ore cercando di capire quale problema conta.
Lighthouse ti dà un punteggio di performance. Non ti dice se sistemare prima le tue immagini o il tuo JavaScript. PageSpeed Insights ti mostra cosa è lento. Non ti dice quale fix ti sposterà da fallimento a successo.
201: I tre fix che contano davvero
Fix 1: Ottimizza il tuo elemento Largest Contentful Paint
LCP è quasi sempre il tuo problema più grande. È anche il più facile da sistemare.
Il tuo elemento LCP è solitamente la tua immagine hero o il tuo titolo principale. La maggior parte dei siti carica questo lentamente perché l’immagine è enorme e non compressa.
Site Audit ha rilevato questo sul nostro sito. Avevamo un’immagine hero di 2,4 MB che veniva visualizzata solo a 1200 pixel di larghezza. L’immagine è stata scattata a 4000 pixel. Quei pixel extra non facevano nulla se non rallentarci.
Ecco cosa fare:
Converti la tua immagine hero nel formato WebP. I file WebP sono il 30% più piccoli dei JPEG con la stessa qualità. Puoi utilizzare strumenti gratuiti come Squoosh o CloudConvert. I browser moderni supportano WebP. Safari ha aggiunto il supporto nel 2020. Edge ha aggiunto il supporto nel 2018.
Ecco l’HTML:
<picture>
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="Your hero image" width="1200" height="800">
</picture>Il browser carica WebP se supportato. Torna a JPEG per i browser più vecchi.
Ridimensiona l’immagine in modo che corrisponda alla dimensione di visualizzazione effettiva. Se la tua immagine hero viene visualizzata a 1200 pixel di larghezza, non caricare un’immagine a 4000 pixel. Usa 1200 pixel per il desktop. Usa 800 pixel per il mobile. Fornisci diverse dimensioni in base alla larghezza dello schermo.
Ecco il codice:
<img
src="hero-1200.webp"
srcset="hero-800.webp 800w, hero-1200.webp 1200w"
sizes="(max-width: 768px) 800px, 1200px"
alt="Your hero image"
width="1200"
height="800"
>Aggiungi attributi di larghezza e altezza al tuo tag immagine. Questo dice al browser quanto spazio riservare. Previene lo spostamento del layout mentre l’immagine si carica. I browser moderni usano questi per calcolare automaticamente le proporzioni.
Usa una Content Delivery Network (CDN). Le CDN forniscono le tue immagini da server vicini ai tuoi visitatori. CloudFlare e BunnyCDN hanno entrambi livelli gratuiti. Una CDN in genere riduce il tempo di caricamento dell’immagine del 40%-60%.
Aggiungi fetchpriority=“high” alla tua immagine LCP. Questo dice al browser di caricare questa immagine prima di altre risorse. È un suggerimento, non un comando. I browser lo rispettano quando possono.
<img
src="hero.webp"
alt="Your hero image"
width="1200"
height="800"
fetchpriority="high"
>Questo fix da solo può ridurre il tuo LCP da 4 secondi a 2 secondi. Questa è la differenza tra un punteggio di passaggio e di fallimento.
Errori comuni con l’ottimizzazione LCP:
Non usare il lazy loading per il tuo elemento LCP. Il lazy loading dice al browser di aspettare. Il tuo elemento LCP dovrebbe caricarsi immediatamente.
Non mettere il tuo elemento LCP sotto la piega. LCP misura il contenuto visibile più grande. Se il tuo hero è piccolo e il tuo contenuto principale è più in basso, ottimizza il contenuto che effettivamente mostra per primo.
Non comprimere le immagini troppo aggressivamente. WebP all’80% di qualità va bene. WebP al 40% di qualità sembra terribile. Gli utenti notano i cali di qualità. Trova l’equilibrio.
Fix 2: Rinvia il JavaScript non critico
JavaScript blocca il rendering. Il browser deve scaricare, analizzare ed eseguire ogni script prima di mostrare la tua pagina. La maggior parte di quel JavaScript non fa nulla al caricamento iniziale.
Il sito medio di una piccola azienda carica 8-12 file JavaScript al caricamento della pagina. La maggior parte di quei file alimenta funzioni sotto la piega. Non hanno bisogno di caricarsi per primi.
Ecco cosa fare:
Aggiungi l’attributo defer ai tuoi tag script. Questo dice al browser di scaricare lo script in background ed eseguirlo dopo il caricamento della pagina.
<!-- Before: blocks rendering -->
<script src="analytics.js"></script>
<!-- After: loads in background -->
<script src="analytics.js" defer></script>L’attributo defer mantiene l’ordine di esecuzione dello script. Se lo script B dipende dallo script A, si eseguono comunque in ordine. Semplicemente non bloccano il rendering.
Sposta gli script di analisi e tracciamento nella parte inferiore della tua pagina. Google Analytics non ha bisogno di caricarsi prima dell’apparizione del tuo contenuto. Nemmeno Facebook Pixel. Nemmeno il widget della chat dal vivo.
Metti questi script subito prima del tag di chiusura </body>. Si caricano dopo tutto il resto.
Rimuovi completamente il JavaScript inutilizzato. La maggior parte dei siti WordPress carica jQuery per funzioni che non utilizza. Molti temi caricano librerie di animazione che alimentano un pulsante.
Controlla quali script si attivano effettivamente al caricamento della pagina. Apri Chrome DevTools. Vai alla scheda Coverage. Aggiorna la tua pagina. Chrome ti mostra quanto di ogni file JavaScript si esegue effettivamente.
Se un file è inutilizzato all’80%, probabilmente non ne hai bisogno. Rimuovilo o dividilo in file più piccoli.
Usa async per gli script che non dipendono l’uno dall’altro. L’attributo async scarica gli script in parallelo e li esegue non appena finiscono di scaricarsi. Usa async per script indipendenti come l’analisi.
<script src="analytics.js" async></script>
<script src="chat-widget.js" async></script>Non usare async per gli script che dipendono l’uno dall’altro. Se lo script B ha bisogno che lo script A si esegua per primo, usa defer invece.
Questo fix in genere migliora l’INP di 100-200 millisecondi. Accelera anche l’LCP perché il browser può concentrarsi sul contenuto invece che sui script.
Errori comuni con l’ottimizzazione JavaScript:
Non rinviare JavaScript che aggiunge funzionalità critiche. Se la tua navigazione principale richiede JavaScript per funzionare, non rinviarla. Gli utenti vedranno un menu rotto.
Non async tutto alla cieca. Async cambia l’ordine di esecuzione. Se i tuoi script dipendono l’uno dall’altro, async li romperà.
Non rimuovere JavaScript senza testare. Rimuovi un file alla volta. Controlla che tutto funzioni ancora. Quindi passa al file successivo.
Fix 3: Specifica le dimensioni di immagini ed elementi
Lo spostamento del layout si verifica quando gli elementi si caricano senza dimensioni definite. Il browser indovina quanto spazio riservare. Il browser indovina male. La tua pagina salta in giro.
Questo è il problema più fastidioso dei Core Web Vitals per gli utenti. Il contenuto si sposta mentre leggono. Fanno clic su un collegamento. La pagina salta. Fanno clic sulla cosa sbagliata.
Ecco cosa fare:
Aggiungi attributi di larghezza e altezza espliciti a ogni immagine. I browser moderni usano questi per calcolare le proporzioni e riservare spazio.
<!-- Before: no dimensions, causes layout shift -->
<img src="product.jpg" alt="Product photo">
<!-- After: browser reserves correct space -->
<img src="product.jpg" alt="Product photo" width="600" height="400">Non devi corrispondere esattamente alla dimensione di visualizzazione. Il browser scala proporzionalmente. Hai solo bisogno di dargli le proporzioni corrette.
Imposta le dimensioni per annunci e incorporamenti prima che si carichino. Se esegui Google Ads, riserva le dimensioni esatte in pixel nel tuo CSS. Se incorpori video YouTube, riserva lo spazio 16:9 prima che l’incorporamento si carichi.
.ad-container {
width: 300px;
height: 250px;
background: #f0f0f0;
}Carica i web font con font-display swap. Questo mostra i font di sistema immediatamente e passa al tuo font personalizzato quando pronto. Evita il testo invisibile e il riflusso del layout.
@font-face {
font-family: 'YourFont';
src: url('your-font.woff2') format('woff2');
font-display: swap;
}Il testo appare immediatamente in un font di fallback. Quando il tuo font personalizzato si carica, cambia. È meglio aspettare il caricamento del font prima di mostrare alcun testo.
Evita di iniettare contenuto sopra il contenuto esistente. Se usi il lazy loading per immagini o annunci, inseriscili sotto la piega dove non spingeranno il contenuto verso il basso.
Usa l’attributo loading="lazy" per le immagini sotto la piega. Questo rinvia il caricamento fino a quando l’utente non scorre vicino a loro.
<img src="below-fold.jpg" alt="Image below fold" loading="lazy" width="800" height="600">Questo fix può abbassare il tuo CLS da 0,3 a sotto 0,1. Questa è la differenza tra un voto di fallimento e un punteggio perfetto.
Errori comuni con lo spostamento del layout:
Non iniettare banner promozionali nella parte superiore della pagina dopo il caricamento. Gli utenti lo odiano. Rovina la loro esperienza di lettura. Se devi mostrare un banner, riserva spazio per esso nel tuo HTML iniziale.
Non usare animazioni CSS che cambiano le dimensioni degli elementi. Le animazioni che ingrandiscono o rimpiccioliscono gli elementi causano lo spostamento del layout. Usa invece transform. Le transform non influiscono sul layout.
Non caricare i font senza fallback. Se il tuo font personalizzato non riesce a caricarsi, gli utenti dovrebbero comunque vedere il testo. Definisci uno stack di font di fallback nel tuo CSS.
Come sapere cosa sistemare sul tuo sito
I tre fix sopra funzionano per la maggior parte dei siti. Ma il tuo sito potrebbe essere diverso.
I siti di e-commerce di solito falliscono l’LCP a causa delle immagini dei prodotti. Hai dozzine di foto ad alta risoluzione. Quelle foto sono spesso da 3 a 5 MB ciascuna. Comprimerle dimezza l’LCP.
I siti SaaS di solito falliscono l’INP a causa dei dashboard pesanti di JavaScript. Hai framework, gestione dello stato e aggiornamenti in tempo reale. Rinviare gli script non critici migliora la reattività.
I siti di notizie di solito falliscono l’CLS a causa degli annunci e del caricamento pigro. Inietti annunci tra i paragrafi. Usi il lazy loading per le immagini negli articoli. Entrambi causano lo spostamento del layout.
Hai bisogno di sapere quale metrica è il tuo anello debole. Hai bisogno di sapere quale fix sposterà i tuoi numeri specifici.
301: Perché i tool tradizionali mancano il segno
PageSpeed Insights ti dà i punteggi. Lighthouse ti dà le opportunità. Nessuno dei due ti dice cosa sistemare per primo.
Ricevi un elenco di 20 problemi. Ogni problema ha un potenziale risparmio di tempo. Il problema che risparmia 2 secondi sembra più importante del problema che risparmia 0,5 secondi.
Quella matematica è fuorviante.
Il risparmio di 2 secondi potrebbe richiedere la riscrittura dell’intera architettura JavaScript. Il risparmio di 0,5 secondi potrebbe richiedere la compressione di un’immagine. Uno richiede 40 ore. Uno richiede 5 minuti.
I tool tradizionali non tengono conto della difficoltà di implementazione. Non ti dicono quali fix ti spostano da fallimento a successo. Semplicemente gettano i dati e ti lasciano capirlo.
Site Audit esegue un audit tecnico in circa 15 minuti. Piani a partire da $50/lavoro. Controlla tutte e tre le metriche dei Core Web Vitals. Ti dice esattamente quali elementi ti stanno rallentando. Classifica i fix per impatto in modo da sapere cosa fare per primo.
Ottieni un rapporto completo con proiezioni prima e dopo. Ottieni i file e i numeri di riga specifici da modificare. Ottieni un file JSON se vuoi automatizzare i fix su più siti.
La maggior parte degli audit costano $500 e richiedono tre giorni. Site Audit costa $50 e si esegue mentre fai il caffè.
Come funziona effettivamente Site Audit
Site Audit combina più strumenti di test in un unico rapporto prioritizzato.
Esegue Google PageSpeed Insights per le metriche di laboratorio. Estrae i dati di Chrome UX Report per le metriche degli utenti reali. Esegue Pa11y per i test di accessibilità. Controlla la compatibilità del browser su Chrome, Firefox, Safari e Edge.
Quindi utilizza l’IA per sintetizzare i risultati in un piano d’azione prioritizzato.
Non ricevi 100 problemi senza contesto. Ricevi 5 azioni prioritizzate con stime di sforzo e punteggi di impatto. Ogni azione include il problema, l’impatto sulla tua attività, la correzione e il risultato atteso.
Site Audit offre due ambiti: 30 pagine o 100 pagine. L’ambito di 30 pagine è perfetto per i piccoli siti. Ottieni audit core, 5 azioni prioritizzate e test del browser.
L’ambito di 100 pagine aggiunge l’analisi dei concorrenti. Site Audit confronta il tuo sito con un massimo di 2 concorrenti fianco a fianco. Vedi esattamente dove sei indietro. Vedi le lacune di parole chiave, la copertura dello schema e i benchmark di performance.
L’ambito espanso include anche l’analisi dei gap di contenuto. Site Audit identifica gli argomenti su cui i tuoi concorrenti sono classificati ma tu no. Ricevi una ricerca alimentata dall’IA su cosa scrivere dopo.
Numeri reali da siti reali
Site Audit ha rilevato 4 problemi legittimi su surmado.com.
Ci mancava lo schema LocalBusiness. Questi dati strutturati guidano un aumento di ricerca locale del 15%-30%. L’abbiamo aggiunto. Il traffico locale è aumentato del 18% in 30 giorni.
Avevamo 3 intestazioni di sicurezza mancanti. Il nostro punteggio di sicurezza era 2 su 5. Abbiamo aggiunto Content-Security-Policy, X-Content-Type-Options e Strict-Transport-Security. Il nostro punteggio è saltato a 5 su 5.
Avevamo colli di bottiglia di Speed Index da font non ottimizzati. Abbiamo passato a font-display swap. Lo Speed Index è sceso da 3,2 secondi a 2,1 secondi.
Lighthouse non ha rilevato questi problemi. Lighthouse testa un browser in condizioni ideali. Site Audit testa 4 browser con metriche di utenti reali. Site Audit testa anche i browser in-app dei social media nella versione Pro. I browser di Instagram, Facebook e LinkedIn si comportano diversamente dai browser standard.
Dal 30% al 50% del traffico proviene dai social media. Se il tuo sito si interrompe nel browser in-app di Instagram, perdi quel traffico.
Il confronto dei tool che ti serve davvero
Ecco come Site Audit si confronta con altre opzioni:
PageSpeed Insights è gratuito e ti dà i punteggi di laboratorio. Non dà priorità ai fix. Non ti confronta con i concorrenti. Non testa i browser dei social. Ti dà i dati. Tu figuri la strategia.
Lighthouse è gratuito e integrato in Chrome DevTools. Richiede competenza tecnica. Hai bisogno di sapere come leggere i grafici a cascata. Hai bisogno di capire le risorse di rendering bloccante. Ti dà le opportunità. Tu figuri quali contano.
Semrush Site Audit costa $1.400 all’anno. Esegue la scansione dell’intero sito e trova tutto quello che va male. Ricevi 100+ problemi senza priorità. Ottieni dashboard per monitorare i trend. Passi ore a capire cosa sistemare per primo.
Screaming Frog costa $199 all’anno. È uno scanner desktop. Trova link rotti, contenuto duplicato e problemi di metadati. Non testa la performance. Non testa le metriche degli utenti reali. Non ti dice l’impatto commerciale.
Site Audit parte da $50/lavoro. Ricevi un piano d’azione prioritizzato in circa 15 minuti. Ricevi 5-10 cose specifiche da fare con stime di sforzo. Ricevi l’analisi dei concorrenti in Pro. Ricevi metriche di utenti reali da Chrome UX Report. Ricevi il test dei browser dei social in Pro.
Ricevi l’audit che avresti scritto dopo aver usato quegli altri tool.
Site Audit è il livello di strategia. Gli altri tool ti danno i dati. Site Audit ti dice cosa farci.
Quando l’ottimizzazione dei Core Web Vitals fallisce
Non ogni sito beneficia dall’ottimizzazione dei Core Web Vitals. Hai bisogno di sapere quando conta e quando no.
Se il tuo sito si posiziona nella pagina 5 per le tue parole chiave target, i Core Web Vitals non ti salveranno. La qualità del contenuto e i backlink contano di più. Sistemali prima.
Se i tuoi concorrenti hanno anche cattivi Core Web Vitals, ottimizzare il tuo ti dà un vantaggio. Se i tuoi concorrenti hanno punteggi perfetti, il tuo equivalgono solo a livellare il campo di gioco.
I Core Web Vitals sono un pareggia. Contano di più quando la qualità del contenuto è uguale e stai competendo per le posizioni 1-5 della pagina 1.
I thread su Reddit dei professionisti di SEO tecnico confermano questo. I siti con punteggi perfetti di Core Web Vitals a volte si posizionano al di sotto dei siti con punteggi falliti. Google considera centinaia di fattori di ranking. I Core Web Vitals sono un fattore.
Non sprecare 40 ore ottimizzando i Core Web Vitals se il tuo contenuto è scarso o il tuo sito non ha backlink. Sistemate prima i fondamenti.
API e automazione per le agenzie
Se gestisci più siti client, hai bisogno di automazione.
Site Audit include supporto completo per API e webhook. Puoi attivare gli audit a livello di programmazione. Ottieni l’output JSON con dati strutturati. Puoi creare dashboard o automatizzare i report.
L’API è basata su REST con autenticazione semplice. Invii una richiesta POST con un URL. Site Audit si esegue in modo asincrono. Ottieni un webhook quando il report finisce. Puoi sondare l’endpoint di stato se preferisci.
L’output JSON include tutte le metriche, le azioni prioritizzate e i confronti dei concorrenti. Puoi analizzare questo nei tuoi sistemi. Puoi generare report personalizzati per i client. Puoi tracciare il progresso nel tempo.
Site Audit supporta anche la modalità con etichetta pulita su Portfolio. Il nome della tua agenzia appare nei report invece di Surmado. I tuoi client vedono il tuo branding.
La maggior parte delle agenzie addebita $500-$1.000 per gli audit SEO. Scout fornisce la stessa qualità in circa 15 minuti. Tu mantieni il margine. I tuoi client ottengono risultati veloci e utilizzabili.
Suggerimenti specifici per il framework
Le tue correzioni dipendono dallo stack tecnico.
Siti WordPress: Usa un plugin di caching come WP Rocket o W3 Total Cache. Questi plugin gestiscono l’ottimizzazione delle immagini, il rinvio di JavaScript e l’integrazione della CDN automaticamente. La maggior parte della configurazione richiede 10 minuti.
Siti Shopify: Usa il caricamento pigro integrato per le immagini dei prodotti. Rinvia le app di terze parti che aggiungono JavaScript. La maggior parte dei negozi Shopify carica 8-12 script di terze parti. Controlla quali ne hai effettivamente bisogno.
Siti Next.js: Usa il componente Image integrato. Gestisce il dimensionamento reattivo, il caricamento pigro e la conversione del formato automaticamente. Usa gli import dinamici per il JavaScript lato client. Questo rinvia il codice che non ha bisogno di essere eseguito sul server.
Siti React: Usa React.lazy() per la divisione del codice. Questo rompe il JavaScript in pezzi più piccoli che si caricano on-demand. Usa l’Intersection Observer API per il caricamento pigro del contenuto sotto la piega.
Siti statici: Prerendi tutto al momento della compilazione. Usa uno strumento di compilazione come Eleventy o Hugo. L’HTML statico si carica più velocemente del contenuto renderizzato da JavaScript. Usa una CDN per servire i tuoi file statici globalmente.
Come misurare i risultati
Dopo aver apportato i fix, hai bisogno di verificare che hanno funzionato.
Usa Google PageSpeed Insights. Inserisci l’URL. Controlla i tuoi punteggi di Core Web Vitals. Confrontali con la tua linea di base prima dei fix.
Esegui il test tre volte. I punteggi fluttuano in base alle condizioni di rete e al carico del server. Fai una media dei risultati. Non entrare in panico se un test mostra punteggi peggiori. Guarda il trend su più test.
Controlla sia il mobile che il desktop. Google classifica in base alla performance mobile. I punteggi desktop sono di solito più alti ma contano meno per i ranking.
Aspetta 28 giorni per i dati di utenti reali. Chrome UX Report aggrega i dati su una finestra mobile di 28 giorni. I tuoi punteggi di laboratorio migliorano immediatamente. I tuoi punteggi di campo migliorano gradualmente man mano che gli utenti reali visitano il tuo sito aggiornato.
Se vuoi il monitoraggio continuo, i piani Pro e Portfolio includono il monitoraggio settimanale. Vedi come cambiano i tuoi punteggi nel tempo. Extra job disponibili per $25 quando hai bisogno di un’analisi più approfondita.
Domande comuni
Quanto tempo dura l’ottimizzazione?
I tre fix in questa guida richiedono 1-3 ore totali per la maggior parte dei siti. L’ottimizzazione delle immagini richiede 30 minuti. Il rinvio di JavaScript richiede 30 minuti. L’aggiunta di dimensioni alle immagini richiede 1-2 ore a seconda di quante immagini hai.
Ho bisogno dell’aiuto dello sviluppatore?
Per i fix di base, no. La compressione delle immagini e l’aggiunta di dimensioni possono essere fatte attraverso il tuo CMS. Per le modifiche di JavaScript, potresti aver bisogno di uno sviluppatore se il tuo sito utilizza un tema personalizzato o un processo di compilazione.
Mi romperà il sito?
No se testi i cambiamenti in un ambiente di staging per primo. Fai un cambio alla volta. Testa che tutto funzioni ancora. Quindi passa al cambio successivo. Non spingere 10 cambiamenti alla produzione in una volta.
Quanto aumento del traffico posso aspettarmi?
Dipende dai tuoi ranking attuali. Se ti posizioni nelle posizioni 4-7 della pagina 1, migliorare i Core Web Vitals può spostarti alle posizioni 2-4. Questo in genere aumenta il traffico del 20%-40%. Se ti posizioni nella pagina 2 o 3, i Core Web Vitals da soli non ti muoveranno alla pagina 1. Concentrati prima sul contenuto e sui backlink.
Dovrei ottimizzare ogni pagina?
No. Inizia con le tue pagine con il traffico più alto. Ottimizza la tua homepage, le tue 10 migliori pagine di destinazione e le tue 10 migliori pagine di prodotto o servizio. Queste pagine guidano l’80% del tuo traffico. Sistemale per primo.
Cosa succede se uso un page builder?
La maggior parte dei page builder aggiunge bloat. Elementor, Divi e Visual Composer caricano tutti JavaScript e CSS extra. Puoi comunque ottimizzare le immagini e aggiungere dimensioni. Il rinvio di JavaScript è più difficile perché i page builder spesso incorporano gli script.
Considera il passaggio a un tema più leggero se la performance è critica. GeneratePress e Kadence sono alternative veloci che funzionano con l’editor a blocchi.
Cosa fare questa settimana
Scegli il fix che corrisponde alla tua metrica peggiore:
Se il tuo LCP è superiore a 2,5 secondi, ottimizza la tua immagine hero. Converti in WebP. Ridimensiona alle dimensioni di visualizzazione. Aggiungi una CDN. Questo richiede 30 minuti e di solito riduce l’LCP del 40%-50%.
Se il tuo INP è superiore a 200 millisecondi, rinvia il tuo JavaScript. Aggiungi attributi defer ai tag script. Sposta l’analisi in fondo. Rimuovi gli script inutilizzati. Questo richiede 30-60 minuti e di solito migliora l’INP di 100-200 millisecondi.
Se il tuo CLS è superiore a 0,1, specifica le dimensioni per tutte le immagini e il contenuto dinamico. Imposta le dimensioni esplicite nell’HTML. Usa font-display swap per i font personalizzati. Evita di iniettare contenuto sopra la piega. Questo richiede 1-2 ore e di solito abbassa il CLS sotto 0,1.
Esegui Site Audit per vedere quale metrica ha bisogno di attenzione per prima. Piani a partire da $50/lavoro. Sistemate i tre problemi principali. Riesegui il test in una settimana.
L’ottimizzazione dei Core Web Vitals non è complicata. Non hai bisogno di una grande agenzia. Non hai bisogno di un ingegnere a tempo pieno. Hai bisogno di sistemare le tre cose giuste.