Chrome Dev Insider: Leistungsskalierung mit dem Framework-System

Paul Kinlan

Mein Name ist Paul Kinlan und ich leite die Entwicklerabteilung für Chrome. Im Rahmen meiner Arbeit arbeite ich mit einem Team von leidenschaftlichen Webfürsprechern zusammen, die unsere Produkt- und Engineering-Teams mit der Perspektive realer Entwickler einbringen und anhand des Nordstern-Messwerts die Zufriedenheit der Entwickler verbessern wollen.

Wir sind uns bewusst, dass „Zufriedenheit“ ein ambitionierter und subjektiver Messwert ist, den es zu verfolgen und zu verbessern gilt. Daher arbeiten wir ständig daran, wie wir etwas bewirken und uns gleichzeitig auf die Anforderungen der Entwickler konzentrieren können. Ein Leitsatz, den wir als nützlich erwiesen haben, lautet: „Entwickler dort abholen, wo sie sind“. Eine aktuelle Stack Overflow-Studie hat gezeigt, dass 75% der Entwickler angeben, dass sie Frameworks oder eine Abstraktion irgendeiner Art verwenden. Wir haben uns also gefragt, wie wir Entwicklern, die bereits Entscheidungen über ihren Technologie-Stack getroffen haben oder keine Kontrolle darüber haben, am besten helfen. Wie können wir die Produktivität steigern, ohne mehr Aufwand zu verursachen?

Ein kleines Team hier bei Chrome hat an einem Projekt namens Aurora gearbeitet, dessen Ziel es ist, mit Abstraktionen von Drittanbietern der Webplattform wie Frameworks und Bibliotheken zu arbeiten. Ziel ist es, Leistungssteigerungen direkt in diese Abstraktionen einfließen zu lassen, anstatt die Last auf die Kundschaft zu entlasten, nämlich für die Webentwickler.

Bei der dritten Ausgabe des Chrome Dev Insider-Programms 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 angegangen sind und was noch bevorsteht.

Insiderwissen: Mit Drittanbieter-Frameworks arbeiten

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

Addy:Aurora begann mit einer einfachen Idee: Wir sollten Entwickler dort treffen, wo sie stehen, und ihnen dabei helfen, ihr Ziel zu erreichen. Sie können beispielsweise einem beliebten Technologie-Stack helfen, um die Leistung zu verbessern. Viele App-Entwickler nutzen heutzutage React, Vue oder Angular – oder Meta-Frameworks* wie Next.js und Nuxt – und natürlich viele andere... Svelte, Lit, Preact, Astro. Die Liste geht noch weiter! Anstatt zu erwarten, dass diese Entwickler zu Experten werden (z. B. in Sachen Leistung), könnten wir dafür sorgen, dass sie in eine Erfolgsgrube geraten, indem wir standardmäßig mehr Best Practices in diese Stacks aufnehmen. So entstehen qualitativ hochwertigere Websites nicht nur für das Web.

Aurora wählt als Partner einige gängige Frameworks und Meta-Frameworks aus und dokumentiert unsere Erkenntnisse – z. B. wie man eine gute Bildkomponente erstellt –, damit andere schnell folgen und ihre Reichweite mithilfe des Chrome Frameworks Fund ausweiten können. Es ist zwar möglich, die Qualität der Nutzererfahrung im Web über den Browser zu verbessern, wir sind jedoch der Meinung, dass dieses Ziel (in einigen Fällen) auch mithilfe von Frameworks erreicht werden kann. Wir hoffen, dass wir dadurch unsere Ziele erreichen können, das Web für alle qualitativ hochwertiger zu gestalten.

Kara:Wir möchten die Leistung im Web verbessern, indem wir die Nutzerfreundlichkeit für Entwickler verbessern. Es reicht nicht aus, Best Practices zur Leistungsoptimierung zu veröffentlichen, da sie sich häufig ändern und es für Unternehmen schwierig ist, mitzuhalten. Sie haben ihre eigenen geschäftlichen Prioritäten, die wahrscheinlich vor der Leistung liegen.

Wenn Entwickler also nur wenig Zeit für die Leistung haben, sollten wir ihnen die Erstellung einer leistungsfähigen App (und schneller) ermöglichen. Wenn wir mit gängigen Web-Frameworks zusammenarbeiten, sind wir auf der richtigen Abstraktionsebene, um die Entwicklererfahrung durch übergeordnete Komponenten, Konformitätswarnungen usw. zu verbessern. Diese Vorteile stehen allen Nutzern zur Verfügung, die diese beliebten Tools verwenden. Und wenn sich die empfohlenen Tipps ändern, können wir unsere Komponenten theoretisch im Hintergrund aktualisieren und die Entwickler müssen sich nicht darum kümmern, dass sie auf dem neuesten Stand bleiben.

