Medir o desempenho em um service worker

Paul Kinlan

Além de Jake Archibald se preocupar com o fato de suas habilidades de desenvolvedor estarem desaparecendo, ele apresentou um argumento forte de que, usando o service worker de maneira inteligente, é possível melhorar drasticamente o desempenho do seu site ou app. Assista ao vídeo para ter uma visão geral.

Se você quiser acelerar o tempo de carregamento da página, como Jake sugere, é preciso entender como os service workers afetam as solicitações da sua página.

A API Resource Timing e a API User Timing são componentes essenciais na infraestrutura de RUM (monitoramento de usuários reais) de muitos sites, porque permitem entender de forma holística como todos os usuários percebem o desempenho do site. Outro caso de uso é detectar a injeção de conteúdo. Em resumo, ele permite que você entenda quase todos os aspectos de cada solicitação da Web feita no seu site, a menos que você tenha um worker da Web ou um worker de serviço.

Confira um exemplo rápido de como ele pode ser usado para gerar uma lista de todas as solicitações feitas para um domínio que não é o atual.

var getThirdPartyRequests = function() {
    var thirdPartyRequests = [];
    var requests = window.performance.getEntriesByType("resource");
    
    var currentHost = window.location.host

    for(var requestIdx = 0; requestIdx < requests.length; requestIdx++) {
    var request = requests[requestIdx];
    var url = new URL(request.name);
    var host = url.host;

    if(host != currentHost) {
        thirdPartyRequests.push(request);
    }
    }
    
    return thirdPartyRequests;
};

As APIs Resource Timing e User Timing foram criadas e implementadas antes do service worker ser uma ideia dos engenheiros, e o código acima não conseguiria entender como o service worker afetou.

Um conjunto recente de mudanças no Chrome 45 (Beta em julho de 2015) vai ajudar a introduzir a capacidade de todos os tipos de workers (worker da Web e worker de serviço) de ter acesso às APIs Resource Timing e User Timing e, assim, permitir que você fique por dentro da performance da rede para todos os usuários.

Como acessar métricas de desempenho em um service worker

A maior mudança é a adição do objeto performance a um contexto de workers (Web e ServiceWorkers), que agora permite entender os tempos de performance de todas as solicitações feitas no contexto do worker e também definir suas próprias marcas para medição da execução do JS. Se você só consegue ver o que acontece no contexto da janela atual, vai perder informações importantes de tempo de:

  • solicitações fetch() feitas dentro do evento oninstall do worker de serviço;
  • As solicitações fetch() feitas ao armazenar dados em cache em um evento onpush agora podem ser rastreadas para entender o desempenho que os usuários têm.
  • Por fim, a solicitação fetch() é feita e interceptada pelo gerenciador onfetch.

O último ponto é importante. Uma maneira de pensar em um service worker é como um proxy que fica entre a interface da Web e a rede. O objeto performance no window só tem acesso aos tempos e às informações da parte da solicitação que ele invoca. Ele não tem conhecimento do worker de serviço entre o cliente e a rede, então não consegue entender o impacto dele.

Como posso usar isso?

Um service worker típico que oferece suporte à execução off-line primeiro tem uma etapa de instalação em que ele faz o download e salva todos os recursos para uso posterior.

Um exemplo de onde isso pode ser usado é para registrar e registrar os dados de tempo da etapa de instalação. Assim, você pode tomar algumas decisões sobre como melhorar a performance da instalação com base no uso real do usuário.

self.addEventListener("install", function() {
    var urls = [
    '/',
    '/images/chrome-touch-icon-192x192.png',
    '/images/ic_add_24px.svg',
    '/images/side-nav-bg@2x.jpg',
    '/images/superfail.svg',
    '/scripts/voicememo-core.js',
    '/styles/voicememo-core.css',
    '/third_party/Recorderjs/recorder.js',
    '/third_party/Recorderjs/recorderWorker.js',
    '/third_party/Recorderjs/wavepcm.js',
    '/third_party/moment.min.js',
    '/favicon.ico',
    '/manifest.json'
    ];

    urls = urls.map(function(url) {
    return new Request(url, {credentials: 'include'});
    });

    event.waitUntil(
    caches
        .open(CACHE_NAME + '-v' + CACHE_VERSION)
        .then(function(cache) {
        // Fetch all the URL's and store in the cache
        return cache.addAll(urls);
        })
        .then(function () {
        // Analyze all the requests
        var requests = self.performance.getEntriesByType("resource");
        
        // Loop across all the requests and save the timing data.
        return;
        })
    );
});

Atualmente, muitos sites usam o RUM para entender como a maioria dos usuários interage com o site. Ferramentas como o Google Analytics já informam dados de velocidade do site usando a API Navigation Timing, mas precisam ser atualizadas para incluir a análise de desempenho de um contexto de worker.

A API Navigation Timing vai chegar aos service workers?

No momento, não há planos de adicionar a API Navigation Timing ao contexto do service worker, porque não há navegações tradicionais em um service worker. O interessante é que, para o service worker, cada navegação no conjunto de páginas controlado por ele parece uma busca de recursos. Isso por si só já torna os service workers uma maneira incrivelmente atraente de centralizar a maioria da lógica de desempenho no app da Web.

Posso saber o que mudou?

Tenho interesse na discussão e nas especificações