Velocizzare un sito web: cosa determina la dimensione del lavoro
La dimensione del lavoro per velocizzare un sito dipende dalla causa della lentezza. Cosa ne fissa la portata e in che ordine conviene iniziare.
Team rabbitclipPubblicato: 6 min di lettura
In breve
La portata del lavoro per velocizzare un sito web dipende dall'origine della lentezza: i problemi di contenuto come immagini e font si risolvono in fretta, mentre i problemi di server, tema o architettura del software comportano un lavoro più grande. Il primo passo giusto non è quindi mettersi a ottimizzare, ma misurare da dove viene la lentezza. I miglioramenti fatti senza misurare spesso consumano settimane senza cambiare nulla.
Questo articolo spiega cosa determina la dimensione del lavoro e in che ordine ha senso procedere. Abbiamo un pezzo a parte sui dettagli tecnici di immagini, font e script; qui la domanda è diversa: questo lavoro è piccolo, medio o grande, e da dove deve cominciare?
Da dove viene la lentezza?
L'origine si trova di solito in uno di quattro punti. Il primo è il contenuto: immagini troppo grandi, molti file di font o video pesanti gonfiano la pagina. Il secondo è il codice: script caricati inutilmente, strumenti di tracciamento di terze parti e codice inutilizzato trascinato da un vecchio tema affaticano il browser.
Il terzo è il server: un hosting lento, o una configurazione senza cache, deve ricostruire ogni pagina a ogni visita. Il quarto è l'architettura: il software su cui è costruito il sito può essere pesante in sé, oppure il modo in cui produce le pagine può essere inefficiente. Queste quattro fonti corrispondono a quattro livelli diversi di impegno.
La maggior parte dei siti non ha una sola causa; più cause si sommano. Di solito però una prevale. La misurazione mostra quale, e il lavoro parte da lì.
Cosa determina la dimensione del lavoro?
Tre fattori fissano la dimensione. Il primo è lo strato del problema: le questioni dello strato dei contenuti richiedono ore o giorni, quelle del codice giorni, e quelle dell'architettura possono richiedere settimane. Il secondo è la dimensione del sito: su un sito di cento pagine, anche la pulizia delle immagini produce tanto lavoro quante sono le pagine.
Il terzo è la flessibilità del software sottostante. Su un sito il cui codice si può lavorare liberamente, i miglioramenti si fanno direttamente; su una piattaforma chiusa ciò che si può modificare è limitato e il risultato raggiunge un tetto. La vera decisione è allora se velocizzare il sito o cambiare piattaforma.
Non indichiamo cifre di costo o di durata, perché lo stesso sintomo di lentezza può venire da cause molto diverse, e tirare a indovinare prima di guardare è fuorviante. Un passaggio di scoperta e misurazione rende visibile la dimensione reale del lavoro.
Cosa va misurato per primo?
La misurazione è il primo passo di qualsiasi lavoro sulla velocità. Spiccano tre indicatori: quanto tempo impiega a comparire il contenuto principale della pagina (LCP, buona soglia 2,5 secondi), con quale rapidità la pagina risponde all'interazione dell'utente (INP, buona soglia 200 millisecondi) e se gli elementi saltano durante il caricamento (CLS, buona soglia 0,1). Queste soglie sono pubblicate e ampiamente note.
Misurare solo su un computer fisso e su una sola pagina è fuorviante. Se la maggior parte dei visitatori arriva da uno smartphone, bisogna misurare su uno smartphone e con una connessione media, e guardare separatamente la home page e le pagine interne più visitate. Potete anche eseguire un test di velocità sul vostro sito con lo strumento gratuito del nostro sito.
Dopo la misurazione, i problemi vengono ordinati per effetto: il punto che tocca più pagine e può essere corretto con il minimo sforzo va per primo. Questo ordinamento indirizza tempo e budget verso il punto più produttivo.
In che ordine dovrebbe procedere il lavoro?
Un ordine sensato parte da ciò che porta più guadagno con meno sforzo. Di solito il primo giro consiste nel ridimensionare le immagini e convertirle in formati moderni, rimuovere gli script inutilizzati e impostare correttamente la cache. Questi passi fanno una differenza netta sulla maggior parte dei siti e comportano poco rischio.
Il secondo giro richiede più impegno: semplificare i font, portare avanti il contenuto critico e ridurre gli strumenti di terze parti a quelli davvero necessari. Il terzo giro è strutturale: un cambio di server, la semplificazione del tema o la riscrittura di parti del sito. In questo giro si entra solo se i primi due si rivelano insufficienti.
- Misurare: registrare i valori chiave su dispositivi e connessioni reali
- Ridurre le immagini e togliere gli script inutili
- Impostare correttamente cache e compressione
- Semplificare i font e gli strumenti di terze parti
- Misurare di nuovo; passare al lavoro strutturale solo se serve
Quali errori sono comuni nel lavoro sulla velocità?
L'errore più comune è iniziare senza misurare. Installare un plugin sperando che il punteggio salga può nascondere la causa reale; il punteggio migliora per un po', ma l'esperienza reale dei visitatori non cambia. Il secondo errore è guardare solo il punteggio: un numero fornito da uno strumento di test non riflette sempre ciò che vivono gli utenti reali.
Il terzo errore è cambiare tutto insieme. Se si fanno più modifiche contemporaneamente, nessuno può dire quale abbia funzionato e quale abbia rotto qualcosa. Il quarto è rompere una funzione mentre si velocizza: rimuovere uno script che risulta alimentare un modulo o un tag di tracciamento costa più della velocità guadagnata. Dopo ogni modifica le funzioni di base vanno provate a mano.
La velocità non è nemmeno un lavoro da fare una volta sola. Man mano che si aggiungono nuovi contenuti, plugin e strumenti di tracciamento, il sito rallenta di nuovo. Una routine di controlli periodici dà quindi un risultato più duraturo di un unico grande sforzo.
Quando velocizzare è la scelta sbagliata?
In alcuni siti il vero problema non è la velocità. Se il messaggio non è chiaro, le pagine non offrono ciò per cui i visitatori sono venuti o il modulo non funziona, migliorare la velocità non farà salire le conversioni. Guardate prima perché i visitatori se ne vanno; la velocità è solo uno dei motivi.
Se il software su cui gira il sito è invecchiato e velocizzarlo diventa rattoppare fondamenta marce, una ricostruzione può essere la strada più sensata. Un sito rattoppato all'infinito diventa più fragile a ogni toppa. In tal caso, un progetto di velocità significa spendere parte del budget per la vecchia struttura anziché per la nuova.
La dimensione di un lavoro di velocizzazione è fissata dall'origine della lentezza, e solo la misurazione rivela quell'origine. Registrate prima i valori chiave su dispositivi reali, ordinate i problemi per effetto, iniziate con passi piccoli e a basso rischio e misurate di nuovo dopo ciascuno. Se desiderate esaminare insieme perché il vostro sito è lento, saremo lieti di organizzare un colloquio conoscitivo con rabbitclip.
Domande frequenti
Quanto tempo ci vuole per velocizzare un sito web?
Dipende dall'origine della lentezza e dalla dimensione del sito. Il lavoro su immagini e script è rapido; ciò che richiede cambi di server o di architettura impiega più tempo. Una stima seria non è possibile prima di misurare.
Se il punteggio di un test di velocità è alto, il sito è veloce?
Non sempre. Un punteggio è un indicatore; l'esperienza reale dei visitatori varia con il dispositivo e la connessione. È più affidabile provare su uno smartphone con una connessione media e controllare LCP, INP e CLS.
Basta un plugin per velocizzare un sito?
In alcuni siti i plugin di cache e compressione fanno la differenza. Ma se il problema sta in immagini pesanti, troppi script o nel server, un plugin non lo risolve da solo. Installarne uno prima di trovare la causa può far perdere tempo.
La velocità del sito influisce davvero sulle vendite?
Un visitatore può lasciare una pagina lenta prima che finisca di caricarsi, il che riduce la probabilità che il modulo o il percorso d'ordine venga usato. L'entità dell'effetto varia da sito a sito e non si può fissare con una cifra.
