Referenciando javascript externo x hospedando minha própria cópia


42

Digamos que eu tenha um aplicativo Web que use jQuery. É uma boa prática hospedar os arquivos javascript necessários em meus próprios servidores, juntamente com os arquivos do meu site, ou referenciá-los na CDN do jQuery (exemplo: http://code.jquery.com/jquery-1.7.1.min.js ) ?

Eu posso ver profissionais de ambos os lados:

  • Se estiver nos meus servidores, é uma dependência externa a menos; se o jQuery cair ou alterar a estrutura de hospedagem ou algo parecido, meu aplicativo será interrompido. Mas sinto que isso não acontecerá com frequência; deve haver muitos sites pequenos fazendo isso, e a equipe do jQuery evitará quebrá-los.
  • Se estiver nos meus servidores, é uma referência externa a menos que alguém poderia chamar de problema de segurança
  • Se for referenciado externamente, não preciso me preocupar com a largura de banda para veicular os arquivos (embora eu saiba que não é muito).
  • Se for referenciado externamente e eu estiver implantando este site em muitos servidores que precisam ter suas próprias cópias de todos os arquivos, então é menos um arquivo que preciso lembrar para copiar / atualizar.

Os dois primeiros pontos se aplicam apenas se você estiver preocupado com o fato de o Google cair ou ser invadido.
user16764

1
@ user16764 - ou eles tiram sua cópia do jQuery por algum motivo (política, quem sabe).
Sr. Jefferson

2
Outro motivo para não fazer isso é a privacidade. O uso de conteúdo hospedado de terceiros fornece a esses terceiros uma maneira de rastrear usuários dos quais eles não podem desativar facilmente.
22612 Ian Newson

Também alguns CDNs especialmente google anfitriões, por vezes, tendem a restringir os arquivos de países específicos
azerafati

Respostas:


58

Você deve fazer as duas coisas:

Comece com a hospedagem de uma CDN como a do Google, pois provavelmente terá um tempo de atividade maior que o seu próprio site e será configurada para o tempo de resposta mais rápido. Além disso, qualquer pessoa que tenha visitado uma página vinculada ao CDN utilizará sua cópia em cache do arquivo, para que não precise baixar novamente uma cópia, tornando o carregamento inicial ainda mais rápido.

Em seguida, adicione uma referência de fallback ao seu próprio servidor, caso a CDN esteja inativa (não é provável, mas a segurança é segura). Os fallbacks são relativamente fáceis de entender, mas precisam ser personalizados para se adequar ao script que está sendo usado:

<script src="https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.18/jquery-ui.min.js"></script>
<script>
    if (!window.jQuery) document.write('<script src="/path/to/jquery-ver.sion.min.js"><\/script>');
</script>

Certifique-se de não escrever em </script>nenhum lugar de um <script>elemento, pois ele fechará o elemento HTML e causará falha no script. A solução simples é usar uma barra invertida como um escape: <\/script>.


Mais um motivo para fazer as duas coisas:

Se você escolher uma CDN popular, é altamente improvável que ela tenha algum tempo de inatividade, no entanto, em um futuro distante (~ 18 meses a partir da lei de Moore ) quando o formato da hospedagem mudar ou o endereço for ajustado ou o endereço rede é colocada atrás de um paywall, ou qualquer outra coisa, é possível que seu link não funcione mais como está. Se você usar um substituto, você terá um tempo para se adaptar a qualquer novo formato de hospedagem antes de voltar a todos os sites que você já criou e alterar os links da CDN.


outro motivo para fazer as duas coisas:

Recentemente, fui atingido por uma série de interrupções na Internet. Consegui continuar trabalhando localmente em projetos nos quais vinculei cópias locais de recursos de script e rapidamente descobri que havia vários projetos que precisavam ter cópias locais vinculadas.


+1 Oferece os benefícios da CDN e também cobre as possíveis armadilhas.
Quentin-starin

5
Qual a relevância do tempo de atividade? Se o seu site não é para cima, tendo os js on-line não é um benefício :)
Boris Yankov

3
@BorisYankov, Se a CDN estiver inativa e seu site estiver ativo, e você não tiver usado um fallback local, ele não funcionará. Essa é a relevância do tempo de atividade. Se seu site estiver inativo, ele estará inativo e a cópia local não será importante.
zzzzBov

A CDN também terá servidores em todo o lugar, para que você obtenha o recurso no nó mais próximo.
hanzolo

35

Eu tinha a mesma pergunta, então li este artigo e fui vendido com a idéia de deixar o Google hospedar minha biblioteca jQuery.

