Ik ben Paul Kinlan en ik leid de ontwikkelaarsrelaties voor Chrome. Als onderdeel van mijn werk werk ik samen met een team van gepassioneerde webadvocaten die de taak hebben om het perspectief van echte ontwikkelaars naar onze product- en engineeringteams te brengen, met de North Star-statistiek om de tevredenheid van ontwikkelaars te verbeteren .
We erkennen dat 'tevredenheid' een ambitieuze en subjectieve maatstaf is om bij te houden en te verbeteren, dus we herhalen voortdurend hoe we impact kunnen maken, terwijl we ons concentreren op de behoeften van ontwikkelaars . Een leidend principe dat we nuttig vinden om te volgen is: ' ontmoet ontwikkelaars waar ze zijn '. Uit een recent Stack Overflow-onderzoek bleek dat 75% van de ontwikkelaars rapporteert gebruik te maken van frameworks of een of andere abstractie. We hebben ons dus afgevraagd hoe we het beste ontwikkelaars kunnen bedienen die al beslissingen hebben genomen over hun tech-stack, of daar geen controle over hebben? Hoe kunnen we ze productiever maken zonder meer 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 rechtstreeks in deze abstracties te brengen, in plaats van de last op hun klanten (webontwikkelaars) te leggen.
Voor de derde editie van de 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 benaderd en wat hen te wachten staat.
Insider primeur: werken met frameworks van derden
Laten we beginnen met het ontstaan van dit project. Hoe is het tot stand gekomen?
Addy: Aurora begon met een eenvoudig idee: laten we ontwikkelaars ontmoeten waar ze zich bevinden en hen helpen daar te komen waar ze heen moeten. Help bijvoorbeeld de populaire tech-stack die ze hebben gekozen om 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. De lijst gaat maar door! ). In plaats van te verwachten dat deze ontwikkelaars diepgaande experts worden (bijvoorbeeld op het gebied van prestaties), kunnen we ervoor zorgen dat ze in een put van succes terechtkomen door standaard meer best practices in deze stapels te bakken. Op die manier zijn sites van betere kwaliteit een neveneffect van het bouwen voor internet.
Aurora kiest een paar veelgebruikte raamwerken en meta-raamwerken om mee samen te werken. We documenteren onze lessen (zoals hoe we een goede beeldcomponent kunnen bouwen), zodat anderen deze snel kunnen volgen en kunnen proberen op te schalen via andere raamwerken en tools via Chrome Kaderfonds. Hoewel het mogelijk is om de kwaliteit van webervaringen via de browser te verbeteren, zijn wij van mening dat dit doel (in sommige gevallen) ook via frameworks kan worden bereikt. We hopen dat dit ons helpt bij het bereiken van onze doelstellingen: een web van hogere kwaliteit voor iedereen.
Kara: Om daar verder op in te gaan, is het de bedoeling om de prestaties op internet te verbeteren door de ontwikkelaarservaring te verbeteren. Het is niet voldoende om best practices op het gebied van prestaties bekend te maken, omdat deze vaak veranderen en het voor bedrijven moeilijk is om bij te blijven. Ze hebben hun eigen zakelijke prioriteiten die waarschijnlijk vóór prestaties gaan.
Ons idee is dus dat als ontwikkelaars weinig tijd hebben om zich aan de prestaties te wijden, we het voor hen gemakkelijker (en sneller) moeten maken om een performante app te bouwen. Als we samenwerken met populaire webframeworks, bevinden we ons op de juiste abstractielaag om de ontwikkelaarservaring te verbeteren via componenten op een hoger niveau, conformiteitswaarschuwingen, enz. Iedereen die deze populaire tools gebruikt, heeft toegang tot deze voordelen. En in theorie kunnen we, als het aanbevolen advies verandert, onze componenten onder de motorkap updaten en hoeven de ontwikkelaars zich geen zorgen te maken over het actueel blijven.
Houssein: Ik kwam bij Google terecht als Developer Advocate voordat ik een paar jaar later overstapte naar een software-engineeringrol. Een groot deel van mijn eerdere werk bestond uit het onderwijzen van webontwikkelaars in de vele verschillende manieren om geweldige gebruikerservaringen op te bouwen. Er werden keer op keer variaties op dezelfde richtlijnen gegeven om ontwikkelaars te waarschuwen voor de veelvoorkomende problemen die waarschijnlijk de prestaties en bruikbaarheid van hun sites zullen 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, zijn jullie een team van wat, zes ingenieurs? Ik wed dat je niet met elk mogelijk raamwerk of bibliotheek kunt werken. Dus hoe kies je met wie je wilt samenwerken? En wie zijn zij?
Addy: Het web lijkt in veel opzichten op het wilde westen. U kunt vrijwel elk gewenst framework, bundelprogramma, bibliotheken en externe partijen kiezen. 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 ervoor te zorgen dat die lagen zich op hun gemak voelen als ze een mening hebben en er meer meningen aan toe te voegen.
Webframeworks (Next.js, Nuxt.js en tot op zekere hoogte Angular) proberen bijvoorbeeld meer meningen en standaarden in te bouwen dan een meer handgerolde oplossing. Dit is één van de redenen waarom wij graag met hen samenwerken! Het hebben van sterkere standaardinstellingen voor het laden van afbeeldingen, lettertypen en scripts voor betere Core Web Vitals is logisch in deze modellen.
Het dient ook als een mooie manier om te bevestigen waar moderne best practices werken of misschien opnieuw moeten worden bekeken, en kan helpen het hele ecosysteem te informeren over hoe het kan worden aangepakt bij het oplossen van optimalisatieproblemen.
Kara: Realistisch gezien moeten we ook rekening houden met populariteit. Als we de grootst mogelijke impact op het web willen hebben, is het werken met frameworks en bibliotheken met een grote bestaande community van ontwikkelaars ideaal. Op die manier kunnen we meer ontwikkelaars en meer apps bereiken. Maar het kan niet alleen maar populariteit zijn. Uiteindelijk is het een kruising van populariteit, hoe eigenwijs een bibliotheek is en de beschikbare functies waarmee we kunnen werken.
Als we bijvoorbeeld alleen naar populariteit kijken, zijn React, Vue en Angular de ‘grote drie’ om te overwegen. Maar we werken het meest met Next.js, Nuxt en Angular. Dit komt omdat weergavebibliotheken zoals React en Vue zich vooral richten op weergave, dus het is onmogelijk om alle gewenste functies er rechtstreeks 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 maken. Ze hebben ook ingebouwde servers, dus we kunnen server-side optimalisaties toevoegen.
Het is je misschien opgevallen dat Angular op de lijst met diepgaande partnerschappen stond, maar het is geen metaframework. Angular is een beetje een speciaal geval omdat het behoorlijk populair is, maar geen complementair metaframework heeft zoals React en Vue. We werken dus rechtstreeks met hen samen en dragen waar mogelijk functies bij via hun CLI.
En het is vermeldenswaard dat we verschillende lopende relaties hebben met andere projecten zoals Gatsby, waar we enigszins regelmatig synchroniseren op het gebied van ontwerp, maar niet actief code bijdragen.
Hoe ziet dit er dan in de praktijk uit? Wat was uw aanpak om dit probleem op te lossen?
Kara: In de praktijk hebben we een aantal raamwerken waarmee we nauw samenwerken. We zullen wat tijd nodig hebben om apps te profileren die dat raamwerk gebruiken en de veelvoorkomende prestatiepijnpunten te achterhalen. Vervolgens werken we samen met het raamwerkteam om experimentele functies te ontwerpen om deze pijnpunten op te lossen en code rechtstreeks aan de OSS-repository bij te dragen om deze te implementeren.
Het is erg belangrijk voor ons om te valideren dat de impact op de prestaties is wat we hadden voorspeld, dus werken we ook samen met externe bedrijven om prestatietests in de productie uit te voeren. Als de resultaten bemoedigend zijn, helpen we de functie 'stabiel' te maken, en maken we er mogelijk een standaard van.
Dit alles kan niet zo eenvoudig zijn als jij het doet klinken. Wat waren enkele van de uitdagingen of lessen die je tot nu toe hebt gehad?
Houssein: Een belangrijk ding dat we zo goed mogelijk proberen te navigeren, is het bijdragen aan populaire open-sourcerepository's die veel concurrerende prioriteiten hebben. Het feit dat we een Google-team zijn, betekent niet noodzakelijkerwijs dat onze functies prioriteit krijgen. Daarom doen we ons best om ons aan te passen aan het typische proces van het voorstellen en verzenden van nieuwe functies zonder iemand op de tenen te trappen. We hebben het grote geluk gehad om samen te werken met ontvankelijke beheerders in de ecosystemen Next.js, Nuxt en Angular. We zijn dankbaar dat ze open hebben gestaan voor het luisteren naar onze zorgen over het web-ecosysteem en bereid zijn om op meer dan één manier met ons samen te werken.
Bij veel van de raamwerken waarmee we werken, is onze algemene missie dezelfde; Hoe kunnen ontwikkelaars out-of-the-box een verbeterde gebruikerservaring krijgen en tegelijkertijd genieten van een geweldige ontwikkelaarservaring? We zijn ons ervan bewust en respecteren dat er honderden, zo niet duizenden gemeenschapsbijdragers en raamwerkonderhouders zijn die elk aan verschillende projecten werken die elkaar kruisen.
Kara: Omdat we het belangrijk vinden om de impact op de prestaties te valideren en te handelen op basis van data, kost het proces bovendien wat meer tijd. We bevinden ons op onbekend terrein, dus soms experimenteren we met een optimalisatie die niet lukt en uiteindelijk bouwen we geen geplande functie. Zelfs als een functie goed werkt, kosten die paar extra stappen om de prestaties te controleren tijd en verlengen ze de tijdlijnen.
Het vinden van productiepartners om onze functies te testen kan ook een uitdaging zijn. Zoals eerder vermeld zijn het bedrijven en hebben ze hun eigen prioriteiten. Het kan voor hen dus een uitdaging zijn om nieuwe initiatieven in te passen als ze niet goed aansluiten bij bestaande projecten die op de eerste plaats moeten komen. Bovendien nemen de bedrijven die het meest geïnteresseerd zijn om te helpen vaak al de tijd om in prestaties te investeren, en vormen ze dus niet echt onze doelgroep. We proberen feedback te verzamelen van het grote deel van de gemeenschap dat niet in prestaties kan investeren, maar de kans is het kleinst dat zij contact met ons opnemen.
Verderop: op welke soort optimalisaties heb je je geconcentreerd?
Houssein: Na duizenden applicaties te hebben geanalyseerd, kwamen we erachter dat de grootste prestatieproblemen meestal te wijten zijn aan antipatronen in de applicatiecode en niet aan het raamwerk 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 rode draad blokkeren, en het niet omgaan met de manier waarop asynchrone inhoud 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 met een mooie ontwikkelaarservaring die mooi past in hun framework-tools?
Met deze gedachte hebben we het volgende verzonden:
- Next.js afbeeldingscomponent .
- Next.js-scriptcomponent .
- Automatische inlining van lettertypen in het bouwproces van Next.js.
- Hoekige beeldrichtlijn .
- Next.js-conforme ESLint-plug-in om bruikbare richtlijnen te bieden aan ontwikkelaars.
Ons werk heeft andere raamwerken en tools geïnspireerd om soortgelijke optimalisaties te implementeren. Dit omvat, maar is niet beperkt tot:
- Nuxt-beeldmodule
- Metrische nuxt-lettertypeoverschrijvingen
- Nuxt-scriptcomponent ( in uitvoering )
- Gatsby Script-component
Kunt u enkele positieve resultaten van uw werk met enkele 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 terugbracht van 2,4 seconden naar 1,7 seconden nadat ze waren overgestapt op de Next.js-afbeeldingscomponent. Er zijn er nog veel meer die zich momenteel in de experiment- en testfase bevinden en we zullen de lessen en overwinningen hieruit blijven delen.
Oké, ik begrijp dat je focus ligt op de meest populaire frameworks, maar zijn er manieren waarop andere frameworks of bibliotheken waarmee je niet proactief werkt ook kunnen profiteren?
Addy: Veel van de prestatie-optimalisaties waaraan Aurora samenwerkt, kunnen door elk raamwerk worden gerepliceerd. Kijk bijvoorbeeld eens naar onze inspanningen op het gebied van Image- of Script-componenten; deze codificeren vaak een bestaande reeks best practices. We proberen het ‘hoe’ van het bouwen van dergelijke componenten te documenteren en hoe ze er in elk raamwerk uitzien. Hopelijk is dit een goed begin om het idee te kopiëren.
We hebben enig succes gezien door de lessen uit het ene ecosysteem (bijvoorbeeld React en Next.js) over te brengen naar andere. Bijvoorbeeld de nieuwe Angular Image Directive (gebaseerd op onze ervaringen met het bouwen van de Next.js Image Component) of Gatsby die onze aanpak voor granulaire JavaScript-chunking verzendt.
Tegelijkertijd begrijpen we dat niet elk raamwerk de bandbreedte of financiering zal hebben voor bijdragers om vergelijkbare prestatiekenmerken uit te bouwen of te investeren in andere optimalisaties waarvan zij denken dat ze belangrijk zijn 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 worden geschaald in het ecosysteem.
Dus wat staat er op de roadmap voor uw team?
Kara: Er komen een heleboel spannende projecten aan! Enkele hoogtepunten:
- Vermindering van lettertype-gerelateerde CLS: Het is vrij gebruikelijk dat lay-outverschuivingen optreden wanneer een weblettertype wordt geladen en het reservelettertype vervangt. We onderzoeken het gebruik van lettertype-metrische overschrijvingen en de eigenschap "size-adjust" om lettertype-gerelateerde CLS standaard te verminderen in Next.js. We hebben hierover ook overleg gevoerd met het Nuxt-team en zijn van plan dit idee volgend jaar uit te breiden naar meer raamwerken.
- Foutopsporing in INP: Nu de INP-metriek (Interaction to Next Paint) is vrijgegeven, werken we met raamwerken om de meest voorkomende hoofdoorzaken van INP-problemen voor hun gemeenschappen te onderzoeken en oplossingen voor te stellen. We hebben hierbij nauw samengewerkt met Angular en hopen binnenkort enkele resultaten te kunnen delen!
- Het optimaliseren van veelgebruikte 3P-scripts: Het op het verkeerde moment laden van scripts van derden kan een aanzienlijke negatieve invloed hebben op de prestaties. Omdat er een paar 3P's zijn die veel voorkomen, onderzoeken we of we hiervoor enkele wrappers 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 me afmeld, wil ik jullie nog een paar interessante updates geven uit de wereld van de frameworks binnen Google.
In juli kondigde het Chrome-team de laatste financieringsronde van $ 500.000 aan voor het Frameworks and Tools Fund dat zich richt op het financieren van projecten die tot doel hebben de prestaties, gebruikerservaring en ontwikkelaarservaring op internet te verbeteren. Bij toekomstige financiering zullen nieuwe projecten in overweging worden genomen, dus vergeet niet uw verzoek in te dienen .
En natuurlijk gebeuren er ook VEEL verbazingwekkende dingen in de gemeenschap. Het ecosysteem is rijp met nieuwe raamwerken zoals Deno's Fresh en geweldige ervaringen zoals de onboarding-tutorial van Svelte, die niet alleen een demo in de browser is, maar ook de Web Container API gebruikt om Node.js native in de browser uit te voeren. Zoveel goede dingen!
Ik word echt opgewonden als ik zie hoe het ecosysteem samenkomt, wat mogelijk is in de browser 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 uw feedback .