Houssein:Ich bin Developer Advocate bei Google, bevor ich einige Jahre später in die Rolle im Softwareentwickler wechselte. Zuvor habe ich Webentwicklern die vielen verschiedenen Möglichkeiten gezeigt, eine großartige Nutzererfahrung zu schaffen. Es wurden immer wieder Varianten derselben Anleitung bereitgestellt, um Entwickler auf häufige Probleme aufmerksam zu machen, die sich wahrscheinlich auf die Leistung und Nutzerfreundlichkeit ihrer Websites auswirken. Als wir über das Aurora-Projekt nachdachten, fragten wir uns: Können wir in eine Richtung gehen, in der wir den Entwicklern nie sagen müssen, was sie tun sollen, weil ihre Toolchain alles für sie übernimmt?

Wenn ich Sie richtig verstehe, sind Sie ein Team aus was, sechs Entwickler? Ich wette, Sie können nicht mit jedem denkbaren Framework oder jeder verfügbaren Bibliothek arbeiten. Wie wählen Sie also die Personen aus, mit denen Sie arbeiten möchten? Und wer sind sie?

Addy:Das Web ist in vielerlei Hinsicht wie der wilde Westen. Sie können beliebige Frameworks, Bundles, Bibliotheken und Drittanbieter auswählen. Dies 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, diejenigen Ebenen zu finden, die keine Meinung vertreten, und diese mit weiteren Meinungen ergänzen.

Web-Frameworks (Next.js, Nuxt.js und zum Teil Angular) versuchen beispielsweise, mehr Meinungen und Standards einzubauen als eine eher handgerollte Lösung. Das ist einer der Gründe, warum wir gerne mit ihnen zusammenarbeiten! Für diese Modelle ist es sinnvoll, für bessere Core Web Vitals strengere Standardeinstellungen für das Laden von Bildern, Schriftarten und Skripts festzulegen.

Außerdem lässt sich damit gut feststellen, wo moderne Best Practices funktionieren oder möglicherweise überdacht werden müssen. Außerdem kann das gesamte System dazu beitragen, eine Lösung für Optimierungsprobleme zu finden.

Kara:Realistisch muss auch die Beliebtheit berücksichtigt werden. Wenn wir den größtmöglichen Einfluss auf das Web erzielen möchten, ist es ideal, mit Frameworks und Bibliotheken zu arbeiten, die bereits über eine große Entwickler-Community verfügen. So können wir mehr Entwickler und mehr Apps erreichen. Aber es geht nicht nur um Beliebtheit. Letztendlich ist dies eine Schnittmenge zwischen Beliebtheit, der Meinung einer Bibliothek und dem verfügbaren Funktionsumfang, mit dem wir arbeiten können.

Wenn wir uns beispielsweise nur die Beliebtheit ansehen, sind React, Vue und Angular die drei „wichtigsten drei“. Aber wir arbeiten am häufigsten mit Next.js, Nuxt und Angular. Das liegt daran, dass Ansichtsbibliotheken wie React und Vue hauptsächlich auf Rendering ausgerichtet sind. Daher ist es unmöglich, alle gewünschten Funktionen direkt in sie einzubinden. Daher arbeiten wir enger mit fundierten Meta-Frameworks zusammen, die darauf aufbauen: Next.js und Nuxt. Auf dieser Abstraktionsebene können wir integrierte Komponenten erstellen. Sie haben auch integrierte Server, sodass wir serverseitige Optimierungen vornehmen können.

Sie werden vielleicht feststellen, dass Angular zwar auf der Liste tiefgehender Partnerschaften stand, aber es ist kein Meta-Framework. Angular ist ein Sonderfall, weil es sehr beliebt ist, aber im Gegensatz zu React und Vue kein passendes Meta-Framework hat. Wir arbeiten also direkt mit ihnen zusammen und fügen nach Möglichkeit Funktionen über ihre Befehlszeile hinzu.

Und es ist erwähnenswert, dass wir mehrere laufende Beziehungen zu anderen Projekten wie Gatsby haben, bei denen wir uns regelmäßig über Design Gedanken machen, aber nicht aktiv Code beitragen.

Wie sieht das in der Praxis aus? Welchen Ansatz haben Sie zur Lösung dieses Problems gewählt?

Kara:In der Praxis gibt es einige Frameworks, mit denen wir eng zusammenarbeiten. Wir nehmen uns etwas Zeit, um mithilfe dieses Frameworks Profile für Apps zu erstellen und häufige Leistungsprobleme zu ermitteln. Anschließend entwickeln wir zusammen mit dem Framework-Team experimentelle Funktionen zur Lösung dieser Probleme und fügen Code direkt zum OSS-Repository für deren Implementierung hinzu.

