Modulo 6 · 6.1

Italiano

Nederlands English Deutsch Français Español Italiano Polski

Cosa rende lento un sito, e come si misura?

Modulo 6: Velocità · Tempo di lettura: 9 minuti

Obiettivo della lezione: dopo questa lezione sarà in grado di misurare dove si perde tempo e di riconoscere la differenza tra lentezza lato server e lentezza lato browser.

Concetti chiave: TTFB, Core Web Vitals (LCP, INP, CLS), dati di laboratorio, dati di campo, PageSpeed Insights, scheda rete, compressione, script esterni, limiti del pacchetto di hosting, 503

Prima misurare, poi intervenire

"Il sito è lento" può avere dieci cause diverse. Chi, senza misurare, installa contemporaneamente un plugin di cache, un plugin di ottimizzazione delle immagini e un pacchetto più grande, non saprà poi cosa ha funzionato, e si ritrova con tre cose in più da gestire. Cominci quindi sempre con tre domande (le stesse della guida del Suo hoster):

Tutto è lento, o solo l'area di amministrazione? Un'area di amministrazione lenta con un frontend veloce indica plugin che fanno molto lavoro nella Bacheca, oppure bot che prendono di mira la pagina di accesso.
Sempre, o solo in certi momenti? Solo nelle ore di punta o quando gira un'attività pianificata: allora il Suo pacchetto sta raggiungendo i propri limiti.
Per tutti, o solo per Lei? Provi dal Suo telefono via 4G o 5G, oppure chieda a qualcun altro. Se è lento solo per Lei, dipende dalla Sua connessione o dalla VPN.

Due metà: server e browser

Il tempo di attesa di un visitatore è composto da due parti (lezione 1.2):

Il server genera l'HTML: webserver, PHP, plugin, database. Lo si vede come TTFB (time to first byte), il tempo necessario per ricevere il primo byte della risposta. web.dev indica come regola generale che la maggior parte dei siti dovrebbe puntare a un TTFB di 0,8 secondi o meno.
Il browser legge quell'HTML e poi recupera tutto ciò che vi è contenuto: fogli di stile, script, font, immagini, video, codici di tracciamento, widget di chat. Solo quando ne è arrivato abbastanza, il visitatore vede qualcosa.

Un TTFB elevato si risolve lato server: caching (lezione 6.2), meno plugin o plugin più leggeri, una versione di PHP più recente, un database riordinato (lezione 6.3) o più potenza di calcolo. Un TTFB basso con una pagina comunque lenta indica il lato browser: immagini troppo grandi, troppi script, componenti esterni.

Core Web Vitals

Google misura l'esperienza dei visitatori con tre valori, i Core Web Vitals:

Misurazione	Cosa misura	Va bene se
LCP (Largest Contentful Paint)	Quanto velocemente diventa visibile il contenuto più grande (spesso la foto grande o il titolo)	2,5 secondi o meno
INP (Interaction to Next Paint)	Quanto velocemente la pagina reagisce quando si clicca, si tocca o si digita	200 millisecondi o meno
CLS (Cumulative Layout Shift)	Quanto la pagina si sposta durante il caricamento	0,1 o meno

Nel marzo 2024 INP ha sostituito la misurazione precedente FID. Google utilizza questi valori, tra l'altro, nella classificazione dei risultati di ricerca, ma la ragione principale per migliorarli è semplice: i visitatori abbandonano una pagina lenta o che si sposta continuamente.

Dati di laboratorio e dati di campo

Esistono due tipi di misurazioni, che forniscono numeri diversi:

Dati di laboratorio (labdata): un test in un determinato momento, da un determinato luogo, con un telefono e una connessione simulati. Utile per confrontare (prima e dopo una modifica), ma non rappresenta un visitatore reale.
Dati di campo (velddata): misurazioni raccolte da visitatori reali con Chrome, relative agli ultimi 28 giorni. È ciò che i visitatori sperimentano realmente. I siti piccoli spesso hanno troppo pochi visitatori per avere dati di campo.

PageSpeed Insights (pagespeed.web.dev) mostra entrambi: in alto i dati di campo (se disponibili), più sotto un test di laboratorio con un punteggio e consigli concreti. Non si concentri ciecamente sul punteggio da 0 a 100. Guardi i singoli elementi: l'LCP è scarso perché il server è lento (TTFB) o perché la foto grande pesa 3 MB?

