Chrome Dev Insider: scalabilità delle prestazioni con l'ecosistema di framework

Paul Kinlan

Mi chiamo Paul Kinlan e sono responsabile dei rapporti con gli sviluppatori per Chrome. Nell'ambito del mio lavoro, collaboro con un team di appassionati sostenitori del web con il compito di portare il punto di vista degli sviluppatori del mondo reale ai nostri team di prodotto e di progettazione, con la metrica "north star" per migliorare la soddisfazione degli sviluppatori.

Siamo consapevoli che la "soddisfazione" è una metrica ambiziosa e soggettiva da monitorare e migliorare, quindi ci impegniamo costantemente per migliorare il modo in cui possiamo fare la differenza, concentrandoci sulle esigenze degli sviluppatori. Un principio guida che abbiamo ritenuto utile seguire è "incontrare gli sviluppatori ovunque si trovino". Un recente studio di Stack Overflow ha dimostrato che il 75% degli sviluppatori riferisce di utilizzare framework o un'astrazione di qualche tipo. Ci siamo quindi chiesti come possiamo assistere al meglio gli sviluppatori che hanno già preso decisioni in merito al loro stack tecnico o non ne hanno alcun controllo. Come possiamo renderle più produttive senza aggiungere ulteriori spese?

Un piccolo team di Chrome sta lavorando a un progetto chiamato Aurora, con l'obiettivo di lavorare con astrazioni di terze parti della piattaforma web, come framework e librerie. Il loro obiettivo è contribuire a portare i miglioramenti delle prestazioni direttamente in queste astrazioni, invece di far cadere il carico sui loro clienti, gli sviluppatori web.

Per la terza edizione di Chrome Dev Insider, ho parlato con Addy Osmani, Kara Erickson e Houssein Djirdeh del team Project Aurora per saperne di più su come si stanno approcciando a questo progetto e su cosa ci aspetta per loro.

Panoramica degli addetti ai lavori: utilizzo di framework di terze parti

Partiamo dalla genesi di questo progetto. Com'è andata?

Addy: Aurora ha iniziato con un'idea semplice: andiamo a conoscere gli sviluppatori a partire dal loro livello e aiutiamoli a raggiungere ciò che desiderano. Ad esempio, aiutare il popolare stack tecnico che hanno scelto di migliorare le prestazioni. Oggi, molti sviluppatori di app creano utilizzando React, Vue o Angular, o meta-framework* come Next.js e Nuxt (e ovviamente molti altri... Giallo, Leggero, Precetto, Astro. Continua così!). Invece di aspettarci che questi sviluppatori diventino esperti (ad esempio in termini di prestazioni), potremmo assicurarci che ricadano all'interno di questi stack integrando per impostazione predefinita più best practice. In questo modo, siti di qualità migliore sono un effetto collaterale della creazione di siti per il web.

Aurora sceglie alcuni framework e meta-framework molto utilizzati con cui collaborare; documentiamo le nostre conoscenze (ad esempio come creare un buon componente di immagini), in modo che altri possano seguire velocemente e provare a scalare tramite altri framework e strumenti tramite il Chrome Frameworks Fund. Sebbene sia possibile migliorare la qualità delle esperienze web tramite il browser, riteniamo che questo obiettivo possa (in alcuni casi) essere raggiunto anche tramite i framework. Speriamo che queste informazioni ci siano di aiuto per raggiungere i nostri obiettivi di qualità migliore per il web per tutti.

Kara: Per ampliare questo aspetto, l'idea è quella di migliorare il rendimento sul web migliorando l'esperienza degli sviluppatori. Non basta pubblicizzare le best practice sul rendimento, perché spesso cambiano ed è difficile per le aziende tenere il passo. Hanno priorità aziendali specifiche che probabilmente verranno prima delle prestazioni.

Pensiamo quindi che se gli sviluppatori hanno poco tempo da dedicare alle prestazioni, rendiamo più semplice (e più veloce) per loro creare un'app dalle prestazioni elevate. Se collaboriamo con framework web popolari, siamo al giusto livello di astrazione per migliorare l'esperienza degli sviluppatori mediante componenti di livello superiore, avvisi di conformità e così via. Chiunque utilizzi questi strumenti popolari avrà accesso a questi vantaggi. In teoria, anche se il consiglio consigliato cambia, possiamo aggiornare i nostri componenti in modo approfondito, senza che gli sviluppatori debbano preoccuparsi di essere aggiornati.