Es ist uns sehr wichtig zu validieren, dass die Auswirkungen auf die Leistung unseren Erwartungen entsprechen. Deshalb arbeiten wir auch mit externen Unternehmen zusammen, um Leistungstests in der Produktion durchzuführen. Wenn die Ergebnisse ermutigen, helfen wir, die Funktion zu „stabil“ zu machen und sie möglicherweise als Standard festzulegen.

All das kann nicht so einfach sein, wie Sie es klingen lassen. Welche Herausforderungen oder Erkenntnisse haben Sie bisher gewonnen?

Houssein:Eines der wichtigen Dinge, die wir so gut wie möglich nutzen können, ist es, einen Beitrag zu beliebten Open-Source-Repositories zu leisten, die viele konkurrierende Prioritäten haben. Nur weil wir ein Google-Team sind, bedeutet das nicht zwangsläufig, dass unsere Funktionen priorisiert werden. Wir versuchen daher unser Bestes, um uns dem typischen Prozess zu widmen, bei dem neue Funktionen vorgeschlagen und veröffentlicht werden, ohne jemandem auf die Füße zu treten. Wir hatten das Glück, mit empfänglichen Verwaltern in den Umgebungen Next.js, Nuxt und Angular zusammenzuarbeiten. Wir sind dankbar, dass sie offen dafür waren, unsere Bedenken in Bezug auf das Web zu hören, und bereit sind, auf vielfältige Weise mit uns zusammenzuarbeiten.

Bei vielen Frameworks, mit denen wir arbeiten, ist unsere übergeordnete Mission die gleiche: Wie können Entwickler von Anfang an eine verbesserte User Experience erhalten und gleichzeitig eine großartige Entwicklererfahrung bieten? Uns ist bewusst und respektiert, dass es Hunderte, wenn nicht Tausende von Community-Beitragenden und Framework-Betreuern gibt, die jeweils an verschiedenen Projekten arbeiten, die sich gegenseitig überschneiden.

Kara:Da es uns wichtig ist, die Auswirkungen auf die Leistung zu validieren und auf Grundlage von Daten zu handeln, dauert der Vorgang etwas länger. Wir befinden uns in Neuland, weshalb wir manchmal mit einer Optimierung experimentieren, die nicht funktioniert und am Ende keine geplante Funktion erstellt wird. Selbst wenn eine Funktion erst eingeführt wird, sind diese wenigen zusätzlichen Schritte zur Überprüfung der Leistung zeitaufwändig und der Zeitaufwand verlängert sich.

Produktionspartner zum Testen unserer Funktionen zu finden, kann ebenfalls eine Herausforderung sein. Wie bereits erwähnt, sind sie Unternehmen und haben ihre eigenen Prioritäten. Daher kann es für sie schwierig sein, sich in neue Initiativen zu integrieren, wenn sie nicht gut mit bestehenden Projekten übereinstimmen, die an erster Stelle stehen müssen. Außerdem nehmen sich die Unternehmen, die am meisten an Unterstützung interessiert sind, in der Regel bereits Zeit für die Leistung. Sie sind also nicht wirklich unsere Zielgruppe. Wir möchten Feedback von allen Nutzern erhalten, die nicht in die Leistung investieren dürfen, aber die Wahrscheinlichkeit, dass sie uns kontaktieren, ist bei uns am geringsten.

Auf welche Art von Optimierungen haben Sie sich konzentriert?

Houssein:Wir haben Tausende von Anwendungen analysiert und festgestellt, dass die größten Leistungsprobleme in der Regel auf Anti-Mustern im Anwendungscode und nicht auf dem Framework selbst zurückzuführen sind. Beispielsweise werden unnötig große Bilder versendet, benutzerdefinierte Schriftarten zu spät geladen, zu viele Anfragen von Drittanbietern abgerufen, die den Hauptthread blockieren, und Unbefugnis, dass asynchrone Inhalte dazu führen, dass sich andere Dinge auf der Seite verschieben. All das können Probleme auftreten, unabhängig davon, welches Tool Sie verwenden. Daher dachten wir uns: Können wir einige Standardoptimierungen einbauen, die diese gut bewältigen, aber mit einer praktischen Entwicklungsumgebung, die gut in ihre Framework-Tools passt?

Dementsprechend haben wir Folgendes entwickelt:

Unsere Arbeit hat andere Konzepte und Tools dazu inspiriert, ähnliche Optimierungen umzusetzen. Beispiele für unzulässige Anzeigen-Placements:

Kannst du einige der positiven Ergebnisse deiner Arbeit mit einigen dieser Akteure teilen?

Houssein:Die Leistung vieler Websites wurde aufgrund der von uns implementierten Optimierungen verbessert. Eines meiner Lieblingsbeispiele ist Leboncoin, das nach der Umstellung auf die Next.js-Bildkomponente den LCP-Wert von 2,4 Sekunden auf 1,7 Sekunden gesenkt hat. Derzeit befinden sich noch viele weitere in der Testphase und wir werden die Erkenntnisse und Erfolge aus diesen hier weiter teilen.

