AutoWebPerf
1.0.0
A AutowebPerf fornece uma estrutura flexível e escalável para executar auditorias de desempenho da Web com ferramentas de auditoria arbitrárias como WebPageTest e PageSpeedInsights. Essa biblioteca permite que os desenvolvedores coletem métricas de forma consistente e armazenem métricas para um armazenamento de dados preferido, como arquivos JSON local, folhas do Google, BigQuery ou um banco de dados SQL interno.
Confira https://web.dev/autowebperf para introdução.
A Autowebperf recebe uma lista de testes de uma plataforma arbitrária de armazenamento de dados, como JSONs locais, folhas do Google, BigQuery ou um banco de dados SQL auto-hospedado. Com a lista de testes, ele executa auditorias com base em cada configuração de teste, coleta métricas de fontes de dados individuais em uma lista de resultados .
O processo de execução de uma auditoria por meio de uma ferramenta de medição (por exemplo, WebPagEtest) é definida no coletor individual. A lógica de leitura e escrita com uma plataforma de dados (por exemplo, JSON local) é implementada em um conector .
src/connectors/csv-connector para obter detalhes)A AutowebPerf serve como um agregador de auditoria de desempenho que automatiza o processo de coleta de auditoria e métricas de desempenho por meio de várias ferramentas de medição de velocidade, incluindo WebPagEtest, PageSpeedInsights e Relatório do Chrome UX. Como cada ferramenta de medição de velocidade individual fornece métricas de auditoria, a AutowebPerf agrega os resultados e grava em qualquer plataforma de armazenamento de dados preferida, como JSONs locais, banco de dados baseado em nuvem ou folhetos googles.
Primeiro, clone awp repo e execute o npm install:
git clone https://github.com/GoogleChromeLabs/AutoWebPerf.git
npm install
Depois de terminar, verifique a instalação executando um único teste com o seguinte comando:
./awp run examples/tests.json output/results.json
Este comando usa o arquivo de exemplo em examples/tests.json e retorna os resultados para output/results.json .
Para iniciar testes recorrentes, você precisará incluir uma propriedade recurring.frequency no arquivo de teste e definir o próximo gatilho no arquivo de teste. Para configurar o próximo tempo de gatilho e executar um teste único, use este comando depois de adicionar a propriedade recurring.frequency aos seus testes:
./awp recurring examples/tests-recurring.json output/results.json
Se isso tiver sido bem -sucedido, o tempo de disparo terá uma base atualizada na frequência escolhida, e um resultado teria sido gravado para output/results.json .
Depois que o tempo de gatilho for definido corretamente, você poderá ter seus testes automaticamente no horário do TriGer com o comando continue :
./awp continue examples/tests-recurring.json output/results.json
Isso executará automaticamente cada teste na frequência especificada. Mais informações podem ser encontradas abaixo na seção "Executar testes recorrentes" abaixo.
URL único: testar um único URL através do PageSpeedInsights:
./awp run url:https://www.thinkwithgoogle.com/ json:output/results.json
Pick Gatheler: Para testar um único URL com um coletor específico como PageSpeedInsights ou WebPageTest:
./awp run --gatherers=psi url:https://web.dev json:output/results.json
Arquivo CSV: Para executar os testes definidos em um arquivo CSV e gravar resultados em um arquivo JSON:
./awp run csv:examples/tests.csv json:output/results.json
PagesPeedInsights API: Para executar testes PageSpeedInsights com uma chave da API:
PSI_APIKEY=SAMPLE_KEY ./awp run examples/tests.json output/results.json
WebPageTest API: para executar testes WebPageTest:
WPT_APIKEY=SAMPLE_KEY ./awp run examples/tests-wpt.json output/results.json
Substituir vs. anexar: para executar testes e substituir os resultados existentes no arquivo de saída
./awp run examples/tests.json output/results.json --override-results
./awp run examples/tests.json output/results.json
Como alternativa, especificar usando o conector JSON para o caminho Tests e o caminho Results :
./awp run json:/examples/tests.json json:output/results.json
Tests e o caminho Results : ./awp run csv:/examples/tests.csv csv:output/results.csv
Test com um URL específico para auditoria. Para executar uma auditoria com apenas um Test com um URL específico: ./awp run url:https://example.com csv:output/results.csv
Observe que este conector funciona apenas com o caminho Tests , não para o caminho Results .
Você pode executar o seguinte a qualquer momento para imprimir os usos da CLI:
./awp --help
Para executar testes, você pode executar o seguinte comando da CLI com os testes determinados JSON, como examples/tests.json , que contém uma variedade de testes. Você pode conferir os examples/tests.json para obter a estrutura de dados dos testes.
./awp run examples/tests.json output/results.json
Isso gerará o (s) objeto (s) de resultado no caminho fornecido para results.json .
Por padrão, o AWP usará o JSON como o conector padrão para testes de leitura e resultados de gravação. Como alternativa, você pode especificar um conector diferente no formato de <connector>:<path> .
Por exemplo, para executar testes definidos no CSV e gravar resultados em JSON:
./awp run csv:examples/tests.csv json:output/results.csv
Para algumas plataformas de auditoria, como o WebPageTest, cada teste pode levar alguns minutos para obter resultados reais. Para esse tipo de auditoria assíncrona , cada resultado permanecerá no status "enviado". Você precisará recuperar explicitamente os resultados posteriormente.
Execute o seguinte para recuperar as métricas finais dos resultados nos results.json .
./awp retrieve examples/tests.json output/results.json
Isso buscará métricas para todas as plataformas de auditoria e atualizará o objeto de resultado na output/results.json . Você pode conferir examples/results.json para obter detalhes em objetos de resultado.
Se você deseja configurar testes recorrentes, pode definir o objeto recurring que contém frequency para esse teste.
./awp recurring examples/tests-recurring.json output/results.json
Isso gerará o objeto de resultado nos results.json tests.json Por exemplo, o objeto de teste atualizado seria o seguinte, com o próximo nextTriggerTimestamp .
{
"label": "web.dev",
"url": "https://web.dev",
"recurring": {
"frequency": "Daily",
"nextTriggerTimestamp": 1599692305567,
"activatedFrequency": "Daily"
},
"psi": {
"settings": {
"locale": "en-GB",
"strategy": "mobile"
}
}
}
O nextTriggerTimestamp será atualizado para o dia seguinte com base no registro de data e hora anterior. Isso é para evitar execuções repetidas com o mesmo teste e garantir que este teste seja executado apenas uma vez por dia.
Na maioria do sistema operacional do tipo UNIX, você pode configurar um trabalho de cron para executar a AWP CLI periodicamente.
Por exemplo, no macOS, você pode executar os seguintes comandos para configurar um trabalho diário de cron com a AWP:
# Edit the cronjob with a text editor.
EDITOR=nano crontab -e
Adicione a seguinte linha ao Crontab para uma corrida diária às 12:00 ao meio -dia. Observe que isso é baseado no tempo do sistema em que é executado AWP.
0 12 * * * PSI_APIKEY=SAMPLE_KEY cd ~/workspace/awp && ./awp run examples/tests.json csv:output/results-recurring.csv
Uma extensão é um módulo para ajudar o AWP para executar testes com processo e computação adicionais. Por exemplo, a extensão budgets é capaz de adicionar orçamentos de desempenho e calcular o delta entre as metas e as métricas de resultado.
Para correr com extensões:
./awp run examples/tests.json output/results.json --extensions=budgets
A lista de testes é simplesmente uma matriz de objetos de testes, como os testes de amostra abaixo. Ou consulte src/examples/tests.js para obter um exemplo detalhado da lista de testes.
[{
"label": "Test-1",
"url": "example1.com",
"webpagetest": {
...
}
}, {
"label": "Test-2",
"url": "example2.com",
"psi": {
...
}
}]
Cada objeto Test define quais auditorias executadas definindo a propriedade gatherers . Por exemplo, o primeiro Test possui uma propriedade webpagetest que define a configuração da execução de uma auditoria no WebPageTest. O segundo Test possui uma propriedade psi que define como executar o PageSpeedInsights Audit.
Após a execução dos testes, uma lista de Results é gerada como abaixo. Cada Result contém suas métricas correspondentes para os gatherers predefinidos, como WebPageTest e PageSpeedInsights. Veja o exemplo abaixo.
[{
"label": "Test-1",
"url": "example1.com",
"webpagetest": {
"metrics": {
FirstContentfulPaint: 900,
...
}
}
}, {
"label": "Test-2",
"url": "example2.com",
"psi": {
"metrics": {
FirstContentfulPaint: 900,
...
}
}
}]
Alguns conedores ou coletores podem exigir uma ou mais variáveis ambientais, como as chaves da API ou o caminho para a conta de serviço. Por exemplo, executar com o Crux API Bettleler requer a chave da API do Crux.
Para passar as variáveis ambientais na CLI, execute o comando com o uso regular de vars de ambiente:
CRUX_APIKEY=<YOUR_KEY> ./awp run url:https://wev.dev/ json:output/results.json
O AWP suporta os seguintes coletores de auditoria. Confira as documentações correspondentes para obter detalhes.
O WebPageTest Gatheler executa testes através dos terminais públicos da WebPageTest ou uma instância de WebPagEtest privada personalizada.
Consulte Docs/WebPageTest.md para obter mais detalhes para o uso do WebPageTest Gatheler.
O PageSpeed Insights Gatheler realiza testes através da API de insights públicos PagesPeed.
Consulte Docs/psi.md para obter mais detalhes para o uso do PSI Gatherer.
O Crux API Gatherer coleta métricas de desempenho através da API do Relatório do Chrome UX.
Consulte Docs/Cruxapi.md para obter mais detalhes para o uso do Crux API Gatherer.
O Crux BigQuery Gatherer coleta métricas de desempenho através do relatório do Chrome UX com seu projeto público do Google BigQuery. NOET que você precisaria configurar um projeto do Google Cloud para consultar a tabela pública de BigQuery.
Consulte Docs/CruxbigQuery.md para obter mais detalhes para o uso do Crux API Gatheler.
O AWP foi projetado com módulos, incluindo módulos para executar auditorias com WebPageTest, PageSpeedInsights ou outras ferramentas e módulos para leitura/gravação de dados de plataformas de dados como JSON, Googlesheets ou um serviço em nuvem.
Em uma visão de alto nível, existem três tipos de módulos:
O mecanismo AWP usa duas principais estruturas de objetos JavaScript para executar auditorias e coletar métricas.
examples/tests.json para um objeto de teste real.examples/results.json para um objeto de resultado real.Para lidar com a ferramenta de auditoria assíncrona como o WebPagEtest, o AWP divide o ciclo de auditoria em três etapas de ações:
Tests e gera uma lista de objetos Results .Tests , gera uma lista de Results e atualiza o NextTriggerTimestamp para cada Test recorrente. Essa ação é útil ao executar com tarefas periódicas ou baseadas em timer, como o Cron Job.Retrieved .Para configurar módulos e suas configurações, uma configuração AWP geral é necessária como um objeto JavaScript.
AWP Config possui as seguintes propriedades necessárias:
connector : o nome do conector.helper : Um ajudante para um conector específico, incluindo manipulador de API e outras funções ajudantes, que serão usadas em coletores e extensões.dataSources : Uma matriz de fontes de auditoria, como webpagetest ou psi . Cada uma das fontes de dados precisa ter um arquivo de coletor correspondente na pasta src/gatherers .extensions : uma variedade de extensões. Cada extensão precisa ter um arquivo de extensão correspondente no src/extensions .Outras propriedades opcionais:
verbose : se deve imprimir mensagens detalhadas.debug : se deve imprimir mensagens de depuração. O exemplo de configuração a seguir vem dos 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,
}
Com o exemplo de configuração acima, ele usará o JSON Connector, que lê e grava testes e resultados como arquivos JSON. Consulte examples/tests.json e examples/results.json para exemplos.
Além das propriedades fundamentais, existem algumas propriedades adicionais usadas pelos módulos:
json como configuração para JSONConnector .budgets de propriedade como configuração para o orçamentoExemplos de criação de uma nova instância de 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,
});
Para enviar todos os testes:
awp.run();
Para enviar testes específicos usando filtros: isso executará o teste que possui ID = 1 e selecionou = Propriedades True.
awp.run({
filters: ['id="1"', 'selected'],
});
Para recuperar todos os resultados pendentes, filtrando com status! == "Recuperado".
awp.retrieve({
filters: ['status!=="Retrieved"'],
});
src/utils/pattern-filter.js com mais exemplos.Para executar testes recorrentes:
// This will run the actual audit and update the nextTriggerTimestamp.
awp.recurring();
Para executar testes com extensões específicas:
// This will override the extension list defined in the awpConfig.
awp.run({
extensions: ['budgets']
})
Uma aula de coletor estende src/gatherers/gatherer.js e substitui os seguintes métodos:
constructor(config, apiHelper, options) :
config : a configuração definida em uma propriedade com o nome deste coletor na configuração AWP. Algumas ferramentas de auditoria como WebPageTest ou PageSpeedInsights requerem teclas de API. A chave da API para o coletor está localizada na config.apiKey .options : Configurações adicionais como verbose e debug . run(test, options) :
test : um objeto Test para esta execução de auditoria. Os dados necessários para este coletor (por exemplo, configurações ou metadados) estarão na propriedade com o nome do coletor. Por exemplo, os dados do WebPageTest estarão no webpagetest deste objeto Test .options : Configurações adicionais. retrieve(result, options) :
result : um objeto Result para recuperar métricas. Os dados necessários para este coletor estarão na propriedade com o nome do coletor. Por exemplo, os dados e métricas estarão no webpagetest deste objeto Result .options : Configurações adicionais como verbose e debug . Uma classe do conector estende src/connectors/connector.js e substitui os seguintes métodos:
constructor(config, apiHandler) :
config : a configuração definida em uma propriedade com o nome deste conector na configuração AWP.apiHandler : A instância do manipulador de API usada para fazer chamadas de API. getConfig() : o método para retornar o objeto de configuração adicional do conector. Esse objeto de configuração depende de onde este conector armazena suas configurações adicionais, incluindo teclas de API para coletores. Por exemplo, o JSONConnector usa os tests.json e lê configurações adicionais da propriedade config , incluindo chaves da API para cada coletor.
getTestList(options) : o método para retornar a lista de Tests como uma matriz.
updateTestList(newTests, options) : o método para atualizar a lista Tests , dada a lista de novos Tests .
getResultList(options) : o método para retornar a lista de Results como uma matriz.
appendResultList(newResults, options) : o método para anexar novos Results ao final da lista Results atuais.
updateResultList(newResults, options) : O método para atualizar Results existentes na lista de Results atuais.
Uma classe de extensão estende src/extensions/extension.js e substitui os seguintes métodos:
constructor(config) :config : a configuração definida em uma propriedade com o nome desta extensão na configuração AWP.beforeRun(context) : o método antes de executar o RUN Etapa para um Test .context.test : o objeto Test correspondente.afterRun(context) : O método após executar a etapa de execução para um Test .context.test : o objeto Test correspondente.context.result : o objeto Result correspondente.beforeAllRuns(context) : o método antes de executar a etapa de execução .context.tests : Todos os objetos Test nesta execução .afterAllRuns(context) : o método após executar a etapa de execução .context.tests : Todos os objetos Test nesta execução .context.results : Todos os objetos Result nesta execução .beforeRetrieve(context) : o método antes de executar a etapa de recuperação para um Result .context.result : o objeto Result correspondente.afterRetrieve(context) : o método após a execução da etapa de recuperação para um Result .context.result : o objeto Result correspondente.beforeAllRetrieves(context) : o método antes de executar a etapa de recuperação .context.result : o objeto Result correspondente.afterAllRetrieves(context) : o método após a execução da etapa de recuperação .context.result : o objeto Result correspondente. Um objeto Test padrão contém as seguintes propriedades:
(Você pode consultar examples/tests.json para um exemplo.)
selected : se deve executar o execução para este Test .label : Nome deste Test .url : URL para auditar.recurring : Configurações para auditoria recorrente.frequency : a sequência de frequência definida em src/common/frequency.js . Por exemplo, 'Daily', 'Weekly' ou 'Monthly'.As configurações específicas do coletor estarão em sua própria propriedade com o nome do coletor em minúsculas. Por exemplo, as configurações para WebPageTests serão:
webpagetestsettings : A configuração do objeto contém localização de auditoria, conexão, etc.metadata : Objeto de metadados contém ID, JSON URL, etc. Um objeto Result padrão contém as seguintes propriedades:
selected : se deve executar a recuperação para este Result .id : ID exclusivo gerado automaticamente para este Result .type : Auditoria Single ou Recurring .status : Submitted , Retrieved ou Error . Consulte src/common/status.js para obter detalhes.label : etiqueta da string para este Result . Este rótulo herda de seu objeto Test original.url : URL auditado.createdTimestamp : quando esse Result é criado.modifiedTimestamp : quando este Result for modificado pela última vez. Todos os nomes de métricas usados no AWP são obrigados a seguir os nomes, sensíveis ao caso. Veja a lista completa de métricas padronizadas em src/common/metrics.js
Métricas de tempo
TimeToFirstByteFirstPaintFirstMeaningfulPaintFirstContentfulPaintVisualCompleteSpeedIndexDOMContentLoadedLoadEventTimeToInteractiveTotalBlockingTimeFirstCPUIdleFirstInputDelayLargestContentfulPaintTamanho de recurso
HTMLJavascriptCSSFontsImagesVideosContagem de recursos
DOMElementsConnectionsRequestsPontuações de recursos
PerformanceProgressiveWebApp Todos os códigos de origem para as principais funções estão localizados na pasta src . Os arquivos são organizados nas seguintes subpastas:
common : Classes e definições comuns, como status, frequência, métricas, etc.connectors : classes de conector.extensions : classes de extensão.gatherers : aulas de coletor.utils : utilitários e ferramentas. Execute os seguintes comandos para executar o teste de unidade:
npm test
Para executar especificações de testes individuais, você pode instalar o módulo JEST NPM em sua máquina local:
npm install -g jest
jest test/some-module.test.js
O teste de unidade é baseado na estrutura de teste da unidade de jest. Todos os testes de unidade estão localizados na pasta ./test e são organizados em suas próprias subpastas correspondentes, como a mesma estrutura da pasta src .
