Chrome Dev Insider: Leistungsskalierung mit dem Framework-System

Paul Kinlan

Ich bin Paul Kinlan und leite die Developer Relations für Chrome. Im Rahmen meiner Arbeit arbeite ich mit einem Team von leidenschaftlichen Web-Advocates zusammen, die die Perspektive von Entwicklern aus der Praxis in unsere Produkt- und Engineering-Teams einbringen sollen. Das Ziel ist es, die Zufriedenheit von Entwicklern zu steigern.

Wir wissen, dass „Zufriedenheit“ eine anspruchsvolle und subjektive Messgröße ist, die es zu erfassen und zu verbessern gilt. Deshalb arbeiten wir ständig daran, wie wir uns auf die Bedürfnisse von Entwicklern konzentrieren und gleichzeitig etwas bewirken können. Ein Leitprinzip, das sich als nützlich erwiesen hat, ist: Entwickler dort abholen, wo sie sich befinden. Eine aktuelle Stack Overflow-Studie hat ergeben, dass 75% der Entwickler Frameworks oder eine Abstraktion verwenden. Wir haben uns gefragt, wie wir Entwickler am besten unterstützen können, die bereits Entscheidungen über ihren Tech-Stack getroffen haben oder keinen Einfluss darauf haben. Wie können wir sie produktiver machen, ohne den Aufwand zu erhöhen?

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

In der dritten 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 angegangen sind und was sie als Nächstes vorhaben.

Insider-Informationen: Zusammenarbeit mit Drittanbieter-Frameworks

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

Addy: Bei Aurora ging es darum, Entwickler dort abzuholen, wo sie sich gerade befinden, und ihnen zu helfen, ihr Ziel zu erreichen. Wir wollten ihnen beispielsweise helfen, die Leistung des von ihnen gewählten beliebten Tech-Stacks zu verbessern. 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 schier endlos. Anstatt von diesen Entwicklern zu erwarten, dass sie Experten (z. B. in Bezug auf die Leistung) werden, könnten wir dafür sorgen, dass sie standardmäßig mehr Best Practices in diese Stacks einbauen. So sind Websites mit besserer Qualität ein Nebeneffekt der Entwicklung für das Web.

Aurora wählt einige weit verbreitete Frameworks und Meta-Frameworks für die Zusammenarbeit aus. 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 über den Chrome Frameworks Fund zu skalieren. Es ist zwar möglich, die Qualität von Weboberflächen ü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 unserem Ziel, das Web für alle zu verbessern, ein Stück näher kommen.

Kara:Das Ziel ist, die Leistung im Web zu verbessern, indem wir die Entwicklerfreundlichkeit verbessern. 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, auf dem Laufenden zu bleiben. Sie haben ihre eigenen geschäftlichen Prioritäten, die wahrscheinlich Vorrang vor der Leistung haben.

Wenn Entwickler nur wenig Zeit für die Leistung haben, möchten wir es ihnen einfacher (und schneller) machen, eine leistungsstarke App zu entwickeln. Wenn wir mit beliebten Web-Frameworks zusammenarbeiten, befinden wir uns auf der richtigen Abstraktionsebene, um die Entwicklerfreundlichkeit durch Komponenten auf höherer Ebene, Konformitätswarnungen usw. zu verbessern. Jeder, der diese beliebten Tools verwendet, profitiert von diesen Vorteilen. Wenn sich die Empfehlungen ändern, können wir unsere Komponenten im Hintergrund aktualisieren und die Entwickler müssen sich nicht darum kümmern, auf dem neuesten Stand zu bleiben.

Houssein:Ich bin als Developer Advocate zu Google gekommen und habe einige Jahre später zu Software Engineering gewechselt. In meiner bisherigen Arbeit habe ich Webentwicklern die vielen verschiedenen Möglichkeiten gezeigt, wie sie eine großartige Nutzererfahrung schaffen können. Variationen derselben Anleitung wurden immer wieder bereitgestellt, um Entwickler vor den häufigen Problemen zu warnen, die sich wahrscheinlich auf die Leistung und Nutzerfreundlichkeit ihrer Websites auswirken. Als wir mit dem Aurora-Projekt begannen, fragten wir uns: Können wir in eine Richtung gehen, 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 Ingenieuren. Ich wette, dass du nicht mit jedem möglichen Framework oder jeder möglichen Bibliothek arbeiten kannst. Wie wählst du also aus, mit wem du zusammenarbeiten möchtest? Wer sind sie?

