Performance front-end 2021: definizione dell'ambiente

Questa guida è stata gentilmente supportata dai nostri amici di LogRocket, un servizio che combina il monitoraggio delle prestazioni del frontend , la riproduzione delle sessioni e l'analisi dei prodotti per aiutarti a creare esperienze migliori per i clienti. LogRocket tiene traccia delle metriche chiave, incl. DOM completo, tempo al primo byte, primo ritardo di input, CPU client e utilizzo della memoria. Ottieni una prova gratuita di LogRocket oggi.

Sommario

1. Prepararsi: pianificazione e metriche
2. Stabilire obiettivi realistici
3. Definire l'ambiente
4. Ottimizzazioni degli asset
5. Costruisci ottimizzazioni
6. Ottimizzazioni di consegna
7. Rete, HTTP/2, HTTP/3
8. Test e monitoraggio
9. Vittorie veloci
10. Tutto in una pagina
11. Scarica la lista di controllo (PDF, Apple Pages, MS Word)
12. Iscriviti alla nostra newsletter via email per non perdere le prossime guide.

Definire l'ambiente

1. Scegli e configura i tuoi strumenti di costruzione.
   Non prestare troppa attenzione a ciò che è apparentemente cool in questi giorni. Attenersi al proprio ambiente per la costruzione, che si tratti di Grunt, Gulp, Webpack, Parcel o una combinazione di strumenti. Finché ottieni i risultati di cui hai bisogno e non hai problemi a mantenere il tuo processo di creazione, stai andando bene.

   Tra gli strumenti di build, Rollup continua a guadagnare terreno, così come Snowpack, ma Webpack sembra essere il più consolidato, con letteralmente centinaia di plugin disponibili per ottimizzare le dimensioni delle tue build. Fai attenzione alla Roadmap Webpack 2021.

   Una delle strategie più importanti apparse di recente è il blocco granulare con Webpack in Next.js e Gatsby per ridurre al minimo il codice duplicato. Per impostazione predefinita, i moduli che non sono condivisi in ogni punto di ingresso possono essere richiesti per i percorsi che non lo utilizzano. Questo finisce per diventare un sovraccarico poiché viene scaricato più codice del necessario. Con il chunking granulare in Next.js, possiamo utilizzare un file manifest di build lato server per determinare quali blocchi emessi vengono utilizzati da diversi punti di ingresso.

   

   Con SplitChunksPlugin, vengono creati più blocchi divisi in base a una serie di condizioni per impedire il recupero di codice duplicato su più percorsi. Ciò migliora il tempo di caricamento della pagina e la memorizzazione nella cache durante le navigazioni. Spedito in Next.js 9.2 e in Gatsby v2.20.7.

   Tuttavia, iniziare con Webpack può essere difficile. Quindi, se vuoi tuffarti in Webpack, ci sono alcune ottime risorse là fuori:

   • La documentazione di Webpack, ovviamente, è un buon punto di partenza, così come Webpack — The Confusing Bits di Raja Rao e An Annotated Webpack Config di Andrew Welch.
   • Sean Larkin ha un corso gratuito su Webpack: The Core Concepts e Jeffrey Way ha rilasciato un fantastico corso gratuito su Webpack per tutti. Entrambi sono ottime introduzioni per immergersi in Webpack.
   • Webpack Fundamentals è un corso molto completo di 4 ore con Sean Larkin, pubblicato da FrontendMasters.
   • Gli esempi di Webpack hanno centinaia di configurazioni Webpack pronte per l'uso, suddivise per argomento e scopo. Bonus: esiste anche un configuratore di configurazione Webpack che genera un file di configurazione di base.
   • awesome-webpack è un elenco curato di utili risorse Webpack, librerie e strumenti, inclusi articoli, video, corsi, libri ed esempi per progetti Angular, React e indipendenti dal framework.
   • Il viaggio verso la creazione rapida di risorse di produzione con Webpack è il case study di Etsy su come il team è passato dall'utilizzo di un sistema di compilazione JavaScript basato su RequireJS all'utilizzo di Webpack e su come ha ottimizzato le proprie build, gestendo in media oltre 13.200 risorse in 4 minuti .
   • I suggerimenti per le prestazioni di Webpack sono una miniera d'oro di Ivan Akulov, con molti suggerimenti incentrati sulle prestazioni, inclusi quelli incentrati specificamente su Webpack.
   • awesome-webpack-perf è un repository GitHub miniera d'oro con utili strumenti Webpack e plug-in per le prestazioni. Mantenuto anche da Ivan Akulov.

