Chrome Dev Insider: Leistungsskalierung mit dem Framework-System

Paul Kinlan

Ich bin Paul Kinlan und leite die Entwicklerbeziehungen für Chrome. Im Rahmen meiner Arbeit arbeite ich mit einem Team von leidenschaftlichen Web-Experten zusammen, die die Perspektive echter Entwickler in unsere Produkt- und Engineering-Teams einbringen sollen. Unser Leitwert ist es, die Zufriedenheit der Entwickler zu verbessern.

Uns ist bewusst, dass „Zufriedenheit“ ein ehrgeiziger und subjektiver Messwert ist, den wir im Blick behalten und verbessern möchten. Deshalb arbeiten wir ständig daran, wie wir einen positiven Beitrag leisten können, und konzentrieren uns dabei auf die Anforderungen der Entwickler. Ein Leitprinzip, das sich bewährt hat, ist: Entwickler dort abholen, wo sie sind. Eine aktuelle Stack Overflow-Studie hat ergeben, dass 75% der Entwickler Frameworks oder eine Art Abstraktion verwenden. Deshalb haben wir uns gefragt, wie wir Entwicklern am besten helfen können, die bereits Entscheidungen bezüglich ihres Tech-Stacks getroffen haben oder keine Kontrolle darüber haben. Wie können wir sie produktiver machen, ohne mehr Aufwand zu verursachen?

Ein kleines Team hier bei Chrome arbeitet an einem Projekt namens Aurora. Ziel ist es, mit Abstraktionsschichten der Webplattform von Drittanbietern wie Frameworks und Bibliotheken zu arbeiten. Ziel ist es, Leistungssteigerungen direkt in diese Abstraktionsebenen zu bringen, anstatt die Last auf die Kunden – die Webentwickler – abzuwälzen.

Für die dritte Ausgabe von Chrome Dev Insider habe ich mit Addy Osmani, Kara Erickson und Houssein Djirdeh vom Project Aurora-Team gesprochen, um mehr darüber zu erfahren, wie sie dieses Projekt angehen und was sie in Zukunft erwartet.

Insiderwissen: Mit Frameworks von Drittanbietern arbeiten

Beginnen wir mit der Entstehung dieses Projekts. Wie kam es dazu?

Addy: Aurora begann mit einer einfachen Idee: Entwickler dort abholen, wo sie sind, und ihnen helfen, dorthin zu gelangen, wo sie hinwollen. Zum Beispiel die Leistung des beliebten Tech-Stacks verbessern, den sie ausgewählt haben. Viele App-Entwickler verwenden heutzutage React, Vue oder Angular – oder Meta-Frameworks* wie Next.js und Nuxt – (und natürlich viele andere… Svelte, Lit, Preact, Astro. Die Liste ist endlos!). Anstatt zu erwarten, dass diese Entwickler zu Experten werden (z. B. in Bezug auf die Leistung), könnten wir dafür sorgen, dass sie von Anfang an auf Erfolgskurs sind, indem wir mehr Best Practices standardmäßig in diese Stacks einbinden. So sind Websites mit höherer Qualität ein Nebeneffekt der Webentwicklung.

Aurora wählt einige weit verbreitete Frameworks und Meta-Frameworks aus, mit denen wir zusammenarbeiten. Wir dokumentieren unsere Erkenntnisse (z. B. wie man eine gute Bildkomponente erstellt), damit andere schnell nachziehen und versuchen können, über andere Frameworks und Tools im Rahmen des Chrome Frameworks Fund zu skalieren. Es ist zwar möglich, die Qualität der Webnutzung über den Browser zu verbessern, wir sind jedoch der Meinung, dass dieses Ziel in einigen Fällen auch über Frameworks erreicht werden kann. Wir hoffen, dass wir so unser Ziel erreichen, das Web für alle noch hochwertiger zu machen.