Addy:Das Web ist in vielerlei Hinsicht wie der Wilde Westen. Sie können so ziemlich jedes Framework, jeden Bundler, jede Bibliothek und jeden Drittanbieter verwenden, den Sie möchten. 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 verbessern, besteht darin, die Ebenen zu finden, die sich gut für die Aufnahme von Meinungen eignen, und ihnen weitere Meinungen hinzuzufügen.

Web-Frameworks wie Next.js, Nuxt.js und in gewissem Maße auch Angular versuchen beispielsweise, mehr Meinungen und Standardeinstellungen als eine selbst entwickelte Lösung zu integrieren. Das ist einer der Gründe, warum wir so gern mit ihnen zusammenarbeiten. In diesen Modellen sind stärkere Standardeinstellungen für das Laden von Bildern, Schriftarten und Skripten sinnvoll, um bessere Core Web Vitals zu erzielen.

Außerdem lässt sich so gut nachvollziehen, wo moderne Best Practices funktionieren oder überdacht werden müssen. Das kann dazu beitragen, das gesamte Ökosystem darüber zu informieren, wie Optimierungsprobleme gelöst werden können.

Kara:Realistisch betrachtet müssen wir auch die Beliebtheit berücksichtigen. Wenn wir die größtmögliche Wirkung auf das Web erzielen möchten, ist es ideal, mit Frameworks und Bibliotheken zu arbeiten, die eine große Community von Entwicklern 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, wie meinungsstark eine Bibliothek ist, 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 drei wichtigsten Frameworks. Wir arbeiten jedoch am häufigsten mit Next.js, Nuxt und Angular. Das liegt daran, dass sich Ansichtsbibliotheken wie React und Vue hauptsächlich auf das Rendern konzentrieren. Daher ist es unmöglich, alle gewünschten Funktionen direkt in sie einzubauen. Deshalb arbeiten wir enger mit Meta-Frameworks zusammen, die auf diesen Frameworks basieren: 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.

Angular war auf dieser Liste der engen Partnerschaften, ist aber kein Meta-Framework. Angular ist insofern ein Sonderfall, als es sehr beliebt ist, aber kein Meta-Framework wie React und Vue hat. Daher arbeiten wir direkt mit dem Angular-Team zusammen und stellen Funktionen über die CLI bereit, sofern möglich.

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

Wie sieht das in der Praxis aus? Wie sind Sie bei der Lösung dieses Problems vorgegangen?

Kara:In der Praxis arbeiten wir eng mit einigen Frameworks zusammen. Wir werden uns etwas Zeit nehmen, um Apps mit diesem Framework zu analysieren und die häufigsten Leistungsprobleme zu ermitteln. Anschließend arbeiten wir mit dem Framework-Team zusammen, um experimentelle Funktionen zu entwickeln, die diese Probleme beheben. Außerdem stellen wir Code direkt für das OSS-Repository bereit, um die Funktionen zu implementieren.

Es ist uns sehr wichtig, zu überprüfen, ob die Leistungseinbußen unseren Prognosen entsprechen. Deshalb arbeiten wir auch mit externen Unternehmen zusammen, um Leistungstests in der Produktion durchzuführen. Wenn die Ergebnisse vielversprechend sind, helfen wir dabei, die Funktion in den Status „stabil“ zu bringen und sie möglicherweise zur Standardeinstellung zu machen.

Das kann doch nicht so einfach sein, wie du es darstellst. Was waren einige der Herausforderungen oder Erkenntnisse, die du bisher hattest?

