Sono Paul Kinlan e gestisco le relazioni con gli sviluppatori per Chrome. Nel mio lavoro collaboro con un team di appassionati web advocate che hanno il compito di portare la prospettiva degli sviluppatori reali ai nostri team di prodotto e di ingegneria, con l'obiettivo principale di migliorare la soddisfazione degli sviluppatori.
Siamo consapevoli che la "soddisfazione" è una metrica ambiziosa e soggettiva da monitorare e migliorare, quindi eseguiamo costantemente iterazioni su come possiamo fare la differenza, concentrandoci sulle esigenze degli sviluppatori. Un principio guida che abbiamo trovato utile seguire è "incontra gli sviluppatori dove si trovano". Un recente studio di Stack Overflow ha dimostrato che il 75% degli sviluppatori dichiara di utilizzare framework o un'astrazione di qualche tipo. Per questo motivo, ci siamo chiesti come poter offrire il miglior servizio agli sviluppatori che hanno già preso decisioni in merito al proprio tech stack o che non hanno alcun controllo su di esso. Come possiamo renderli più produttivi senza aumentare i costi?
Un piccolo team di Chrome sta lavorando a un progetto chiamato Aurora, con l'obiettivo di utilizzare le astrazioni di terze parti della piattaforma web, come framework e librerie. Il loro obiettivo è contribuire ad aumentare il rendimento direttamente in queste astrazioni, anziché far ricadere il peso sui clienti, ovvero gli sviluppatori web.
Per la terza edizione di Chrome Dev Insider, ho parlato con Addy Osmani, Kara Erickson e Houssein Djirdeh del team di Project Aurora per scoprire di più su come hanno affrontato questo progetto e su cosa li attende.
Informazioni privilegiate: lavorare con framework di terze parti
Iniziamo con la genesi di questo progetto. Come è nata?
Addy: Aurora è nata da un'idea semplice: incontrare gli sviluppatori dove si trovano e aiutarli a raggiungere i loro obiettivi. Ad esempio, aiuta la suite di tecnologie più utilizzata che hanno scelto a migliorare il rendimento. Al giorno d'oggi, molti sviluppatori di app utilizzano React, Vue o Angular, oppure meta-framework* come Next.js e Nuxt (e ovviamente molti altri... Svelte, Lit, Preact, Astro. L'elenco potrebbe continuare all'infinito. Anziché aspettarci che questi sviluppatori diventino esperti in materia (ad esempio, in termini di rendimento), potremmo assicurarci che raggiungano il successo integrando per impostazione predefinita più best practice in questi stack. In questo modo, i siti di qualità migliore sono un effetto collaterale della semplice creazione per il web.
Aurora sceglie alcuni framework e meta-framework ampiamente utilizzati con cui collaborare e documenta le proprie scoperte (ad esempio come creare un buon componente immagine) in modo che altri possano seguire rapidamente 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 essere raggiunto anche (in alcuni casi) tramite i framework. Ci auguriamo che questo ci aiuti a raggiungere i nostri obiettivi di un web di qualità superiore per tutti.
Kara: Per approfondire, l'idea è migliorare le prestazioni sul web migliorando l'esperienza degli sviluppatori. Non è sufficiente pubblicizzare le best practice per il rendimento, perché cambiano spesso ed è difficile per le aziende stare al passo. Hanno le proprie priorità aziendali che probabilmente avranno la precedenza sul rendimento.
Il nostro ragionamento è che, se gli sviluppatori hanno poco tempo da dedicare al rendimento, rendiamo più facile (e veloce) per loro creare un'app performante. Se collaboriamo con framework web popolari, ci troviamo al livello di astrazione giusto per migliorare l'esperienza dello sviluppatore tramite componenti di livello superiore, avvisi di conformità e così via. Chiunque utilizzi questi strumenti popolari avrà accesso a questi vantaggi. In teoria, se i consigli consigliati cambiano, possiamo aggiornare i nostri componenti sotto il cofano e gli sviluppatori non devono preoccuparsi di rimanere al passo con le novità.
Houssein: ho iniziato a lavorare in Google come Developer Advocate prima di passare a un ruolo di ingegneria del software qualche anno dopo. Gran parte del mio lavoro precedente consisteva nell'insegnare agli sviluppatori web i diversi modi per creare esperienze utente straordinarie. Sono state fornite ripetutamente varianti delle stesse indicazioni per avvisare gli sviluppatori dei problemi comuni che potrebbero influire sul rendimento e sull'usabilità dei loro siti. Quando abbiamo iniziato a pensare al progetto Aurora, ci siamo chiesti: possiamo andare in una direzione in cui non dovremo mai dire agli sviluppatori cosa fare perché la loro toolchain si occupa di tutto per loro?
Se ho capito bene, il tuo team è composto da sei ingegneri? Scommetto che non puoi lavorare con ogni possibile framework o libreria. Come scegli con chi collaborare? E chi sono?
Addy: il web è in molti modi simile al selvaggio West. Puoi scegliere praticamente qualsiasi framework, bundler, librerie e terze parti. Ciò introduce diversi livelli di complessità che possono contribuire a un rendimento buono o scarso. Uno dei modi migliori per migliorare il rendimento è trovare i livelli in cui è possibile esprimere opinioni e aggiungerne altre.
Ad esempio, i framework web (Next.js, Nuxt.js e, in misura minore, Angular) cercano di integrare più opinioni e impostazioni predefinite rispetto a una soluzione più personalizzata. Questo è uno dei motivi per cui amiamo collaborare con loro. In questi modelli ha senso avere impostazioni predefinite più stringenti per il caricamento di immagini, caratteri e script al fine di migliorare Core Web Vitals.
È anche un ottimo modo per verificare dove le best practice moderne funzionano o potrebbero richiedere un ripensamento e può aiutare a informare l'intero ecosistema su come affrontare la risoluzione dei problemi di ottimizzazione.
Kara: in realtà, dobbiamo prendere in considerazione anche la popolarità. Se vogliamo avere il maggiore impatto possibile sul web, è 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ò essere solo popolarità. In definitiva, si tratta di un'intersezione tra popolarità, opinioni di una biblioteca e set di funzionalità disponibili con cui possiamo lavorare.
Ad esempio, se prendiamo in considerazione solo la popolarità, React, Vue e Angular sono i "tre grandi" da considerare. Tuttavia, lavoriamo principalmente con Next.js, Nuxt e Angular. Questo perché le librerie di visualizzazione come React e Vue si concentrano principalmente sul rendering, quindi è impossibile incorporare direttamente tutte le funzionalità che vogliamo. Per questo motivo, collaboriamo più strettamente con meta-framework opinativi basati su questi: Next.js e Nuxt. A questo livello di astrazione, possiamo creare componenti integrati. Hanno anche server integrati, quindi possiamo includere ottimizzazioni lato server.
Potresti notare che Angular era presente nell'elenco delle partnership strette, ma non è un meta-framework. Angular è un caso un po' speciale perché è molto popolare, ma non ha un meta-framework complementare come React e Vue. Pertanto, collaboriamo direttamente con loro e, se possibile, contribuiamo con funzionalità tramite la loro CLI.
Inoltre, vale la pena notare che abbiamo diversi rapporti in corso con altri progetti come Gatsby, con cui sincronizziamo abbastanza regolarmente il design, ma non contribuiamo attivamente con il codice.
Come funziona in pratica? Qual è stato il tuo approccio per risolvere il problema?
Kara: In pratica, abbiamo alcuni framework con cui collaboriamo strettamente. Ci prenderemo del tempo per creare il profilo delle app che utilizzano questo framework e individuare i problemi di rendimento più comuni. Poi collaboriamo con il team del framework per progettare funzionalità sperimentali per risolvere questi problemi e contribuire con il codice direttamente al repository OSS per implementarle.
Per noi è molto importante verificare che l'impatto sul rendimento sia quello previsto, quindi collaboriamo anche con aziende esterne per eseguire test di rendimento in produzione. Se i risultati sono incoraggianti, aiuteremo la funzionalità a raggiungere lo stato "stabile" e potremmo impostarla come predefinita.
Tutto questo non può essere così facile come sembra. Quali sono state alcune delle sfide o delle cose che hai imparato finora?
Houssein: una cosa importante che cerchiamo di fare al meglio delle nostre capacità è contribuire ai repository open source più diffusi che hanno molte priorità in concorrenza. Il fatto che siamo un team di Google non significa necessariamente che le nostre funzionalità avranno la priorità, quindi facciamo del nostro meglio per allinearci alla procedura tipica di proposta e lancio di nuove funzionalità senza intralciare nessuno. Abbiamo avuto la fortuna di collaborare con sviluppatori ricettivi negli ecosistemi Next.js, Nuxt e Angular. Siamo grati per la disponibilità a ascoltare i nostri dubbi sull'ecosistema web e per la volontà di collaborare con noi in più di un modo.
Con molti dei framework con cui collaboriamo, la nostra missione complessiva è la stessa: come possono gli sviluppatori ottenere un'esperienza utente migliorata e allo stesso tempo un'esperienza di sviluppo eccezionale? Siamo consapevoli e rispettiamo il fatto che esistono centinaia, se non migliaia, di collaboratori della community e gestori del framework che lavorano a progetti diversi che si intersecano tra loro.
Kara: inoltre, poiché ci preme convalidare l'impatto sul rendimento e intervenire in base ai dati, il processo richiede un po' più di tempo. Ci troviamo in un territorio inesplorato, quindi a volte sperimentiamo con un'ottimizzazione che non va a buon fine e non riusciamo a creare una funzionalità pianificata. Anche quando una funzionalità funziona, i pochi passaggi aggiuntivi per verificarne il rendimento richiedono tempo e prolungano le tempistiche.
Anche trovare partner di produzione per testare le nostre funzionalità può essere complicato. Come accennato in precedenza, si tratta di aziende con le proprie priorità, quindi può essere difficile per loro adattarsi a nuove iniziative se non sono ben in linea con i progetti esistenti che devono avere la priorità. Inoltre, le aziende più interessate a ricevere assistenza tendono già a investire nel rendimento, quindi non sono il nostro pubblico di destinazione. Stiamo cercando di raccogliere feedback dalla vasta gamma di utenti della community che non possono investire nel rendimento, ma sono quelli meno propensi a contattarci.
Passiamo ad altro. Su quali tipi di ottimizzazioni ti stai concentrando?
Houssein: dopo aver analizzato migliaia di applicazioni, abbiamo riscontrato che i problemi di rendimento più gravi sono generalmente dovuti ad antipattern nel codice dell'applicazione anziché al framework stesso. Ad esempio, l'invio di immagini inutilmente grandi, il caricamento di caratteri personalizzati troppo tardi, il recupero di troppe richieste di terze parti che bloccano il thread principale e la mancata gestione del modo in cui i contenuti asincroni possono causare lo spostamento di altri elementi nella pagina. Questi sono tutti problemi che possono sorgere indipendentemente dallo strumento utilizzato, quindi ci siamo chiesti: possiamo integrare alcune ottimizzazioni predefinite che li gestiscono bene, ma con un'esperienza dello sviluppatore ordinata che si inserisce perfettamente negli strumenti del framework?
In base a questo approccio, abbiamo rilasciato:
- Componente immagine Next.js.
- Componente script Next.js.
- Inlining automatico dei caratteri nel processo di compilazione di Next.js.
- Direttiva relativa alle immagini angolari.
- Plug-in ESLint di conformità a Next.js per fornire indicazioni utili agli sviluppatori.
Il nostro lavoro ha ispirato altri framework e strumenti a implementare ottimizzazioni simili. A titolo esemplificativo, non è consentito quanto segue:
- Modulo di immagini Nuxt
- Override delle metriche dei caratteri di Nuxt
- Componente script Nuxt (in corso)
- Componente Script di Gatsby
Puoi condividere alcuni risultati positivi del tuo lavoro con alcuni di questi attori?
Houssein: molti siti hanno registrato miglioramenti delle prestazioni grazie alle ottimizzazioni che abbiamo implementato. Uno dei miei esempi preferiti è Leboncoin, che ha ridotto il proprio LCP da 2,4 secondi a 1,7 secondi dopo il passaggio al componente immagine Next.js. Attualmente ne sono in corso molti altri in fase di sperimentazione e test e continueremo a condividere le nostre scoperte e i risultati ottenuti qui.
Ok, capisco che la tua attenzione si concentra su quelli più apprezzati, ma ci sono modi per far sì che anche altri framework o librerie con cui non collabori possano trarre vantaggio in modo proattivo?
Addy: molte delle ottimizzazioni del rendimento su cui collabora Aurora possono essere replicate da qualsiasi framework. Ad esempio, dai un'occhiata ai nostri sforzi per i componenti di immagini o script, che spesso codificano un insieme esistente di best practice. Cerchiamo di documentare il "come" creare questi componenti e come appaiono in ogni framework. Spero che questo sia un buon inizio per copiare l'idea.
Abbiamo ottenuto buoni risultati trasferendo le lezioni apprese da un ecosistema (ad esempio React e Next.js) ad altri. Ad esempio, la nuova Angular Image Directive (basata sui nostri apprendimenti durante la creazione del componente immagine Next.js) o Gatsby che implementa il nostro approccio allo chunking granulare di JavaScript.
Allo stesso tempo, siamo consapevoli che non tutti i framework avranno la larghezza di banda o i finanziamenti necessari per consentire ai collaboratori di creare funzionalità di rendimento simili o di investire in altre ottimizzazioni che ritengono importanti per i propri utenti. Il Fondo per i framework web di Chrome ci consente di sponsorizzare il lavoro sul rendimento nell'ecosistema JavaScript per consentire ai progetti di pagare i propri collaboratori e di espandere ulteriormente il lavoro sul rendimento nell'ecosistema.
Quali sono i prossimi passi del tuo team?
Kara: abbiamo molti progetti interessanti in programma. Alcuni elementi fondamentali:
- Riduzione del CLS correlato ai caratteri:è abbastanza comune osservare variazioni del layout quando viene caricato un carattere web e sostituisce il carattere di riserva. Stiamo valutando la possibilità di utilizzare le sostituzioni delle metriche dei caratteri e la proprietà "size-adjust" per ridurre il CLS relativo ai caratteri per impostazione predefinita in Next.js. Abbiamo anche consultato il team di Nuxt in merito 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 collaborando con i framework per esaminare le cause principali più comuni dei problemi INP per le loro community e suggerire correzioni. Stiamo collaborando strettamente con Angular per questo progetto e ci auguriamo di poter condividere presto alcuni risultati.
- Ottimizzazione degli script di terze parti comuni:il caricamento di script di terze parti al momento sbagliato può avere un impatto negativo significativo sulle prestazioni. Poiché esistono alcuni componenti di terze parti molto comuni, stiamo valutando la possibilità di offrire alcuni wrapper per garantire che vengano caricati in modo ottimale con i framework e non blocchino il thread principale. Utilizziamo il componente dello 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 salutarti, volevo lasciarti con un paio di aggiornamenti interessanti dal mondo dei framework in Google.
A luglio, il team di Chrome ha annunciato l'ultima tranche di finanziamenti di 500.000 $per il Fondo per framework e strumenti, che si concentra sul finanziamento di progetti volti a migliorare le prestazioni, l'esperienza utente e quella degli sviluppatori sul web. I finanziamenti futuri prenderanno in considerazione i nuovi progetti, quindi ricordati di inviare la tua richiesta.
E, naturalmente, nella community stanno accadendo anche un sacco di cose fantastiche. L'ecosistema è ricco di nuovi framework come Fresh di Deno ed esperienze straordinarie come il tutorial di onboarding di Svelte, che non è solo una demo in-browser, ma utilizza anche l'API Web Container per eseguire Node.js in modo nativo nel browser. Tanta roba buona.
Mi entusiasma vedere l'ecosistema che si forma, spingere le possibilità del browser e aiutare gli sviluppatori a creare prodotti che funzionino per tutti. È un momento entusiasmante per essere uno sviluppatore web.
A presto, Hwyl fawr.
Cosa ne pensi di questa edizione di The Chrome Dev Insider? Condividi il tuo feedback.