Kara: Um das zu ergänzen: Es geht darum, die Leistung im Web zu verbessern, indem die Entwicklerfreundlichkeit verbessert wird. Es reicht nicht aus, Best Practices für die Leistung zu veröffentlichen, da sie sich häufig ändern und es für Unternehmen schwierig ist, mitzuhalten. Sie haben eigene Geschäftsprioritäten, die wahrscheinlich vor der Leistung stehen.

Wenn Entwickler nur begrenzt Zeit für die Leistung haben, sollten wir es ihnen einfacher und schneller machen, eine leistungsstarke App zu entwickeln. Wenn wir mit beliebten Web-Frameworks zusammenarbeiten, sind wir auf der richtigen Abstraktionsebene, um die Entwicklerfreundlichkeit durch Komponenten höherer Ebene, Konformitätswarnungen usw. zu verbessern. Alle, die diese beliebten Tools verwenden, haben Zugriff auf diese Vorteile. Und theoretisch können wir unsere Komponenten im Hintergrund aktualisieren, wenn sich die empfohlenen Empfehlungen ändern, sodass die Entwickler sich keine Sorgen machen müssen, auf dem neuesten Stand zu bleiben.

Houssein: Ich bin als Developer Advocate zu Google gekommen und habe einige Jahre später eine Stelle im Software Engineering angenommen. Ein Großteil meiner bisherigen Arbeit bestand darin, Webentwicklern die vielen verschiedenen Möglichkeiten zu vermitteln, eine hervorragende Nutzererfahrung zu schaffen. Immer wieder wurden Entwickler auf die häufigsten Probleme hingewiesen, die sich wahrscheinlich auf die Leistung und Nutzerfreundlichkeit ihrer Websites auswirken. Als wir uns Gedanken über das Aurora-Projekt gemacht haben, haben wir uns gefragt: Können wir eine Richtung einschlagen, in der wir Entwicklern nie sagen müssen, was sie tun sollen, weil ihre Toolchain alles für sie erledigt?

Wenn ich das richtig verstehe, besteht Ihr Team aus sechs Entwicklern. Ich wette, Sie können nicht mit jedem möglichen Framework oder jeder Bibliothek arbeiten. Wie wählen Sie also aus, mit wem Sie zusammenarbeiten möchten? Und wer sind sie?

Addy:Das Web ist in vielerlei Hinsicht wie der Wilde Westen. Sie können praktisch jedes Framework, jeden Bundler, jede Bibliothek und jeden Drittanbieter verwenden. Das führt zu mehreren Komplexitätsebenen, die zu einer guten oder schlechten Leistung beitragen können. Eine der besten Möglichkeiten, die Leistung zu steigern, besteht darin, nach den Ebenen zu suchen, die sich mit ihrer Meinung wohlfühlen, und ihnen weitere Meinungen hinzuzufügen.

Web-Frameworks wie Next.js, Nuxt.js und in gewissem Maße Angular versuchen beispielsweise, mehr Meinungen und Standardeinstellungen zu berücksichtigen als eine selbst erstellte Lösung. Das ist einer der Gründe, warum wir gerne mit ihnen zusammenarbeiten. Bei diesen Modellen ist es sinnvoll, strengere Standardeinstellungen für das Laden von Bildern, Schriftarten und Scripts zu verwenden, um bessere Core Web Vitals zu erzielen.

Außerdem können Sie so feststellen, wo moderne Best Practices funktionieren oder möglicherweise überdacht werden müssen. So können Sie das gesamte Team darüber informieren, wie Sie Optimierungsprobleme angehen können.

Kara:Wir müssen aber auch die Beliebtheit berücksichtigen. Wenn wir möglichst große Auswirkungen auf das Web haben möchten, ist es ideal, mit Frameworks und Bibliotheken zu arbeiten, die eine große Entwicklergemeinschaft haben. So können wir mehr Entwickler und mehr Apps erreichen. Aber es kann nicht nur um Beliebtheit gehen. Letztendlich ist es eine Kombination aus Beliebtheit, Voreingenommenheit einer Bibliothek und den verfügbaren Funktionen, mit denen wir arbeiten können.

