Prestazioni del sito web e parametri Web fondamentali

Perché la velocità del sito web influisce direttamente sulle conversioni

Le prestazioni non sono un punteggio estetico, ma un problema di produzione. Un TTFB lento, script che bloccano il rendering e valori Web Vitals scadenti comportano perdite di lead, fatturato e posizionamento su Google. Questa pagina spiega cosa non funziona a livello tecnico sui siti WordPress e cosa fa effettivamente la differenza in termini di prestazioni.

Richiedi un'analisi delle prestazioni → Spiegazione delle Core Web Vitals
  • ✓ LCP, INP e CLS senza termini alla moda
  • ✓ WordPress e WooCommerce in produzione
  • ✓ Memorizzazione nella cache, CDN e blocco del rendering
  • ✓ Prestazioni legate alla conversione

Prestazioni migliori all'interno del sito web

← Prestazioni del sito web velocità del sito web Elementi essenziali del sito Web

Guide alle prestazioni correlate

← Agenzia di Web Design Elementi essenziali del sito Web Creazione di un sito web Creare un sito web WordPress Richiedi un preventivo per il tuo sito web
risposta diretta

Quanto è davvero importante la velocità di un sito web?

La velocità del sito web è un fattore determinante per il posizionamento nei risultati di ricerca e per le conversioni. Google utilizza i Core Web Vitals (LCP, INP, CLS) come indicatore ufficiale. I dati raccolti dal Chrome User Experience Report hanno un peso maggiore rispetto al punteggio ottenuto da un test Lighthouse.

Per ogni secondo aggiuntivo di tempo di caricamento, il tasso di conversione diminuisce in media del 7% (studi Akamai/e-commerce). Lo stesso schema si osserva sui siti di acquisizione contatti: la frequenza di rimbalzo aumenta, mentre il numero di moduli compilati diminuisce, soprattutto su dispositivi mobili. Per i siti delle PMI con WordPress, le prestazioni raramente dipendono da una singola impostazione: si tratta piuttosto di un problema complesso che coinvolge server (TTFB), caching, bundle JavaScript, immagini e script di terze parti.

Un punteggio PageSpeed superiore a 90 è utile come linea guida, non come obiettivo fine a se stesso. Ciò che conta è: un CWV verde in Search Console, un LCP veloce sulle pagine di pagamento e un INP che non blocchi l'interazione (menu, modulo, checkout).

📉

impatto della SEO

CWV è un segnale di ranking a livello di pagina. Le pagine di categoria lente hanno un ranking inferiore, anche se la tua homepage è veloce.

💰

Impatto della conversione

I siti lenti perdono i lead prima che la pagina principale si carichi. Le prestazioni sono UX — vedi anche ottimizzazione della conversione.

🔬

Misurabile

Search Console (dati sul campo), WebPageTest (metodo a cascata), Lighthouse (test di laboratorio). Tre fonti, tre verità: confrontatele sempre.

Impatto sul business

Perché i siti web lenti costi di ricavo

Le prestazioni non sono una statistica IT, bensì una perdita di fatturato a ogni caricamento di pagina.

53%
Gli utenti che visitano il sito da dispositivi mobili lo abbandonano se il tempo di caricamento supera i 3 secondi (ricerca di Google).
-7%
Conversione per secondo aggiuntivo di tempo di caricamento (siti e-commerce/di acquisizione contatti medi)
2×
Frequenza di rimbalzo più elevata con LCP > 4s rispetto a LCP < 2,5s: stesso traffico, metà delle possibilità di un lead
Annunci
Pagine di destinazione lente = CPC più alto e punteggio di qualità più basso: paghi il doppio

Tipica perdita di traffico a imbuto sui siti WordPress lenti:

  1. Clic dei visitatori (organico, annunci o traffico diretto) → il server risponde lentamente (TTFB elevato)
  2. carica gli elementi LCP in ritardo (immagine principale, webfont) → oltre il 40% di rimbalzo prima dello scorrimento
  3. Il menu/modulo risponde lentamente (INP) → l'interazione sembra "interrotta"
  4. spostamento del layout (CLS) → clic errato sulla CTA o abbandono al momento del pagamento
  5. Risultato: stesso budget di marketing, meno contatti — mentre website redesign o se una soluzione mirata per migliorare le prestazioni sia spesso più economica rispetto all'acquisto di ulteriore traffico.
