AutoWebPerf
1.0.0
AutoweBPerf fournit un framework flexible et évolutif pour exécuter des audits de performances Web avec des outils d'audit arbitraire comme WebPageTest et PageSpeedInsights. Cette bibliothèque permet aux développeurs de collecter les mesures de manière cohérente et de stocker des mesures à un magasin de données préféré tel que les fichiers JSON locaux, les feuilles Google, BigQuery ou une base de données SQL interne.
Consultez https://web.dev/autowebperf pour l'introduction.
Autowebperf prend une liste de tests à partir d'une plate-forme de magasin de données arbitraire, telles que les JSons locaux, les feuilles Google, BigQuery ou une base de données SQL auto-hébergée. Avec la liste des tests, il exécute des audits en fonction de chaque configuration de test, collecte des mesures à partir de sources de données individuelles dans une liste de résultats .
Le processus d'exécution d'un audit via un outil de mesure (par exemple, WebPageTest) est défini dans le cueilleur individuel. La logique de la lecture et de l'écriture avec une plate-forme de données (par exemple JSON local) est implémentée dans un connecteur .
src/connectors/csv-connector pour plus de détails)AutoweBPerf sert d'agrégateur d'audit de performances qui automatise le processus de collecte d'audit et de métriques des performances via des outils de mesure à vitesse multiple, notamment WebPageTest, PageSpeedInsights et Chrome UX Report. Comme chaque outil de mesure de vitesse individuelle fournit des mesures d'audit, AutoweBPerf agrége les résultats et les écritures sur n'importe quelle plate-forme de stockage de données préférée, tels que les JSons locaux, la base de données basés sur le cloud ou leshets Googles.
Tout d'abord, Clone AWP Repo and Exécutez l'installation de NPM:
git clone https://github.com/GoogleChromeLabs/AutoWebPerf.git
npm install
Une fois terminé, vérifiez l'installation en exécutant un seul test avec la commande suivante:
./awp run examples/tests.json output/results.json
Cette commande utilise le fichier d'exemple dans examples/tests.json et renvoie les résultats à output/results.json .
Pour démarrer des tests récurrents, vous devrez inclure une propriété recurring.frequency . Pour configurer le temps de déclenchement suivant et pour exécuter un test unique, utilisez cette commande après avoir ajouté la propriété recurring.frequency .
./awp recurring examples/tests-recurring.json output/results.json
Si cela a réussi, le temps de déclenchement aura mis à jour la base sur la fréquence de votre choix, et un résultat aurait été écrit sur output/results.json .
Une fois que l'heure de déclenchement est correctement définie, vous pouvez passer automatiquement vos tests sur le prochain temps du triger avec la commande continue :
./awp continue examples/tests-recurring.json output/results.json
Cela exécutera automatiquement chaque test à la fréquence spécifiée. Plus d'informations peuvent être trouvées ci-dessous dans la section "Exécuter les tests récurrents" ci-dessous.
URL unique: pour tester une seule URL via PageSpeedInsights:
./awp run url:https://www.thinkwithgoogle.com/ json:output/results.json
Choisissez Gather: pour tester une seule URL avec un cueilleur spécifique comme PageSpeedInsights ou WebPageTest:
./awp run --gatherers=psi url:https://web.dev json:output/results.json
Fichier CSV: Pour exécuter des tests définis dans un fichier CSV et écrire des résultats dans un fichier JSON:
./awp run csv:examples/tests.csv json:output/results.json
API PageSpeedInsights: Pour exécuter PageSpeedInsights Tests avec une clé API:
PSI_APIKEY=SAMPLE_KEY ./awp run examples/tests.json output/results.json
API WebPageTest: Pour exécuter des tests WebPageTest:
WPT_APIKEY=SAMPLE_KEY ./awp run examples/tests-wpt.json output/results.json
Regarder par rapport à APPEND: Pour exécuter les tests et remplacer les résultats existants dans le fichier de sortie
./awp run examples/tests.json output/results.json --override-results
./awp run examples/tests.json output/results.json
Alternativement, pour spécifier l'utilisation du connecteur JSON pour le chemin Tests et le chemin Results :
./awp run json:/examples/tests.json json:output/results.json
Tests et le chemin Results : ./awp run csv:/examples/tests.csv csv:output/results.csv
Test avec une URL spécifique pour l'audit. Pour exécuter un audit avec un seul Test avec une URL spécifique: ./awp run url:https://example.com csv:output/results.csv
Veuillez noter que ce connecteur ne fonctionne qu'avec le chemin Tests , et non pour le chemin Results .
Vous pouvez exécuter ce qui suit à tout moment pour l'impression d'usages CLI:
./awp --help
Pour exécuter des tests, vous pouvez exécuter la commande CLI suivante avec des tests donnés JSON, comme examples/tests.json , qui contient un tableau de tests. Vous pouvez consulter les examples/tests.json pour la structure de données des tests.
./awp run examples/tests.json output/results.json
Cela générera le (s) objet (s) de résultat dans le chemin donné aux results.json .
Par défaut, AWP utilisera JSON comme connecteur par défaut pour les tests de lecture et d'écriture des résultats. Alternativement, vous pouvez spécifier un connecteur différent dans le format de <connector>:<path> .
Par exemple, exécuter des tests définis dans CSV et les résultats de l'écriture en JSON:
./awp run csv:examples/tests.csv json:output/results.csv
Pour certaines plateformes d'audit comme WebPageTest, chaque test peut prendre quelques minutes pour récupérer les résultats réels. Pour ce type d'audits asynchrones , chaque résultat restera en statut "soumis". Vous devrez récupérer explicitement les résultats plus tard.
Exécutez ce qui suit pour récupérer les mesures finales des résultats dans les results.json .
./awp retrieve examples/tests.json output/results.json
Cela va récupérer les métriques pour toutes les plates-formes d'audit et mettre à jour l'objet de résultat dans la output/results.json . Vous pouvez consulter examples/results.json pour plus de détails dans les objets de résultat.
Si vous souhaitez configurer des tests récurrents, vous pouvez définir l'objet recurring qui contient frequency pour ce test.
./awp recurring examples/tests-recurring.json output/results.json
Cela générera l'objet de résultat dans les results.json et mettra à jour le temps de déclenchement suivant à son objet de test d'origine dans les tests.json . Par exemple, l'objet de test mis à jour ressemblerait à ce qui suit, avec le nextTriggerTimestamp mis à jour.
{
"label": "web.dev",
"url": "https://web.dev",
"recurring": {
"frequency": "Daily",
"nextTriggerTimestamp": 1599692305567,
"activatedFrequency": "Daily"
},
"psi": {
"settings": {
"locale": "en-GB",
"strategy": "mobile"
}
}
}
Le nextTriggerTimestamp sera mis à jour au lendemain en fonction de l'horodatage précédent. Il s'agit d'empêcher des exécutions répétées avec le même test et de garantir que ce test n'est exécuté qu'une fois par jour.
Dans la plupart des systèmes d'exploitation de type Unix, vous pouvez configurer un travail CRON pour exécuter périodiquement l'AWP CLI.
Par exemple, dans MacOS, vous pouvez exécuter les commandes suivantes pour configurer un travail Cron quotidien avec AWP:
# Edit the cronjob with a text editor.
EDITOR=nano crontab -e
Ajoutez la ligne suivante au Crontab pour une course quotidienne à 12h00 à midi. Notez que cela est basé sur l'heure du système où il exécute AWP.
0 12 * * * PSI_APIKEY=SAMPLE_KEY cd ~/workspace/awp && ./awp run examples/tests.json csv:output/results-recurring.csv
Une extension est un module pour aider AWP à exécuter des tests avec un processus et un calcul supplémentaires. Par exemple, la prolongation budgets est en mesure d'ajouter des budgets de performance et de calculer le delta entre les cibles et les métriques des résultats.
Pour courir avec des extensions:
./awp run examples/tests.json output/results.json --extensions=budgets
La liste des tests est simplement un tableau d'objets de tests, comme les exemples de tests ci-dessous. Ou consultez src/examples/tests.js pour un exemple détaillé de la liste des tests.
[{
"label": "Test-1",
"url": "example1.com",
"webpagetest": {
...
}
}, {
"label": "Test-2",
"url": "example2.com",
"psi": {
...
}
}]
Chaque objet Test définit les audits à exécuter en définissant la propriété gatherers . Par exemple, le premier Test a une propriété webpagetest qui définit la configuration de l'exécution d'un audit WebPageTest. Le deuxième Test a une propriété psi qui définit comment exécuter PageSpeedInsights Audit.
Après avoir exécuté des tests, une liste de Results est générée comme ci-dessous. Chaque Result contient ses mesures correspondantes aux gatherers prédéfinis tels que WebPageTest et PageSpeedInsights. Voir l'exemple ci-dessous.
[{
"label": "Test-1",
"url": "example1.com",
"webpagetest": {
"metrics": {
FirstContentfulPaint: 900,
...
}
}
}, {
"label": "Test-2",
"url": "example2.com",
"psi": {
"metrics": {
FirstContentfulPaint: 900,
...
}
}
}]
Certains conencteurs ou cueilleurs peuvent nécessiter une ou plusieurs variables environnementales, telles que les clés API ou le compte de chemin vers le service. Par exemple, l'exécution avec le cueilleur API Crux nécessite la clé API Crux.
Pour passer les variables environnementales de la CLI, exécutez la commande avec l'utilisation régulière de l'environnement VARS:
CRUX_APIKEY=<YOUR_KEY> ./awp run url:https://wev.dev/ json:output/results.json
AWP prend en charge les cueilleurs d'audit suivants. Veuillez consulter les documentations correspondantes pour plus de détails.
Le webPageTest Gatherer exécute des tests via les points de terminaison publiques WebPageTest ou une instance WebPageTest privée personnalisée.
Voir docs / webPageTest.md pour plus de détails pour l'utilisation de WebPageTest Gather.
Le PagesPeed Insights Gather effectue des tests via l'API Public PagesPeed Insights.
Voir Docs / Psi.md pour plus de détails pour l'utilisation de PSI Gather.
Le Crux API Gather recueille des mesures de performance via l'API Chrome UX Report.
Voir Docs / Cruxapi.md pour plus de détails pour l'utilisation de Crux API Gather.
Le Crux BigQuery Gather recueille des mesures de performance via le rapport Chrome UX avec son projet public Google BigQuery. Veuillez noter que vous auriez besoin de configurer un projet Google Cloud afin d'interroger la table publique BigQuery.
Voir docs / cruxbigquery.md pour plus de détails pour l'utilisation de Crux API Gather.
AWP est conçu avec des modules, y compris des modules pour exécuter des audits avec WebPageTest, PageSpeedInsights ou d'autres outils, et des modules pour la lecture / rédaction de données de plates-formes de données telles que JSON, GoogleSheets ou un service cloud.
Dans une vue de haut niveau, il existe trois types de modules:
Le moteur AWP utilise deux principales structures d'objets JavaScript pour exécuter des audits et collecter des mesures.
examples/tests.json pour un objet de test réel.examples/results.json pour un objet de résultat réel.Afin de gérer l'outil d'audit asynchrone comme WebPageTest, AWP divise le cycle d'audit en trois étapes des actions:
Tests et génère une liste d'objets Results .Tests , génère une liste de Results et met à jour NextTriggerTimeStamp pour chaque Test récurrent. Cette action est utile lors de l'exécution avec des tâches périodiques ou basées sur le chronomètre telles que Cron Job.Retrieved .Pour configurer des modules et leurs configurations, une configuration AWP globale est requise en tant qu'objet JavaScript.
AWP Config a les propriétés requises suivantes:
connector : le nom du connecteur.helper : une aide pour un connecteur spécifique, y compris le gestionnaire d'API et d'autres fonctions d'assistance, qui seront utilisées dans les cueilleurs et les extensions.dataSources : un tableau de sources d'audit, telles que webpagetest ou psi . Chacune des sources de données doit avoir un fichier de cueilleur correspondant dans le dossier src/gatherers .extensions : un tableau d'extensions. Chaque extension doit avoir un fichier d'extension correspondant dans src/extensions .Autres propriétés facultatives:
verbose : s'il faut imprimer des messages verbeux.debug : s'il faut imprimer des messages de débogage. L'exemple de configuration suivant provient des 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,
}
Avec l'exemple de configuration ci-dessus, il utilisera le connecteur JSON qui lit et écrit des tests et des résultats comme fichiers JSON. Voir examples/tests.json et examples/results.json pour les exemples.
En plus des propriétés fondamentales, il existe quelques propriétés supplémentaires utilisées par les modules:
json comme configuration de JSONConnector .budgets Propriété comme configuration de BudgetSextensionExemples de création d'une nouvelle instance d'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,
});
Pour soumettre tous les tests:
awp.run();
Pour soumettre des tests spécifiques à l'aide de filtres: cela exécutera le test qui a id = 1 et sélectionné = True Properties.
awp.run({
filters: ['id="1"', 'selected'],
});
Pour récupérer tous les résultats en attente, filtrant avec statut! == "récupéré".
awp.retrieve({
filters: ['status!=="Retrieved"'],
});
src/utils/pattern-filter.js avec plus d'exemples.Pour exécuter des tests récurrents:
// This will run the actual audit and update the nextTriggerTimestamp.
awp.recurring();
Pour exécuter des tests avec des extensions spécifiques:
// This will override the extension list defined in the awpConfig.
awp.run({
extensions: ['budgets']
})
Une classe de cueilleur étend src/gatherers/gatherer.js et remplace les méthodes suivantes:
constructor(config, apiHelper, options) :
config : la configuration définie dans une propriété avec le nom de ce cueilleur dans la configuration AWP. Certains outils d'audit comme WebPageTest ou PageSpeedInsights nécessitent des clés API. La clé API pour le cueilleur est située dans la config.apiKey .options : Paramètres supplémentaires comme verbose et debug . run(test, options) :
test : un objet Test pour cette exécution d'audit. Les données requises pour ce cueilleur (par exemple paramètres ou métadonnées) seront dans la propriété avec le nom du cueilleur. Par exemple, les données de WebPageTest seront dans webpagetest de cet objet Test .options : Paramètres supplémentaires. retrieve(result, options) :
result : un objet Result pour récupérer des mesures avec. Les données requises pour ce cueilleur seront dans la propriété avec le nom du cueilleur. Par exemple, les données et les mesures seront dans webpagetest de cet objet Result .options : Paramètres supplémentaires comme verbose et debug . Une classe de connecteur étend src/connectors/connector.js et remplace les méthodes suivantes:
constructor(config, apiHandler) :
config : la configuration définie dans une propriété avec le nom de ce connecteur dans la configuration AWP.apiHandler : L'instance de gestionnaire API utilisé pour passer des appels API. getConfig() : la méthode pour renvoyer l'objet de configuration supplémentaire du connecteur. Cet objet config dépend de l'endroit où ce connecteur stocke ses paramètres supplémentaires, y compris les clés de l'API pour les cueilleurs. Par exemple, JSONConnector utilise les tests.json et lit des paramètres supplémentaires à partir de la propriété config , y compris les clés d'API pour chaque rassemblement.
getTestList(options) : la méthode pour renvoyer la liste des Tests en tant que tableau.
updateTestList(newTests, options) : la méthode pour mettre à jour la liste Tests , compte tenu de la liste des nouveaux Tests .
getResultList(options) : la méthode pour renvoyer la liste des Results en tant que tableau.
appendResultList(newResults, options) : La méthode pour ajouter de nouveaux Results à la fin de la liste Results actuelle.
updateResultList(newResults, options) : La méthode pour mettre à jour Results existants dans la liste Results actuelle.
Une classe d'extension étend src/extensions/extension.js et remplace les méthodes suivantes:
constructor(config) :config : la configuration définie dans une propriété avec le nom de cette extension dans la configuration AWP.beforeRun(context) : la méthode avant d'exécuter l'étape d'exécution pour un Test .context.test : l'objet Test correspondant.afterRun(context) : la méthode après avoir exécuté l'étape d'exécution pour un Test .context.test : l'objet Test correspondant.context.result : l'objet Result correspondant.beforeAllRuns(context) : la méthode avant d'exécuter l'étape d'exécution .context.tests : tous les objets Test dans cette exécution .afterAllRuns(context) : la méthode après l'exécution de l'étape d'exécution .context.tests : tous les objets Test dans cette exécution .context.results : Tous les objets Result dans cette exécution .beforeRetrieve(context) : La méthode avant d'exécuter la récupération de l'étape pour un Result .context.result : l'objet Result correspondant.afterRetrieve(context) : La méthode après avoir exécuté la récupération étape pour un Result .context.result : l'objet Result correspondant.beforeAllRetrieves(context) : la méthode avant d'exécuter la récupération de l'étape.context.result : l'objet Result correspondant.afterAllRetrieves(context) : la méthode après l'exécution de la récupération .context.result : l'objet Result correspondant. Un objet Test standard contient les propriétés suivantes:
(Vous pouvez vous référer à examples/tests.json pour un exemple.)
selected : s'il faut effectuer l'exécution de ce Test .label : nom de ce Test .url : URL pour auditer.recurring : paramètres pour l'audit récurrent.frequency : la chaîne de fréquence définie dans src/common/frequency.js . Par exemple, «quotidien», «hebdomadaire» ou «mensuel».Les paramètres spécifiques à des cueilleurs seront dans leur propre propriété avec le nom du cueilleur en minuscules. Par exemple, les paramètres de WebPageTest seront:
webpagetestsettings : le paramètre L'objet contient l'emplacement de l'audit, la connexion, etc.metadata : l'objet Metadata contient l'ID de WebPageTests, l'URL JSON, etc. Un objet Result standard contient les propriétés suivantes:
selected : s'il faut effectuer une récupération pour ce Result .id : ID unique généré automatiquement pour ce Result .type : Audit Single ou Recurring .status : Submitted , Retrieved ou Error . Reportez-vous à src/common/status.js pour plus de détails.label : étiquette de chaîne pour ce Result . Cette étiquette hérite de son objet Test d'origine.url : URL audité.createdTimestamp : lorsque ce Result est créé.modifiedTimestamp : lorsque ce Result est modifié pour la dernière fois. Tous les noms métriques utilisés dans AWP sont tenus de suivre les noms, sensibles à la casse. Voir la liste complète des mesures standardisées dans src/common/metrics.js
Métriques de synchronisation
TimeToFirstByteFirstPaintFirstMeaningfulPaintFirstContentfulPaintVisualCompleteSpeedIndexDOMContentLoadedLoadEventTimeToInteractiveTotalBlockingTimeFirstCPUIdleFirstInputDelayLargestContentfulPaintTaille des ressources
HTMLJavascriptCSSFontsImagesVideosNombre de ressources
DOMElementsConnectionsRequestsScores de ressources
PerformanceProgressiveWebApp Tous les codes source pour les fonctions principales sont situés dans le dossier src . Les fichiers sont organisés dans les sous-dossiers suivants:
common : classes et définitions courantes, telles que l'état, la fréquence, les mesures, etc.connectors : Classes de connecteur.extensions : classes d'extension.gatherers : Cours de cueilleurs.utils : utilitaires et outils. Exécutez les commandes suivantes pour exécuter le test unitaire:
npm test
Pour exécuter des spécifications de test individuelles, vous pouvez installer le module NPM de plaisanterie sur votre machine locale:
npm install -g jest
jest test/some-module.test.js
Le test unitaire est basé sur le cadre de test unitaire de plaisanterie. Tous les tests unitaires sont situés dans le dossier ./test et sont organisés dans ses propres sous-dossiers correspondants, comme la même structure que dans le dossier src .
