De onde você inclui a biblioteca jQuery? JSAPI do Google? CDN?

Existem algumas maneiras de incluir jQuery e jQuery UI e estou me perguntando o que as pessoas estão usando?

• JSAPI do Google
• Site do jQuery
• seu próprio site / servidor
• outro CDN

Recentemente, eu uso o Google JSAPI, mas descobri que leva muito tempo para configurar uma conexão SSL ou mesmo para resolver o google.com. Eu tenho usado o seguinte para o Google:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>

Gosto da ideia de usar o Google para que ele seja armazenado em cache ao visitar outros sites e economizar largura de banda do nosso servidor, mas, se continuar sendo a parte mais lenta do site, posso alterar a inclusão.

O que você usa? Você já teve algum problema?

Editar: Apenas visitei o site do jQuery e eles usam o seguinte método:

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

Edit2: Veja como eu incluí o jQuery sem problemas no último ano:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

A diferença é a remoção de http:. Ao remover isso, você não precisa se preocupar em alternar entre http e https.

Sem dúvida, opto por ter o JQuery servido pelos servidores da API do Google. Eu não segui o método jsapi, já que não utilizo nenhuma outra API do Google; no entanto, se isso mudar, consideraria isso ...

Primeiro: os servidores API do Google são distribuídos em todo o mundo, em vez do meu único servidor: servidores mais próximos geralmente significam tempos de resposta mais rápidos para o visitante.

Segundo: muitas pessoas optam por ter o JQuery hospedado no Google; portanto, quando um visitante chega ao meu site, ele já pode ter o script JQuery no cache local. O conteúdo pré-armazenado em cache geralmente significa tempos de carregamento mais rápidos para o visitante.

Terceiro: Minha empresa de hospedagem cobra pela largura de banda usada. Não faz sentido consumir 18 mil por sessão de usuário se o visitante puder obter o mesmo arquivo em outro lugar.

Entendo que confio no Google uma porção de confiança para veicular o arquivo de script correto e estar online e disponível. Até o momento, não fiquei desapontado com o uso do Google e continuarei com essa configuração até que faça sentido.

Uma coisa que vale a pena destacar ... Se você possui uma mistura de páginas seguras e inseguras em seu site, pode alterar dinamicamente a fonte do Google para evitar o aviso habitual exibido ao carregar conteúdo inseguro em uma página segura:

Aqui está o que eu vim com:

<script type="text/javascript">
    document.write([
        "\<script src='",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>" 
    ].join(''));
</script>

ATUALIZAÇÃO 8/9/2010 - Algumas sugestões foram feitas para reduzir a complexidade do código removendo o HTTP e HTTPS e simplesmente usando a seguinte sintaxe:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Além disso, você também pode alterar o URL para refletir o número principal do jQuery se quiser ter certeza de que a versão principal mais recente das bibliotecas do jQuery foi carregada:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Por fim, se você não quiser usar o Google e preferir o jQuery, poderá usar o seguinte caminho de origem (lembre-se de que o jQuery não suporta conexões SSL):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>

Um motivo pelo qual você pode hospedar em um servidor externo é solucionar as limitações do navegador de conexões simultâneas com um servidor específico.

No entanto, como o arquivo jQuery que você está usando provavelmente não será alterado com muita frequência, o cache do navegador entrará em ação e fará com que esse ponto seja discutido na maior parte do tempo.

O segundo motivo para hospedá-lo em um servidor externo é diminuir o tráfego para o seu próprio servidor.

No entanto, dado o tamanho do jQuery, é provável que seja uma pequena parte do seu tráfego. Você provavelmente deve tentar otimizar seu conteúdo real.

O jQuery 1.3.1 min tem apenas 18k de tamanho. Acho que isso não é pedir demais no carregamento da página inicial. Será armazenado em cache depois disso. Como resultado, eu mesmo o hospedo.

Se você deseja usar o Google, o link direto pode ser mais responsivo. Cada biblioteca tem o caminho listado para o arquivo direto. Este é o caminho do jQuery

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Basta reler sua pergunta. Existe algum motivo para usar https? Esta é a tag de script que o Google lista no exemplo

<script src="http://www.google.com/jsapi"></script>

Eu não gostaria que nenhum site público que desenvolvi dependesse de qualquer site externo e, portanto, eu mesmo hospedaria o jQuery.

Você está disposto a ter uma interrupção no seu site quando o outro (Google, jquery.com etc.) cai? Menos dependências é a chave.

