A pré-busca de link funciona entre subdomínios?


10

Eu tenho tentado usar algo assim para obter um aumento de desempenho ao clicar em uma página de destino simples para um aplicativo de página única e pesado:

<link rel="prefetch" href="https://example.com" as="document" />
<link rel="prefetch" href="https://example.com/app.js" as="script" />
<link rel="prefetch" href="https://example.com/app.css" as="style" />

Parece não ter um aumento perceptível no desempenho quando minha página de destino está em um subdomínio. Diga https://subdomain.example.com,.

Quando eu clicar em um link para visitar https://example.com, ainda vejo um longo atraso na guia rede Chrome como app.jse app.csssão carregados:

Recursos pré-buscados Tempo de download de recursos com pré-busca

Aqui está o mesmo recurso com a pré-busca desativada:

Tempo de download do recurso sem pré-buscar

Leva aproximadamente a mesma quantidade de tempo no total.


Solicite cabeçalhos para um dos ativos carregados com o cache de pré-busca:

Geral:

Request URL: https://example.com/css/app.bffe365a.css
Request Method: GET
Status Code: 200  (from prefetch cache)
Remote Address: 13.226.219.19:443
Referrer Policy: no-referrer-when-downgrade

Resposta:

accept-ranges: bytes
cache-control: max-age=31536000
content-encoding: gzip
content-length: 39682
content-type: text/css
date: Mon, 06 Jan 2020 21:42:53 GMT
etag: "d6f5135674904979a2dfa9dab1d2c440"
last-modified: Mon, 06 Jan 2020 20:46:46 GMT
server: AmazonS3
status: 200
via: 1.1 example.cloudfront.net (CloudFront)
x-amz-cf-id: dO3yiCoPErExrE2BLYbUJaVye32FIJXXxMdI4neDGzGX9a6gcCDumg==
x-amz-cf-pop: LAX50-C1
x-amz-id-2: 1O0LmihxpHIywEaMQWX7G3FDAzxtH9tZq1T/jeVLMzifFSJSIIJSS6+175H61kKdAq6iEbwfs2I=
x-amz-request-id: AF35C178092B65D4
x-cache: Hit from cloudfront

Solicitação:

DNT: 1
Referer: https://example.com/auth/join
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Minha pergunta é: se o Chrome indica que o cache de pré-busca é usado, por que o tempo de download de conteúdo é significativo?

Parece que o Chrome possui diferentes tipos de caches: cache de pré-busca, cache de disco e cache de memória. O cache do disco e o cache da memória são muito rápidos (tempos de carregamento de 5 ms e 0 ms). No entanto, o cache de pré-busca é bastante inútil, com tempos de download de 300ms às vezes. Posso obter uma explicação técnica de por que isso acontece? É um bug no Chrome? Estou no Chrome 79.0.3945.117.


A pré-busca é usada para acelerar futuras navegações, veja uma breve explicação de ( web.dev/link-prefetch )
Mohammad Yaseer

Sim, a pré-busca deve acelerar as futuras navegações. Então por que não acelerou no meu caso? Veja os gráficos de tempo.
Maros 9/01

Você pode tentar colocar o conteúdo do subdomínio em outro domínio e verificar se isso também leva o mesmo tempo para carregar? Parece que você concluiu que o subdomínio pode ser um problema sem mostrá-lo, mostrando como o caso de não subdomínio (ou seja, outro domínio) funciona. Se o subdomínio for um problema, o próximo passo seria explorar se há uma configuração do Chrome para fazer isso, ou
Martin

Ou os mesmos tempos de carregamento do subdomínio e / ou do domínio independente aparecem em outros navegadores com conjuntos de ferramentas semelhantes, como Firefox Inspector ou Opera? Se o mesmo problema de tempo estiver ocorrendo em outros navegadores que usam mecanismos diferentes (não sei mais o que fazem e não fazem mais) como você menciona, pode ser um bug - posso acreditar inteiramente que poderia ser um bug do Chrome se esses valores de tempo anotados forem notavelmente diferentes em outros navegadores.
Martin

Respostas:


0

A adição <link rel=prefetch>a uma página da web informa ao navegador para baixar páginas inteiras ou alguns dos recursos (como scripts ou arquivos CSS) que o usuário pode precisar no futuro. Isso pode melhorar métricas, como Primeira pintura com conteúdo e Tempo para interativo, e pode fazer com que as navegações subsequentes pareçam carregar instantaneamente.

insira a descrição da imagem aqui

A dica de pré-busca consome bytes extras para recursos que não são imediatamente necessários; portanto, essa técnica precisa ser aplicada cuidadosamente; somente busque recursos quando tiver certeza de que os usuários precisarão deles. Considere não buscar previamente quando os usuários estiverem em conexões lentas. Você pode detectar isso com a API de informações de rede.

