Ik ben Paul Kinlan en ik leid de ontwikkelaarsrelaties voor Chrome. Als onderdeel van mijn werk werk ik samen met een team van gepassioneerde webambassadeurs die de taak hebben om het perspectief van echte ontwikkelaars over te brengen naar onze product- en engineeringteams, met als belangrijkste doel de tevredenheid van ontwikkelaars te verbeteren .
We erkennen dat "tevredenheid" een ambitieuze en subjectieve maatstaf is om te volgen en te verbeteren, dus we blijven continu nadenken over hoe we impact kunnen maken en tegelijkertijd de behoeften van ontwikkelaars centraal stellen. Een leidend principe dat we nuttig vinden om te volgen, is: " ontmoet ontwikkelaars waar ze zijn ". Een recent onderzoek van Stack Overflow toonde aan dat 75% van de ontwikkelaars aangeeft frameworks of een abstractie te gebruiken . We hebben ons daarom afgevraagd hoe we ontwikkelaars die al beslissingen hebben genomen over, of geen controle hebben over, hun tech stack het beste van dienst kunnen zijn? Hoe maken we ze productiever zonder extra overhead toe te voegen?
Een klein team hier bij Chrome heeft gewerkt aan een project genaamd Aurora , met als doel te werken met abstracties van het webplatform van derden, zoals frameworks en bibliotheken. Hun doel is om prestatieverbeteringen direct in deze abstracties te realiseren, in plaats van de last bij hun klanten – webontwikkelaars – te leggen.
Voor de derde editie van Chrome Dev Insider sprak ik met Addy Osmani , Kara Erickson en Houssein Djirdeh van het Project Aurora-team om meer te weten te komen over hoe zij dit project hebben aangepakt en wat de toekomst voor hen in petto heeft.
Insider scoop: Werken met frameworks van derden
Laten we beginnen met de ontstaansgeschiedenis van dit project. Hoe is het ontstaan?
Addy: Aurora begon met een simpel idee: laten we ontwikkelaars ontmoeten waar ze zijn en hen helpen hun doelen te bereiken. Bijvoorbeeld door de populaire tech stack die ze hebben gekozen te helpen de prestaties te verbeteren. Veel app-ontwikkelaars bouwen tegenwoordig met React, Vue of Angular – of metaframeworks* zoals Next.js en Nuxt – (en natuurlijk vele andere... Svelte, Lit, Preact, Astro. En zo kunnen we nog wel even doorgaan!). In plaats van te verwachten dat deze ontwikkelaars diepgaande experts worden (bijvoorbeeld op het gebied van prestaties), zouden we ervoor kunnen zorgen dat ze in een valkuil van succes terechtkomen door standaard meer best practices in deze stacks te integreren. Op die manier zijn websites van betere kwaliteit een bijwerking van alleen maar bouwen voor het web.
Aurora kiest een aantal veelgebruikte frameworks en meta-frameworks om mee samen te werken. We documenteren onze bevindingen (zoals hoe je een goede afbeeldingscomponent bouwt), zodat anderen snel kunnen volgen en kunnen proberen op te schalen via andere frameworks en tools via het Chrome Frameworks Fund. Hoewel het mogelijk is om de kwaliteit van webervaringen via de browser te verbeteren, geloven we dat dit doel (in sommige gevallen) ook met frameworks kan worden bereikt. We hopen dat dit ons helpt bij het bereiken van onze doelen: een web van hogere kwaliteit voor iedereen.
Kara: Om daar verder op in te gaan: het idee is om de prestaties op het web te verbeteren door de ontwikkelaarservaring te verbeteren. Het is niet voldoende om best practices voor prestaties te publiceren, omdat deze vaak veranderen en het voor bedrijven moeilijk is om bij te blijven. Ze hebben hun eigen bedrijfsprioriteiten die waarschijnlijk belangrijker zijn dan prestaties.
Dus onze gedachte is dat als ontwikkelaars weinig tijd hebben om aan prestaties te besteden, we het voor hen makkelijker (en sneller) moeten maken om een performante app te bouwen. Door samen te werken met populaire webframeworks bevinden we ons op de juiste abstractielaag om de ontwikkelaarservaring te verbeteren met behulp van componenten op een hoger niveau, conformiteitswaarschuwingen, enzovoort. Iedereen die deze populaire tools gebruikt, heeft toegang tot deze voordelen. En theoretisch gezien, als het aanbevolen advies verandert, kunnen we onze componenten onder de motorkap updaten en hoeven de ontwikkelaars zich geen zorgen te maken over het up-to-date houden van de app.
Houssein: Ik begon bij Google als Developer Advocate, voordat ik een paar jaar later overstapte naar een functie als software engineer. Veel van mijn eerdere werk bestond uit het leren van webontwikkelaars over de vele verschillende manieren om geweldige gebruikerservaringen te creëren. Er werden steeds weer variaties op dezelfde richtlijnen gegeven om ontwikkelaars te waarschuwen voor veelvoorkomende problemen die waarschijnlijk de prestaties en bruikbaarheid van hun sites zouden beïnvloeden. Toen we begonnen na te denken over het Aurora-project, vroegen we ons af: kunnen we een richting inslaan waarin we ontwikkelaars nooit meer hoeven te vertellen wat ze moeten doen, omdat hun toolchain alles voor hen regelt?
Als ik het goed begrijp, vormen jullie een team van wat, zes engineers? Ik wed dat jullie niet met elk mogelijk framework of elke bibliotheek kunnen werken. Dus hoe kiezen jullie met wie jullie gaan samenwerken? En wie zijn dat?
Addy: Het web is in veel opzichten net als het Wilde Westen. Je kunt vrijwel elk framework, elke bundel, elke bibliotheek en elke externe partij kiezen die je maar wilt. Dit introduceert verschillende lagen van complexiteit die kunnen bijdragen aan goede of slechte prestaties. Een van de beste manieren om de prestaties te verbeteren, is door die lagen te laten wennen aan hun eigen mening en er meer meningen aan toe te voegen.
Webframeworks (Next.js, Nuxt.js en tot op zekere hoogte Angular) proberen bijvoorbeeld meer meningen en standaardinstellingen in te bouwen dan een meer handmatig ontwikkelde oplossing. Dit is een van de redenen waarom we er zo graag mee werken! Sterkere standaardinstellingen voor het laden van afbeeldingen, lettertypen en scripts voor betere Core Web Vitals zijn in deze modellen logisch.
Het is bovendien een mooie manier om te controleren of moderne best practices wel werken of misschien herzien moeten worden. Bovendien kan het het hele ecosysteem informeren over hoe optimalisatieproblemen aangepakt moeten worden.
Kara: Realistisch gezien moeten we ook rekening houden met populariteit. Als we een zo groot mogelijke impact op het web willen hebben, is werken met frameworks en bibliotheken met een grote bestaande community van ontwikkelaars ideaal. Zo kunnen we meer ontwikkelaars en meer apps bereiken. Maar het kan niet alleen om populariteit gaan. Uiteindelijk is het een kruising van populariteit, de mate van mening die een bibliotheek heeft en de beschikbare functies waarmee we kunnen werken.
Als we bijvoorbeeld alleen naar populariteit kijken, zijn React, Vue en Angular de "grote drie". Maar wij werken het meest met Next.js, Nuxt en Angular. Dit komt doordat viewbibliotheken zoals React en Vue zich voornamelijk richten op rendering, waardoor het onmogelijk is om alle gewenste functies er direct in te bouwen. Daarom werken we nauwer samen met eigenzinnige metaframeworks die daarop zijn gebouwd: Next.js en Nuxt. Op dit abstractieniveau kunnen we ingebouwde componenten creëren. Deze hebben ook ingebouwde servers, zodat we server-side optimalisaties kunnen toepassen.
Je hebt misschien opgemerkt dat Angular op die lijst met diepgaande partnerschappen stond, maar het is geen metaframework. Angular is een beetje een speciaal geval omdat het behoorlijk populair is, maar geen aanvullend metaframework heeft zoals React en Vue. Daarom werken we rechtstreeks met hen samen en leveren we waar mogelijk functies via hun CLI.
Het is ook de moeite waard om te vermelden dat we verschillende doorlopende relaties hebben met andere projecten, zoals Gatsby. Hierbij overleggen we regelmatig over het ontwerp, maar leveren we geen actieve bijdrage aan de code.
Hoe ziet dit er in de praktijk uit? Wat was jouw aanpak om dit probleem op te lossen?
Kara: In de praktijk werken we nauw samen met een paar frameworks. We nemen de tijd om apps die dat framework gebruiken te profileren en de meest voorkomende prestatieproblemen te identificeren. Vervolgens werken we samen met het frameworkteam om experimentele functies te ontwerpen om die problemen op te lossen en leveren we code rechtstreeks aan de OSS-repository om ze te implementeren.
Het is erg belangrijk voor ons om te valideren dat de prestatie-impact overeenkomt met wat we voorspelden. Daarom werken we ook samen met externe bedrijven om prestatietests in productie uit te voeren. Als de resultaten bemoedigend zijn, zullen we de functie helpen om stabiel te worden en mogelijk een standaardfunctie te maken.
Dit kan allemaal niet zo makkelijk zijn als je het doet lijken. Wat waren enkele uitdagingen of leermomenten die je tot nu toe hebt gehad?
Houssein: Een belangrijk aspect waar we zo goed mogelijk mee proberen om te gaan, is bijdragen aan populaire open-source repositories met veel concurrerende prioriteiten. Dat we een Google-team zijn, betekent niet per se dat onze functies prioriteit krijgen. Daarom doen we ons best om ons aan te passen aan het gebruikelijke proces van het voorstellen en uitbrengen van nieuwe functies, zonder daarbij op iemands tenen te trappen. We hebben het geluk gehad om samen te werken met ontvankelijke beheerders in de Next.js-, Nuxt- en Angular-ecosystemen. We zijn dankbaar dat ze open hebben gestaan voor onze zorgen over het webecosysteem en bereid zijn om op meerdere manieren met ons samen te werken.
Bij veel van de frameworks waarmee we werken, is onze missie hetzelfde: hoe kunnen ontwikkelaars direct een verbeterde gebruikerservaring krijgen en tegelijkertijd genieten van een geweldige ontwikkelervaring? We zijn ons ervan bewust en respecteren dat er honderden, zo niet duizenden, community-bijdragers en framework-beheerders zijn die allemaal aan verschillende projecten werken die met elkaar in wisselwerking staan.
Kara: Bovendien, omdat we het belangrijk vinden om de impact van prestaties te valideren en te handelen op basis van data, kost het proces wat meer tijd. We bevinden ons op onbekend terrein, dus soms experimenteren we met een optimalisatie die niet werkt en bouwen we uiteindelijk geen geplande feature. Zelfs als een feature wel werkt, kosten die paar extra stappen om de prestaties te controleren tijd en verlengen ze de planning.
Het vinden van productiepartners om onze functies te testen, kan ook een uitdaging zijn. Zoals eerder vermeld, zijn het bedrijven met hun eigen prioriteiten. Het kan dus lastig zijn om nieuwe initiatieven te integreren als deze niet goed aansluiten bij bestaande projecten die voorrang moeten krijgen. Bovendien investeren de bedrijven die het meest geïnteresseerd zijn in hulp vaak al in prestaties, waardoor ze niet echt onze doelgroep zijn. We proberen feedback te verzamelen van het grote deel van de community dat niet kan investeren in prestaties, maar zij nemen het minst snel contact met ons op.
Laten we verder gaan, op wat voor soort optimalisaties heb je je gericht?
Houssein: Na duizenden applicaties te hebben geanalyseerd, ontdekten we dat de grootste prestatieproblemen meestal te wijten zijn aan antipatronen in de applicatiecode en niet aan het framework zelf. Bijvoorbeeld het verzenden van onnodig grote afbeeldingen, het te laat laden van aangepaste lettertypen, het ophalen van te veel verzoeken van derden die de hoofdthread blokkeren, en het niet verwerken van hoe asynchrone content ervoor kan zorgen dat andere dingen op de pagina verschuiven. Dit zijn allemaal problemen die zich kunnen voordoen, ongeacht welke tool je gebruikt, dus dachten we: kunnen we een aantal standaardoptimalisaties inbouwen die ze goed afhandelen, maar wel een nette ontwikkelervaring bieden die perfect aansluit bij de tools van hun framework?
Met deze gedachtegang in ons achterhoofd hebben wij het volgende geleverd:
- Next.js-afbeeldingcomponent .
- Next.js scriptcomponent .
- Automatische lettertype-inline-indeling in het Next.js-bouwproces.
- Richtlijn voor hoekige afbeeldingen .
- De Next.js-conformiteits-ESLint-plug-in biedt ontwikkelaars bruikbare richtlijnen.
Ons werk heeft andere frameworks en tools geïnspireerd om vergelijkbare optimalisaties te implementeren. Dit omvat, maar is niet beperkt tot:
- Nuxt-imagemodule
- Nuxt-lettertypemetrische overschrijvingen
- Nuxt-scriptcomponent ( in uitvoering )
- Gatsby Script-component
Kunt u enkele positieve resultaten van uw werk met een aantal van deze spelers delen?
Houssein: Veel sites hebben prestatieverbeteringen gezien dankzij de optimalisaties die we hebben doorgevoerd. Een van mijn favoriete voorbeelden is Leboncoin , die hun LCP verlaagde van 2,4 seconden naar 1,7 seconden na de overstap naar de Next.js-afbeeldingcomponent. Er zijn er momenteel nog veel meer in de experimenteer- en testfase en we zullen de lessen en successen die we hier hebben behaald, blijven delen.
Oké, ik begrijp dat je je richt op de frameworks of bibliotheken die het populairst zijn, maar zijn er ook manieren waarop andere frameworks of bibliotheken waarmee je niet proactief werkt, hiervan profiteren?
Addy: Veel van de prestatieoptimalisaties waaraan Aurora meewerkt, kunnen door elk framework worden gerepliceerd. Kijk bijvoorbeeld eens naar onze inspanningen op het gebied van Image- of Script-componenten; die leggen vaak een bestaande set best practices vast. We proberen te documenteren hoe dergelijke componenten worden gebouwd en hoe ze er in elk framework uitzien. Hopelijk is dit een goed begin om het idee te kopiëren.
We hebben goede resultaten gezien met het toepassen van de kennis uit één ecosysteem (bijvoorbeeld React en Next.js) op andere systemen. Bijvoorbeeld de nieuwe Angular Image Directive (gebaseerd op onze kennis uit de Next.js Image Component) of Gatsby, die onze aanpak voor gedetailleerde JavaScript-chunking implementeert.
Tegelijkertijd begrijpen we dat niet elk framework de bandbreedte of financiering heeft om bijdragers in staat te stellen vergelijkbare prestatiefuncties te ontwikkelen of te investeren in andere optimalisaties die zij belangrijk vinden voor hun gebruikers. Het Chrome Web Frameworks Fund is voor ons een manier om prestatiewerk in het JavaScript-ecosysteem te sponsoren, zodat projecten hun bijdragers kunnen betalen en prestatiewerk verder kan opschalen in het ecosysteem.
Wat zijn de plannen voor jouw team?
Kara: We hebben een heleboel spannende projecten in het verschiet! Een paar hoogtepunten:
- Vermindering van lettertypegerelateerde CLS: Het is vrij gebruikelijk om lay-outverschuivingen te zien wanneer een webfont wordt geladen en het fallback-font wordt vervangen. We onderzoeken de mogelijkheid om lettertype-metrische overschrijvingen en de eigenschap "size-adjust" te gebruiken om lettertypegerelateerde CLS standaard te verminderen in Next.js. We hebben hierover ook overlegd met het Nuxt-team en zijn van plan dit idee volgend jaar uit te breiden naar meer frameworks.
- INP debuggen: Nu de Interaction to Next Paint (INP) -metriek is vrijgegeven, werken we samen met frameworks om de meest voorkomende oorzaken van INP-problemen voor hun communities te onderzoeken en oplossingen voor te stellen. We hebben hiervoor nauw samengewerkt met Angular en hopen binnenkort de resultaten te kunnen delen!
- Optimalisatie van veelgebruikte 3P-scripts: Het laden van scripts van derden op het verkeerde moment kan een aanzienlijke negatieve impact hebben op de prestaties. Omdat er een aantal 3P's zijn die veel voorkomen, onderzoeken we of we wrappers hiervoor kunnen aanbieden om ervoor te zorgen dat ze optimaal worden geladen met frameworks en de hoofdthread niet blokkeren. We gebruiken de Next.js-scriptcomponent die we hebben gebouwd als uitgangspunt voor dit onderzoek.
Ontwikkelaars kunnen onze voortgang op deze site volgen.
In het nieuws
Voordat ik afsluit, wil ik u nog een paar interessante updates meegeven over de wereld van frameworks binnen Google.
In juli kondigde het Chrome-team de nieuwste financieringsronde van $ 500.000 aan voor het Frameworks and Tools-fonds , dat zich richt op de financiering van projecten die de prestaties, gebruikerservaring en ontwikkelaarservaring op het web verbeteren. Toekomstige financiering zal nieuwe projecten omvatten, dus vergeet niet uw aanvraag in te dienen .
En natuurlijk gebeuren er ook een heleboel fantastische dingen in de community. Het ecosysteem zit boordevol nieuwe frameworks zoals Deno's Fresh en fantastische ervaringen zoals Svelte's onboarding tutorial, die niet alleen een demo in de browser is, maar ook de Web Container API gebruikt om Node.js native in de browser te draaien. Zoveel goeds!
Ik word er echt enthousiast van als ik zie hoe het ecosysteem samenkomt, de mogelijkheden van de browser vergroot en ontwikkelaars helpt producten te bouwen die voor iedereen werken. Het is een spannende tijd om webontwikkelaar te zijn.
Tot de volgende Insider, Hwyl Fawr.
Wat vond je van deze editie van The Chrome Dev Insider? Deel je feedback .