Optimierung des Ladens von JavaScript auf Wikipedia

Der Autor des Materials, dessen Übersetzung wir heute veröffentlichen, sagt, dass er Mitte September 2019 endlich das Projekt abgeschlossen hat, an dem er seit einem Jahr arbeitet. Das Ziel dieses Projekts war es, die Größe des Manifests zu reduzieren, das zum Initialisieren der asynchronen JavaScript-Pipeline von Wikipedia erforderlich ist. Die Manifestgröße betrug nämlich 36 Kb. Es musste in weniger als 28 KB passen, was zwei 14-Kilobyte-Fragmenten der Sequenz von Internet-Paketen entspricht.

Das Ergebnis dieses Projekts war eine tägliche Einsparung von 4,3 Terabyte Verkehr.


Zuerst überschritt die Manifestgröße 36 Kb, und nach der Optimierung wurde ihre Größe kleiner als 28 Kb

Die Grafik zeigt eine allmähliche Abnahme der Manifestgröße. Es handelt sich um komprimierte Daten (dh es ist die Nettolast im Netzwerk, die die Übertragung dieser Daten vom Server zum Browser bewirkt).

Optimierungsprozess

Das Initialisierungsmanifest wird durch Daten dargestellt, die nicht einfach zu optimieren sind. Der Großteil seines Codes ist keine funktionale Logik, die mit herkömmlichen Mitteln optimiert werden kann. Stattdessen wird fast das gesamte Manifest durch reine Daten dargestellt. Diese Daten werden automatisch vom ResourceLoader- Inhaltslieferungssystem generiert. Sie sind eine Registrierung von Modulpaketen. Wikipedia verwendet das ResourceLoader-System, um mit JavaScript-, CSS- und Textressourcen zu arbeiten.

Die Registrierung enthält Metadaten für alle auf Wikipedia bereitgestellten Front-End-Funktionen. Das Manifest listet die Namen der Bundles, ihre aktuellen Versionen und ihre Abhängigkeiten von anderen ähnlichen Bundles auf.

Ich suchte zunächst nach Code, der in der Praxis nie verwendet wurde ( T202154 ). Dies beinhaltete das Auffinden unvollständiger oder vergessener Codeteile im Zusammenhang mit älteren Funktionen. Der nicht verwendete Code wurde sofort entfernt, um die Kompatibilität mit Browsern zu gewährleisten, die unseren Test nicht mehr bestanden haben, wodurch sichergestellt wurde, dass sie in die Gruppe der modernen Browser ( Klasse A ) aufgenommen wurden. Ich habe auch ein Dokument über die Leistung beim Laden von Seiten vorbereitet. Dieses Dokument diente als Referenz, damit Entwickler die Auswirkungen von Änderungen verschiedener Typen auf die verschiedenen Phasen des Seitenladevorgangs verstehen können.

Reduzieren Sie die Anzahl der Module

Der nächste Schritt war die Zusammenarbeit mit den Ingenieurteams der Wikimedia Foundation und Wikimedia Deutschland. Wir mussten herausfinden, welche Funktionen des Systems eine übermäßige Anzahl von Modulen verwenden. Wenn man dies verstanden hat, wäre es beispielsweise möglich, zuvor verstreute Bündel zu kombinieren, aus denen eine bestimmte Funktionalität aufgebaut wurde. Solche Bündel werden auch in verstreutem Zustand immer zusammen geladen. Dies würde dazu führen, dass das System weniger Endpunkte enthält, deren Metadaten in der von ResourceLoader erstellten Registrierung gespeichert werden sollen.

Hier einige interessante Punkte zur Anwendung dieses Optimierungsansatzes:

• Die WikiEditor-Erweiterung enthält jetzt 11 Module weniger als zuvor. Weitere 31 Module wurden aus dem UploadWizard entfernt.
• Bei der Optimierung des ContentTranslation-Programms wurden 24 Module kombiniert.
• Das MobileFrontend-Projekt kombiniert 25 Module.
• 20 Module aus RevisionSlider und TwoColConflict entfernt.

Es ist auch sehr wichtig, dass der Wikidata-Client für Wikipedia optimiert wurde. Dieser Teil der Arbeit selbst war ein episches Projekt ( T203696 ). Für die Implementierung dieser Funktion waren zunächst 248 Einzelmodule verantwortlich. Nachdem wir mehr als 200 Module losgeworden waren, gab es nur 42 davon.

Das obige Diagramm zeigt die kleinen Verbesserungen, die im Laufe des Jahres am Projekt vorgenommen wurden. Sie alle haben uns dem Ziel näher gebracht. Ich möchte besonders zwei große Tropfen in der Größe des Manifests bemerken. Ein solcher Sturz ereignete sich in der ersten Augustwoche. Zu diesem Zeitpunkt wurde eine verbesserte Version von Wikidata bereitgestellt. Der zweite Größenabfall ist ganz am Ende des Diagramms zu sehen. Es geschah Mitte September. Jetzt möchte ich Ihnen von ihm erzählen.

Reduzieren Sie die Metadatengröße

Die Verbesserung des Manifests Mitte September wurde durch zwei globale Änderungen ermöglicht, die auf eine intelligentere Datenorganisation abzielten.