O artigo descreve os principais benefícios de permitir que suas bibliotecas sejam hospedadas pela CDN (Rede de entrega de conteúdo) do Google:

  • Latência reduzida - Os usuários que não estiverem fisicamente próximos ao servidor poderão fazer o download do jQuery mais rapidamente do Google do que se você os forçar a fazer o download no servidor localizado arbitrariamente.
  • Paralelismo aumentado - os navegadores limitam o número de conexões que podem ser feitas simultaneamente. Dependendo do navegador, esse limite pode ser tão baixo quanto duas conexões por nome de host. O uso da CDN do Google AJAX Libraries elimina uma solicitação ao seu site, permitindo que mais conteúdo local seja baixado em paralelo.
  • Melhor cache - Usando as bibliotecas do Google AJAX, talvez seus usuários não precisem baixar o jQuery. Por outro lado, se você estiver hospedando o jQuery localmente, seus usuários deverão baixá-lo pelo menos uma vez. Provavelmente, cada um de seus usuários já possui dezenas de cópias idênticas do jQuery no cache do navegador, mas essas cópias do jQuery são ignoradas quando eles visitam o site.

Quanto aos dois tópicos listados como profissionais por hospedar sua própria biblioteca, lembre-se de que o Google está hospedando a versão em nuvem, e o Google sabe o que está fazendo e pode ser confiável quanto à disponibilidade e segurança. No entanto, @zzzzBov faz um argumento muito bom em sua resposta a essa pergunta, onde recomenda também armazenar uma cópia local da biblioteca e usar como padrão no caso improvável de que a versão da CDN não possa ser acessada por qualquer motivo.


4
Ah, tenho certeza de que posso fazer um trabalho melhor hospedando ativos estáticos do que o google. ;)
Xeoncross

Não usar os dois (CDN + fallback local) é simplesmente desleixado. É uma pena que esta é a resposta mais importante.
Quentin-starin

@qes É justo, eu adicionei uma nova frase no final da minha resposta.
CFL_Jeff

17

Pessoalmente, tomo uma sugestão de http://html5boilerplate.com/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"></script>
<script>!window.jQuery && document.write(unescape('%3Cscript src="includes/js/libs/jquery-1.6.1.min.js"%3E%3C/script%3E'))</script>

Isso puxa o arquivo principal do jQuery do Google, mas se ele não carregar por algum motivo, a próxima linha o carrega do seu próprio servidor.


5
Isso tem o benefício adicional de permitir que você desenvolva offline.
RSG

O uso de uma URL relativa ao protocolo não é mais tão útil quanto era antes (consulte paulirish.com/2010/the-protocol-relative-url ). Aqui é razoável apenas digitar https://.
GKFX 13/03

5

É uma prática melhor usar uma CDN e, se esse CDN for o Google, tanto melhor - como observaram @CFL_Jeff e @Morons.

Estou adicionando esta resposta para apontar algo que muitas vezes passa despercebido ao apontar para outro lugar, o que está evitando o aviso de conteúdo misto . Considere usar URLs sem protocolo, por exemplo:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js" type="text/javascript">
</script>

Ainda existem alguns problemas de suporte no uso de URLs sem protocolo, portanto, dê uma olhada nas respostas em Posso alterar todos os meus links http: // para apenas //? no SO, mas pelo menos tente manipular possíveis avisos de conteúdo misto de alguma maneira.


4

Você deve fazer referência à Biblioteca de APIs do Google .

A principal razão para isso é acelerar o carregamento da página . Se o usuário já visitou outro site que faz referência à mesma biblioteca, ele já será armazenado no cache do navegador e não precisará ser baixado .


0

Eu posso estar errado, mas a implementação de document.write substitui qualquer coisa que o DOM tenha. Como é uma boa prática colocar arquivos JavaScript no final do corpo,

Proponho o seguinte método com base em respostas anteriores:

<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script>
<script type="text/javascript">

if(!window.jQuery)
{
    //Creates the script element
    var script = document.createElement('script'); 
    //Adds the type attribute with "text/javascript" value
        script.setAttribute('type', 'text/javascript'); 
    //Adds the source attribute and populates it
        script.setAttribute('src', 'Put_The_Relative_Path_To_Your_JavaScript_File_Here'); 
    //Adds it to the end of the body, as it is good practice, to prevent render-blocking.  
    document.body.appendChild(script);

}

//Note that there's no need for you to verify with an onload function, since all scripts
//must be loaded before going to the next one! 

</script>

0

Gostaria de acrescentar que hospedar uma cópia local é uma prática recomendada, porque nenhuma das opções acima menciona algo relacionado a uma postura segura, na qual a Localização geográfica e a Lista branca estrita são imperativas. Não hospedar esse arquivo localmente pressupõe uma postura de segurança reduzida em seus clientes.


Uma política de segurança que lista negra ou restringe a CDN do Google do jQuery quebrará muitos sites, não apenas o do solicitante. Em outras palavras, há problemas maiores com que se preocupar.

2
@ Snowman ... como o Great Firewall na China (que quebra regularmente sites do Stack Exchange que usam uma CDN para seus scripts)?
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.