PRPL è un acronimo che descrive un pattern utilizzato per velocizzare il caricamento e la riattivazione delle pagine web:
- Precarica le risorse scoperte in ritardo.
- Esegui il rendering del percorso iniziale il prima possibile.
- Pre-cache gli asset rimanenti.
- Carica in modo lazy altri percorsi e asset non critici.
In questa guida scoprirai come ognuna di queste tecniche si integra insieme ma può comunque essere utilizzata in modo indipendente per ottenere risultati in termini di prestazioni.
Controllare la pagina con Lighthouse
Esegui Lighthouse per identificare le opportunità di miglioramento in linea con le tecniche PRPL:
- Premi "Control+Maiusc+J" (o "Comando+Opzione+J" su Mac) per aprire DevTools.
- Fai clic sulla scheda Lighthouse.
- Seleziona le caselle di controllo Rendimento e App web progressive.
- Fai clic su Esegui controlli per generare un report.
Per ulteriori informazioni, consulta Scoprire opportunità di miglioramento del rendimento con Lighthouse.
Precarica le risorse critiche
Lighthouse mostra il seguente controllo non riuscito se una determinata risorsa viene analizzata e recuperata in ritardo:
Il precaricamento è una richiesta di recupero dichiarativa che indica al browser di richiedere una risorsa che altrimenti non sarebbe rilevabile dallo scanner di precaricamento del browser, ad esempio un'immagine a cui fa riferimento la proprietà background-image
. Precarica le risorse scoperte in ritardo aggiungendo un tag <link>
con rel="preload"
all'intestazione del documento HTML:
<link rel="preload" as="image" href="hero-image.jpg">
L'aggiunta di una direttiva <link rel="preload">
avvia una richiesta per la risorsa e la memorizza nella cache. Il browser sarà quindi in grado di recuperarlo quando necessario.
Per ulteriori informazioni sul precaricamento delle risorse fondamentali, consulta la guida Precarica gli asset critici.
Esegui il rendering del percorso iniziale il prima possibile
Lighthouse fornisce un avviso se sono presenti risorse che ritardano la prima visualizzazione, ovvero il momento in cui il sito esegue il rendering dei pixel sullo schermo:
Per migliorare First Paint, Lighthouse consiglia di incorporare codice JavaScript fondamentale e di rinviare il resto utilizzando async
, nonché di incorporare il codice CSS fondamentale utilizzato above the fold. Questo migliora le prestazioni eliminando i round trip al server per recuperare gli asset che bloccano il rendering.
Tuttavia, il codice in linea è più difficile da gestire dal punto di vista dello sviluppo e non può essere memorizzato nella cache separatamente dal browser.
Un altro approccio per migliorare First Paint è quello di eseguire il rendering lato server del codice HTML iniziale della pagina. In questo modo, i contenuti vengono visualizzati immediatamente all'utente mentre gli script vengono ancora recuperati, analizzati ed eseguiti. Tuttavia, questo può aumentare notevolmente il payload del file HTML, il che può danneggiare il tempo di risposta, ovvero il tempo necessario affinché l'applicazione diventi interattiva e possa rispondere all'input dell'utente.
Non esiste una singola soluzione corretta per ridurre il primo rendering nella tua applicazione e dovresti prendere in considerazione l'inserimento in linea degli stili e il rendering lato server solo se i vantaggi superano i compromessi per la tua applicazione. Puoi approfondire entrambi i concetti consultando le seguenti risorse.
Esegui la precache degli asset
Agendo da proxy, i service worker possono recuperare gli asset direttamente dalla cache anziché dal server durante le visite ripetute. In questo modo, non solo gli utenti possono utilizzare la tua applicazione quando sono offline, ma i tempi di caricamento delle pagine sono anche più rapidi durante le visite ripetute.
Utilizza una libreria di terze parti per semplificare il processo di generazione di un service worker, a meno che tu non abbia requisiti di memorizzazione nella cache più complessi rispetto a quelli forniti da una libreria. Ad esempio, Workbox fornisce una collezione di strumenti che ti consentono di creare e gestire un worker di servizio per memorizzare nella cache gli asset. Per ulteriori informazioni sui service worker e sull'affidabilità offline, consulta la guida ai service worker nel percorso di apprendimento sull'affidabilità.
Caricamento lento
Lighthouse mostra un controllo non riuscito se invii troppi dati tramite la rete.
Ciò include tutti i tipi di asset, ma i grandi payload di JavaScript sono particolarmente costosi a causa del tempo impiegato dal browser per analizzarli e compilarli. Lighthouse fornisce anche un avviso in merito, se opportuno.
Per inviare un payload JavaScript più piccolo che contenga solo il codice necessario quando un utente carica inizialmente l'applicazione, suddividi l'intero bundle e carica in modo lazy i chunk su richiesta.
Dopo aver suddiviso il bundle, precarica i chunk più importanti (consulta la guida Precarica gli asset critici). Il precaricamento garantisce che le risorse più importanti vengano recuperate e scaricate prima dal browser.
Oltre a suddividere e caricare diversi chunk di JavaScript su richiesta, Lighthouse fornisce anche un controllo per il caricamento lento delle immagini non critiche.
Se carichi molte immagini nella tua pagina web, rimanda quelle che non sono visibili o al di fuori dell'area visibile del dispositivo quando viene caricata una pagina (vedi Utilizzare lazysizes per il caricamento lazy delle immagini).
Passaggi successivi
Ora che hai compreso alcuni dei concetti di base alla base del pattern PRPL, passa alla guida successiva di questa sezione per saperne di più. È importante ricordare che non tutte le tecniche devono essere applicate insieme. Qualsiasi sforzo fatto in base a quanto segue fornirà notevoli miglioramenti del rendimento.
- Precarica le risorse fondamentali.
- Esegui il rendering del percorso iniziale il prima possibile.
- Pre-cache gli asset rimanenti.
- Carica in modo lazy altri percorsi e asset non critici.
Scopri di più sui pattern PRPL.