Die erste Verbesserung besteht darin, dass die Metadaten des EventLogging- Erweiterungsschemas früher Teil des Hauptmanifests waren. Dieser Mechanismus wurde überarbeitet, sodass Schemametadaten jetzt im JS-Bundle des EventLogging-Clients enthalten sind. Infolgedessen wurde der früher von EventLogging geleistete Beitrag zur Manifestgröße um mehr als 90% reduziert. Dies bedeutete, dass der kritische Pfad jetzt 2 KB weniger Daten enthält! Dies bedeutete außerdem, dass die Erweiterung der Funktionen von EventLogging nicht mehr zu einer Erhöhung der Manifestgröße führte. Beim Zusammenstellen solcher Bundles wurde eine neue Funktion von ResourceLoader, Paketdateien, verwendet . Diese Funktion wurde im Februar 2019 eingeführt. Einer der Gründe für das Interesse daran ist die Tatsache, dass sie dazu beitragen kann, die Anzahl der Module in der Registrierung zu verringern. Paketdateien vereinfachen das Kombinieren von generierten Daten und JavaScript-Code in einem einzigen Modul erheblich.

Die zweite Verbesserung trat auf, als wir die durchschnittliche Größe jedes Registrierungseintrags reduzierten ( T229245 ). Das Manifest enthält zwei Einträge für jedes Modul. Dies ist der Name des Moduls und die Kennung (ID) seiner Version. Die Versionskennung benötigte zuvor 7 Datenbytes. Nachdem wir im Zusammenhang mit ResourceLoader über das Geburtstagsparadox nachgedacht hatten, entschieden wir, dass das Wahrscheinlichkeitsspektrum für Versions-IDs sicher von 78 Milliarden auf „nur“ 60 Millionen reduziert werden kann. Details dazu finden Sie in den Codekommentaren . Um diese Verbesserung zusammenzufassen, können wir sagen, dass wir dadurch 2 Bytes in der Beschreibung jedes der 1.100 Module sparen konnten, die sich noch in der Registrierung befinden. Infolgedessen wurde die Größe des Manifests um weitere 2-3 Kb verringert.

Unten sehen Sie ein vergrößertes Fragment des Diagramms, das die letzten Betriebstage zeigt (diese Indikatoren stammen aus dem synthetischen Überwachungssystem, hier werden unkomprimierte Daten verwendet).


Manifest-Größenänderung in der letzten Phase eines Projekts

Die Änderung wurde vom ResourceLoader-Überwachungssystem erfasst. Der Screenshot zeigt das Fenster für die Größe des Startmanifests in einer öffentlichen Instanz von Grafana. Hier sehen Sie, dass die Größe des unkomprimierten Datenstroms um 2,8 KB verringert wurde.

Die Bereitstellung des Systems, die Mitte September stattfand, führte zur Erreichung des ursprünglichen Ziels, das Manifest auf eine Größe von nicht mehr als 28 KB zu komprimieren. Die Implementierung dieses Großprojekts führte dazu, dass das Initialisierungsmanifest um 9 KB reduziert wurde (es handelt sich um komprimierte Daten). Vor einem Jahr betrug diese Größe 36,2 KB, und nach Abschluss des Projekts waren es bereits 27,2 KB.

In Wikipedia und verwandten Projekten werden pro Minute etwa 363.000 Seitenaufrufe generiert. In einer Stunde - 21 Millionen und 800 Tausend. Täglich - 523 Millionen ( hier sind die Statistiken zu Seitenaufrufen). Diese Version des Systems, die Mitte September bereitgestellt wurde, führte zu Einsparungen von ungefähr 1,4 Terabyte Verkehr pro Tag. Und wenn Sie das, was heute ist, mit dem vergleichen, was es vor einem Jahr war, stellt sich heraus, dass jetzt täglich 4,3 Terabyte Verkehr gespeichert werden.

Was weiter?

Wir haben es geschafft, das 28-KB-Wikipedia-Initialisierungsmanifest anzupassen. Dies ist die Größe, die aufgrund der Tatsache gewählt wurde, dass es sich um die kleinste Größe handelt, die ein Vielfaches von 14 KB ist. Daten dieser Größe können in Fragmente der Sequenz von Internetpaketen abgelegt werden, die an den Browser übertragen werden.

Jetzt stehen wir vor einer neuen Aufgabe: Positionen nicht aufzugeben. Im letzten Jahr habe ich das Manifest genau beobachtet. Ich habe dies getan, um unsere Erfolge sicherzustellen und mögliche Probleme zu entdecken, die uns zurückziehen. Am Ende habe ich diesen Prozess mithilfe des öffentlichen Grafana-Dashboards automatisiert.

Wenn Sie diesem Panel glauben, haben wir immer noch viele Möglichkeiten, die Verpackung des Codes zu verbessern und Probleme zu lösen, die noch stärker sind als jetzt, und die Erstellung von Bundles zu erleichtern. Ich hoffe, dass diese bevorstehenden Verbesserungen für uns nützlich sein werden, aber wir arbeiten derzeit an neuen Systemfunktionen, während wir uns bemühen, die Anforderungen für das Niveau der Projektleistung zu erfüllen.

Liebe Leser! Haben Sie jemals an der Optimierung großer Internetprojekte teilgenommen?