Houssein: Mi sono unita a Google come Developer Advocate prima di passare a un ruolo di ingegnere del software alcuni anni dopo. Gran parte del mio lavoro precedente riguardava l'insegnamento agli sviluppatori web dei tanti modi diversi di creare esperienze utente eccellenti. Sono state continuamente fornite varianti delle stesse indicazioni per avvisare gli sviluppatori dei problemi comuni che potrebbero influire sulle prestazioni e sull'usabilità dei loro siti. Quando abbiamo iniziato a pensare al progetto Aurora, ci siamo chiesti se possiamo andare in una direzione in cui non dobbiamo mai dire agli sviluppatori cosa fare perché la loro toolchain si occupa di tutto.

Se ho capito bene, sei un team di sei ingegneri? Scommetto che non puoi lavorare con tutti i framework o tutte le librerie possibili. Come si fa a scegliere con chi lavorare? E chi sono?

Addy: il web è per molti aspetti come il Far West. Puoi scegliere praticamente qualsiasi framework, bundler, librerie e terze parti tu voglia. Questo introduce diversi livelli di complessità che possono contribuire a un rendimento buono o scarso. Uno dei modi migliori per spostare l'ago della bilancia in termini di prestazioni è quello di trovare a proprio agio questo strato avere un ruolo centrale e di aggiungere più opinioni a loro.

Ad esempio, i framework web (Next.js, Nuxt.js e in una certa misura Angular) provano a sfornare più opinioni e valori predefiniti di una soluzione più manuale. Questo è uno dei motivi per cui ci piace lavorare con loro. In questi modelli è utile disporre di impostazioni predefinite più efficaci per caricare immagini, caratteri e script al fine di migliorare i Segnali web essenziali.

Serve anche per confermare dove si applicano le best practice moderne o per cui potrebbe essere necessario ripensare, e può aiutare a informare l'intero ecosistema su come affrontare la risoluzione dei problemi di ottimizzazione.

Kara: In modo realistico, dobbiamo anche considerare la popolarità. Se vogliamo avere il massimo impatto possibile sul web, l'ideale è lavorare con framework e librerie che dispongono di una vasta community di sviluppatori. In questo modo possiamo raggiungere più sviluppatori e più app. Ma non può trattarsi solo di popolarità. Essenzialmente, è un punto di incontro tra popolarità, la capacità di influenzare una biblioteca e l'insieme di funzionalità disponibili con cui possiamo lavorare.

Ad esempio, se consideriamo solo la popolarità, React, Vue e Angular sono i "tre principali" da considerare. ma lavoriamo soprattutto con Next.js, Nuxt e Angular. Questo perché le librerie di visualizzazione come React e Vue si concentrano principalmente sul rendering, pertanto è impossibile creare direttamente tutte le funzionalità che vogliamo. Per questo lavoriamo a più stretto contatto con meta-framework "guidati" basati su questi ultimi: Next.js e Nuxt. A questo livello di astrazione, possiamo creare componenti integrati. Hanno anche server integrati, il che ci permette di includere le ottimizzazioni lato server.

Come puoi notare, Angular fa parte di quell'elenco di partnership profonde, ma non è un meta-framework. Angular è un caso speciale perché è abbastanza popolare, ma non ha un meta-frame complementare come quello di React e Vue. Collaboriamo direttamente con loro e contribuiamo alle funzionalità tramite la loro interfaccia a riga di comando, ove possibile.

E vale la pena notare che abbiamo diversi rapporti continuativi con altri progetti come Gatsby, in cui sincronizziamo in qualche modo regolarmente la progettazione ma non contribuiamo attivamente al codice.

Come funziona in pratica? Qual è stato il tuo approccio alla risoluzione di questo problema?

Kara: In pratica, abbiamo alcuni framework con cui collaboriamo a stretto contatto. Ci vorrà un po' di tempo per profilare le app che usano questo framework e capire i punti deboli più comuni relativi alle prestazioni. Dopodiché collaboriamo con il team del framework per progettare funzionalità sperimentali al fine di risolvere questi punti dolenti e contribuire al codice direttamente nel repository OSS per implementarle.

