Prós e contras de scripts hospedados [fechado]


12

Vi alguns desenvolvedores usarem scripts hospedados para vincular suas bibliotecas.

cdn.jquerytools.org é um exemplo.

Também vi pessoas reclamarem que um link de script hospedado foi invadido.

Quão seguro é o uso de scripts hospedados na realidade? Os scripts são atualizados automaticamente? Por exemplo, se o jQuery 5 for 6, obtenho a versão 6 automaticamente ou preciso atualizar meu link?

Também vejo que o Google tem um grande conjunto desses scripts de configuração para hospedagem.

Quais são os prós e contras?

Respostas:


11

Prós

  • Seus scripts são carregados mais rapidamente . Se você possui uma abundância de recursos que precisam ser carregados de um único domínio, seu navegador normalmente afunila isso para que você tenha apenas algumas solicitações paralelas ao mesmo host. Portanto, se você estiver carregando dezesseis scripts separados, várias imagens e vários documentos CSS, haverá fila enquanto cada recurso aguarda sua vez de ser carregado. (Definitivamente, concatenar seus arquivos CSS e Javascript - carregar apenas dois recursos de script será significativamente mais rápido).
  • Se você girar esses recursos em um domínio separado, no entanto, seu navegador não terá problemas para abrir conexões adicionais com esse servidor, o que significa que mais recursos são carregados simultaneamente, resultando em uma execução mais rápida da página. Você também está permitindo que um servidor diferente lide com parte do carregamento da página, o que é bom para o servidor que provavelmente está trabalhando em várias solicitações de execução de scripts.
  • Além disso, esses servidores CDN (redes de distribuição de conteúdo) são configurados para operar como CDNs. Eles são tipicamente sem cozimento (para tamanhos de pacotes menores) e são configurados com um servidor extremamente leve que se preocupa totalmente com a veiculação de recursos e o armazenamento em cache de recursos comumente usados, e não tanto com o levantamento diário que algo como um padrão comum O servidor Apache irá executar.
  • O uso de uma CDN como o Google ou a Akami também traz outros benefícios - o Google possui servidores em todo o mundo e seus sistemas de roteamento são inteligentes o suficiente para emparelhar uma solicitação de recurso com a cópia geográfica mais próxima que existe. Seu servidor pode estar tentando servir o jQuery.js para Vladimir na Rússia - o Google provavelmente tem o mesmo recurso na rua abaixo de Vladimir, diminuindo a latência.
  • Além disso, como muitos sites já usam essas CDNs, há uma alta probabilidade de que o recurso que você está servindo já tenha sido armazenado em cache pelo usuário. O jQuery.js do seu servidor e o jQuery.js do servidor do Google não são tratados como o mesmo arquivo, independentemente de serem exatamente iguais - se você carregar no Google, ele poderá usar a cópia em cache do site anterior que o usuário visitou.
  • Os arquivos em si não serão alterados, especialmente para recursos de script como estruturas Javascript. Se uma nova versão for lançada, o Google continuará hospedando a versão antiga (não importa o quão hediondo os bugs), especificamente para que a CDN continue funcionando normalmente e não atenda a solicitações ruins. É por isso que qualquer arquivo CDN possui o sufixo completo com o número da versão apropriado.

Contras

  1. Existe a possibilidade do seu CDN não estar disponível. As chances, no entanto, são menores que o seu site, provavelmente. CDNs maiores, como Google e Akami, têm várias camadas de failover.
  2. Criar uma nova conexão pode não valer a pena se você tiver apenas um ou dois recursos para carregar do seu próprio servidor.
  3. Você não tem nenhum controle sobre o arquivo que está sendo veiculado; portanto, o uso da sua versão personalizada do jQuery ou de qualquer outra coisa que você está tentando carregar está esgotado, a menos que você esteja pagando pelo seu próprio CDN.

Segurança

Eu recomendaria este post do El Stack, além de uma boa quantidade de Googling sobre o assunto. Cada CDN será diferente, embora, em poucas palavras, eu pense que isso seria uma preocupação menor.


1