Wenn wir uns beispielsweise nur die Beliebtheit ansehen, sind React, Vue und Angular die „Big Three“, die Sie in Betracht ziehen sollten. Am häufigsten arbeiten wir jedoch mit Next.js, Nuxt und Angular. Das liegt daran, dass sich Ansichtsbibliotheken wie React und Vue hauptsächlich auf das Rendering konzentrieren. Daher ist es nicht möglich, alle gewünschten Funktionen direkt in sie einzubinden. Deshalb arbeiten wir verstärkt mit Meta-Frameworks, die auf diesen basieren: Next.js und Nuxt. Auf dieser Abstraktionsebene können wir integrierte Komponenten erstellen. Außerdem sind Server integriert, sodass wir serverseitige Optimierungen vornehmen können.

Angular war zwar in dieser Liste der engen Partnerschaften aufgeführt, ist aber kein Meta-Framework. Angular ist ein Sonderfall, da es zwar sehr beliebt ist, aber kein ergänzendes Meta-Framework wie React und Vue hat. Daher arbeiten wir direkt mit ihnen zusammen und tragen nach Möglichkeit über ihre Befehlszeile Funktionen bei.

Außerdem haben wir mehrere laufende Beziehungen zu anderen Projekten wie Gatsby, bei denen wir uns relativ regelmäßig über das Design abstimmen, aber nicht aktiv Code beitragen.

Wie sieht das in der Praxis aus? Wie haben Sie dieses Problem gelöst?

Kara: In der Praxis haben wir einige Frameworks, mit denen wir eng zusammenarbeiten. Wir nehmen uns etwas Zeit, um Apps mit diesem Framework zu profilieren und die häufigsten Leistungsprobleme zu ermitteln. Anschließend arbeiten wir mit dem Framework-Team zusammen, um experimentelle Funktionen zu entwickeln, um diese Probleme zu beheben, und tragen Code direkt in das OSS-Repository ein, um sie zu implementieren.

Es ist uns sehr wichtig, zu prüfen, ob die Leistungsauswirkungen den vorhergesagten entsprechen. Deshalb arbeiten wir auch mit externen Unternehmen zusammen, um Leistungstests in der Produktion durchzuführen. Wenn die Ergebnisse vielversprechend sind, werden wir die Funktion so optimieren, dass sie stabil ist, und sie möglicherweise als Standard festlegen.

Das kann nicht so einfach sein, wie Sie es darstellen. Welche Herausforderungen oder Erkenntnisse haben Sie bisher erlebt?

Houssein: Wir versuchen, nach bestem Wissen und Gewissen zu beliebten Open-Source-Repositories beizutragen, die viele konkurrierende Prioritäten haben. Nur weil wir ein Google-Team sind, bedeutet das nicht unbedingt, dass unsere Funktionen priorisiert werden. Deshalb versuchen wir, uns an den üblichen Prozess für die Vorschläge und Einführung neuer Funktionen anzupassen, ohne anderen auf die Füße zu treten. Wir hatten das Glück, mit aufgeschlossenen Maintainern in den Next.js-, Nuxt- und Angular-Umgebungen zusammenzuarbeiten. Wir sind dankbar, dass sie sich unsere Bedenken hinsichtlich des Web-Ökosystems angehört und sich bereit erklärt haben, auf verschiedene Weise mit uns zusammenzuarbeiten.

Bei vielen der Frameworks, mit denen wir arbeiten, haben wir dasselbe Ziel: Wie können Entwickler von vornherein eine verbesserte Nutzererfahrung und gleichzeitig eine gute Entwicklererfahrung erzielen? Wir sind uns bewusst, dass es Hunderte, wenn nicht Tausende von Community-Mitgliedern und Framework-Verantwortlichen gibt, die an verschiedenen Projekten arbeiten, die sich überschneiden.