1. Usa il miglioramento progressivo come impostazione predefinita.
   Tuttavia, dopo tutti questi anni, mantenere il miglioramento progressivo come principio guida dell'architettura e della distribuzione front-end è una scommessa sicura. Progetta e costruisci prima l'esperienza di base, quindi migliora l'esperienza con funzionalità avanzate per browser capaci, creando esperienze resilienti. Se il tuo sito Web funziona velocemente su una macchina lenta con uno schermo scadente in un browser scadente su una rete non ottimale, funzionerà più velocemente solo su una macchina veloce con un buon browser su una rete decente.

   In effetti, con il servizio di moduli adattivi, sembra che stiamo portando il miglioramento progressivo a un altro livello, offrendo esperienze di base "lite" ai dispositivi di fascia bassa e migliorando con funzionalità più sofisticate per i dispositivi di fascia alta. È improbabile che il miglioramento progressivo svanisca presto.

2. Scegli una linea di base di prestazioni forti.
   Con così tante incognite che incidono sul caricamento: rete, limitazione termica, rimozione della cache, script di terze parti, modelli di blocco del parser, I/O del disco, latenza IPC, estensioni installate, software antivirus e firewall, attività CPU in background, vincoli hardware e di memoria, differenze nella memorizzazione nella cache L2/L3, RTTS: JavaScript ha il costo più pesante dell'esperienza, accanto ai caratteri Web che bloccano il rendering per impostazione predefinita e alle immagini che spesso consumano troppa memoria. Con i colli di bottiglia delle prestazioni che si spostano dal server al client, come sviluppatori dobbiamo considerare tutte queste incognite in modo molto più dettagliato.

   Con un budget di 170 KB che contiene già il percorso critico HTML/CSS/JavaScript, router, gestione dello stato, utilità, framework e logica dell'applicazione, dobbiamo esaminare a fondo il costo di trasferimento di rete, il tempo di analisi/compilazione e il costo di runtime del quadro di nostra scelta. Fortunatamente, negli ultimi anni abbiamo assistito a un enorme miglioramento nella velocità con cui i browser possono analizzare e compilare gli script. Tuttavia, l'esecuzione di JavaScript è ancora il collo di bottiglia principale, quindi prestare molta attenzione al tempo di esecuzione degli script e alla rete può avere un impatto.

   Tim Kadlec ha condotto una fantastica ricerca sulle prestazioni dei framework moderni e le ha riassunte nell'articolo "I framework JavaScript hanno un costo". Parliamo spesso dell'impatto dei framework standalone, ma come osserva Tim, in pratica non è raro avere più framework in uso . Forse una versione precedente di jQuery che viene lentamente migrata a un framework moderno, insieme ad alcune applicazioni legacy che utilizzano una versione precedente di Angular. Quindi è più ragionevole esplorare il costo cumulativo dei byte JavaScript e del tempo di esecuzione della CPU che può facilmente rendere le esperienze utente a malapena utilizzabili, anche su dispositivi di fascia alta.

   In generale, i framework moderni non danno la priorità ai dispositivi meno potenti , quindi le esperienze su un telefono e su desktop saranno spesso notevolmente diverse in termini di prestazioni. Secondo la ricerca, i siti con React o Angular trascorrono più tempo sulla CPU rispetto ad altri (il che ovviamente non significa necessariamente che React sia più costoso sulla CPU di Vue.js).

   Secondo Tim, una cosa è ovvia: "se stai utilizzando un framework per costruire il tuo sito, stai facendo un compromesso in termini di prestazioni iniziali , anche nel migliore degli scenari".