Existem diferentes maneiras de determinar quais links pré-buscar. O mais simples é pré-buscar o primeiro link ou os primeiros links na página atual. Existem também bibliotecas que usam abordagens mais sofisticadas, explicadas mais adiante neste post - https://web.dev/link-prefetch/ .


Eu estava procurando obter uma explicação de por que a pré-busca de links não está acelerando as coisas no meu caso específico. É por causa de subdomínios, trabalhadores de serviço ou algo mais? Se você observar minhas capturas de tela, poderá ver que o navegador baixa novamente o conteúdo, apesar da pré-busca.
Maros

0

Eu posso apenas adivinhar. A resposta confiável provavelmente só pode ser encontrada por você, através do experimento. Existem muitas variáveis ​​a serem consideradas. Mas aqui estão algumas idéias:

  1. prefetché uma dica para um navegador. O navegador pode ignorá-lo por alguns motivos arbitrários. Mais do que isso, tem a menor prioridade.
  2. Por exemplo, por precaução, verifique as configurações do seu navegador:
    Menu/Settings/Advanced/Privacy and security/Preload pages for faster browsing and searching
    (ou algo parecido).
  3. Se por acaso você estiver usando internet móvel, também pode ser um problema.
    https://www.technipages.com/google-chrome-prefetch
  4. Com que velocidade você navega da sua página de destino para a example.com?
  5. Verifique os logs do servidor para ver se ele recebe prefetchsolicitações.
  6. Verifique se o servidor define alguns cabeçalhos estranhos em resposta a prefetchsolicitações. Por exemplo Cache-Control: no-cache. Sim, eu vejo que você tem cache-control: max-age=31536000, então seria realmente estranho, se o servidor enviar cabeçalho diferente para a mesma solicitação (bem ... quase o mesmo , pelo menos você não disse que é, e pelo menos pode alguns cabeçalhos indicando que é uma prefetchsolicitação), mas coisas estranhas acontecem.

  7. Você provavelmente deve tentar adicionar crossoriginatributo. Por exemplo

    <link rel="prefetch" href="https://example.com/app.css" as="style" crossorigin />

    Aqui https://www.w3.org/TR/resource-hints/, você pode encontrar este exemplo

    <link rel="preconnect" href="//example.com">
    <link rel="preconnect" href="//cdn.example.com" crossorigin>

    bastante relevante para o seu caso, mas infelizmente sem explicação.

  8. Na versão original da sua pergunta, você mencionou trabalhadores de serviço ... Se eles fazem o download de algo, ou mesmo você faz o download manual de algo, também pode ser o problema. Devido à menor prioridade deprefetch

    https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefetching_FAQ#What_if_I.27m_downloading_something_in_the_background.3F_Will_link_prefetching_compete_for_bandwidth.3F

    Se você estiver baixando algo usando o Mozilla, a pré-busca do link será adiada até que os downloads em segundo plano sejam concluídos

    Eu acho que o mesmo vale para o Chrome.

  9. Você tentou mover sua página de destino para o domínio raiz? Se sim e prefetchfuncionar como esperado, sim - subdomínio é a causa do problema. E a mensagem da GUI Status Code: 200 (from prefetch cache)provavelmente é apenas uma falha. Porque, recentemente, algumas coisas começaram a mudar no prefetchcomportamento do Chrome. E ainda não sei se as coisas se resolveram. Basicamente, sim, há certa probabilidade de que você possa prefetchapenas da mesma origem.

    https://docs.google.com/document/d/1bKGDIePAuF6YXmmrwM33LeLvtuCsla3vTspsxsNp-f8/edit


Algumas notas aleatórias depois de ler sua resposta: Navego muito lentamente da página de destino para o example.com, permitindo tempo suficiente para o carregamento de todos os recursos. Fiz o teste acima com os trabalhadores de serviço desativados no Chrome. Eu acho que o atributo crossorigin é para outra coisa. Eu tentei usá-lo e sem sorte. Na pior das hipóteses, farei o teste sugerido movendo a página de destino para o domínio raiz. Eu esperava que uma resposta aqui me salvasse o trabalho.
Maros 17/01

11
Você já experimentou FF? No link MDN acima: "O Mozilla pré-buscará documentos de um host diferente? Sim. Não há restrição de mesma origem para pré-busca de links. Limitar a pré-busca apenas a URLs do mesmo servidor não ofereceria maior segurança ao navegador". Esta passagem pode estar desatualizada, mas ainda assim. Será bom saber se eles diferem em seu comportamento com o Chrome.
x00 17/01

Tentei, mas não consegui desabilitar os trabalhadores de serviço que pareciam ter precedência sobre o cache de pré-busca. Mas posso tentar outra vez.
Maros 17/01

@Maros, de alguma forma você não possui o código, ou houve algum problema técnico?
x00 17/01

-1

você deve adicionar o código abaixo, caso seja um subdomínio e deseje recursos do domínio

<link rel="preconnect" href="https://example.com">
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.