Kara:Außerdem ist es uns wichtig, die Leistungsauswirkungen zu validieren und auf der Grundlage von Daten zu handeln. Das dauert etwas länger. Wir betreten Neuland. Manchmal führen wir Tests mit einer Optimierung durch, die nicht funktioniert, und entwickeln die geplante Funktion dann nicht weiter. Selbst wenn eine Funktion gut funktioniert, kosten diese zusätzlichen Schritte zur Prüfung der Leistung Zeit und verlängern die Zeitpläne.

Es kann auch schwierig sein, Produktionspartner für den Test unserer Funktionen zu finden. Wie bereits erwähnt, sind sie Unternehmen und haben ihre eigenen Prioritäten. Daher kann es schwierig sein, neue Initiativen zu integrieren, wenn sie nicht gut zu bestehenden Projekten passen, die an erster Stelle stehen. Außerdem nehmen sich die Unternehmen, die am ehesten Hilfe benötigen, in der Regel schon die Zeit, in die Leistung zu investieren. Sie sind also nicht wirklich unsere Zielgruppe. Wir versuchen, Feedback von der großen Gruppe der Community einzuholen, die nicht in die Leistung investieren kann, aber am wenigsten wahrscheinlich ist, sich an uns zu wenden.

Welche Optimierungen haben Sie bisher vorgenommen?

Houssein: Nach der Analyse von Tausenden von Anwendungen haben wir festgestellt, dass die größten Leistungsprobleme in der Regel auf Anti-Muster im Anwendungscode zurückzuführen sind und nicht auf das Framework selbst. Dazu gehören beispielsweise das Senden unnötig großer Bilder, das zu späte Laden benutzerdefinierter Schriftarten, das Abrufen zu vieler Anfragen von Drittanbietern, die den Hauptthread blockieren, und das Nichtbeachten, dass asynchrone Inhalte dazu führen können, dass sich andere Elemente auf der Seite verschieben. Diese Probleme können unabhängig vom verwendeten Tool auftreten. Deshalb haben wir uns gefragt, ob wir einige Standardoptimierungen einbinden können, die diese Probleme gut beheben, aber eine gute Entwicklererfahrung bieten, die gut in die Framework-Tools passt.

Aus diesem Grund haben wir Folgendes eingeführt:

Unsere Arbeit hat andere Frameworks und Tools dazu inspiriert, ähnliche Optimierungen zu implementieren. Dazu zählt unter anderem Folgendes:

Können Sie uns einige positive Ergebnisse Ihrer Arbeit mit einigen dieser Akteure teilen?

Houssein:Durch die von uns eingeführten Optimierungen konnten viele Websites ihre Leistung verbessern. Eins meiner Lieblingsbeispiele ist Leboncoin, das seinen LCP von 2,4 Sekunden auf 1,7 Sekunden reduzierte, nachdem es zur Next.js-Bildkomponente gewechselt war. Viele weitere befinden sich derzeit in der Testphase. Die Erkenntnisse und Erfolge daraus teilen wir hier mit euch.

Ok, ich verstehe, dass Sie sich auf die beliebtesten konzentrieren. Gibt es aber Möglichkeiten, wie auch andere Frameworks oder Bibliotheken, mit denen Sie nicht proaktiv arbeiten, davon profitieren können?

Addy:Viele der Leistungsoptimierungen, an denen Aurora mitarbeitet, können mit jedem Framework repliziert werden. Wenn Sie sich beispielsweise unsere Bild- oder Script-Komponenten ansehen, werden Sie feststellen, dass sie oft eine Reihe bestehender Best Practices codifizieren. Wir versuchen, zu dokumentieren, wie solche Komponenten erstellt werden und wie sie in den einzelnen Frameworks aussehen. Hoffentlich ist das ein guter Anfang, um die Idee zu kopieren.

Wir haben gute Erfahrungen damit gemacht, die Erkenntnisse aus einem Ökosystem (z. B. React und Next.js) auf andere zu übertragen. Dazu gehören beispielsweise die neue Angular-Bildrichtlinie, die auf unseren Erfahrungen beim Erstellen der Next.js-Bildkomponente basiert, oder Gatsby, das unseren Ansatz für detailliertes JavaScript-Chunking verwendet.