1. Valuta framework e dipendenze.
   Ora, non tutti i progetti necessitano di un framework e non tutte le pagine di un'applicazione a pagina singola devono caricare un framework. Nel caso di Netflix, "la rimozione di React, diverse librerie e il codice dell'app corrispondente dal lato client ha ridotto la quantità totale di JavaScript di oltre 200 KB, causando una riduzione di oltre il 50% del tempo di interattività di Netflix per la home page disconnessa ." Il team ha quindi utilizzato il tempo trascorso dagli utenti sulla pagina di destinazione per precaricare React per le pagine successive su cui è probabile che gli utenti atterrano (continua a leggere per i dettagli).

   E se rimuovessi del tutto un framework esistente su pagine critiche? Con Gatsby, puoi controllare gatsby-plugin-no-javascript che rimuove tutti i file JavaScript creati da Gatsby dai file HTML statici. Su Vercel, puoi anche consentire la disabilitazione di JavaScript runtime in produzione per determinate pagine (sperimentale).

   Una volta scelto un framework, lo utilizzeremo per almeno alcuni anni, quindi se dobbiamo utilizzarne uno, dobbiamo assicurarci che la nostra scelta sia informata e ben ponderata, e questo vale soprattutto per le metriche chiave delle prestazioni che cura.

   I dati mostrano che, per impostazione predefinita, i framework sono piuttosto costosi: il 58,6% delle pagine React spedisce oltre 1 MB di JavaScript e il 36% dei caricamenti di pagine Vue.js ha un First Contentful Paint di <1,5s. Secondo uno studio di Ankur Sethi, "la tua applicazione React non si caricherà mai più velocemente di circa 1,1 secondi su un telefono medio in India, non importa quanto la ottimizzi. La tua app Angular impiegherà sempre almeno 2,7 secondi per avviarsi. Il gli utenti della tua app Vue dovranno attendere almeno 1 secondo prima di poter iniziare a utilizzarla." Potresti comunque non rivolgerti all'India come mercato principale, ma gli utenti che accedono al tuo sito con condizioni di rete non ottimali avranno un'esperienza simile.

   Ovviamente è possibile realizzare SPA veloci, ma non sono veloci, quindi dobbiamo tenere conto del tempo e degli sforzi necessari per realizzarle e mantenerle veloci. Probabilmente sarà più facile scegliendo all'inizio un costo di base delle prestazioni leggero.

   Allora come scegliamo un framework ? È buona norma considerare almeno il costo totale sulla dimensione + i tempi di esecuzione iniziali prima di scegliere un'opzione; opzioni leggere come Preact, Inferno, Vue, Svelte, Alpine o Polymer possono portare a termine il lavoro perfettamente. La dimensione della tua linea di base definirà i vincoli per il codice della tua applicazione.

   Come notato da Seb Markbage, un buon modo per misurare i costi di avvio per i framework è prima eseguire il rendering di una vista, quindi eliminarla e quindi renderizzare di nuovo in quanto può dirti come scala il framework. Il primo rendering tende a riscaldare un mucchio di codice compilato in modo pigro, di cui un albero più grande può trarre vantaggio quando viene ridimensionato. Il secondo rendering è fondamentalmente un'emulazione di come il riutilizzo del codice in una pagina influisce sulle caratteristiche delle prestazioni man mano che la pagina cresce in complessità.

   Potresti arrivare fino a valutare i tuoi candidati (o qualsiasi libreria JavaScript in generale) sul sistema di punteggio in scala a 12 punti di Sacha Greif esplorando funzionalità, accessibilità, stabilità, prestazioni, ecosistema di pacchetti , comunità, curva di apprendimento, documentazione, strumenti, track record , team, compatibilità, sicurezza per esempio.

   

   Puoi anche fare affidamento sui dati raccolti sul Web per un periodo di tempo più lungo. Ad esempio, Perf Track tiene traccia delle prestazioni del framework su larga scala, mostrando i punteggi dei Core Web Vitals aggregati all'origine per i siti Web creati in Angular, React, Vue, Polymer, Preact, Ember, Svelte e AMP. Puoi anche specificare e confrontare i siti Web creati con Gatsby, Next.js o Create React App, nonché i siti Web creati con Nuxt.js (Vue) o Sapper (Svelte).

   Un buon punto di partenza è scegliere un buon stack predefinito per la tua applicazione. Gatsby (React), Next.js (React), Vuepress (Vue), Preact CLI e PWA Starter Kit forniscono impostazioni predefinite ragionevoli per un rapido caricamento immediato sull'hardware mobile medio. ​​Inoltre, dai un'occhiata alla guida alle prestazioni specifiche del framework web.dev per React e Angular ( grazie, Phillip! ).

   E forse potresti adottare un approccio leggermente più rinfrescante alla creazione di applicazioni a pagina singola: Turbolinks, una libreria JavaScript da 15 KB che utilizza HTML anziché JSON per il rendering delle visualizzazioni. Quindi, quando segui un link, Turbolinks recupera automaticamente la pagina, scambia il suo <body> e unisce il suo <head> , il tutto senza incorrere nel costo di un caricamento completo della pagina. Puoi controllare i dettagli rapidi e la documentazione completa sullo stack (Hotwire).

