O JavaScript referenciado na seção principal deve ser veiculado com o mesmo nome de host que o documento principal?

12

Fiquei com a impressão de que, para obter o melhor desempenho, o Javascript deve ser tratado como conteúdo estático e veiculado em um domínio sem cookies, juntamente com arquivos CSS, imagens etc.

Mas o Google diz aqui: Não envie arquivos JS externos carregados antecipadamente do domínio sem cookies

Para JavaScript mencionado no cabeçalho do documento e necessário para a inicialização da página, ele deve ser veiculado com o mesmo nome de host que o documento principal. Como a maioria dos navegadores bloqueia outros downloads e renderizações até que todos os arquivos JavaScript tenham sido baixados, analisados e executados, é melhor evitar o risco de uma pesquisa DNS adicional neste momento do processamento.

Então agora eu estou em conflito. Não sei ao certo o que "necessário para a inicialização da página" significa.

Normalmente, tenho duas referências JavaScript, JQuery, veiculadas em ajax.googleapis.com e um arquivo master.js que geralmente contém manipuladores de eventos na função $ (document) .ready (). Isso é necessário para a inicialização da página?

Dadas as opções disponíveis (ajax.googleapis.com, domínio sem cookies estático, nome do host original), onde meu JavaScript deve ser exibido?

— James Lawruk
fonte

5

Então agora eu estou em conflito. Não sei ao certo o que "necessário para a inicialização da página" significa.

Isso depende muito de como o site funciona. Basicamente, é o JavaScript que precisa ser executado antes que alguém possa fazer uso da página da web.

Como exemplo, se você acessar o site http://www.weather.com/ , poderá ver que o pessoal decidiu usar alguma mágica do JavaScript para fornecer uma dica para o formulário de pesquisa climática. Ou seja, as palavras Enter Zip, City or Place (e.g. Disney World)aparecem no campo de entrada de texto. Infelizmente, há um pequeno atraso quando a página está carregando, pelo menos do meu lado. Portanto, se a página estiver lenta o suficiente para carregar e você for rápido o suficiente para começar a digitar a entrada de texto antes que o JavaScript seja executado - o que não é muito complicado - sua entrada poderá ser alterada pelo JavaScript que coloca cegamente essa dica texto na caixa de entrada.

Concedido, isso pode ser evitado verificando a entrada do usuário na caixa de texto primeiro ou simplesmente desistindo dessa técnica anacrônica. No entanto, não serviria como um exemplo muito bom.

Dadas as opções disponíveis (ajax.googleapis.com, domínio sem cookies estático, nome do host original), onde meu JavaScript deve ser exibido?

Isso realmente não pode ser respondido sem saber o que seu JavaScript faz. Além disso, como bpeterson76 alude, isso depende da situação específica do seu site. Ou seja, qual é o tamanho da página? quão bem o seu host está atendendo à demanda? quantos arquivos CSS, imagens, etc, carrega? quantos recursos externos está carregando?

Dependendo da sua situação específica, isso pode ser uma otimização prematura.

— George Marian
fonte

4

A regra "qualquer coisa necessária antes que a página comece a renderizar deve ser do mesmo servidor" geralmente se aplica ao seuservidores ou outros recursos menores - situações em que essa pesquisa de DNS pode levar uma fração perceptível de segundo (o que pode aumentar rapidamente se seus objetos estiverem espalhados por muitos domínios). Com recursos públicos comuns, como o cache de jQuery do Google e outras bibliotecas, há uma boa chance de o navegador do visitante já ter feito essa pesquisa de DNS hoje (porque outros sites estão referenciando o conteúdo desse serviço) e provavelmente o arquivo também está em cache. a transferência precisa ser feita (ou, se uma solicitação for feita, ela poderá receber uma resposta curta "304 - não modificada"). Mesmo que seja necessário um download completo para o objeto, a rede de entrega de conteúdo do Google será mais rápida para a maioria dos usuários do que sua operação em menor escala.

Uma regra relacionada: objetos que não são necessários para a função correta da página (como o usuário vê) devem ser referidos o mais tarde possível na resposta HTTP principal. Por exemplo, coisas como os scripts necessários para os serviços de anúncios / estatísticas (por exemplo, Google Analytics e outros) - forneça ao usuário o seu conteúdo o mais rápido possível e carregue o material de segundo plano que realmente interessa a você. Eu bloqueei alguns serviços de anúncios / estatísticas (mapeando-os para 127.0.0.1 no meu arquivo hosts) porque eles costumam ser muito lentos e os sites que os referem cedo me dão uma página em branco enquanto os scripts são aguardados. de me referir a eles tarde, para que eu possa ler o conteúdo em que estou lá enquanto as outras coisas rolam ao fundo.