Per noi è davvero importante verificare che l'impatto sulle prestazioni corrisponda a quanto previsto, quindi collaboriamo anche con aziende esterne per condurre test sulle prestazioni in produzione. Se i risultati sono incoraggianti, aiuteremo la funzionalità a diventare "stabile" e potenzialmente a renderla predefinita.

Tutto questo non può essere facile come lo stai facendo sentire. Quali sono state alcune delle sfide o degli insegnamenti che avete avuto finora?

Houssein: una cosa importante che cerchiamo di dare il meglio di sé è dare il proprio contributo per creare repository open source popolari con molte priorità in conflitto. Il fatto di fare parte del team di Google non implica necessariamente che le nostre funzionalità avranno la priorità. Pertanto, facciamo del nostro meglio per allinearci al tipico processo di proposta e distribuzione di nuove funzionalità senza mettere in difficoltà nessuno. Abbiamo avuto la fortuna di lavorare con manutentori ricettivi negli ecosistemi Next.js, Nuxt e Angular. Siamo grati che siano stati disponibili ad ascoltare le nostre preoccupazioni in merito all'ecosistema del web e a collaborare con noi in più modi.

Per molti dei framework con cui lavoriamo, la nostra mission generale è la stessa: in che modo gli sviluppatori possono ottenere un'esperienza utente migliore fin dal primo avvio, garantendo al contempo un'ottima esperienza per gli sviluppatori? Sappiamo e rispettiamo il fatto che ci sono centinaia, se non migliaia, di collaboratori e collaboratori della community che lavorano a progetti diversi che si intersecano tra loro.

Kara: Inoltre, dal momento che ci interessa convalidare l'impatto sul rendimento e agire in base ai dati, il processo richiede un po' più di tempo. Siamo in un territorio inesplorato, per cui a volte sperimentiamo con un'ottimizzazione che non si protrae e non finisca per creare una funzionalità pianificata. Anche quando una funzionalità si interrompe, quei pochi passaggi in più per controllare le prestazioni richiedono tempo ed estendono i tempi.

Anche trovare partner di produzione che testino le nostre funzionalità può essere impegnativo. Come accennato in precedenza, sono aziende e hanno le proprie priorità, per cui può essere difficile per loro adattarsi a nuove iniziative se non sono in linea con i progetti esistenti che devono essere prima di tutto. Inoltre, le aziende più interessate ad aiutare tendono a investire già del tempo nel rendimento e, pertanto, non sono proprio il nostro pubblico di destinazione. Stiamo cercando di raccogliere feedback da un ampio ventaglio di membri della community che non può investire nel rendimento, ma è meno propenso a contattarci.

Per quanto riguarda le ottimizzazioni, su quali aspetti ti stai concentrando?

Houssein: dopo aver analizzato migliaia di applicazioni, abbiamo scoperto che i maggiori problemi di prestazioni sono di solito dovuti alla presenza di anti-pattern nel codice dell'applicazione anziché nel framework stesso. Ad esempio, spedire immagini inutilmente grandi, caricare caratteri personalizzati troppo tardi, recuperare troppe richieste di terze parti che bloccano il thread principale e non gestire il modo in cui i contenuti asincroni possono causare variazioni di altri elementi nella pagina. Tutti questi problemi possono sorgere indipendentemente dallo strumento utilizzato, quindi abbiamo pensato: possiamo introdurre alcune ottimizzazioni predefinite che li gestiscono bene, ma con un'esperienza sviluppatore piacevole che si adatta perfettamente agli strumenti del framework?

Partendo da questo ragionamento, abbiamo spedito:

Il nostro lavoro ha ispirato altri framework e strumenti a implementare ottimizzazioni simili. A titolo esemplificativo, non è consentito quanto segue:

Puoi condividere alcuni risultati positivi del tuo lavoro con alcuni di questi giocatori?

Houssein: molti siti hanno visto miglioramenti delle prestazioni grazie alle ottimizzazioni che abbiamo implementato. Uno dei miei esempi preferiti è Leboncoin, che ha ridotto l'LCP da 2,4 a 1,7 secondi dopo il passaggio al componente immagine Next.js. Attualmente ce ne sono molte altre in fase di sperimentazione e test e continueremo a condividere gli insegnamenti e i risultati ottenuti qui.