Algo que ninguém mencionado é mais uma opção de rastreamento para o Google. Eles não estão oferecendo todos esses serviços sem nenhum custo e sem motivo. O AdSense e o Analytics são suficientes e pelo menos esses podem ser filtrados. Isso é um grande golpe no meu livro.


0

Prós:

  • Você não precisa pagar pela largura de banda relacionada à veiculação dos arquivos e, geralmente,

Contras:

  • Você está sujeito à disponibilidade do provedor de hospedagem que você está usando (se eles forem desativados por qualquer motivo, você também estará desativado).
  • Você forçou a qualquer versão dos scripts que os provedores de hospedagem possuem

Existem outros benefícios do uso de uma CDN, mas eles não se relacionam diretamente ao uso de um terceiro serviço de hospedagem de scripts.


0

No que diz respeito às práticas recomendadas, a abordagem comum para otimizar o carregamento da página é agrupar todos os seus recursos de JS, devido ao número restrito de conexões para um único domínio, como Jarrod mencionou, e definir um cabeçalho de vencimento futuro muito distante na resposta.

O que as CDNs trazem para essa mistura, especialmente as populares, como Jarrod também apontou, é que o usuário já teria acessado a URL anteriormente e pode recuperar o recurso JS imediatamente do cache de seu cliente, sem precisar estabelecer uma conexão.

Nesse sentido, se todos nós usamos CDNs e empregamos práticas recomendadas, podemos evitar que o usuário recupere ~ 10 a 50 KB adicionais quando acessar inicialmente nossos URLs e permitir que eles carreguem suas páginas mais rapidamente.

Eu recomendo fortemente o uso de CDNs por dois motivos: os contras mencionados por Jarrod são verdadeiros, mas completamente insignificantes e se você já estiver agrupando suas fontes em um único documento, forçará todos a recuperar, digamos, a parte estática do jQuery do o documento (~ 33 KB) toda vez que você atualizar um dos recursos agrupados.

Eu não sei o quão importante isso soa para você, mas com grandes bases de usuários, isso leva a um corte significativo na largura de banda e economias significativas, dos quais podemos desviar para assuntos mais prementes, como streaming de pornografia e compra de cervejas.


-2

Não faça

Pessoalmente, eu não confiaria em scripts hospedados por terceiros. Se você aproveitar os scripts de outras pessoas, estará à mercê deles. Há várias coisas a considerar:

  1. Se o site for desativado, a página poderá expirar ou ocorrer um erro.
  2. Se eles saem do negócio e desativam a hospedagem, você acaba de perder toda essa funcionalidade
  3. Se eles forem hackeados, você também poderá ser hackeado.
  4. O script entre sites pode causar estragos nos certificados SSL
  5. O tempo de carregamento da página pode aumentar drasticamente
  6. Se a interface mudar, você precisará modificar todas as chamadas de função

É mais seguro hospedar o código em seu próprio site, confie em mim. Você só precisa se queimar uma vez e ter 250 sites que você construiu e hospeda começa a agir de maneira engraçada porque confiou em um script hospedado de terceira parte que parou de funcionar.


1
Acho que se você usar um CDN grande e confiável, provavelmente não enfrentará muitas de suas preocupações. 1.) Espero que o CDN do Google tenha um tempo de atividade muito bom, 2.) Não vejo o Google encerrando suas atividades tão cedo, 3.) É plausível, mas novamente esperaria correções / correções muito rápidas, 4 .) Não vi nenhum problema. 5.) Se for uma CDN respeitável, o carregamento da página deve ser realmente mais rápido do que o que você provavelmente pode oferecer (entre pipelining, cache de vários sites e domínios sem cookies), 6.) Para bibliotecas com versão principal, como jQuery, não deve ter problema.
scunliffe

1
... também, não há nada que o impeça de implementar seus próprios scripts de fallback caso os CDN remotos falhem.
scunliffe

Nenhuma dessas razões listadas pela Cape Cod Gunny são preocupações válidas com CDNs modernas como o Google ou com muitos outros grandes fornecedores de CDN por aí.
Jarrod Nettles
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.