Prós: o host no Google tem benefícios

• Provavelmente mais rápido (seus servidores são mais otimizados)
• Eles lidam com o cache corretamente - 1 ano (lutamos para poder fazer as alterações para obter os cabeçalhos corretos em nossos servidores)
• Os usuários que já tiveram um link para a versão hospedada pelo Google em outro domínio já têm o arquivo em seu cache

Contras:

• Alguns navegadores podem vê-lo como domínio cruzado XSS e não permitir o arquivo.
• Particularmente usuários executando o plugin NoScript para Firefox

Gostaria de saber se você pode incluir do Google e, em seguida, verificar a presença de alguma variável global, ou algo assim, e se a carga de ausência do seu servidor?

Existem alguns problemas aqui. Primeiro, o método de carregamento assíncrono que você especificou:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load('jquery', '1.3.1');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

tem alguns problemas. As tags de script pausam o carregamento da página enquanto são recuperadas (se necessário). Agora, se o carregamento for lento, isso é ruim, mas o jQuery é pequeno. O verdadeiro problema com o método acima é que, como o carregamento do jquery.js ocorre independentemente em muitas páginas, eles terminam de carregar e renderizar antes do carregamento do jquery, portanto, qualquer estilo de jquery que você fizer será uma alteração visível para o usuário .

A outra maneira é:

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Tente alguns exemplos simples, como, ter uma tabela simples e altere o plano de fundo das células para amarelo com o método setOnLoadCallback () vs $ (document) .ready () com uma carga estática de jquery.min.js. O segundo método não terá cintilação perceptível. A primeira vontade. Pessoalmente, acho que não é uma boa experiência do usuário.

Como exemplo, execute isso:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

Você (deve) vê a tabela aparecer e as linhas ficam amarelas.

O segundo problema com o método google.load () é que ele hospeda apenas um intervalo limitado de arquivos. Este é um problema para o jquery, pois é extremamente dependente do plug-in. Se você tentar incluir um plug-in jquery com uma <script src="...">tag e google.load()o plug-in provavelmente falhará com as mensagens "jQuery não está definido" porque ainda não foi carregado. Eu realmente não vejo uma maneira de contornar isso.

O terceiro problema (com qualquer um dos métodos) é que eles são uma carga externa. Supondo que você tenha alguns plug-ins e seu próprio código Javascript, você deve ter no mínimo duas solicitações externas para carregar seu Javascript. Provavelmente, é melhor você obter o jquery, todos os plug-ins relevantes e seu próprio código e colocá-lo em um arquivo minificado.

De você deve usar a API de bibliotecas Ajax do Google para hospedagem? :

Quanto aos tempos de carregamento, você está realmente carregando dois scripts - o script jsapi e o mootools (a versão compactada de cima). Portanto, são duas conexões, em vez de uma. Na minha experiência, descobri que o tempo de carregamento era na verdade 2-3 vezes mais lento do que o carregamento do meu servidor compartilhado pessoal, mesmo que fosse do Google, e minha versão do arquivo compactado era duas vezes maior que a do Google. Isso, mesmo depois que o arquivo foi carregado e (presumivelmente) armazenado em cache. Então, para mim, como a largura de banda não importa muito, não importa.

Por fim, você tem o problema potencial de um navegador paranóico sinalizando a solicitação como algum tipo de tentativa de XSS. Normalmente, não é um problema com as configurações padrão, mas nas redes corporativas em que o usuário pode não ter controle sobre qual navegador usar, sem falar nas configurações de segurança que você pode ter.

Portanto, no final, não consigo me ver usando a API do Google AJAX para jQuery pelo menos (as APIs mais "completas" são uma história diferente em alguns aspectos) muito, exceto para postar exemplos aqui.

Além das pessoas que aconselham hospedá-lo no próprio servidor, propus mantê-lo em domínio separado (por exemplo, static.website.com) para permitir que os navegadores o carreguem em outro segmento de conteúdo. Essa dica também funciona para todas as coisas estáticas, como imagens e css.

Eu tenho que votar em -1 nas bibliotecas hospedadas no Google. Eles estão coletando dados, no estilo do Google Analytics, com seus invólucros em torno dessas bibliotecas. No mínimo, não quero que um navegador cliente faça mais do que estou pedindo, muito menos qualquer outra coisa na página. Na pior das hipóteses, esta é a "nova versão" do Google de não ser má - usando javascript discreto para coletar mais dados de uso.

