Recentemente, pesquisei a capacidade de cache de recursos do Shopify. Visitava a página de tantas em tantas horas e rastreava o número de respostas 200 OK versus 304 Não Modificada. Para minha surpresa, o guia de rede do Google Chrome indicava que quase todas as respostas eram “do cache”.

Não fazia sentido. Em muitos casos, as URLs de recurso mudaram entre os períodos de teste. Como é que uma URL nunca vista antes podia vir “do cache”? Nos casos em que a URL era a mesma, observei que o cabeçalho de resposta da data tinha mudado desde o teste anterior, mas o Chrome ainda o marcava como “do cache”. Como a data podia mudar sem um código de status de resposta 200?

Comecei a pensar no meu trabalho de “pré-navegação” (artigo, slides, vídeo). Em minhas descobertas, eu falo sobre como os navegadores, especialmente o Chrome, têm feito mais trabalho de antecipação do que o usuário vai precisar depois. Esse trabalho proativo inclui fazer requisições de consultas DNS, estabelecer conexões TCP, baixar recursos e até pré-renderizar páginas inteiras.

Seria possível que o Chrome estivesse pré-renderizando a página inteira?

Comecei dando uma olhada em chrome://predictors. Certos caracteres digitados na Omnibox (a barra de endereços) mostram para qual URL você provavelmente vai. Nos meus testes, eu sempre digitava a URL na barra de endereços, portanto as previsões para “shopify” podiam afetar o comportamento do Chrome nesses testes. Eis o que encontrei em chrome://predictors:

O Chrome previa que, se eu incorporasse “www.s” na Omnibox, acabaria indo para “http://www.shopify.com/” com confiança 1.0 (como se vê na coluna mais à direita). De fato, digitar apenas “ww” obteve uma confiança de 0.9 de ir para o Shopify. Em outras palavras, o Chrome tinha desenvolvido um histórico profundo mapeando minhas digitações na Omnibox para o site Shopify, como se vê nas colunas verdes.

A partir da minha pesquisa de pré-navegação, eu sabia que se a confiança do chrome://predictors fosse bastante alta, o Chrome resolveria o DNS e conectaria o TCP previamente. Pode ser também que o Chrome estivesse enviando requisições de HTTP proativamente antes que elas fossem de fato necessárias. Para responder essa questão, abri o painel de rede do Chrome e digitei “www.s” no Omnibox, mas não dei Enter. Fiquei sentado lá e esperei 10 segundos. Mas não apareceu nada no painel de rede do Chrome:

Desconfiando que as requisições em segundo plano podiam não estar aparecendo no painel de rede, mandei ver em tcpdump e repeti o teste – novamente digitando apenas “www.s” e NÃO dando Enter. Subi o arquivo pcap para o CloudShark e vi 86 requisições de HTTP!

Examinei algumas requisições individuais e vi que eram novas URLs que nunca tinham aparecido antes, mas estavam no documento HTML. Isso confirmou que o Chrome estava pré-renderizando o documento HTML (em vez de fazer a busca prévia de recursos individuais baseados no histórico anterior). Fiquei surpreso com o fato de que ninguém tinha descoberto isso antes, então voltei ao High Performance Networking in Google Chrome, de Ilya Grigorik, e dei uma olhada na seção de Omnibox:

as cores amarela e verde para os candidatos prováveis são também sinais importantes para o ResourceDispatcher! Se tivermos um candidato provável (amarelo), o Chrome pode fazer uma busca prévia do DNS para o host alvo. Se houver um candidato de nível de confiança elevado (verde), então o Chrome pode fazer uma conexão prévia de TCP depois que o hostname for resolvido. Finalmente, se ambos os processos forem completados enquanto o usuário ainda estiver pensando, o Chrome pode até pré-renderizar a página inteira numa aba escondida.

Pontos importantes

O que começou como uma rápida análise de desempenho virou um quebra-cabeças que levou vários dias. A solução do enigma rendeu algumas lições:

• Lembre-se de que o Chrome pode fazer a busca prévia do DNS, a conexão prévia de TCP e até a pré-renderização da página completa com base nos índices de confiança do chrome://predictors.
• Nem todas as requisições HTTP relacionadas a uma página ou aba são mostradas no painel de rede do Chrome. Eu gostaria de ver esse erro consertado, talvez com uma opção para mostrar essas requisições nos bastidores.
• O Ilya sabe de tudo. Releia seus textos, artigos e livro antes de fazer experiências que durem vários dias.

***

Artigo traduzido pela Redação iMasters com autorização do autor. Publicado originalmente em http://www.stevesouders.com/blog/2014/04/30/unexpected-prerender-in-chrome/