1. Rendering lato client o rendering lato server? Tutti e due!
   È una conversazione piuttosto accesa da avere. L'approccio finale sarebbe quello di impostare una sorta di avvio progressivo: utilizzare il rendering lato server per ottenere un rapido First Contentful Paint, ma includere anche alcuni JavaScript necessari minimi per mantenere il tempo di interazione vicino al First Contentful Paint. Se JavaScript arriva troppo tardi dopo l'FCP, il browser bloccherà il thread principale durante l'analisi, la compilazione e l'esecuzione di JavaScript scoperto in ritardo, limitando così l'interattività del sito o dell'applicazione.

   Per evitarlo, suddividi sempre l'esecuzione delle funzioni in attività asincrone separate e, ove possibile, usa requestIdleCallback . Prendi in considerazione il caricamento lento di parti dell'interfaccia utente utilizzando il supporto dinamico import() di WebPack, evitando il costo di caricamento, analisi e compilazione fino a quando gli utenti non ne hanno davvero bisogno ( grazie Addy! ).

   Come accennato in precedenza, Time to Interactive (TTI) ci dice il tempo che intercorre tra la navigazione e l'interattività. In dettaglio, la metrica viene definita osservando la prima finestra di cinque secondi dopo il rendering del contenuto iniziale, in cui nessuna attività JavaScript richiede più di 50 ms ( Attività lunghe ). Se si verifica un'attività superiore a 50 ms, la ricerca di una finestra di cinque secondi ricomincia. Di conseguenza, il browser presumerà prima di tutto di aver raggiunto Interactive , solo per passare a Frozen , solo per tornare eventualmente a Interactive .

   Una volta raggiunto Interactive , possiamo quindi, su richiesta o quando il tempo lo consente, avviare parti non essenziali dell'app. Sfortunatamente, come ha notato Paul Lewis, i framework in genere non hanno un semplice concetto di priorità che può essere mostrato agli sviluppatori, e quindi l'avvio progressivo non è facile da implementare con la maggior parte delle librerie e dei framework.

   Comunque ci stiamo arrivando. In questi giorni ci sono un paio di scelte che possiamo esplorare, e Houssein Djirdeh e Jason Miller forniscono un'eccellente panoramica di queste opzioni nel loro discorso sul Rendering sul Web e nel commento di Jason e Addy sulle moderne architetture front-end. La panoramica di seguito si basa sul loro lavoro stellare.

   • Rendering completo lato server (SSR)
     Nell'SSR classico, come WordPress, tutte le richieste vengono gestite interamente sul server. Il contenuto richiesto viene restituito come pagina HTML finita e i browser possono visualizzarlo immediatamente. Pertanto, le app SSR non possono davvero utilizzare le API DOM, ad esempio. Il divario tra First Contentful Paint e Time to Interactive è generalmente piccolo e la pagina può essere visualizzata immediatamente mentre l'HTML viene trasmesso in streaming al browser.

     Ciò evita ulteriori round trip per il recupero dei dati e la creazione di modelli sul client, poiché viene gestito prima che il browser riceva una risposta. Tuttavia, ci ritroviamo con un tempo di riflessione del server più lungo e di conseguenza Time To First Byte e non utilizziamo le funzionalità reattive e ricche delle applicazioni moderne.

   • Rendering statico
     Sviluppiamo il prodotto come un'applicazione a pagina singola, ma tutte le pagine vengono prerenderizzate in HTML statico con JavaScript minimo come fase di compilazione. Ciò significa che con il rendering statico produciamo in anticipo singoli file HTML per ogni possibile URL , cosa che non molte applicazioni possono permettersi. Ma poiché l'HTML di una pagina non deve essere generato al volo, possiamo ottenere un Time To First Byte costantemente veloce. Pertanto, possiamo visualizzare rapidamente una pagina di destinazione e quindi precaricare un framework SPA per le pagine successive. Netflix ha adottato questo approccio diminuendo il caricamento e il Time-to-Interactive del 50%.

   • Rendering lato server con (ri)idratazione (rendering universale, SSR + CSR)
     Possiamo provare a usare il meglio di entrambi i mondi: gli approcci SSR e CSR. Con l'idratazione nel mix, la pagina HTML restituita dal server contiene anche uno script che carica un'applicazione lato client completa. Idealmente, ciò ottenga un rapido First Contentful Paint (come SSR) e quindi continui il rendering con la (ri)idratazione. Sfortunatamente, questo è raramente il caso. Più spesso, la pagina sembra pronta ma non può rispondere all'input dell'utente, producendo clic di rabbia e abbandoni.

     Con React, possiamo utilizzare il modulo ReactDOMServer su un server Node come Express, quindi chiamare il metodo renderToString per eseguire il rendering dei componenti di livello superiore come una stringa HTML statica.

     Con Vue.js, possiamo utilizzare vue-server-renderer per eseguire il rendering di un'istanza Vue in HTML utilizzando renderToString . In Angular, possiamo usare @nguniversal per trasformare le richieste dei client in pagine HTML completamente visualizzate dal server. È anche possibile ottenere immediatamente un'esperienza di rendering completamente server con Next.js (React) o Nuxt.js (Vue).

     L'approccio ha i suoi lati negativi. Di conseguenza, otteniamo la piena flessibilità delle app lato client fornendo al contempo un rendering lato server più veloce, ma finiamo anche con un divario più lungo tra First Contentful Paint e Time To Interactive e un aumento del First Input Delay. La reidratazione è molto costosa e di solito questa strategia da sola non sarà abbastanza buona poiché ritarda pesantemente Time To Interactive.

     
   • Rendering in streaming lato server con idratazione progressiva (SSR + CSR)
     Per ridurre al minimo il divario tra Time To Interactive e First Contentful Paint, eseguiamo il rendering di più richieste contemporaneamente e inviamo il contenuto in blocchi man mano che vengono generati. Quindi non dobbiamo aspettare l'intera stringa di HTML prima di inviare contenuto al browser e quindi migliorare Time To First Byte.

     In React, invece di renderToString() , possiamo usare renderToNodeStream() per reindirizzare la risposta e inviare l'HTML in blocchi. In Vue, possiamo usare renderToStream() che può essere inviato in pipe e trasmesso in streaming. Con React Suspense, potremmo usare il rendering asincrono anche per questo scopo.

     Sul lato client, invece di avviare l'intera applicazione in una volta, avviamo i componenti progressivamente . Le sezioni delle applicazioni vengono prima suddivise in script standalone con suddivisione del codice e quindi idratate gradualmente (in base alle nostre priorità). In effetti, possiamo idratare prima i componenti critici, mentre il resto potrebbe essere idratato in seguito. Il ruolo del rendering lato client e lato server può quindi essere definito in modo diverso per componente. Possiamo quindi anche posticipare l'idratazione di alcuni componenti fino a quando non vengono visualizzati, o sono necessari per l'interazione dell'utente, o quando il browser è inattivo.

     Per Vue, Markus Oberlehner ha pubblicato una guida sulla riduzione del Time To Interactive delle app SSR utilizzando l'idratazione sull'interazione dell'utente e vue-lazy-hydration, un plug-in in fase iniziale che consente l'idratazione dei componenti sulla visibilità o sull'interazione specifica dell'utente. Il team Angular lavora sull'idratazione progressiva con Ivy Universal. Puoi implementare l'idratazione parziale anche con Preact e Next.js.

   • Rendering trisomorfo
     Con i service worker attivi, possiamo utilizzare il rendering del server di streaming per le navigazioni iniziali/non JS e quindi fare in modo che il service worker esegua il rendering di HTML per le navigazioni dopo che è stato installato. In tal caso, l'operatore del servizio esegue il prerendering del contenuto e abilita le esplorazioni in stile SPA per il rendering di nuove viste nella stessa sessione. Funziona bene quando puoi condividere lo stesso modello e codice di routing tra il server, la pagina del client e l'operatore del servizio.

   

   • CSR con prerendering
     Il prerendering è simile al rendering lato server, ma anziché eseguire il rendering dinamico delle pagine sul server, eseguiamo il rendering dell'applicazione in HTML statico in fase di compilazione. Sebbene le pagine statiche siano completamente interattive senza molto JavaScript lato client, il prerendering funziona in modo diverso . Fondamentalmente acquisisce lo stato iniziale di un'applicazione lato client come HTML statico in fase di compilazione, mentre con il prerendering l'applicazione deve essere avviata sul client affinché le pagine siano interattive.

     Con Next.js, possiamo utilizzare l'esportazione HTML statico eseguendo il prerendering di un'app in HTML statico. In Gatsby, un generatore di siti statici open source che utilizza React, utilizza il metodo renderToStaticMarkup invece del metodo renderToString durante le build, con il blocco JS principale precaricato e le route future vengono precaricate, senza attributi DOM che non sono necessari per semplici pagine statiche.

     Per Vue, possiamo usare Vuepress per raggiungere lo stesso obiettivo. Puoi anche usare il prerender-loader con Webpack. Navi fornisce anche il rendering statico.

     Il risultato è Time To First Byte e First Contentful Paint migliori e riduciamo il divario tra Time To Interactive e First Contentful Paint. Non possiamo usare l'approccio se ci si aspetta che il contenuto cambi molto. Inoltre, tutti gli URL devono essere conosciuti in anticipo per generare tutte le pagine. Quindi alcuni componenti potrebbero essere renderizzati usando il prerendering, ma se abbiamo bisogno di qualcosa di dinamico, dobbiamo fare affidamento sull'app per recuperare il contenuto.

   • Rendering completo lato client (CSR)
     Tutta la logica, il rendering e l'avvio vengono eseguiti sul client. Il risultato è solitamente un enorme divario tra Time To Interactive e First Contentful Paint. Di conseguenza, le applicazioni spesso sembrano lente poiché l'intera app deve essere avviata sul client per eseguire il rendering di qualsiasi cosa.

     Poiché JavaScript ha un costo in termini di prestazioni, poiché la quantità di JavaScript cresce con un'applicazione, la suddivisione del codice aggressiva e il rinvio di JavaScript saranno assolutamente necessari per domare l'impatto di JavaScript. In questi casi, un rendering lato server sarà solitamente un approccio migliore nel caso in cui non sia richiesta molta interattività. Se non è un'opzione, prendi in considerazione l'utilizzo di The App Shell Model.

     In generale, la SSR è più veloce della CSR. Tuttavia, è un'implementazione abbastanza frequente per molte app là fuori.

   Quindi, lato client o lato server? In generale, è una buona idea limitare l'uso di framework completamente lato client alle pagine che li richiedono assolutamente. Per le applicazioni avanzate, non è nemmeno una buona idea affidarsi al solo rendering lato server. Sia il rendering del server che il rendering del client sono un disastro se eseguiti male.

   Sia che tu stia propendo per CSR o SSR, assicurati di eseguire il rendering di pixel importanti il ​​prima possibile e di ridurre al minimo il divario tra quel rendering e Time To Interactive. Prendi in considerazione il prerendering se le tue pagine non cambiano molto e rimanda l'avvio dei framework se puoi. Trasmetti in streaming l'HTML in blocchi con il rendering lato server e implementa l'idratazione progressiva per il rendering lato client e idrata la visibilità, l'interazione o durante i tempi di inattività per ottenere il meglio da entrambi i mondi.