Ho capito che ti stai concentrando su quelli più popolari, ma ci sono modi in cui anche altri framework o librerie con cui non collabori in modo proattivo traggono vantaggio?

Addy: molte delle ottimizzazioni delle prestazioni a cui Aurora collabora possono essere replicate da qualsiasi framework. Ad esempio, diamo un'occhiata alle nostre iniziative per i componenti Immagine o Script: spesso codificano un insieme esistente di best practice. Cerchiamo di documentare il "come" di creazione di questi componenti e il loro aspetto in ogni framework. Speriamo che questo sia un buon inizio per copiare l'idea.

Abbiamo ottenuto ottimi risultati utilizzando le informazioni apprese da un ecosistema (ad esempio, React e Next.js) per trasferirle ad altri. Ad esempio, la nuova direttiva sull'immagine angolare (basata sui nostri insegnamenti relativi alla creazione del componente dell'immagine Next.js) o Gatsby spiega il nostro approccio alla suddivisione granulare in JavaScript.

Allo stesso tempo, siamo consapevoli che non tutti i framework disporranno della larghezza di banda o dei fondi necessari ai collaboratori per sviluppare funzionalità di rendimento simili o investire in altre ottimizzazioni che ritengono importanti per i propri utenti. Il Chrome Web Frameworks Fund è un modo per noi di sponsorizzare le attività legate al rendimento nell'ecosistema JavaScript per consentire ai progetti di pagare i propri collaboratori e consentire un ulteriore incremento delle prestazioni nell'ecosistema.

Quali sono i programmi in arrivo per il tuo team?

Kara: Abbiamo in serbo tantissimi progetti interessanti! Alcuni elementi fondamentali:

  • Riduzione del CLS relativo ai caratteri: è abbastanza comune vedere variazioni del layout quando un carattere web viene caricato e sostituisce il carattere di riserva. Stiamo esplorando l'utilizzo delle sostituzioni delle metriche relative ai caratteri e della proprietà "size-adjust" per ridurre il CLS relativo ai caratteri per impostazione predefinita in Next.js. Inoltre, ci siamo consultati con il team Nuxt al riguardo e prevediamo di estendere questa idea ad altri framework il prossimo anno.
  • Debug dell'INP: ora che la metrica Interaction to Next Paint (INP) è stata rilasciata, stiamo lavorando con i framework per esaminare le cause principali dei problemi INP per le loro comunità e suggerire le relative soluzioni. Stiamo collaborando a stretto contatto con Angular a questo proposito e ci auguriamo di poter condividere presto alcuni risultati.
  • Ottimizzazione degli script di terze parti comuni: il caricamento sbagliato di script di terze parti può avere un impatto negativo sostanziale sulle prestazioni. Poiché esistono alcune terze parti molto comuni, stiamo valutando la possibilità di offrire alcuni wrapper per garantire che vengano caricati in modo ottimale con i framework e che non blocchino il thread principale. Stiamo utilizzando il componente script Next.js che abbiamo creato come punto di partenza per questa indagine.

Gli sviluppatori possono seguire i nostri progressi su questo sito.

Nelle notizie

Prima di concludere, volevo lasciarti un paio di aggiornamenti interessanti dal mondo dei framework che avvengono all'interno di Google.

A luglio, il team di Chrome ha annunciato l'ultimo finanziamento di 500.000 $per il fondo per framework e strumenti, che si concentra sul finanziamento di progetti volti a migliorare prestazioni, esperienza utente ed esperienza degli sviluppatori sul web. I finanziamenti futuri prenderanno in considerazione i nuovi progetti, quindi ricordati di inviare la richiesta.

E, naturalmente, ci sono anche tantissime cose straordinarie succedendo nella community. L'ecosistema è ricco di nuovi framework come Fresh di Deno e di esperienze fantastiche come il tutorial di onboarding di Svelte, che non è solo una demo nel browser, ma utilizza anche l'API Web Container per eseguire Node.js in modo nativo nel browser. Quanta roba buona!

Sono davvero entusiasta di vedere che l'ecosistema si riunisce, promuove ciò che è possibile nel browser e aiuta gli sviluppatori a creare prodotti che funzionino per tutti. È un momento entusiasmante per essere uno sviluppatore web.

Fino al prossimo Insider, Hwyl fawr.

Cosa ne pensi di questa edizione di The Chrome Dev Insider? Condividi il tuo feedback.