AutoWebPerf
1.0.0
AutoWebPerf bietet ein flexibles und skalierbares Framework für das Ausführen von Web -Performance -Audits mit willkürlichen Prüftools wie WebPagetest und PageSpeedInsights. Diese Bibliothek ermöglicht es Entwicklern, Metriken konsequent zu sammeln und Metriken in einem bevorzugten Datenspeicher wie lokalen JSON-Dateien, Google-Blättern, BigQuery oder einer internen SQL-Datenbank zu speichern.
Schauen Sie sich https://web.dev/autowebperf zur Einführung an.
AutoWebPerf enthält eine Liste von Tests von einer beliebigen Datenspeicherplattform wie lokalen Jsons, Google Sheets, BigQuery oder einer selbst gehosteten SQL-Datenbank. Mit der Liste der Tests wird Audits basierend auf jeder Testkonfiguration ausgeführt und Metriken aus einzelnen Datenquellen in eine Liste von Ergebnissen erfasst.
Der Prozess der Ausführung einer Prüfung über ein Messwerkzeug (z. B. WebPagetest) wird im einzelnen Sammler definiert. Die Logik des Lesens und Schreibens mit einer Datenplattform (z. B. lokaler JSON) wird in einem Connector implementiert.
src/connectors/csv-connector .)AutoWebPerf dient als Leistungsprüfungsaggregator, der den Prozess der Leistungsprüfung und der Sammlung von Metriken über mehrere Geschwindigkeitsmesswerkzeuge wie WebPagetest, PageSpeedInsights und Chrome UX -Bericht automatisiert. Da jedes individuelle Geschwindigkeitsmesswerkzeug Prüfungsmetriken bietet, aggregiert AutoWebPerf die Ergebnisse und schreibt auf eine beliebte Datenspeicherplattform wie lokale Jsons, Cloud-basierte Datenbank oder GoogleSheets.
Zunächst klonen AWP Repo und führen Sie die NPM -Installation aus:
git clone https://github.com/GoogleChromeLabs/AutoWebPerf.git
npm install
Überprüfen Sie nach Abschluss die Installation, indem Sie einen einzelnen Test mit dem folgenden Befehl ausführen:
./awp run examples/tests.json output/results.json
Dieser Befehl verwendet die Beispieldatei in examples/tests.json und gibt die Ergebnisse in output/results.json zurück.
Um wiederkehrende Tests zu starten, müssen Sie eine recurring.frequency Eigenschaft in die Testdatei einbeziehen und den nächsten Auslöser in der Testdatei festlegen. Verwenden Sie diesen Befehl, um die nächste Auslöserzeit einzustellen und einen recurring.frequency Test auszuführen.
./awp recurring examples/tests-recurring.json output/results.json
Wenn dies erfolgreich wäre, hat die Auslöserzeit die Basis auf Ihrer gewählten Häufigkeit aktualisiert, und ein Ergebnis wäre in output/results.json geschrieben worden.
Sobald die Auslöserzeit korrekt eingestellt ist, können Sie Ihre Tests mit dem Befehl continue automatisch mit dem nächsten Triger-Zeit-TRIGER-Zeit übertragen lassen:
./awp continue examples/tests-recurring.json output/results.json
Dadurch wird jeder Test automatisch mit der angegebenen Frequenz ausgeführt. Weitere Informationen finden Sie unten im Abschnitt "Wiederkehrende Tests rennen".
Einzelne URL: Um eine einzelne URL durch PageSpeedInsights zu testen:
./awp run url:https://www.thinkwithgoogle.com/ json:output/results.json
Wählen Sie Sammel: Um eine einzelne URL mit einem bestimmten Sammler wie PageSpeedInsights oder WebPagetest zu testen:
./awp run --gatherers=psi url:https://web.dev json:output/results.json
CSV -Datei: Um Tests auszuführen, die in einer CSV -Datei definiert sind und Ergebnisse in eine JSON -Datei schreiben:
./awp run csv:examples/tests.csv json:output/results.json
PageSpeedInsights -API: Ausführen von PageSpeedInsights -Tests mit einem API -Schlüssel:
PSI_APIKEY=SAMPLE_KEY ./awp run examples/tests.json output/results.json
WebPagetest -API: Ausführen von WebPagetest -Tests:
WPT_APIKEY=SAMPLE_KEY ./awp run examples/tests-wpt.json output/results.json
Überschreiben im Vergleich zum Anhang: Ausführen von Tests und Überschreiben vorhandener Ergebnisse in der Ausgabedatei
./awp run examples/tests.json output/results.json --override-results
./awp run examples/tests.json output/results.json
Alternativ, um die Verwendung des JSON -Anschlusses für den Tests und den Results anzugeben:
./awp run json:/examples/tests.json json:output/results.json
Tests und den Results anzugeben: ./awp run csv:/examples/tests.csv csv:output/results.csv
Test mit einer bestimmten URL für die Prüfung. Um ein Audit mit nur einem Test mit einer bestimmten URL durchzuführen: ./awp run url:https://example.com csv:output/results.csv
Bitte beachten Sie, dass dieser Anschluss nur mit Tests und nicht für den Results funktioniert.
Sie können Folgendes jederzeit ausführen, um die CLI -Verwendungen zu drucken:
./awp --help
Um Tests auszuführen, können Sie den folgenden CLI -Befehl mit gegebenen Tests JSON ausführen, z. B. examples/tests.json , das eine Reihe von Tests enthält. Sie können die examples/tests.json für die Datenstruktur von Tests überprüfen.
./awp run examples/tests.json output/results.json
Dadurch werden die Ergebnisobjekte (en) im angegebenen Pfad zu results.json generiert.
Standardmäßig verwendet AWP JSON als Standardanschluss sowohl zum Lesen von Tests als auch zum Schreiben von Ergebnissen. Alternativ können Sie einen anderen Anschluss im Format von <connector>:<path> angeben.
EG, um Tests auszuführen, die in CSV definiert sind und Ergebnisse in JSON schreiben:
./awp run csv:examples/tests.csv json:output/results.csv
Für einige Audit -Plattformen wie WebPagetest kann jeder Test einige Minuten dauern, bis die tatsächlichen Ergebnisse erzielt werden. Für diese Art von asynchronen Audits bleibt jedes Ergebnis im Status "eingereicht". Sie müssen die Ergebnisse später explizit abrufen.
Führen Sie Folgendes aus, um die endgültigen Metriken der Ergebnisse in den results.json abzurufen. JSON.
./awp retrieve examples/tests.json output/results.json
Dadurch werden Metriken für alle Audit -Plattformen abgerufen und das Ergebnisobjekt in der output/results.json aktualisiert. Sie können examples/results.json für Details in Ergebnisobjekten überprüfen.
Wenn Sie wiederkehrende Tests einrichten möchten, können Sie das recurring Objekt definieren, das frequency für diesen Test enthält.
./awp recurring examples/tests-recurring.json output/results.json
Dies generiert das Ergebnisobjekt in den results.json und aktualisiert die nächste Auslöserzeit in seinem ursprünglichen Testobjekt in den tests.json . Z. B. das aktualisierte Testobjekt würde wie das folgende aussehen, mit dem aktualisierten nextTriggerTimestamp .
{
"label": "web.dev",
"url": "https://web.dev",
"recurring": {
"frequency": "Daily",
"nextTriggerTimestamp": 1599692305567,
"activatedFrequency": "Daily"
},
"psi": {
"settings": {
"locale": "en-GB",
"strategy": "mobile"
}
}
}
Der nextTriggerTimestamp wird basierend auf dem vorherigen Zeitstempel auf den nächsten Tag aktualisiert. Dies soll wiederholte Läufe mit demselben Test verhindern und sicherstellen, dass dieser Test nur einmal pro Tag durchgeführt wird.
In den meisten Unix-ähnlichen Betriebssystemen können Sie einen Cron-Job einrichten, um die AWP CLI regelmäßig auszuführen.
In macOS können Sie beispielsweise die folgenden Befehle ausführen, um einen täglichen Cron -Job mit AWP einzurichten:
# Edit the cronjob with a text editor.
EDITOR=nano crontab -e
Fügen Sie die folgende Zeile zum täglichen Lauf um 12:00 Uhr um 12:00 Uhr hinzu. Beachten Sie, dass dies auf der Systemzeit basiert, in der es AWP ausführt.
0 12 * * * PSI_APIKEY=SAMPLE_KEY cd ~/workspace/awp && ./awp run examples/tests.json csv:output/results-recurring.csv
Eine Erweiterung ist ein Modul, mit dem AWP beim Ausführen von Tests mit zusätzlichem Prozess und Berechnung unterstützt wird. Beispielsweise kann budgets -Erweiterung Leistungsbudgets hinzufügen und das Delta zwischen den Zielen und den Ergebnismetriken berechnen.
Mit Erweiterungen laufen:
./awp run examples/tests.json output/results.json --extensions=budgets
Die Liste der Tests ist einfach eine Reihe von Testobjekten, wie die folgenden Beispieltests. Oder lesen Sie src/examples/tests.js für ein detailliertes Beispiel für die Testliste.
[{
"label": "Test-1",
"url": "example1.com",
"webpagetest": {
...
}
}, {
"label": "Test-2",
"url": "example2.com",
"psi": {
...
}
}]
Jedes Test definiert, welche Audits durch Definieren gatherers durchgeführt werden sollen. Der erste Test verfügt beispielsweise über eine webpagetest -Eigenschaft, die die Konfiguration des Ausführens eines WebPagetest -Audits definiert. Der zweite Test verfügt über eine psi -Eigenschaft, die definiert, wie das PageSpeedInsights -Audit ausgeführt wird.
Nach dem Ausführen von Tests wird eine Liste von Results wie unten generiert. Jedes Result enthält seine entsprechenden Metriken an die vordefinierten gatherers wie WebPagetest und PageSpeedInsights. Siehe das Beispiel unten.
[{
"label": "Test-1",
"url": "example1.com",
"webpagetest": {
"metrics": {
FirstContentfulPaint: 900,
...
}
}
}, {
"label": "Test-2",
"url": "example2.com",
"psi": {
"metrics": {
FirstContentfulPaint: 900,
...
}
}
}]
Einige Conenctors oder Sammler benötigen möglicherweise eine oder mehrere Umgebungsvariablen wie API -Schlüssel oder den Pfad zum Servicekonto. Das Laufen mit dem Crux -API -Sammler erfordert beispielsweise die Crux -API -Schlüssel.
Führen Sie den Befehl mit der regelmäßigen Verwendung von Umgebungsvars aus, um die Umgebungsvariablen in der CLI zu übergeben:
CRUX_APIKEY=<YOUR_KEY> ./awp run url:https://wev.dev/ json:output/results.json
AWP unterstützt die folgenden Prüfungssammler. Bitte lesen Sie die entsprechenden Dokumentationen für Details.
Der WebPagetest -Sammel führt Tests entweder über die öffentlichen WebPagetest -Endpunkte oder eine benutzerdefinierte private WebPagetest -Instanz aus.
Weitere Informationen zur Verwendung von WebPagetest -Sammler finden Sie unter DOCS/WebPagetest.md.
Der PageSpeed Insights -Sammler führt Tests über die öffentliche PageSpeed Insights -API durch.
Weitere Informationen zur Verwendung des PSI -Sammlers finden Sie unter docs/psi.md.
Der CRUX API -Sammler sammelt Leistungsmetriken über die Chrome UX -Berichts -API.
Weitere Informationen zur Verwendung des CRUX -API -Sammlers finden Sie unter docs/cruxapi.md.
Der CRUX BigQuery -Sammel sammelt mit seinem öffentlichen Google BigQuery -Projekt Leistungsmetriken im Rahmen des Chrome UX -Berichts. Bitte noet, dass Sie ein Google Cloud -Projekt einrichten müssen, um die öffentliche BigQuery -Tabelle abzufragen.
Weitere Informationen zur Verwendung des CRUX -API -Sammlers finden Sie unter docs/cruxbigQuery.md.
AWP ist mit Modulen entwickelt, einschließlich Modulen zum Ausführen von Audits mit WebPagetest, PageSpeedInsights oder anderen Tools sowie Modulen zum Lesen/Schreiben von Daten von Datenplattformen wie JSON, GoogleSheets oder einem Cloud -Dienst.
In einer hochrangigen Ansicht gibt es drei Arten von Modulen:
Die AWP -Engine verwendet zwei wichtige JavaScript -Objektstrukturen, um Audits auszuführen und Metriken zu sammeln.
examples/tests.json für ein tatsächliches Testobjekt beziehen.examples/results.json beziehen. JSON für ein tatsächliches Ergebnisobjekt.Um mit einem asynchronen Audit -Tool wie WebPagetest umzugehen, unterteilt AWP den Prüfungszyklus in drei Schritte von Aktionen:
Tests und generiert eine Liste von Results .Tests , generiert eine Liste von Results und aktualisiert NextTriggertimestamp für jeden wiederkehrenden Test . Diese Aktion ist nützlich, wenn sie mit periodischen oder zimerbasierten Aufgaben wie Cron-Job ausgeführt werden.Retrieved Status sind.Um Module und deren Konfigurationen einzurichten, ist als JavaScript -Objekt eine AWP -Konfiguration erforderlich.
AWP -Konfiguration hat die folgenden erforderlichen Eigenschaften:
connector : Der Name des Steckers.helper : Ein Helfer für einen bestimmten Anschluss, einschließlich API -Handler und anderen Helferfunktionen, die in Sammlern und Erweiterungen verwendet werden.dataSources : Eine Reihe von Prüfungsquellen wie webpagetest oder psi . Jede der Datenquelle muss eine entsprechende Sammeldatei im Ordner src/gatherers haben.extensions : Eine Reihe von Erweiterungen. Jede Erweiterung muss eine entsprechende Erweiterungsdatei in src/extensions haben.Andere optionale Eigenschaften:
verbose : Ob Sie ausführliche Nachrichten drucken sollen.debug : Ob Debug -Nachrichten drucken sollen. Das folgende Konfigurationsbeispiel stammt aus den examples/awp-config.js :
{
connector: 'JSON',
helper: 'Node',
dataSources: ['webpagetest'],
json: { // Config for JSON Connector.
tests: 'tests.json',
results: 'results.json',
},
extensions: [
'budgets',
],
budgets: { // Config for Budgets extension.
dataSource: 'webpagetest',
},
verbose: true,
debug: false,
}
Mit der obigen Beispielkonfiguration wird JSON -Connector verwendet, der Tests und Ergebnisse als JSON -Dateien liest und schreibt. examples/tests.json und examples/results.json finden Sie für Beispiele.
Zusätzlich zu grundlegenden Eigenschaften gibt es einige zusätzliche Eigenschaften, die von Modulen verwendet werden:
json -Eigenschaft als Konfiguration für JsonConnector .budgets als Konfiguration für BudgetSextensionBeispiele für die Erstellung einer neuen Instanz von AWP:
let awp = new AutoWebPerf({
connector: 'JSON',
helper: 'Node',
dataSources: ['webpagetest'],
extensions: extensions,
json: { // Config for JSON connector.
tests: argv['tests'],
results: argv['results'],
},
verbose: verbose,
debug: debug,
});
Alle Tests einreichen:
awp.run();
Um bestimmte Tests mit Filtern einzureichen: Dadurch wird der Test mit ID = 1 und ausgewählt = echte Eigenschaften durchgeführt.
awp.run({
filters: ['id="1"', 'selected'],
});
Um alle anstehenden Ergebnisse abzurufen, filtern Sie mit Status! == "abgerufen".
awp.retrieve({
filters: ['status!=="Retrieved"'],
});
src/utils/pattern-filter.js mit weiteren Beispielen.Wiederkehrende Tests durchführen:
// This will run the actual audit and update the nextTriggerTimestamp.
awp.recurring();
Tests mit spezifischen Erweiterungen ausführen:
// This will override the extension list defined in the awpConfig.
awp.run({
extensions: ['budgets']
})
Eine Sammelklasse erweitert src/gatherers/gatherer.js und überschreibt die folgenden Methoden:
constructor(config, apiHelper, options) :
config : Die in einer Eigenschaft mit dem Namen dieses Sammlers in der AWP -Konfiguration definierte Konfiguration. Einige Audit -Tools wie WebPagetest oder PageSpeedInsights erfordern API -Schlüssel. Der API -Schlüssel für den Sammler befindet sich in der config.apiKey .options : Zusätzliche Einstellungen wie verbose und debug . run(test, options) :
test : Ein Test für diesen Audit -Lauf. Die für diesen Sammler erforderlichen Daten (z. B. Einstellungen oder Metadaten) befinden sich in der Immobilie mit dem Namen des Sammlers. ZB Die Daten für WebPagetest befinden sich in webpagetest dieses Test .options : Zusätzliche Einstellungen. retrieve(result, options) :
result : Ein Result zum Abrufen von Metriken mit. Die für diesen Sammler erforderlichen Daten werden mit dem Namen des Sammlers in der Immobilie sein. ZB Daten und Metriken befinden sich in webpagetest dieses Result .options : Zusätzliche Einstellungen wie verbose und debug . Eine Connector -Klasse erweitert src/connectors/connector.js und überschreibt die folgenden Methoden:
constructor(config, apiHandler) :
config : Die Konfiguration in einer Eigenschaft mit dem Namen dieses Connectors in der AWP -Konfiguration definiert.apiHandler : Die API -Handlerinstanz, die zum Tätigen von API -Aufrufen verwendet wird. getConfig() : Die Methode, um das zusätzliche Konfigurationsobjekt des Connectors zurückzugeben. Dieses Konfigurationsobjekt hängt davon ab, wo dieser Connector seine zusätzlichen Einstellungen, einschließlich API -Schlüssel für Sammler, speichert. Beispielsweise verwendet JsonConnector die tests.json und liest zusätzliche Einstellungen aus der config , einschließlich API -Schlüssel für jeden Sammler.
getTestList(options) : Die Methode, um die Liste der Tests als Array zurückzugeben.
updateTestList(newTests, options) : Die Methode zum Aktualisieren Tests in der Liste der neuen Tests .
getResultList(options) : Die Methode zur Rückgabe der Results als Array.
appendResultList(newResults, options) : Die Methode, um neue Results am Ende der aktuellen Results anzuhängen.
updateResultList(newResults, options) : Die Methode zum Aktualisieren vorhandener Results in der aktuellen Results .
Eine Erweiterungsklasse erweitert src/extensions/extension.js und überschreibt die folgenden Methoden:
constructor(config) :config : Die in einer Eigenschaft mit diesem Erweiterungsnamen in der AWP -Konfiguration definierte Konfiguration.beforeRun(context) : Die Methode vor der Ausführung von Ausführen Schritt für einen Test .context.test : Das entsprechende Test .afterRun(context) : Die Methode nach der Ausführung von Ausführungsschritt für einen Test .context.test : Das entsprechende Test .context.result : Das entsprechende Result .beforeAllRuns(context) : Die Methode vor der Ausführung von Laufschritt .context.tests : Alle Test in diesem Lauf .afterAllRuns(context) : Die Methode nach Ausführung von Auslaufschritt .context.tests : Alle Test in diesem Lauf .context.results : Alle Result in diesem Lauf .beforeRetrieve(context) : Die Methode vor dem Ausführen von Schritt für ein Result .context.result : Das entsprechende Result .afterRetrieve(context) : Die Methode nach Ausführen des Durchführens von Schritt für ein Result .context.result : Das entsprechende Result .beforeAllRetrieves(context) : Die Methode vor der Ausführung von Schritt.context.result : Das entsprechende Result .afterAllRetrieves(context) : Die Methode nach Ausführen von Schritten.context.result : Das entsprechende Result . Ein Standard Test enthält die folgenden Eigenschaften:
(Sie können für ein Beispiel auf examples/tests.json verweisen.)
selected : Ob Sie für diesen Test ausgeführt werden sollen.label : Name dieses Test .url : URL zu Prüfung.recurring : Einstellungen für wiederkehrende Prüfung.frequency : Die in src/common/frequency.js definierte Frequenzzeichenfolge. ZB "täglich", "wöchentlich" oder "monatlich".Sammelspezifische Einstellungen werden in ihrem eigenen Eigentum mit dem Namen des Sammlers im unteren Fall sein. Beispielsweise sind die Einstellungen für WebPagetests :
webpagetestsettings : Das Einstellen von Objekten enthält Prüfungsspeicherort, Verbindung usw.metadata : Metadata -Objekt enthält die ID von WebPagetests, JSON -URL usw. Ein Standard Result enthält die folgenden Eigenschaften:
selected : Ob dieses Result abgerufen werden soll.id : Automatisch generierte eindeutige ID für dieses Result .type : Single oder Recurring Prüfung.status : Submitted , Retrieved oder Error . Einzelheiten finden Sie in src/common/status.js .label : String -Etikett für dieses Result . Dieses Etikett erbt von ihrem ursprünglichen Test .url : Auditierte URL.createdTimestamp : Wenn dieses Result erstellt wird.modifiedTimestamp : Wenn dieses Result zuletzt geändert wird. Alle in AWP verwendeten metrischen Namen sind erforderlich, um die Namensempfindungen zu befolgen. Siehe die vollständige Liste der standardisierten Metriken in src/common/metrics.js
Zeitmetriken
TimeToFirstByteFirstPaintFirstMeaningfulPaintFirstContentfulPaintVisualCompleteSpeedIndexDOMContentLoadedLoadEventTimeToInteractiveTotalBlockingTimeFirstCPUIdleFirstInputDelayLargestContentfulPaintRessourcengröße
HTMLJavascriptCSSFontsImagesVideosRessourcenzahl
DOMElementsConnectionsRequestsRessourcenwerte
PerformanceProgressiveWebApp Alle Quellcodes für wichtige Funktionen befinden sich im src -Ordner. Dateien werden in die folgenden Unterordner organisiert:
common : Gemeinsame Klassen und Definitionen wie Status, Häufigkeit, Metriken usw.connectors : Anschlussklassen.extensions : Erweiterungsklassen.gatherers : Sammlerkurse.utils : Dienstprogramme und Tools. Führen Sie die folgenden Befehle aus, um den Unit -Test auszuführen:
npm test
Um die individuelle Testspezifikation auszuführen, können Sie das JEST -NPM -Modul auf Ihrem lokalen Computer installieren:
npm install -g jest
jest test/some-module.test.js
Der Unit -Test basiert auf dem Scherz -Unit -Test -Framework. Alle Unit -Tests befinden sich im Ordner ./test und werden in seine eigenen entsprechenden Unterordner organisiert, wie dieselbe Struktur wie im src -Ordner.