1. Quanto possiamo servire staticamente?
   Che tu stia lavorando su una grande applicazione o su un piccolo sito, vale la pena considerare quale contenuto potrebbe essere servito staticamente da una CDN (ad esempio JAM Stack), piuttosto che essere generato dinamicamente al volo. Anche se disponi di migliaia di prodotti e centinaia di filtri con numerose opzioni di personalizzazione, potresti comunque voler pubblicare le tue pagine di destinazione critiche in modo statico e separare queste pagine dal framework di tua scelta.

   Ci sono molti generatori di siti statici e le pagine che generano sono spesso molto veloci. Più contenuti possiamo pre-costruire in anticipo invece di generare visualizzazioni di pagina su un server o un client al momento della richiesta, migliori saranno le prestazioni che otterremo.

   In Creazione di siti Web statici parzialmente idratati e progressivamente migliorati, Markus Oberlehner mostra come creare siti Web con un generatore di siti statici e una SPA, ottenendo al contempo un miglioramento progressivo e una dimensione minima del bundle JavaScript. Markus usa Eleventy e Preact come suoi strumenti e mostra come impostare gli strumenti, aggiungere idratazione parziale, idratazione pigra, file di immissione del cliente, configurare Babel per Preact e raggruppare Preact con Rollup, dall'inizio alla fine.

   Con JAMStack utilizzato in questi giorni su siti di grandi dimensioni, è apparsa una nuova considerazione sulle prestazioni: il tempo di build . In effetti, creare anche migliaia di pagine con ogni nuova distribuzione può richiedere minuti, quindi è promettente vedere build incrementali in Gatsby che migliorano i tempi di creazione di 60 volte , con un'integrazione in soluzioni CMS popolari come WordPress, Contentful, Drupal, Netlify CMS e altri.

   

   Inoltre, Next.js ha annunciato la generazione statica anticipata e incrementale, che ci consente di aggiungere nuove pagine statiche in fase di esecuzione e aggiornare le pagine esistenti dopo che sono state già create, ridisegnandole in background all'arrivo del traffico .

   Hai bisogno di un approccio ancora più leggero? Nel suo intervento su Eleventy, Alpine e Tailwind: verso un Jamstack leggero, Nicola Goutay spiega le differenze tra CSR, SSR e tutto il resto e mostra come utilizzare un approccio più leggero, insieme a un repository GitHub che mostra l'approccio in pratica.