Elementi essenziali del sito Web

Spiegazione delle Core Web Vitals senza termini alla moda.

Tre parametri che Google misura negli utenti reali. Nessun termine di marketing: questi sono i dati che il browser comunica a CrUX.

LCP ≤ 2,5 s = Buono

Vernice più grande e ricca di contenuti

Quando l'elemento visibile più grande (di solito un'immagine principale, un poster video o un blocco di testo di grandi dimensioni) è completamente renderizzato. Misura il tempo di caricamento, non il "DOM ready".

Cause tipiche su WordPress:
  • TTFB lento → HTML si carica in ritardo
  • Eroe come sfondo CSS invece di <img>
  • Nessuna priorità di precaricamento/recupero sull'elemento LCP
  • Visualizza il CSS bloccante dal page builder
INP ≤ 200 ms = Buono

Interazione con Next Paint

Quanto tempo ci vuole perché la pagina risponda visivamente dopo un clic, un tocco o un tasto? INP sostituisce FID e misura il peggio interazione (75° percentile).

Cause tipiche:
  • Esecuzione di attività di lunga durata tramite JavaScript di terze parti (GTM, chat, mappe di calore)
  • Thread principale bloccato dal frontend JS del page builder
  • Frammenti del carrello WooCommerce su ogni pagina
  • Nessuna suddivisione del codice: un unico pacchetto per tutto.
CLS ≤ 0,1 = Buono

Spostamento cumulativo del layout

Quanto si sposta inaspettatamente il layout durante il caricamento? Caratteri, annunci pubblicitari, elementi incorporati senza altezza: gli utenti spesso non vedono i pulsanti, soprattutto su dispositivi mobili.

Cause tipiche:
  • Caratteri web senza regolazione delle dimensioni / metriche di fallback
  • Immagini senza attributi di larghezza/altezza
  • Banner dei cookie e widget di chat che mostrano contenuti
  • Contenuti caricati in modo differito nella parte superiore della pagina

Il TTFB (Time to First Byte) non è Core Web Vital, ma il collo di bottiglia a monte: se il server necessita di 800 ms, LCP non potrà mai diventare "verde", indipendentemente da quanto sia buono il tuo frontend. Vedi SEO tecnico per la sovrapposizione con la scansione e l'indicizzazione.

WordPress in produzione

I maggiori problemi di prestazioni a WordPress

Non esiste una lista di controllo: questi sono gli schemi che riscontriamo settimanalmente sui siti web delle PMI, sui siti di acquisizione clienti e sui negozi WooCommerce.

Server

TTFB lento a causa dell'hosting condiviso

Problema: Un tempo di risposta al primo byte (Time to First Byte) superiore a 600 ms significa che il browser è in attesa di PHP/MySQL prima che l'HTML possa essere analizzato. Con l'hosting condiviso, il tuo sito condivide la CPU con decine di altre installazioni WordPress.

Impatto: LCP e FCP aumentano vertiginosamente: la memorizzazione nella cache è utile solo se l'HTML viene scaricato rapidamente dalla cache.

Aggiustare: Cache degli oggetti (Redis), cache delle pagine a livello di server, ottimizzazione delle query, upgrade a VPS o hosting WordPress gestito.

Plugin

Plugin sovraccarichi e opzioni di caricamento automatico

Problema: Ogni plugin attivo carica hook, script e talvolta query di database a ogni richiesta. Le opzioni caricate automaticamente di dimensioni superiori a 1 MB rallentano il caricamento di ogni pagina, inclusa quella di amministrazione.

Impatto: TTFB più elevato, più codice JavaScript che blocca il rendering, INP peggiore a causa del blocco del thread principale.

