Entwickler sagen uns oft, dass es schwierig ist, mit den Änderungen im Web Schritt zu halten und zu verstehen, warum diese Änderungen stattfinden. Heute starten wir eine neue Reihe namens Chrome Dev Insider, in der wir (1) Neuigkeiten und interessante Themen teilen, (2) Einblicke in unsere Entscheidungsprozesse zu wichtigen Themen geben (z. B. Änderungen an FLOC) oder unsere Arbeit im Chrome-Ökosystem beschreiben (z. B. Interop 2022) und (3) wirklich wichtige Dinge, die Sie wissen sollten (z. B. Änderungen an User-Agent-Strings).
Wir teilen unsere Pläne im Kontext unserer vier Prioritäten für 2022 mit:
- Eine ansprechende Nutzererfahrung ermöglichen: Sorgen Sie dafür, dass alles für Nutzer intuitiv ist, ganz gleich, ob es um Leistung, Transaktionen, Identität oder Übergänge geht.
- Funktionen des Webs verbessern:Unterstützung der sich wandelnden Rolle des Webs von einer Plattform zur Konsumierung von Inhalten zu einer Plattform für eine breite Palette von Anwendungen, einschließlich solcher, die eine umfassende Integration auf Betriebssystem- und Hardwareebene erfordern.
- Vereinfachte Webentwicklung:Erleichtert die Entscheidungsfindung und steigert die Produktivität der Entwickler.
- Datenschutz im Web verbessern:Die Erwartungen von Webnutzern an einen besseren Datenschutz erfüllen, angesichts der immer ausgefeilteren Tracking- und Targeting-Funktionen von Entwicklern.
In den Nachrichten: Interop 2022
Bei der Planung unserer Roadmaps berücksichtigen wir unter anderem das Feedback von Entwicklern, um die größten Herausforderungen und Anforderungen von Webentwicklern zu verstehen. Ein wichtiges Thema, das immer wieder auftaucht, ist die Browserkompatibilität, damit die Website in allen Browsern gleich funktioniert. Im letzten Jahr haben wir mit der Webentwicklungsbranche zusammengearbeitet, um dieses Thema im Rahmen unserer Priorität „Webentwicklung vereinfachen“ anzugehen.
Letztes Jahr haben Microsoft, Chrome und andere Akteure des Ökosystems Compat 2021 angekündigt. Im Rahmen dieses Programms haben alle gängigen Browser-Engines (Chromium, Gecko und Webkit) in den fünf wichtigsten Schwerpunktbereichen des Jahres eine Punktzahl von über 90% erreicht. Compat 2021 hat unter anderem zu einer soliden Grundlage für leistungsstarke Funktionen wie CSS Grid (12% Nutzung und stetig wachsender Anteil) und CSS Flexbox (77% Nutzung) geführt.
Im letzten Monat haben sich Apple, Bocoup, Google, Igalia, Microsoft und Mozilla als Unterstützer zusammengeschlossen, um die wichtigsten von Webentwicklern identifizierten Kompatibilitätsprobleme von Browsern zu lösen und sich auf einen gemeinsamen Benchmark zu einigen. Das Ergebnis ist Interop 2022, ein Projekt, mit dem die Plattform homogener werden soll. Der Benchmark konzentriert sich auf 15 Prioritätsbereiche, die von Entwicklern als entscheidend für die Verbesserung ihrer Produktivität eingestuft wurden.
Insiderinformationen: Zusammenarbeit mit anderen Browsern
Im Hinblick auf die Interop 2022 habe ich mich mit Robert Nyman und Philip Jägenstedt zusammengesetzt, die an diesen Gesprächen beteiligt waren, um mehr darüber zu erfahren. Hier ist der Editor-Cut, der zeigt, wie das Video entstanden ist.
Woher stammt diese Initiative?
Robert: Alles begann 2019 mit der MDN DNA 2019-Umfrage. Kompatibilitätsprobleme waren eindeutig das Hauptproblem für Entwickler, die für das Web entwickeln. Im MDN-Browserkompatibilitätsbericht 2020 haben wir uns ausführlicher mit diesem Thema befasst. So hatten wir genügend Informationen und umsetzbare Daten, um mit dem Compat 2021-Projekt zu beginnen. Dies wiederum führte dazu, dass wir diese Arbeit fortgesetzt und mit Interop 2022 erweitert haben.
Philip: Ich möchte auch web-platform-tests und State of CSS 2021 erwähnen. Wir arbeiten seit Jahren eng mit anderen Browseranbietern zusammen, um mit WPT zu testen. Das wollten wir unbedingt nutzen. Die Tests für diese Funktionen waren größtenteils bereits geschrieben. Wir mussten sie nur noch überprüfen und die fehlende Abdeckung ergänzen. Google hat viel in wpt.fyi investiert, aber wir haben auch Mozilla zu verdanken, dass WPT heute so erfolgreich ist. Mozilla hat natürlich auch einen großen Beitrag zu den MDN DNA-Umfragen geleistet. Außerdem gibt es den Bericht „State of CSS 2021“. Um eine Veranstaltung wie Interop 2022 zu organisieren, benötigen wir aktuelle Informationen zu den Anforderungen von Webentwicklern. Deshalb haben wir mit der Leiterin der Umfrage, Sacha, zusammengearbeitet, um einige neue Fragen zu Problemen mit der Browserkompatibilität aufzunehmen. Das hat uns bei der Planung von Interop 2022 sehr geholfen.
Haben Sie Erkenntnisse oder Feedback von Compat 2021?
Robert: Es war sehr hilfreich, die Leistung der einzelnen Browser-Engines zu messen und Bewertungen und Statistiken zu erhalten. So konnten wir den Fortschritt verfolgen und Probleme besprechen und beheben, die unklar waren oder priorisiert werden mussten. Außerdem haben wir schnell gemerkt, dass „Interop“ ein besserer Name für die Initiative ist. Die Begriffe Kompatibilität und Interoperabilität werden in der Regel von Browseranbietern unterschieden. Dabei bezieht sich „Kompatibilität“ auf die Websitekompatibilität und „Interoperabilität“ auf zwei oder mehr Browser, die sich gleich verhalten. In dieser Terminologie geht es bei diesem Projekt um Interoperabilität und daher wurde der Name entsprechend gewählt.
Was ist unsere Vision?
Robert:Damit das Web offen bleibt, ist Vielfalt bei Browsern und Rendering-Engines entscheidend. Leider hat das derzeit einen hohen Preis für unsere Entwickler, die mit unterschiedlichen Unterstützungsstufen für Funktionen in den einzelnen Suchmaschinen Schritt halten müssen. Wir möchten, dass Entwickler die Webplattform als die beste und attraktivste Option für ihre Anforderungen ansehen und sich darauf konzentrieren können, die bestmögliche Nutzererfahrung zu bieten, anstatt viel Zeit für die Behebung von Interoperabilitätsproblemen aufzuwenden. Und es ist ganz klar, dass die am häufigsten nachgefragten Funktionen in allen wichtigen Browser-Engines verfügbar sein müssen, damit Entwickler auf der Webplattform wirklich erfolgreich sein können.
Wie können wir gemeinsam vorankommen, wenn Browser mit (manchmal) unterschiedlichen Zielen zusammenkommen?
Philip: Wir haben nach Bereichen mit gemeinsamen Interessen gesucht, um Win-Win-Partnerschaften zu finden, bei denen die Ziele bereits grob übereinstimmen. Durch die Priorisierung einer begrenzten Anzahl von Dingen, an denen gleichzeitig gearbeitet werden soll, können wir uns auf diese Bereiche konzentrieren, schneller vorankommen und eine höhere Qualität erzielen, als wenn wir einfach getrennt arbeiten würden. Das ist die Idee.
Ich denke, es ist wichtig zu erkennen, dass dieser konsensbasierte Ansatz Grenzen hat. Wenn die Ziele nicht ausreichend übereinstimmen, müssen wir auf andere Weise vorgehen. Manchmal kann es hilfreich sein, mehr Nachweise zu den Anforderungen von Webentwicklern oder Nutzern vorzulegen. Letztendlich können Browseranbieter jedoch Funktionen einführen, die nicht allgemein akzeptiert werden. Im Idealfall wird der Wert der Funktion dann von Webentwicklern demonstriert, die die Funktion ausprobieren, feststellen, dass sie ihre Anforderungen erfüllt, und die gleiche Funktion in allen Browsern anfordern.
Kommen wir zurück zur Interop 2022: Werden wir in Zukunft auch Funktionen sehen, die nicht mit Design oder Layout zu tun haben?
Philip: Auf jeden Fall. Interop 2022 war nicht auf Stil- und Layoutfunktionen beschränkt, aber es wurde sehr stark auf CSS gesetzt. Teilweise, weil der State of CSS 2021 noch frisch war, aber auch, weil Webentwickler uns mitgeteilt haben, dass sie hier die größten Probleme mit Unterschieden zwischen Browsern haben. Mehrere Schwerpunktbereiche wie Formular- und Dialogelemente gehen über CSS hinaus. Außerdem untersuchen wir derzeit die Bearbeitung von APIs sowie Zeiger- und Mausereignisse. Ich hoffe, dass wir für Interop 2023 mehr aktuelle Daten zu den Anforderungen von Entwicklern im Web haben und weitere solcher Funktionen einbeziehen können.
Wichtige bevorstehende Änderungen
Ziel dieser Reihe ist es unter anderem, Entwickler auf bevorstehende wichtige Änderungen hinzuweisen, die für die Verbesserung der Nutzerfreundlichkeit und der Funktionen der Plattform wichtig sind.
Die unten genannten Zeitpläne geben an, wann wir mit diesen Änderungen rechnen. Es ist jedoch möglich, dass sich die Release-Versionen für Funktionen ändern.
User-Agent-Reduzierung
Die User-Agent-Header und die zugehörigen JS-Schnittstellen übertragen nicht nur nützliche Browser- und Geräteinformationen, sondern auch alte und fehlerhafte Informationen. Problematischer als die nahezu endlose Anzahl von UA-String-Parsing-Fehlern ist die Tatsache, dass der UA-String für alle Navigations- und untergeordneten Ressourcenanfragen passiv an die Server gesendet wird. Das entspricht etwa 10 Bit Entropie, mit denen Server stabile Tracking-IDs erstellen können, während Nutzer im Web surfen.
Derzeit planen wir, den vorhandenen UA-String zu reduzieren, indem wir weiterhin die Hauptversion des Browsers mit niedriger Entropie, den Plattformnamen und die Mobilität senden und die Informationen mit hoher Entropie einfrieren. Für Anwendungsfälle, die zusätzliche Informationen erfordern, die nicht im Header enthalten sind, bieten wir seit Chrome 89 die User-Agent Client Hints API an.
Wir haben 6 Monate lang einen Origin-Test durchgeführt, um das System zu testen und Feedback zu erhalten. Wir waren erfreut, dass wir trotz mehr als 200 Teilnehmern kein Feedback zu Abstürzen erhalten haben.
- Zeitplan:In Chrome 101 gehen wir mit Phase 4 voran: Die
MINOR.BUILD.PATCH
-Informationen im UA-String werden auf0.0.0
reduziert. Außerdem werden wir Websites weiterhin rechtzeitig informieren und ihnen Zeit geben, sich auf Phase 5 und darüber hinaus vorzubereiten. Außerdem haben wir Enterprise-Richtlinien erstellt, mit denen sich diese Änderungen deaktivieren lassen. Außerdem führen wir einen Test zur Einstellung bis Chrome 113 durch, um Websites mehr Zeit für die Vorbereitung zu geben. - Aufruf:Migrieren Sie Ihre Website zu UA-Clienthinweisen oder nehmen Sie am Test zur Einstellung teil.
Local Fonts Access API
In Chrome wird die Local Font Access API eingeführt. Websites können schon lange lokale Schriftarten verwenden. Diese API listet die Liste der lokalen Schriftarten auf und gewährt Zugriff auf die Schriftartdaten selbst. Mit dieser Funktion können Nutzer alle ihre Schriftarten für webbasiertes Design und andere Anwendungen verwenden.
Lokale Schriftarten sind seit langem als Vektor für Fingerprinting bekannt. Diese neue API erhöht zwar nicht die Möglichkeiten zur Verwendung von Schriftarten für Fingerprinting, in Chrome muss ein Nutzer jedoch eine neue "local-fonts"
-Berechtigung für eine Website gewähren, bevor die neue Local Font Access API verwendet werden kann.
Künftig soll dieselbe Berechtigung „local-fonts“ erforderlich sein, bevor eine andere API verwendet werden kann, die Zugriff auf lokale Schriftarten gewährt.
- Zeitplan:Ausrichtung auf Chrome 103 (Juni 2022)
- Aufruf:Weitere Informationen zur API und zur Nutzung, um mit der Implementierung zu beginnen.
BFCache mit Cache-control: no-store
verwenden
Wir haben eine erhebliche Verbesserungsmöglichkeit erkannt, wie oft der Back-Forward-Cache eine sofortige Navigation zurück und vorwärts ermöglichen kann. Dazu muss das Verhalten von BFCache auf Seiten geändert werden, die mit dem HTTP-Header „Cache-Control: no-store“ ausgeliefert werden. Wir haben einen öffentlichen Vorschlag, der dazu beitragen soll, unerwartete Ergebnisse zu vermeiden. Dazu werden verschiedene Signale überwacht (z. B. werden Seiten aus dem BFCache entfernt, wenn sich ein Nur-HTTP-Cookie ändert) und es gibt Ausnahmen (z. B. Gruppenrichtlinien für Enterprise-/Education-Kunden) für bestimmte Kontexte. Das ist eine komplexe, aber spannende Aufgabe. Wir würden uns über weitere Prüfungen und Feedback freuen.
- Zeitplan:Zielversion ist Chrome 104 (Juli 2022), sofern keine größeren Überraschungen auftreten.
- Aufruf:Weitere Informationen, z. B. dazu, wie Sie eine Implementierung in der Entwicklungsphase aktivieren und wie Sie Feedback geben können, z. B. zu tatsächlichen Szenarien, in denen unser Ansatz neue Hürden schaffen würde, finden Sie in diesem Vorschlag.
Mit dieser Reihe möchte ich unserer Entwickler-Community einen Einblick in mein Team und seine Arbeit geben. Wir halten dich auf dem Laufenden.
Bis dahin
Wie hat Ihnen die erste Ausgabe von The Chrome Dev Insider gefallen? Feedback geben