2. Prendi in considerazione l'utilizzo del modello PRPL e dell'architettura della shell dell'app.
   Framework diversi avranno effetti diversi sulle prestazioni e richiederanno diverse strategie di ottimizzazione, quindi è necessario comprendere chiaramente tutti i dadi e i bulloni del framework su cui farete affidamento. Quando si crea un'app Web, esaminare il modello PRPL e l'architettura della shell dell'applicazione. L'idea è abbastanza semplice: spingere il codice minimo necessario per diventare interattivo per il rendering rapido del percorso iniziale, quindi utilizzare Service Worker per memorizzare nella cache e pre-memorizzare le risorse e quindi caricare i percorsi lazy necessari, in modo asincrono.

1. Hai ottimizzato le prestazioni delle tue API?
   Le API sono canali di comunicazione per un'applicazione per esporre i dati ad applicazioni interne e di terze parti tramite endpoint . Quando si progetta e si costruisce un'API, è necessario un protocollo ragionevole per consentire la comunicazione tra il server e le richieste di terze parti. Il Representational State Transfer ( REST ) ​​è una scelta logica ben consolidata: definisce un insieme di vincoli che gli sviluppatori seguono per rendere i contenuti accessibili in modo performante, affidabile e scalabile. I servizi Web conformi ai vincoli REST sono chiamati servizi Web RESTful .

   Come con le buone vecchie richieste HTTP, quando i dati vengono recuperati da un'API, qualsiasi ritardo nella risposta del server si propagherà all'utente finale, ritardando quindi il rendering . Quando una risorsa vuole recuperare alcuni dati da un'API, dovrà richiedere i dati dall'endpoint corrispondente. Un componente che esegue il rendering dei dati da diverse risorse, ad esempio un articolo con commenti e foto dell'autore in ogni commento, potrebbe richiedere diversi viaggi di andata e ritorno sul server per recuperare tutti i dati prima che possano essere visualizzati. Inoltre, la quantità di dati restituita tramite REST è spesso superiore a quella necessaria per eseguire il rendering di quel componente.

   Se molte risorse richiedono dati da un'API, l'API potrebbe diventare un collo di bottiglia delle prestazioni. GraphQL fornisce una soluzione efficiente a questi problemi. Di per sé, GraphQL è un linguaggio di query per la tua API e un runtime lato server per l'esecuzione di query utilizzando un sistema di tipi che definisci per i tuoi dati. A differenza di REST, GraphQL può recuperare tutti i dati in un'unica richiesta e la risposta sarà esattamente quella richiesta, senza sovra o sotto -prelievo dei dati come accade in genere con REST.

   Inoltre, poiché GraphQL utilizza lo schema (metadati che raccontano come sono strutturati i dati), può già organizzare i dati nella struttura preferita, quindi, ad esempio, con GraphQL, potremmo rimuovere il codice JavaScript utilizzato per gestire la gestione dello stato, producendo un codice dell'applicazione più pulito che viene eseguito più velocemente sul client.

   Se vuoi iniziare con GraphQL o riscontrare problemi di prestazioni, questi articoli potrebbero essere molto utili:

   • Un primer GraphQL: perché abbiamo bisogno di un nuovo tipo di API di Eric Baer,
   • A GraphQL Primer: The Evolution Of API Design di Eric Baer,
   • Progettazione di un server GraphQL per prestazioni ottimali di Leonardo Losoviz,
   • Le prestazioni di GraphQL spiegate da Wojciech Trocki.