Aggiustare: Sostituisci le verifiche dei plugin e la pulizia dell'autoload con alternative leggere o codice personalizzato.

Page builder

Elementor / Divi CSS e JS per widget

Problema: I page builder generano CSS inline per ogni sezione e caricano i bundle frontend per ogni tipo di widget, anche per i widget che non sono presenti nella pagina.

Impatto: Fogli di stile che bloccano il rendering, grandi pacchetti JS, LCP scadente a causa del rendering ritardato dell'eroe.

Aggiustare: Limita il caricamento delle risorse, rimuovi il CSS inutilizzato, valuta l'utilizzo di un tema personalizzato o di una build ibrida.

WooCommerce

Frammenti del carrello e richieste di informazioni sui prodotti

Problema: WooCommerce carica il frammento del carrello tramite AJAX su ogni pagina, anche al di fuori del negozio. Gli archivi dei prodotti senza caching delle query generano query JOIN molto complesse.

Impatto: Pagine di categoria lente, elevato numero di articoli non visualizzati nella pagina "Aggiungi al carrello", carico del server durante i picchi di traffico.

Aggiustare: Memorizzazione nella cache dei frammenti, disabilitazione dei frammenti sulle pagine non di negozio, tabelle di ricerca dei prodotti, CDN per le risorse statiche.

Media

Caricamenti non compressi e senza srcset

Problema: Immagini hero da 4 MB direttamente dalla libreria multimediale, senza WebP/AVIF, senza attributi di larghezza/altezza → problemi CLS e LCP.

Impatto: L'elemento LCP è quasi sempre l'immagine principale: questo rappresenta il principale collo di bottiglia sui siti web delle PMI.

Aggiustare: Immagini responsive, formati moderni, fetchpriority="high" su LCP, lazy loading solo al di sotto della parte visibile della pagina.

Terzo

Pixel di tracciamento e widget di chat

Problema: GTM carica Tag Assistant, Hotjar, Intercom, Facebook Pixel e il remarketing di Google Ads, tutti elementi che bloccano il rendering o che richiedono molto tempo per essere caricati.

Impatto: INP peggiora, Lighthouse "Riduci JavaScript inutilizzato" esplode, gli utenti reali sono più lenti rispetto al punteggio di laboratorio.

Aggiustare: Caricamento con consenso, differimento a dopo LCP, tracciamento lato server ove possibile, verifica dei tag.

Con una nuova costruzione, impediamo strutturalmente questo attraverso il nostro Sito web WordPress approccio. Per i siti esistenti, partiamo da un'analisi a cascata, non da "l'ennesimo plugin di cache".

Generatore di pagine vs. sviluppo personalizzato

Elementor vs. personalizzazione: prestazioni in cifre.

Elementor è flessibile, ma l'architettura frontend ha un costo. Un confronto equo evita false aspettative.

Aspetto Elementor (tipico) Personalizzato / ibrido
output CSS CSS inline per ogni widget + CSS globale del kit (100–400 KB+) CSS critico in linea, il resto differito — in genere 15–40 KB nella parte visibile della pagina
JavaScript Pacchetto frontend + gestori di widget, inclusi i widget non utilizzati JavaScript solo per i componenti interattivi di quella pagina
Query di espansione Query meta aggiuntive per modello/sezione Query ottimizzate, spesso HTML statico con cache
Eroe LCP Immagini di sfondo tramite CSS: il browser lo ha scoperto in ritardo <img> con fetchpriority, precaricamento, dimensioni esplicite
Manutenzione Gli aggiornamenti dei plugin possono compromettere le prestazioni. Implementazioni controllate, senza costi aggiuntivi per gli sviluppatori.
Faro realistico 60–85 dopo l'ottimizzazione (tipica PMI) 90–100 raggiungibili con lo stesso contenuto

Elementor può essere ottimizzato: lo facciamo sul nostro Siti web Elementor percorsi. Ma la fisica del CSS inline per widget rimane. Per i progetti che privilegiano le prestazioni, optiamo più spesso per lo sviluppo personalizzato o software su misura quando il sito è di importanza cruciale per l'attività aziendale.