Houssein:Eine wichtige Sache, die wir so gut wie möglich zu bewältigen versuchen, ist die Beteiligung an beliebten Open-Source-Repositories, in denen viele konkurrierende Prioritäten bestehen. Nur weil wir ein Google-Team sind, heißt das nicht, dass unsere Funktionen automatisch priorisiert werden. Wir versuchen, uns so gut wie möglich an den typischen Prozess der Vorschläge und der Einführung neuer Funktionen zu halten, ohne jemandem auf die Füße zu treten. Wir hatten das Glück, mit aufgeschlossenen Maintainern in den Next.js-, Nuxt- und Angular-Ökosystemen zusammenzuarbeiten. Wir sind dankbar, dass sie offen für unsere Bedenken bezüglich des Web-Ökosystems waren und bereit sind, auf verschiedene Weise mit uns zusammenzuarbeiten.

Bei vielen der Frameworks, mit denen wir arbeiten, ist unser übergeordnetes Ziel dasselbe: Wie können Entwickler eine verbesserte Nutzererfahrung erzielen und gleichzeitig eine gute Entwicklererfahrung haben? Wir wissen, dass es Hunderte, wenn nicht Tausende von Community-Beitragenden und Framework-Maintainern gibt, die jeweils an verschiedenen Projekten arbeiten, die sich überschneiden.

Kara:Da wir die Auswirkungen auf die Leistung validieren und auf Grundlage von Daten handeln möchten, dauert der Prozess etwas länger. Wir befinden uns auf unbekanntem Terrain. Daher kann es vorkommen, dass wir mit einer Optimierung experimentieren, die nicht funktioniert, und wir eine geplante Funktion nicht entwickeln. Selbst wenn sich eine Funktion bewährt, kosten die zusätzlichen Schritte zur Überprüfung der Leistung Zeit und verlängern die Zeitpläne.

Auch die Suche nach Produktionspartnern zum Testen unserer Funktionen kann schwierig sein. Wie bereits erwähnt, sind das Unternehmen mit eigenen Prioritäten. Es kann daher schwierig sein, neue Initiativen zu integrieren, wenn sie nicht gut mit bestehenden Projekten übereinstimmen, die Vorrang haben. Außerdem sind die Unternehmen, die am meisten daran interessiert sind, zu helfen, in der Regel bereits in die Leistung investiert, sodass sie nicht wirklich unsere Zielgruppe sind. Wir versuchen, Feedback von einem großen Teil der Community zu erhalten, der nicht in die Leistung investieren kann, aber am wenigsten wahrscheinlich ist, dass sie sich an uns wenden.

Auf welche Optimierungen haben Sie sich konzentriert?

Houssein:Nach der Analyse Tausender von Anwendungen haben wir festgestellt, dass die größten Leistungsprobleme in der Regel auf Anti-Patterns im Anwendungscode und nicht auf das Framework selbst zurückzuführen sind. Beispiele hierfür sind das Senden unnötig großer Bilder, das zu späte Laden benutzerdefinierter Schriftarten, das Abrufen zu vieler Drittanbieteranfragen, die den Hauptthread blockieren, und das Nichtbeachten, wie 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. Wir haben uns daher gefragt, ob wir einige Standardoptimierungen einbauen können, die diese Probleme gut bewältigen, aber gleichzeitig eine gute Entwicklerfreundlichkeit bieten und sich gut in die Framework-Tools einfügen.

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:

Kannst du uns einige positive Ergebnisse deiner Arbeit mit einigen dieser Akteure nennen?

Houssein:Viele Websites haben aufgrund der von uns eingeführten Optimierungen eine Leistungssteigerung erfahren. Eines meiner Lieblingsbeispiele ist Leboncoin. Das Unternehmen konnte seinen LCP von 2,4 Sekunden auf 1,7 Sekunden reduzieren, nachdem es zur Next.js-Bildkomponente gewechselt war. Viele weitere befinden sich derzeit in der Testphase. Wir werden hier weiterhin Erkenntnisse und Erfolge teilen.

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