1. Utilizzerai AMP o Instant Articles?
   A seconda delle priorità e della strategia della tua organizzazione, potresti prendere in considerazione l'utilizzo di AMP di Google o di Articoli istantanei di Facebook o Apple News di Apple. Puoi ottenere buone prestazioni senza di loro, ma AMP fornisce un solido framework di prestazioni con una rete di distribuzione di contenuti (CDN) gratuita , mentre gli articoli istantanei aumenteranno la tua visibilità e le tue prestazioni su Facebook.

   Il vantaggio apparentemente ovvio di queste tecnologie per gli utenti sono le prestazioni garantite , quindi a volte potrebbero persino preferire AMP-/Apple News/Instant Pages-link rispetto a pagine "normali" e potenzialmente gonfie. Per i siti Web ricchi di contenuti che hanno a che fare con molti contenuti di terze parti, queste opzioni potrebbero potenzialmente aiutare ad accelerare notevolmente i tempi di rendering.

   A meno che non lo facciano. Secondo Tim Kadlec, ad esempio, "i documenti AMP tendono ad essere più veloci delle loro controparti, ma non significano necessariamente che una pagina sia performante. AMP non è ciò che fa la differenza maggiore dal punto di vista delle prestazioni".

   Un vantaggio per il proprietario del sito web è evidente: la rilevabilità di questi formati sulle rispettive piattaforme e una maggiore visibilità nei motori di ricerca.

   Beh, almeno è così che era una volta. Poiché AMP non è più un requisito per le Top Stories , gli editori potrebbero invece passare da AMP a uno stack tradizionale ( grazie, Barry! ).

   Tuttavia, puoi anche creare AMP Web progressivi riutilizzando gli AMP come origine dati per la tua PWA. Svantaggio? Ovviamente, una presenza in un giardino recintato mette gli sviluppatori nella posizione di produrre e mantenere una versione separata dei loro contenuti, e in caso di articoli istantanei e notizie di Apple senza URL reali (grazie Addy, Jeremy!) .