Server e frontend

Memorizzazione nella cache, script e blocco del rendering.

Ottimizzare le prestazioni significa sapere quale livello risolve il problema. La cache maschera la lentezza di PHP, ma non la risolve a livello strutturale.

cache del browser

Intestazioni Cache-Control per le risorse statiche (CSS, JS, font, immagini).

Insidia: Un valore di max-age troppo basso o l'assenza di versioning → i visitatori visualizzano risorse obsolete dopo la pubblicazione.

cache edge CDN

File HTML e statici vicini all'utente (Cloudflare, Bunny, Fastly).

Insidia: Contenuti dinamici (utente connesso, carrello) memorizzati accidentalmente nella cache: bug del checkout.

cache di pagina

Risposta HTML completa memorizzata nella cache (LiteSpeed, WP Rocket, Nginx fastcgi_cache).

Insidia: Invalidazione della cache durante gli aggiornamenti dei contenuti; esclusione per gli utenti autentificati.

Cache degli oggetti

Redis/Memcached per i risultati delle query del database e i dati transitori.

Insidia: Senza cache degli oggetti, il TTFB rimane elevato, anche con la cache di pagina per le pagine non memorizzate nella cache.

Blocco del rendering: cosa fa realmente il browser

Il browser analizza l'HTML dall'alto verso il basso. <link rel="stylesheet"> Nella testa, il rendering è bloccato finché il CSS non viene scaricato e analizzato. Ogni sincronizzazione <script> Nell'intestazione, l'analisi HTML si interrompe fino all'esecuzione del codice JavaScript.

I page builder, WooCommerce, GTM e i widget di chat aggiungono decine di risorse bloccanti. "Rimandare tutto" sembra una buona idea, ma interrompe gli script inline che si aspettano DOMContentLoaded, motivo per cui decidiamo per ogni risorsa: risorse critiche inline, il resto precaricamento/differimento/asincrono, terze parti dopo LCP.

  • ✓ CSS critico: stili above-fold inline, resto caricamento asincrono
  • ✓ Suddivisione dei bundle JS: niente monolite da 400 KB per un singolo fisarmonica
  • ✓ CDN per risorse statiche + multiplexing HTTP/2 o HTTP/3
  • ✓ Caricamento differito solo nella parte inferiore della pagina, mai nell'immagine LCP.
Prestazioni del frontend

Immagini, caratteri e caricamento frontend.

La maggior parte dei "consigli per velocizzare le cose" si ferma al WebP. In produzione, invece, si tratta di catena di distribuzione e stabilità del layout.

🖼️

Immagini e LCP

Responsive srcset, WebP/AVIF con fallback, larghezza/altezza esplicite, fetchpriority="high" su hero. Precarica l'immagine LCP in <head> quando è nota la statica.

  • Non è consentito caricare immagini di 3000 pixel per contenitori di 800 pixel.
  • Ottimizzazione delle immagini CDN (ridimensionamento sul bordo)
  • Caricamento differito solo dopo il commit di LCP
🔤

Caratteri web e CLS

Google Fonts tramite woff2 self-hosted, font-display: scambio di opzioni, size-adjust per metriche di fallback. Massimo 2 famiglie di font, pesi limitati.

  • Precarica il woff2 primario
  • Nessun @import nella catena CSS
  • Caratteri variabili = meno richieste
📦

Pacchetti JS

Tree shaking, importazione dinamica per moduli pesanti, nessuna jQuery per un singolo interruttore. INP migliora quando il thread principale rimane bloccato per < 50 ms dopo l'interazione.

  • Controllo tramite la scheda Copertura in DevTools
  • Terze parti con un totale inferiore a 100 KB nella parte visibile della pagina
  • Partytown solo dove è davvero utile
Prestazioni e SEO

Prestazioni vs. SEO: sovrapposizione e differenza.

Sovrapposizione: I Core Web Vitals sono fattori di ranking. I siti lenti a volte vengono indicizzati in modo meno efficiente (budget di indicizzazione per siti di grandi dimensioni). L'usabilità mobile e l'HTTPS appartengono a entrambe le discipline.

