Se hai notato che i visitatori del tuo sito web se ne vanno rapidamente prima che la pagina si carichi, non sei il solo. Il caricamento lento di un sito web è un problema che influisce sull'esperienza utente, sul posizionamento nei risultati di ricerca e persino sulle vendite. Molte soluzioni popolari si concentrano su strumenti a pagamento o modifiche complesse, ma nella maggior parte dei casi la causa sottostante è semplice e può essere risolta in pochi minuti. Questo articolo ti mostra da dove iniziare e cosa la maggior parte delle soluzioni ignora.
Potresti aver notato che alcune delle tue pagine web impiegano più di 10 secondi per caricarsi: non sei il solo. Le pagine web lente causano tassi di rimbalzo più elevati, e questo è un problema. La colpa è di strumenti moderni e tecniche obsolete. Fortunatamente, con un po' di conoscenza e una strategia intelligente, puoi facilmente superare questo problema comune.
Il tuo obiettivo generale dovrebbe essere quello di mantenere le tue pagine web leggere, evitare eccessive richieste di rete durante i caricamenti iniziali e concentrarti sul rendering dei contenuti delle pagine il più rapidamente possibile. Utilizza le seguenti tecniche ed evita approcci tradizionali come framework e librerie che appesantiscono la tua pagina. Il tuo stile unico ti distinguerà dalla concorrenza.
Evitate le montature troppo grandi.
In un post precedente che offriva consigli agli sviluppatori web principianti, ho suggerito di evitare i framework perché sono difficili da imparare e richiedono molte risorse per essere utilizzati. La maggior parte dei framework reinventa le soluzioni delegando troppo lavoro a JavaScript, il che non è proprio l'ideale.
La tua strategia dovrebbe essere quella di creare una pagina web veloce ed efficiente, quindi un framework potrebbe essere la scelta sbagliata. I principali vantaggi di un framework sono applicazioni a pagina singola, una migliore organizzazione del codice e aggiornamenti del DOM più efficienti: i primi due sono controversi, mentre il terzo è valido solo in determinate situazioni.
Personalmente, utilizzo i Web Components per progetti più piccoli e mirati. Non solo sono più piccoli, ma continueranno a funzionare anche dopo la scomparsa di React, Angular e Vue, perché fanno parte dello standard W3. Il framework Lit (di Google) è un wrapper leggero per i Web Components che sembra molto promettente; risolve parte del codice boilerplate (codice noioso e duplicato).
Quindi, se possibile, evitate framework (pesanti); gran parte dei consigli che seguono presuppongono questo. Tuttavia, se utilizzate un framework (come React), alcune cose potrebbero non essere applicabili, ma sono comunque essenziali.
Utilizzare dipendenze meno numerose e più leggere
Quando la pagina si carica inizialmente, le richieste di rete per estrarre le dipendenze contribuiscono in modo significativo alle scarse prestazioni. Cerco di evitare le dipendenze a tutti i costi, soprattutto con librerie helper come Lodash o Ramda. Purtroppo, questo significa utilizzare soluzioni personalizzate per alcune cose.
Ad esempio, una volta avevo bisogno di un semplice bus di eventi, una classe che essenzialmente rappresenta un canale di comunicazione condiviso nel mio codice. Una soluzione popolare è una libreria chiamata RxJS, ma invece di includerla come dipendenza, che è di 17.7 KB (compressa), ho scritto una mia classe da 200 byte. Questo mi ha fatto risparmiare solo 100 millisecondi di tempo di caricamento iniziale, ma il tutto si è sommato.
Il metodo tradizionale per scrivere codice per il browser prevede la compilazione. Questo processo richiede la scrittura di codice in Node.js e l'utilizzo di uno strumento, come Webpack, per convertirlo in un formato utilizzabile dal browser. Il risultato è un unico, grande blocco di codice che include tutto, spesso di dimensioni superiori a 100 kilobyte. Per risolvere questo problema si sono evolute tecniche come la frammentazione del codice, che suddivide il codice in blocchi; il framework o il browser scarica quindi questi blocchi solo quando necessario. Un'altra tecnica è il tree-shaking, che analizza il codice per estrarre solo ciò che è necessario; ESM funziona in modo piuttosto simile.
ESM è il moderno sistema di moduli JavaScript, il nuovo standard per importare librerie. Ecco un esempio di ESM:
<script type="module">
const {foo} from "https://example.com/all-the-things.js"
</script>L'esempio sopra riportato scaricherà il modulo richiesto e tutti gli altri moduli che dipendono da esso. È così che funziona ESM, e presenta alcune vaghe somiglianze con il tree shaking.
ESM non è una soluzione magica e ha certamente i suoi limiti. Pur incoraggiandovi a utilizzarlo, mi attengo al mio precedente consiglio di scrivere soluzioni semplici (ove possibile), evitando così un albero delle dipendenze troppo elaborato per librerie di terze parti. Se la scrittura richiede meno di 30 minuti, perché no?
Un limite di ESM è che se un modulo dipende da molti altri moduli, il browser deve scaricarli tutti: questo raggruppamento è chiamato albero delle dipendenze. Ad esempio, l'importazione della funzione capitalize da Lodash richiede il download di diversi file aggiuntivi:
<script type="module">
import capitalize from 'https://cdn.jsdelivr.net/npm/lodash-es@4.17.21/capitalize.js';
alert(capitalize("hello world!"))
</script>Dalle immagini si può vedere che usando Lodash per scrivere in maiuscolo la prima lettera di una parola si eseguono 23 richieste e si impiegano 4.4 secondi su una connessione GPRS (20 kbps); mentre su una connessione a 100 Mbps, ci vogliono comunque 2.2 secondi. Se una velocità di connessione 5000 volte superiore si traduce solo nel doppio della velocità di download, ciò indica che il problema non è la larghezza di banda.
Nella terza immagine, la sezione contrassegnata con 1 mostra il browser che invia richieste in sequenza, scaricando solo il codice di cui ha bisogno (un po' come scuotere un albero). Il browser scarica ogni file, ne controlla le importazioni (dipendenze) e poi le scarica. La connessione utilizza HTTP/2, che in alcuni scenari è molto più veloce di HTTP/1. Questo perché HTTP/2 mantiene un'unica connessione persistente, mentre in alcuni casi HTTP/1 si basa su più connessioni separate, ognuna delle quali comporta costi di negoziazione aggiuntivi. Ora immagina che un vecchio browser carichi questa pagina web, utilizzando HTTP/1 per caricare ciascun modulo.
Per mettere in maiuscolo la prima lettera di una frase basta un po' di codice:
function capitalize(str) {
return str.charAt(0).toUpperCase() + str.slice(1);
}
È meglio implementare una soluzione personalizzata se è semplice; questo mantiene il codice leggero e focalizzato sui tuoi obiettivi. Inoltre, ricorda che le importazioni sono costose quando usi ESM, e devi riflettere attentamente su come suddividere il codice; cerca di ridurre al minimo le dipendenze tra i moduli. Il bundling è ancora un modo molto efficace per ridurre il numero di richieste del browser. Ci sono molti aspetti da considerare, quindi prenditi del tempo per questo.
La linea guida è usare le dipendenze con parsimonia. I framework creano dipendenze significative e le librerie rappresentano un problema. L'obiettivo è un'esecuzione rapida ed efficiente, e la latenza di rete avrà un impatto negativo sulle prestazioni.
Utilizzare defer o async sui tag di script
Defer e async sono due attributi che puoi usare sui tag script per modificarne il comportamento. Entrambi hanno un impatto sulle prestazioni, ma funzionano in modo leggermente diverso l'uno dall'altro e ci sono chiari casi d'uso per ciascuno.
Ad eccezione di defer, async ed ESM, si prega di notare che tutti i tag script vengono scaricati in parallelo tra loro, ma vengono eseguiti prima del parser HTML. Questo è il comportamento tipico dei tag script.
Utilizzando un server web personalizzato, ho impostato intenzionalmente i ritardi di download per gli script 1 e 2. Nella Figura 5, si noti che entrambi gli script hanno iniziato a scaricare più o meno nello stesso momento, con quello con il ritardo di 2000 ms partito per primo. Se i download non fossero stati paralleli, lo script più lungo (2000 ms) avrebbe impedito all'altro script di scaricare fino al suo completamento.
Osservando la Figura 4, si può anche notare che l'HTML (Figura 3) non è stato analizzato finché tutti gli script non sono stati completati. Questo dimostra che gli script bloccavano l'analizzatore HTML durante il download e l'esecuzione.
Rinvio
L'attributo defer sui tag script consente al browser di ritardare l'esecuzione dello script fino a dopo il rendering HTML. Questo è importante perché non vogliamo bloccare il contenuto iniziale della pagina mentre aspettiamo che il codice JavaScript pesante venga scaricato ed eseguito. Inoltre, si noti che gli script differiti vengono eseguiti nell'ordine in cui appaiono nell'HTML.
<html>
<head>
<script src="/js/foo.js" defer></script>
</head>
<p>I render before the script.</p>
</html>Consigli
Anche l'ESM è rinviato di default.
Lo script differito viene eseguito al termine del caricamento dell'HTML, consentendo di accedere al DOM in modo sicuro. Se è necessario eseguire il codice al termine di tutti gli script differiti, utilizzare l'evento DOMContentLoaded, che si attiva al termine dell'analisi dell'HTML e dell'esecuzione di tutti gli script differiti.
// /js/foo.js
document.addEventListener("DOMContentLoaded", () => {
console.log("The DOM is fully loaded!")
})Tuttavia, la funzione DOMContentLoaded non attende immagini, script asincroni o frame in linea.
Consigli
Gli script differiti attendono che il browser abbia scaricato e analizzato tutti i fogli di stile, il che è diverso dal comportamento dei normali tag di script.
C'è molto da ricordare, ma in parole povere: la funzione DOMContentLoaded attende che il renderer HTML e i fogli di stile siano completati. Per essere assolutamente certi che la pagina sia pronta, ascoltate la funzione DOMContentLoaded.
async
L'attributo async indica al browser di scaricare lo script mentre l'HTML viene analizzato. Lo script può essere eseguito in qualsiasi momento. Lo script e l'analizzatore HTML non si attendono a vicenda, ma lo script può interrompere l'analizzatore HTML se necessario. Funge da incrocio tra lo scripting normale e lo scripting differito.
<head>
<script src="/js/foo.js" async></script>
</head>
riepilogo
- Gli script differiti (ESM) vengono scaricati immediatamente ed eseguiti dopo l'analizzatore HTML e i fogli di stile.
- Gli script asincroni vengono scaricati immediatamente ed eseguiti in qualsiasi momento, il che potrebbe interrompere l'analizzatore HTML.
- Gli script semplici vengono scaricati immediatamente ed eseguiti prima dell'analizzatore HTML.
L'immagine seguente mostra le tempistiche per ciascun tipo di script, indicando quando vengono scaricati ed eseguiti dal parser HTML:
Utilizza script asincroni per script esterni isolati, come gli annunci pubblicitari, ovvero script che non interagiscono con il resto della pagina. Utilizza script differiti quando possibile. L'uso di script differiti sarà particolarmente importante nella prossima sezione, che tratterà i CSS critici.
CSS importante incluso
Quando una pagina web viene visualizzata per la prima volta, diciamo che gli stili visibili sullo schermo si trovano sopra la piega, mentre gli stili sotto la piega si trovano sotto. Importante: il CSS si occupa di visualizzare gli stili sopra la piega il più rapidamente possibile per dare all'utente l'impressione che la pagina si carichi rapidamente ed evitare di mettere a dura prova la sua pazienza. Questo è importante perché più a lungo gli utenti aspettano che la pagina si carichi, più è probabile che abbandonino la pagina.
Per visualizzare i contenuti above the fold il più rapidamente possibile, dobbiamo suddividere gli stili in due pacchetti, uno per i contenuti above the fold e uno per i contenuti below. Per raggiungere questo obiettivo, analizziamo manualmente gli stili per ogni sezione, sia per i dispositivi desktop che per quelli mobili.
Per dividere i tuoi modelli in due pacchetti, ecco un esempio di base:
<!DOCTYPE html>
<html lang="en">
<head>
<script src="below-the-fold.js" defer></script>
<style>
/* Critical CSS. */
</style>
</head>
<body>
<aside>Above the fold.</aside>
<main>
<p>Below the fold.</p>
</main>
<link rel="stylesheet" type="text/css" href="below-the-fold.css">
</body>
</html>Per renderlo più leggibile, l'esempio sopra riportato è incompleto; un esempio reale è il seguente:
Il tag di stile nella sezione 1 contiene codice CSS importante, che dovrebbe includere gli stili sopra la piega. Nel nostro esempio, il tag "side" (sezione 6) contiene tutto il contenuto sopra la piega. Se desideri modificarne lo stile, modifica la sezione 1.
Quando la pagina viene visualizzata per la prima volta, il contenuto sottostante non ha stili, quindi lampeggerà brevemente, mostrando il contenuto senza stile: questo è chiamato flash of unstyled content (FOUC). Per risolvere questo problema, ho nascosto il contenuto con un'opacità pari a 0 (sezione 1). Quando si esegue JavaScript (sezione 4), questa opacità verrà impostata a 1. C'è un effetto di transizione graduale, quindi la dissolvenza in entrata è gradevole.
Poiché i fogli di stile nell'elemento head bloccano il motore di rendering HTML, carichiamo invece il CSS non essenziale verso la fine del testo (Sezione 3), dopo che tutto il resto del codice HTML è stato renderizzato. In breve, il browser renderizza prima il codice HTML e poi scarica il foglio di stile alla fine del testo, prima di eseguire lo script differito.
ملاحظة
Utilizziamo uno script differito perché viene eseguito dopo che l'HTML è stato completamente renderizzato e dopo che tutti i fogli di stile sono stati scaricati e applicati.
Il processo si svolge in questo modo:
- Il browser richiede HTML.
- Il browser inizia ad analizzare il documento.
- Il browser scarica JavaScript in background, quindi lo rende attivo (sezione 5).
- Il browser analizza gli stili in linea (sezione 1).
- Il browser visualizza il tag “side”, posizionato sopra la piega (sezione 6).
- Il browser visualizza il contenuto principale (sezione 2), situato sotto la piega, con trasparenza 0, grazie al CSS di base (sezione 1).
- Il browser scarica CSS non core (sezione 3).
- Il browser completa l'analisi dell'HTML e degli stili, quindi esegue DOMContentLoaded.
- Abilita JavaScript per rendere visibile il contenuto sotto la piega (Figura 4).
In breve: il browser esegue il CSS in fondo alla pagina, visualizzando tutto l'HTML e rendendo invisibile il contenuto below-the-fold. Una volta completato, viene eseguito JavaScript per mostrare il contenuto below-the-fold.
In breve: mostra rapidamente la piega superiore e nascondi tutto il resto finché non sei pronto.
Prendetevi il tempo necessario per assimilare quanto detto finora e per svilupparlo ulteriormente. Vi suggerisco di abbandonare le raccomandazioni tradizionali per React, Angular e migliaia di dipendenze. Invece, dovreste:
- Controlla le tue dipendenze e riducile al minimo. Meno richieste significano caricamenti delle pagine più rapidi.
- Scopri come funzionano i tag script, quando caricarli e come evitare di bloccare il parser HTML.
- Capire quando vengono caricati i fogli di stile, sia nell'intestazione che nel corpo, e quindi capire se bloccano il renderer HTML.
- Visualizza il testo HTML visibile il più velocemente possibile; carica tutto in tempo.
Se vuoi mettere in pratica ciò che hai appena imparato ma hai bisogno di risorse che ti aiutino, dai un'occhiata ai siti web che ogni sviluppatore web principiante dovrebbe conoscere. Oppure, se vuoi iniziare ma ti manca l'ispirazione, dai un'occhiata alla nostra guida su come creare la tua prima semplice app web per il conteggio delle parole.
Non hai bisogno di strumenti costosi o server avanzati per velocizzare il tuo sito. File di grandi dimensioni non compressi, immagini non ottimizzate o codice JavaScript non gestito sono spesso i colpevoli. Utilizzando le semplici modifiche descritte in questo articolo, puoi ridurre significativamente il tempo di caricamento delle pagine del tuo sito. Hai provato qualcuno di questi passaggi? Condividi la tua esperienza con noi o chiedi nei commenti, così possiamo aiutarti ad analizzare il tuo sito gratuitamente.