Nota: se eles mudaram essa prática, super. Mas na última vez em que pensei em usar as bibliotecas hospedadas, monitorei o tráfego http de saída no meu site, e as chamadas periódicas aos servidores do Google não eram algo que eu esperava ver.

Eu posso ser antiquado sobre isso, mas continuo franzindo o cenho. Talvez o Google seja a exceção, mas, em geral, são realmente boas maneiras hospedar os arquivos em seu próprio servidor.

Vou adicionar isso como um motivo para hospedar esses arquivos localmente.

Recentemente, um nó no sul da Califórnia no TWC não conseguiu resolver o domínio ajax.googleapis.com (para usuários com IPv4) apenas, portanto, não estamos obtendo os arquivos externos. Isso foi intermitente até ontem (agora é persistente.) Como era intermitente, eu estava tendo muitos problemas para solucionar problemas de usuário do SaaS. Passamos inúmeras horas tentando rastrear por que alguns usuários não estavam tendo problemas com o software e outros estavam se afogando. No meu processo de depuração habitual, não tenho o hábito de perguntar a um usuário se o IPv6 está desativado.

Eu tropecei no problema porque eu mesmo estava usando essa "rota" específica para o arquivo e também usando apenas IPV4. Eu descobri o problema com as ferramentas dos desenvolvedores dizendo que o jquery não estava carregando e comecei a fazer traceroutes, etc ... para encontrar o problema real.

Depois disso, provavelmente nunca voltarei a arquivos hospedados externamente porque: o google não precisa ser desativado para que isso se torne um problema e ... qualquer um desses nós pode ser comprometido com o seqüestro de DNS e fornecer js maliciosos em vez do arquivo real. Sempre pensei que estava seguro, pois um domínio do Google nunca seria desativado, agora sei que qualquer nó entre um usuário e o host pode ser um ponto de falha.

Eu apenas incluí a versão mais recente do site jQuery: http://code.jquery.com/jquery-latest.pack.js Atende às minhas necessidades e nunca preciso me preocupar em atualizar.

EDIT: Para um aplicativo Web importante, certamente o controle; faça o download e sirva você mesmo. Mas para o meu site pessoal, eu não poderia me importar menos. As coisas não desaparecem magicamente, geralmente são preteridas primeiro. Eu o acompanho o suficiente para saber o que mudar para lançamentos futuros.

Aqui, algum recurso útil, a esperança pode ajudá-lo a escolher sua CDN. A MS recentemente adicionou um novo domínio para entrega de bibliotecas através de sua CDN.

Formato antigo: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js Novo formato: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

Isso não deve enviar todos os cookies para microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Aqui estão algumas estatísticas sobre a tecnologia mais popular usada na Web em todas as tecnologias. http://trends.builtwith.com/

A esperança pode ajudá-lo a escolher.

Se eu sou responsável pelo site 'ao vivo' é melhor eu estar ciente de tudo o que está acontecendo e para o meu site. Por esse motivo, eu mesmo hospedo a versão jquery-min no mesmo servidor ou em um servidor estático / externo, mas de qualquer maneira em um local em que apenas eu (ou meu programa / proxy) possa atualizar a biblioteca depois de verificar / testar todas as alterações

Na cabeça:

  (function() {
    var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
    jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
  })();

Fim do corpo:

<script type="text/javascript">
google.load("jquery", "version");
</script>

Eu o hospedo com meus outros arquivos js no meu próprio servidor e, nesse ponto, os combino e minifico (com django-compresser, aqui, mas esse não é o ponto) para serem servidos como apenas um arquivo js, ​​com todo o site necessidades colocadas nele. Você precisará servir seus próprios arquivos js de qualquer maneira, por isso não vejo razão para não adicionar os bytes jquery extras também - alguns kbs são muito mais baratos para transferir do que mais solicitações a serem feitas. Você não depende de ninguém e, assim que seu js minificado é armazenado em cache, você é super rápido também.

Na primeira carga, uma solução baseada em CDN pode vencer, porque você deve carregar os kilobytes de jquery adicionais do seu próprio servidor (mas, sem uma solicitação adicional). Duvido que a diferença seja perceptível, no entanto. E então, em um primeiro carregamento com cache limpo, sua própria solução hospedada provavelmente sempre será muito mais rápida, devido a mais solicitações (e pesquisas de DNS) necessárias, para buscar o jquery CDN.

Eu me pergunto como esse ponto quase nunca é mencionado e como as CDNs parecem dominar o mundo :)