Esegua sempre il test alcune volte (i numeri variano) e provi anche una pagina normale, non solo la homepage.

Controllare da sé con il browser

Gli strumenti di sviluppo del Suo browser (F12) mostrano cosa succede realmente:

Scheda Rete: aggiorni la pagina con la cache disattivata (casella "Disabilita cache"). Vedrà ogni file caricato, la sua dimensione e il tempo impiegato. Ordini per dimensione: i file più grandi sono spesso immagini. Ordini per dominio: quanto arriva da altre parti terze (font, codici di tracciamento, video)?
La prima richiesta (l'HTML stesso): vi clicchi sopra, scheda Tempistiche (Timing). "Waiting for server response" è il TTFB.
Intestazioni (header) di quella prima richiesta: c'è compressione (content-encoding: br o gzip), e la pagina proveniva da una cache (lezione 6.2)?

I soliti colpevoli

Nella pratica, la lentezza in WordPress deriva solitamente da una di queste cause:

Nessuna cache di pagina: ogni pagina viene rigenerata a ogni visita (lezione 6.2).
Troppi plugin o plugin pesanti, in particolare plugin che a ogni richiesta chiamano servizi esterni o eseguono query pesanti (lezione 5.3).
Immagini grandi: una foto da 5 MB scattata con un telefono, pubblicata sulla homepage (lezioni 4.4 e 6.3).
Un tema pesante o un page builder che su ogni pagina carica molti script e fogli di stile (lezione 5.1).
Componenti esterni: font, video, widget di chat, codici di tracciamento, pulsanti di social media di terze parti. Ognuno è una connessione verso un altro server che può essere lento.
Una versione di PHP obsoleta (lezione 8.4).
Un database disordinato: migliaia di revisioni, spam, tabelle di log di plugin (lezione 6.3).
Bot: crawler, crawler IA e tentativi di accesso occupano il Suo pacchetto (lezione 7.3).
Il pacchetto raggiunge i propri limiti: troppo poca potenza di calcolo (CPU), processi o memoria per il traffico.

I limiti del Suo pacchetto

Con l'hosting condiviso, ogni pacchetto riceve una parte fissa del server: potenza di calcolo, memoria, velocità del disco e un certo numero di processi contemporanei. Se il Suo sito consuma di più, viene rallentato, oppure i visitatori ricevono un messaggio di errore 503 (Service Unavailable, presso alcuni hoster "Resource Limit Is Reached"). Con DirectAdmin e CloudLinux lo vede in Resource Usage (con dei "faults" se il Suo sito è stato rallentato) e con X-Ray vede per ogni pagina quale plugin o query costa tempo. Altri hoster offrono panoramiche simili, a volte solo su richiesta.

Un pacchetto più grande aiuta se il Suo sito ha davvero bisogno di più risorse (un negozio online molto frequentato). Non risolve un sito organizzato male: il problema poi ritorna. Cerchi prima la causa.

Riepilogo

Misuri prima: tutto o solo l'area di amministrazione, sempre o a volte, tutti o solo Lei.
Il TTFB è il lato server (punti a 0,8 secondi o meno); il resto è ciò che carica il browser.
Core Web Vitals: LCP (2,5 s), INP (200 ms) e CLS (0,1); nel 2024 INP ha sostituito FID.
PageSpeed Insights mostra dati di campo e dati di laboratorio; la scheda rete mostra cosa carica realmente.
La maggior parte della lentezza deriva dall'assenza di cache, plugin pesanti, immagini grandi e componenti esterni; un pacchetto più grande è solo l'ultimo passo.

Quiz

Esercizio

Esercizio A6.1: Misuri il TTFB e la compressione. Inserisca l'indirizzo del Suo sito e, se desidera, una pagina normale (ad esempio la Sua pagina dei contatti). Il programma richiede ogni pagina tre volte senza cookie e fornisce il TTFB mediano, la dimensione dell'HTML e se il server invia l'HTML in modo compresso (content-encoding gzip o br). Confronti il risultato con un test su PageSpeed Insights e annoti cosa nota.

Per approfondire

Questi articoli descrivono i passaggi nei pannelli di WebOké; in altri pannelli il funzionamento è simile.

Cookie su WebOké

Impostazioni cookie

Necessari

Marketing