Addy:Viele der Leistungsoptimierungen, an denen Aurora mitarbeitet, können von jedem Framework repliziert werden. Ein Blick hinter unsere Bemühungen für die Bild- oder Script-Komponente zeigt beispielsweise, dass sie oft eine Reihe bestehender Best Practices kodifizieren. Wir versuchen, das Erstellen solcher Komponenten und ihr Aussehen in den einzelnen Frameworks zu dokumentieren. Das ist hoffentlich ein guter Anfang für die Umsetzung der Idee.

Wir haben gute Erfahrungen damit gemacht, Erkenntnisse aus einem Ökosystem (z. B. React und Next.js) auf andere zu übertragen. Beispiele hierfür sind die neue Angular Image Directive (die auf unseren Erkenntnissen beim Erstellen der Next.js Image Component basiert) oder Gatsby, das unseren Ansatz für das granulare JavaScript-Chunking verwendet.

Gleichzeitig wissen wir, dass nicht jedes Framework die Bandbreite oder Finanzierung für Mitwirkende hat, um ähnliche Leistungsfunktionen zu entwickeln oder in andere Optimierungen zu investieren, die sie für ihre Nutzer als wichtig erachten. Mit dem Chrome Web Frameworks Fund möchten wir Leistungsverbesserungen im JavaScript-Ökosystem fördern, damit Projekte ihre Mitwirkenden bezahlen können und Leistungsverbesserungen im Ökosystem weiter skaliert werden können.

Was steht als Nächstes auf der Roadmap Ihres Teams?

Kara:Wir haben viele spannende Projekte vor uns. Nachfolgend werden einige der Änderungen aufgeführt:

  • CLS im Zusammenhang mit Schriftarten reduzieren:Es ist relativ häufig, dass es zu Layoutverschiebungen kommt, wenn eine Web-Schriftart geladen wird und die Fallback-Schriftart ersetzt. Wir prüfen, ob wir Schriftart-Messwertüberschreibungen und die „size-adjust“-Eigenschaft verwenden können, um den CLS-Wert, der mit Schriftarten zusammenhängt, in Next.js standardmäßig zu reduzieren. Wir haben uns auch mit dem Nuxt-Team beraten und planen, diese Idee im nächsten Jahr auf weitere Frameworks auszuweiten.
  • INP-Fehlerbehebung:Nachdem der Messwert Interaction to Next Paint (INP) veröffentlicht wurde, arbeiten wir mit Frameworks zusammen, um die häufigsten Ursachen von INP-Problemen für ihre Communities zu untersuchen und Korrekturen vorzuschlagen. Wir arbeiten eng mit Angular zusammen und hoffen, bald Ergebnisse präsentieren zu können.
  • Häufig verwendete Drittanbieter-Skripts optimieren:Wenn Drittanbieter-Skripts zum falschen Zeitpunkt geladen werden, kann sich das erheblich negativ auf die Leistung auswirken. Da einige 3Ps sehr häufig vorkommen, prüfen wir, ob wir einige Wrapper dafür anbieten können, damit sie optimal mit Frameworks geladen werden und den Hauptthread nicht blockieren. Wir verwenden die von uns entwickelte Next.js-Script-Komponente als Ausgangspunkt für diese Untersuchung.

Entwickler können unseren Fortschritt auf dieser Website verfolgen.

In den Nachrichten

Bevor ich mich verabschiede, 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 Frameworks and Tools Fund angekündigt. Dieser Fonds konzentriert sich auf die Finanzierung von Projekten, die darauf abzielen, die Leistung, Nutzerfreundlichkeit und Entwicklerfreundlichkeit im Web zu verbessern. Bei der zukünftigen Finanzierung werden neue Projekte berücksichtigt. Reichen Sie daher Ihren Antrag ein.

Und natürlich gibt es auch eine MENGE toller Dinge, die in der Community passieren. Das Ökosystem bietet viele neue Frameworks wie Fresh von Deno und tolle Funktionen wie das 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 sehr, dass das Ökosystem zusammenwächst, die Möglichkeiten im Browser erweitert und Entwicklern hilft, Produkte zu entwickeln, die für alle funktionieren. Es ist eine aufregende Zeit für Webentwickler.

Bis zum nächsten Insider, Hwyl fawr.

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