Differenza: La SEO ottimizza la reperibilità (contenuti, link, dati strutturati, indicizzazione). Le prestazioni ottimizzano ciò che accade dopo il clic. Puoi posizionarti in prima pagina con un CWV (Content Work Value) scadente, ma perderai clic e conversioni a favore di concorrenti più veloci.

Ordine ideale per un sito lento: prima correggere TTFB e CWV sulle pagine a pagamento, poi potenziare i contenuti e la link building con il nostro aiuto. agenzia SEOAltrimenti, paghi per un traffico che si interrompe immediatamente.

🔍

SEO senza performance

Più impressioni, meno conversioni. Search Console mostra CWV "Necessita di miglioramenti", un segnale che il posizionamento per un termine potrebbe calare.

⚡

Prestazioni senza SEO

Sito veloce che nessuno trova. Tecnicamente impeccabile, commercialmente invisibile.

🎯

Entrambi

Traffico + esperienza veloce = massimo ROI. Questo è lo standard in ogni creazione di siti web programma presso Ploko.

Pagespeed Insights

Quando Pagespeed ottiene un punteggio essere fuorvianti.

Lighthouse è uno strumento da laboratorio. Utile per il debug, senza alcun contratto relativo a classifiche o ricavi.

  • Dati di laboratorio vs. dati sul campo: Lighthouse funziona con una simulazione di limitazione della velocità. I dati sul campo di CrUX (Search Console) mostrano l'esperienza reale degli utenti, ed è questo che conta per il posizionamento.
  • Distorsione da URL singolo: la tua homepage ottiene un punteggio di 95, ma le pagine prodotto e le landing page si fermano a 40. Google valuta per URL, non per l'intero sito.
  • Cache calda vs. fredda: PSI testa spesso la cache fredda. I visitatori che accedono per la prima volta vedono un TTFB di oltre 800 ms, mentre i visitatori di ritorno di 200 ms: solo la cache fredda è rilevante per il nuovo traffico.
  • Modalità "punteggio 100" del plugin: il differimento/ritardo aggressivo interrompe i moduli, il tracciamento o il checkout. Il punteggio aumenta, la conversione diminuisce.
  • Desktop vs mobile: desktop 98, mobile 52 è normale per build pesanti. L'indicizzazione mobile-first considera il CWV mobile.
  • INP vs FID: la vecchia misurazione FID non tiene conto di molti ritardi di interazione. INP misura l'interazione nel caso peggiore: i siti che "caricano velocemente" ma rispondono lentamente continuano a fallire.

Cosa misurare?

Search Console → Report Core Web Vitals (dati dei campi, 28 giorni). WebPageTest waterfall su 4G. Monitoraggio utenti reali se si dispone di volume. Lighthouse solo per test di regressione dopo l'implementazione.

Domande frequenti

Domande frequenti su velocità del sito web.

Cerca di ottenere valori ottimali per i Core Web Vitals in Search Console: LCP ≤ 2,5 secondi, INP ≤ 200 millisecondi e CLS ≤ 0,1. Un TTFB inferiore a 200 ms è ideale per il livello server. Un punteggio Lighthouse superiore a 90 è auspicabile; i dati di campo (CrUX) hanno un peso maggiore per Google e riflettono l'esperienza reale dei visitatori.

Le cause più comuni sono: hosting condiviso lento (TTFB elevato), troppi plugin attivi, sovraccarico del page builder (CSS e JS di Elementor/Divi), immagini non compresse, assenza di cache di pagina o cache degli oggetti, frammenti del carrello WooCommerce su ogni pagina e script di terze parti (GTM, chat, heatmap) che causano blocchi di rendering. Raramente si tratta di una singola impostazione: un'analisi a cascata mostra dove si verifica l'interruzione della catena.

