Referenciando javascript externo vs. hospedando minha própria cópia

Você deve fazer as duas coisas:

Comece a hospedagem em um CDN, como do Google , porque ele provavelmente terá um nível mais alto -time do que o seu próprio site e será configurado para o tempo de resposta mais rápido. Além disso, qualquer pessoa que tenha visitado uma página vinculada ao CDN usará a cópia em cache do arquivo para que não seja necessário 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('<scriptsrc="/path/to/jquery-ver.sion.min.js"><\/script>');
</script>

Certifique-se de não escrever </script> em qualquer lugar dentro de um elemento <script> , pois ele fechará o elemento HTML e fará com que o script falhe. A correção simples é usar uma barra invertida como escape: <\/script> .

_{Mais uma razão para fazer as duas coisas:}

Se você escolher um CDN popular, é altamente improvável que ele tenha algum tempo de inatividade, no entanto, no futuro distante (~ 18 meses a partir de agora <Moore's law ) quando o formato de hospedagem muda, ou o endereço é ajustado, ou a rede é colocada atrás de um paywall, ou qualquer outra coisa, é possível que seu link não funcionará mais como está. Se você usar um substituto, ele lhe dará um pouco de tempo para se adaptar a qualquer novo formato de hospedagem antes de ter que voltar por todos os sites que você criou e alterar os links 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 em que havia vinculado cópias locais de recursos de script e descobri rapidamente que havia vários projetos que precisavam ter cópias locais vinculadas.

Eu fiz a mesma pergunta, então eu li esta artigo e fui vendido com a ideia de deixar o Google hospedar minha biblioteca jQuery.

O artigo declara os principais benefícios de permitir que suas bibliotecas sejam hospedadas pela Rede de Distribuição de Conteúdo (CDN) do Google:

• Diminuição da latência : os usuários que não estão fisicamente próximos do servidor poderão fazer o download do jQuery mais rapidamente do Google do que se você forçá-los a fazer o download do servidor localizado arbitrariamente.
• Paralelismo Aumentado - Os navegadores limitam o número de conexões que podem ser feitas simultaneamente. Dependendo de qual navegador, esse limite pode ser tão baixo quanto duas conexões por nome de host. O uso do CDN Bibliotecas AJAX do Google elimina uma solicitação para o seu site, permitindo que mais conteúdo local seja baixado em paralelo.
• Better Caching - Usando as bibliotecas do Google AJAX, seus usuários podem não precisar baixar o jQuery. Por outro lado, se você estiver hospedando o jQuery localmente, seus usuários deverão fazer o download pelo menos uma vez. Cada um dos seus usuários provavelmente já possui dúzias de cópias idênticas do jQuery no cache do navegador, mas essas cópias do jQuery são ignoradas quando visitam o site.

Quanto aos dois pontos listados como profissionais para hospedar sua própria biblioteca, lembre-se de que o Google hospeda a versão da nuvem, e o Google sabe o que está fazendo e pode ser confiável na medida em que a disponibilidade e a segurança estejam. No entanto, @zzzzBov faz um bom ponto em sua resposta a esta pergunta, onde ele recomenda também armazenar uma cópia local da biblioteca e padronizá-la no caso improvável de que a versão do CDN não possa ser acessada por qualquer motivo.

Pessoalmente, aceito o link

<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 extrai o arquivo principal do jQuery do Google, mas se ele não for carregado por algum motivo, a próxima linha carregará ele do seu próprio servidor.

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

Estou adicionando essa resposta para apontar algo que muitas vezes é negligenciado ao apontar para outro lugar, o que é evitar o aviso de conteúdo misto . Considere o uso de URLs sem protocolo, por exemplo:

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

Ainda há alguns problemas de suporte ao usar URLs sem protocolo, por isso, dê uma olhada nas respostas em Posso alterar todos os meus http: // links para apenas //? em SO, mas pelo menos tente lidar com possíveis avisos de conteúdo misto em alguns caminho.

Você deve consultá-lo para a biblioteca de APIs do Google .

O principal motivo para isso é acelerar os carregamentos de sua página . Se o usuário já visitou outro site referenciando a mesma biblioteca, ele já estará armazenado no cache do navegador e ele não precisará ser baixado em todos os .

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,

Eu proponho o seguinte método com base nas 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>

Gostaria de acrescentar que hospedar uma cópia local é uma prática recomendada, porque nenhuma das ações acima menciona algo relacionado a uma postura segura, em que o Geo Location e a White Listing são imperativos. Não hospedar esse arquivo localmente pressupõe que haja uma postura de segurança reduzida em seus clientes.