Okay, ich verstehe, dass Sie sich auf die mit der größten Beliebtheit konzentrieren. Aber gibt es auch andere Frameworks oder Bibliotheken, mit denen Sie nicht arbeiten, proaktiv?

Addy:Viele der Leistungsoptimierungen, an denen Aurora zusammenarbeitet, können von jedem Framework repliziert werden. Werfen wir einen Blick hinter die Kulissen unserer Bild- oder Skript-Komponenten. Oftmals werden darin bereits Best Practices festgeschrieben. Wir versuchen zu dokumentieren, wie solche Komponenten erstellt werden und wie sie in den einzelnen Frameworks aussehen. Hoffentlich ist dies ein guter Anfang, um die Idee zu übernehmen.

Die Erkenntnisse aus einem System (z. B. React und Next.js) lassen sich sehr erfolgreich auf andere übertragen. Zum Beispiel haben die neue Angular-Image-Anweisung, die auf unseren Erkenntnissen zur Next.js-Bildkomponente aufbaut, oder Gatsby veröffentlichen unseren Ansatz für detailliertes JavaScript-Chunking.

Uns ist aber auch klar, dass nicht jedes Framework genügend Kapazität oder finanzielle Unterstützung hat, um ähnliche Leistungsmerkmale zu entwickeln oder in andere Optimierungen zu investieren, die ihrer Meinung nach für ihre Nutzer wichtig sind. Mit dem Chrome Web Frameworks Fund können wir leistungsorientierte Projekte im JavaScript-System sponsern, damit Projekte ihre Spende bezahlt und Leistungsarbeiten weiter weiterentwickelt werden können.

Was ist also auf der Roadmap Ihres Teams?

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

  • Reduzierung der schriftbezogenen CLS:Häufig kommt es zu Layoutverschiebungen, wenn eine Webschriftart geladen wird und dadurch die Fallback-Schriftart ersetzt. Wir erforschen Überschreibungen von Schriftartmesswerten und die Eigenschaft „size-Adjust“, um schriftspezifische CLS-Werte in Next.js standardmäßig zu reduzieren. Wir haben uns auch mit dem Nuxt-Team dazu beraten und planen, diese Idee im nächsten Jahr auf weitere Frameworks auszuweiten.
  • Debugging INP:Nachdem der Messwert Interaction to Next Paint (INP) veröffentlicht wurde, arbeiten wir mit Frameworks daran, die häufigsten Ursachen von INP-Problemen für ihre Communities zu untersuchen und Lösungen vorzuschlagen. Wir arbeiten hierzu eng mit Angular zusammen und hoffen, schon bald einige Ergebnisse vorlegen zu können.
  • Häufige Drittanbieter-Skripts optimieren: Wenn Drittanbieter-Skripts zur falschen Zeit geladen werden, kann dies erhebliche negative Auswirkungen auf die Leistung haben. Da es einige sehr gängige Drittanbieter gibt, prüfen wir, ob wir dafür einige Wrapper anbieten können, damit sie optimal mit Frameworks geladen werden und nicht den Hauptthread blockieren. Als Ausgangspunkt für diese Untersuchung verwenden wir die von uns erstellte Next.js-Skriptkomponente.

Entwickler können unseren Fortschritt auf dieser Website verfolgen.

In den Nachrichten

Bevor ich mich verabschiede, möchte ich Sie noch auf ein paar interessante Updates aus der Welt der Frameworks bei Google aufmerksam machen.

Im Juli gab das Chrome-Team die letzte Finanzierungsrunde in Höhe von 500.000 $für den Fonds für Frameworks und Tools bekannt, der Projekte zur Verbesserung der Leistung, Nutzererfahrung und Entwicklererfahrung im Web finanziert. Für die zukünftige Förderung werden neue Projekte berücksichtigt. Denken Sie daher daran, Ihre Anfrage zu senden.

Und natürlich passiert in der Community wirklich jede Menge Erstaunliches. Die Umgebung bietet zahlreiche neue Frameworks wie Fresh von Deno und großartige Erlebnisse wie das Onboarding-Tutorial von Svelte, das nicht nur eine browserinterne Demo ist, sondern auch die Web Container API verwendet, um Node.js nativ im Browser auszuführen. So viel gutes Zeug!

Ich bin wirklich begeistert, wie sich das Ökosystem zusammenstellt, das Mögliche im Browser voranbringt und Entwickler dabei unterstützt, Produkte zu entwickeln, die für alle funktionieren. Es sind spannende Zeiten für Webentwickler.

Bis zum nächsten Insider: „Hwyl Fawr“.

Wie hat Ihnen diese Ausgabe von „Chrome Dev Insider“ gefallen? Feedback geben