I Core Web Vitals sono tre metriche di performance misurate da Google sulla base di dati reali degli utenti: LCP (tempo di caricamento dell'elemento più grande visibile), INP (reattività dopo l'interazione) e CLS (stabilità visiva). Sono fattori di ranking ufficiali e influenzano direttamente la frequenza di rimbalzo e la conversione. Spiegazione completa di ciascuna metrica sulla nostra pagina dedicata. Elementi essenziali del sito Web; contesto di prestazione più ampio su velocità del sito web e SEO tecnico.

Un plugin di cache (WP Rocket, LiteSpeed Cache) è utile principalmente per migliorare il TTFB (Time To First Byte) e le visite ripetute: la cache di pagina carica l'HTML più velocemente e la cache del browser riutilizza le risorse. Tuttavia, la cache non maschera le query PHP lente, il codice JavaScript che blocca il rendering o un'immagine principale da 4 MB. Per un miglioramento strutturale, è consigliabile combinare la cache di pagina con la cache degli oggetti (Redis), l'ottimizzazione delle immagini, il CSS critico e un'analisi dei plugin. I punteggi migliorano realmente solo quando il collo di bottiglia è stato risolto.

Lighthouse è una simulazione di laboratorio: una simulazione di limitazione della velocità, una singola esecuzione, utile per il debug. I dati di campo in PageSpeed Insights provengono da CrUX: 28 giorni di dati aggregati da utenti reali di Chrome. Google utilizza i dati di campo per il posizionamento. La tua homepage potrebbe ottenere un punteggio di 95 su Lighthouse, mentre i dati di campo mostrano "Da migliorare" su dispositivi mobili: fidati sempre dei dati di campo per le decisioni aziendali.

Le analisi e le correzioni mirate delle prestazioni partono in genere da poche centinaia di euro per colli di bottiglia specifici (configurazione della cache, pipeline delle immagini, analisi degli script). I progetti completi di ottimizzazione delle prestazioni di WordPress, che includono l'ottimizzazione del server, l'ottimizzazione di WooCommerce o la migrazione da un page builder allo sviluppo personalizzato, hanno un costo maggiore. Iniziamo sempre con una scansione e forniamo un piano concreto prima dell'implementazione: niente pacchetti a sorpresa.

Sì, immediatamente. Ogni secondo di tempo di caricamento aggiuntivo costa in media circa il 7% di conversioni. Un INP lento rende moduli e menu frustranti; un CLS elevato causa clic errati. Per i siti web di acquisizione lead e gli e-commerce, le prestazioni sono parte integrante della CRO (Conversion Rate Optimization): scopri anche il nostro servizio. ottimizzazione della conversioneLa velocità senza chiare call to action (CTA) aiuta solo in misura limitata; le CTA senza velocità generano un abbandono della pagina.

Elementor non è "cattivo", ma la sua architettura genera CSS inline per ogni widget e carica bundle frontend più pesanti di un tema personalizzato. Con l'ottimizzazione (caricamento delle risorse, rimozione del CSS inutilizzato, buon hosting), è possibile raggiungere 70-85 Lighthouse mobile. Per siti che privilegiano le prestazioni o negozi WooCommerce ad alto traffico, spesso scegliamo lo sviluppo personalizzato. Ulteriori confronti su Realizzazione di un sito web con Elementor.

Servizi correlati

Dalle prestazioni a conversione.

Le prestazioni sono il fondamento: i prossimi passi commerciali per l'implementazione e la crescita.

Elementi essenziali del sito Web Creare un sito web WordPress Richiedi un preventivo per il tuo sito web
Prestazioni che generano conversioni

Sito web lento? Prima misuriamo, poi ottimizziamo.

Nessun consiglio generico del tipo "installa il plugin X". Analizziamo il TTFB, il waterfall, i Core Web Vitals e l'impatto sui tuoi lead o sul tuo fatturato. Quindi, un piano concreto: server, caching, frontend o ricostruzione – che risolva realmente il problema.

Analisi delle prestazioni gratuita → Preventivo/restyling del sito web
✓ Dati raccolti sul campo + analisi di laboratorio
✓ WordPress e WooCommerce
✓ Impatto della conversione nel report
✓ Niente caccia al punteggio, ma verde CWV