PRPL è un acronimo che descrive un pattern utilizzato per velocizzare il caricamento e la riattivazione delle pagine web:
- Precarica le risorse scoperte in un secondo momento.
- Esegui il rendering del percorso iniziale il prima possibile.
- Pre-cache gli asset rimanenti.
- Carica lentamente altre route e asset non critici.
In questa guida scoprirai come ogni una di queste tecniche si combina con le altre, ma può essere utilizzata anche in modo indipendente per ottenere risultati in termini di rendimento.
Controllare la pagina con Lighthouse
Esegui Lighthouse per identificare le opportunità di miglioramento in linea con le tecniche PRPL:
- Premi "Ctrl+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 saperne di più, consulta Scoprire le opportunità di 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 un secondo momento aggiungendo un tag <link> con rel="preload" all'head 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 può quindi 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 visualizza un avviso se sono presenti risorse che ritardano la prima colorazione, il momento in cui i pixel del sito vengono visualizzati 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. In questo modo, le prestazioni vengono migliorate eliminando i viaggi di andata e ritorno 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 il First Paint è 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 un'unica soluzione corretta per ridurre il First Paint nella tua applicazione e dovresti prendere in considerazione l'utilizzo di stili incorporati 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.
Prememorizza gli asset nella cache
Agendo da proxy, i lavoratori di servizio possono recuperare gli asset direttamente dalla cache anziché dal server in visite ripetute. Questo non solo consente agli utenti di utilizzare la tua applicazione quando sono offline, ma si traduce anche in tempi di caricamento della pagina più rapidi per 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.
Sono inclusi tutti i tipi di asset, ma i payload JavaScript di grandi dimensioni sono particolarmente costosi a causa del tempo necessario al 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 critiche.
- 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.