Uns ist aber auch bewusst, dass nicht jedes Framework die Bandbreite oder die Finanzierung für Entwickler bietet, um ähnliche Leistungsfunktionen zu entwickeln oder in andere Optimierungen zu investieren, die sie für ihre Nutzer für wichtig halten. Mit dem Chrome Web Frameworks Fund können wir die Leistungsentwicklung im JavaScript-Ökosystem fördern, damit Projekte ihre Mitwirkenden bezahlen und die Leistungsentwicklung im Ökosystem weiter skalieren können.

Was steht also auf der Roadmap Ihres Teams?

Kara:Es stehen viele spannende Projekte an. Nachfolgend werden einige der Änderungen aufgeführt:

  • Schriftbezogene CLS-Werte reduzieren:Layoutverschiebungen sind relativ häufig, wenn eine Webschrift geladen und die Fallback-Schrift ersetzt wird. Wir prüfen derzeit, ob wir Schriftmesswerte überschreiben und die Property „size-adjust“ verwenden können, um den CLS-Wert für Schriftarten standardmäßig in Next.js zu reduzieren. Wir haben uns auch mit dem Nuxt-Team beraten und planen, diese Idee im nächsten Jahr auf weitere Frameworks auszuweiten.
  • INP-Fehler beheben:Nachdem der Messwert Interaction to Next Paint (INP) veröffentlicht wurde, arbeiten wir mit Frameworks, um die häufigsten Ursachen für INP-Probleme für ihre Communitys zu untersuchen und Lösungen vorzuschlagen. Wir arbeiten in dieser Angelegenheit eng mit Angular zusammen und hoffen, bald erste Ergebnisse präsentieren zu können.
  • Gängige Drittanbieter-Scripts optimieren:Wenn Drittanbieter-Scripts zum falschen Zeitpunkt geladen werden, kann sich das erheblich negativ auf die Leistung auswirken. Da es einige sehr gängige Drittanbieter gibt, prüfen wir, ob wir Wrapper für diese anbieten können, damit sie optimal mit Frameworks geladen werden und den Hauptthread nicht blockieren. Wir verwenden die von uns erstellte Next.js-Scriptkomponente als Ausgangspunkt für diese Untersuchung.

Entwickler können den Fortschritt auf dieser Website verfolgen.

In den Nachrichten

Bevor ich ende, möchte ich Ihnen noch einige interessante Neuigkeiten aus der Welt der Frameworks bei Google mitteilen.

Im Juli hat das Chrome-Team die neueste Finanzierungsrunde in Höhe von 500.000 $für den Fonds für Frameworks und Tools angekündigt. Dieser Fonds konzentriert sich auf die Finanzierung von Projekten, die die Leistung, Nutzerfreundlichkeit und Entwicklerfreundlichkeit im Web verbessern sollen. Bei zukünftigen Förderungen werden neue Projekte berücksichtigt. Reichen Sie daher Ihre Anfrage ein.

Und natürlich gibt es auch in der Community jede Menge spannender Dinge. Das Ökosystem ist voll von neuen Frameworks wie Fresh von Deno und tollen Tools wie dem Onboarding-Tutorial von Svelte, das nicht nur eine In-Browser-Demo ist, sondern auch die Web Container API verwendet, um Node.js nativ im Browser auszuführen. So viele tolle Sachen!

Ich freue mich wirklich, dass das Ökosystem immer weiter wächst, wir die Möglichkeiten im Browser erweitern und Entwicklern helfen, Produkte zu entwickeln, die für alle funktionieren. Es ist eine spannende Zeit für Webentwickler.

Bis zum nächsten Mal! Hwyl fawr.

Wie hat Ihnen diese Ausgabe von The Chrome Dev Insider gefallen? Gib uns Feedback.