PRPL è un acronimo che descrive un pattern utilizzato per caricare le pagine web e renderle interattive e veloci:
- Precarica le risorse scoperte in ritardo.
- Esegui il rendering della route iniziale il prima possibile.
- Pre-memorizza nella cache gli asset rimanenti.
- Caricamento lento di altre route e asset non critici.
In questa guida scoprirai come ognuna di queste tecniche si integra bene, ma può comunque essere utilizzata in modo indipendente per ottenere risultati di prestazioni.
Controlla la tua pagina con Lighthouse
Esegui Lighthouse per identificare opportunità di miglioramento in linea con le tecniche del PRPL:
- Premi "Control+Maiusc+J" (o "Comando+Opzione+J" su Mac) per aprire DevTools.
- Fai clic sulla scheda Lighthouse.
- Seleziona le caselle di controllo Prestazioni e App web progressiva.
- Fai clic su Esegui controlli per generare un report.
Per saperne di più, consulta Scoprire le opportunità per le prestazioni con Lighthouse.
Precarica le risorse critiche
Lighthouse mostra il seguente controllo non riuscito se una determinata risorsa viene analizzata e recuperata in ritardo:
Precarica è 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 più di recente aggiungendo un tag <link> con rel="preload" all'intestazione del documento HTML:
<link rel="preload" as="image" href="hero-image.jpg">
L'aggiunta di un'istruzione <link rel="preload"> avvierà una richiesta per la risorsa e la archivierà nella cache. Il browser è quindi in grado di recuperarlo quando necessario.
Per ulteriori informazioni sul precaricamento delle risorse critiche, consulta la guida Precaricare gli asset critici.
Visualizza il percorso iniziale il prima possibile
Lighthouse fornisce un avviso se sono presenti risorse che ritardano la visualizzazione di First Paint, nel momento in cui il tuo sito esegue il rendering dei pixel sullo schermo:
Per migliorare First Paint, Lighthouse consiglia di incorporare codice JavaScript critico e di differire il resto utilizzando async, oltre a incorporare i CSS essenziali utilizzati above the fold. Ciò migliora le prestazioni eliminando i round trip al server per recuperare gli asset che bloccano la visualizzazione.
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 è eseguire il rendering lato server del codice HTML iniziale della pagina. In questo modo i contenuti vengono visualizzati immediatamente all'utente mentre gli script sono ancora in fase di recupero, analisi ed esecuzione. Tuttavia, questo può aumentare notevolmente il payload del file HTML, il che può danneggiare il valore di Tempo all'interattività o il tempo necessario affinché l'applicazione diventi interattiva e sia in grado di rispondere all'input dell'utente.
Non esiste un'unica soluzione corretta per ridurre la prima visualizzazione nella tua applicazione e ti consigliamo di prendere in considerazione gli stili incorporati e il rendering lato server solo se i vantaggi superano i compromessi per la tua applicazione. Puoi scoprire di più su entrambi questi concetti consultando le seguenti risorse.
Memorizza nella cache gli asset
Agendo come proxy, i service worker 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 riduce anche i tempi di caricamento delle pagine in occasione di 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 che può fornire una libreria. Ad esempio, Workbox offre una raccolta di strumenti che consentono di creare e mantenere un service worker per memorizzare gli asset nella cache. 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 payload JavaScript di grandi dimensioni sono particolarmente costosi perché il browser impiega il browser ad analizzarli e compilarli. Lighthouse fornisce anche un avviso, quando opportuno.
Per inviare un payload JavaScript di dimensioni inferiori che contenga solo il codice necessario quando un utente carica inizialmente l'applicazione, suddividi l'intero bundle e i blocchi con caricamento lento on demand.
Quando hai completato la suddivisione del bundle, precarica i blocchi più importanti (consulta la guida Precarica gli asset critici). Il precaricamento assicura che le risorse più importanti vengano recuperate e scaricate prima dal browser.
Oltre a suddividere e caricare diversi blocchi JavaScript on demand, Lighthouse offre anche un controllo per il caricamento lento delle immagini non fondamentali.
Se nella pagina web carichi molte immagini, rinvia tutte le immagini below the fold o esterne all'area visibile del dispositivo quando viene caricata una pagina (consulta la sezione Utilizzare la funzionalità lazysize per il caricamento lento delle immagini).
Passaggi successivi
Ora che conosci 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 compiuto in uno dei seguenti modi permetterà di ottenere notevoli miglioramenti delle prestazioni.
- Precarica le risorse critiche.
- Esegui il rendering della route iniziale il prima possibile.
- Pre-memorizza nella cache gli asset rimanenti.
- Caricamento lento di altre route e asset non critici.
Puoi leggere ulteriori informazioni sui pattern PRPL.