2. Scegli saggiamente la tua CDN.
   Come accennato in precedenza, a seconda della quantità di dati dinamici di cui disponi, potresti essere in grado di "esternalizzare" parte del contenuto a un generatore di siti statici, spingendolo su una CDN e servendo da esso una versione statica, evitando così richieste al server. In effetti, alcuni di questi generatori sono in realtà compilatori di siti Web con molte ottimizzazioni automatiche fornite immediatamente. Man mano che i compilatori aggiungono ottimizzazioni nel tempo, l'output compilato diventa più piccolo e più veloce nel tempo.

   Si noti che le CDN possono anche servire (e scaricare) contenuto dinamico. Quindi, non è necessario limitare la tua CDN alle risorse statiche. Verifica se la tua CDN esegue compressione e conversione (ad es. ottimizzazione e ridimensionamento dell'immagine ai margini), se forniscono supporto per i server worker, test A/B e include edge-side, che assemblano parti statiche e dinamiche delle pagine a bordo della CDN (ovvero il server più vicino all'utente) e altre attività. Inoltre, controlla se la tua CDN supporta HTTP su QUIC (HTTP/3).

   Katie Hempenius ha scritto una fantastica guida ai CDN che fornisce spunti su come scegliere un buon CDN , come perfezionarlo e tutte le piccole cose da tenere a mente quando ne valuta uno. In generale, è una buona idea memorizzare nella cache il contenuto nel modo più aggressivo possibile e abilitare le funzionalità delle prestazioni CDN come Brotli, TLS 1.3, HTTP/2 e HTTP/3.

   Nota : in base alla ricerca di Patrick Meenan e Andy Davies, la definizione delle priorità HTTP/2 è effettivamente interrotta su molte CDN, quindi fai attenzione quando scegli una CDN. Patrick ha maggiori dettagli nel suo intervento sulla priorità HTTP/2 ( grazie, Barry! ).

   

   Quando scegli una CDN, puoi utilizzare questi siti di confronto con una panoramica dettagliata delle loro caratteristiche:

   • Confronto CDN, una matrice di confronto CDN per Cloudfront, Aazure, KeyCDN, Fastly, Verizon, Stackpach, Akamai e molti altri.
   • CDN Perf misura la velocità delle query per le CDN raccogliendo e analizzando 300 milioni di test ogni giorno, con tutti i risultati basati sui dati RUM di utenti di tutto il mondo. Controlla anche il confronto delle prestazioni DNS e il confronto delle prestazioni del cloud.
   • CDN Planet Guides fornisce una panoramica delle CDN per argomenti specifici, come Serve Stale, Purge, Origin Shield, Prefetch e Compression.
   • Web Almanac: CDN Adoption and Usage fornisce informazioni dettagliate sui principali provider CDN, sulla loro gestione RTT e TLS, sui tempi di negoziazione TLS, sull'adozione di HTTP/2 e altro. (Purtroppo i dati sono solo del 2019).

Sommario

1. Prepararsi: pianificazione e metriche
2. Stabilire obiettivi realistici
3. Definire l'ambiente
4. Ottimizzazioni degli asset
5. Costruisci ottimizzazioni
6. Ottimizzazioni di consegna
7. Rete, HTTP/2, HTTP/3
8. Test e monitoraggio
9. Vittorie veloci
10. Tutto in una pagina
11. Scarica la lista di controllo (PDF, Apple Pages, MS Word)
12. Iscriviti alla nostra newsletter via email per non perdere le prossime guide.