A utilidade de um domínio sem cookie para conteúdo estático é uma questão de escala. Se tudo o que você tem é um ID de sessão de 10 bytes nos cookies e dez mil visitantes por dia solicitando ~ 20 objetos estáticos por visita, você estará economizando apenas ~ 118Mbyte de largura de banda por mês (20 * 20 * 10000 * 31/1024/1024). Se, por outro lado, o seu site mantiver um ou dois Kbytes em cookies, a diferença pode ser muito mais significativa, especialmente se algum de seus usuários acessar o site por meio de conexões lentas (por exemplo, GPRS por meio de conexão a um celular ou mais link wifi lotado em uma área de alta interferência) ou se você receber milhões de visitas por dia.

Resumindo, para scripts que devem ser carregados antes que a página possa renderizar minhas preferências seriam:

ajax.googleapis.com ou similar
nome do host original da página de chamada
domínio estático sem cookies

Para recursos que não são essenciais para a renderização inicial da página, consulte-os o mais tarde possível e inverta a lista de preferências acima (embora a diferença entre o nome do host original e o domínio sem cookies não seja provavelmente significativa, a menos que você esteja operando em grande escala )

— David Spillett
fonte

With common public resources ... there is a good chance that your visitor's browser has already done that DNS lookup today

Pessoalmente, não me sentiria confortável contando com isso no meu site. Eu gostaria que fosse o mais rápido possível em tantas situações quanto possível. Independentemente disso, você faz bons pontos. +1

— George Marian

1

O Google administra uma enorme rede de conteúdo distribuída em todo o mundo que coloca o conteúdo mais próximo do usuário do que qualquer servidor que você provavelmente esteja executando (pense na Akami, mas de propriedade do Google). Portanto, do ponto de vista da velocidade, é lógico que O Google enviará seu arquivo ao usuário mais rapidamente que o servidor local ... a menos que eles estejam muito próximos do seu servidor pessoal.

Essa pergunta foi repetida no Stackoverflow, e a resposta acima parece ser sempre o consenso. Mas, do ponto de vista realista, os ganhos obtidos ao hospedar um contra o outro serão razoavelmente mínimos a longo prazo. Você obterá benefícios muito melhores ao reduzir, otimizar e reduzir solicitações de HTTP gerais do que examinar onde as coisas estão localizadas fisicamente. Nas situações em que isso começa a importar (eu fiz um trabalho em que uma página carregava mais de 1,5 milhão de vezes / dia, para uma melhoria de 5k significou 5 shows em economia de largura de banda), geralmente há uma equipe de tomadores de decisão encarregada de examinar essas decisões.

Pessoalmente, costumo hospedar no Google pelo único motivo de me fornecerem a cópia mais atualizada do que estou procurando.

— bpeterson76
fonte

Onde você hospeda seu JavaScript personalizado? Domínio estático sem cookies ou nome de host original?

— James Lawruk 03/08/19

Honestamente, fora do (principalmente) Jquery in-line, realmente não há muito que não possa ser vinculado dinamicamente. Costumo manter o vodu no mínimo, usando (principalmente) o núcleo do Jquery e da interface do usuário do Jquery, com a possível exceção do plug-in Datatables. Acredito muito no conceito de Manter simples (estúpido) e não lançarei código se ele não for compatível com versões anteriores, o que exclui muitas opções. Como eu disse acima, colocar um arquivo em um domínio que não seja sem cozinheiro não é tão importante assim.

— precisa saber é o seguinte

1

Uma coisa importante a lembrar é que os navegadores têm limites de quantos recursos serão baixados simultaneamente do mesmo domínio, geralmente entre 2 e 6, dependendo do navegador. O uso de um domínio diferente permite que o navegador baixe mais coisas simultaneamente do seu domínio.

Portanto, a melhor solução é usar uma CDN popular como ajax.googleapis.com, pois assim não há cookies. O usuário provavelmente já fez a pesquisa de DNS e pode até ter armazenado em cache o recurso. As CDNs são otimizadas para velocidade e provavelmente têm um servidor próximo ao seu usuário.

Se uma CDN não for uma opção, se você tiver muitos cookies ou muitos recursos para fazer o download (imagens etc.), use um domínio sem cookies (só é necessário fazer uma pesquisa de DNS uma vez).

Se você tiver poucos recursos (apenas um arquivo javascript personalizado) e alguns cookies (apenas uma pequena identificação de sessão) hospedam no mesmo domínio.

Bons recursos:

http://www.phpied.com/free-falling-waterfalls/

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

http://developer.yahoo.com/performance/rules.html

— Adão
fonte

1

Embora as respostas acima tenham dissecado a maior parte da sua pergunta, contribuirei com "necessário para a inicialização da página". Traduzo para: este script é essencial para usar o site? Por experiência, geralmente a resposta é não. No entanto, casos em que eu:

Validação de formulário
Uma navegação baseada em JavaScript (não é o ideal)
Se o layout depender do JavaScript
Se JavaScript ou uma biblioteca (como jQuery) for usada para modificações DOM que são críticas

E as diretrizes de desempenho YSlow do Yahoo para referência.

— Taylor Edmiston
fonte