Por que mover seus arquivos JavaScript para um domínio principal diferente que você também próprio?

Question

Tenho notado que apenas no último ano ou assim, muitos dos principais sites fizeram a mesma alteração na forma como suas páginas são estruturados. Cada mudou seus arquivos Javascript de ser hospedado no mesmo domínio como a própria página (ou um subdomínio do que), a ser hospedado em um domínio diferente nomeado.

Não é simplesmente paralelização

Agora, há uma técnica bem conhecida de espalhar os componentes da sua página em vários domínios para download parallelize. Yahoo recomenda que como fazem muitos outros. Por exemplo, www.example.com é onde seu HTML está hospedado, então você colocar imagens em images.example.com e javascripts em scripts.example.com . Isso fica em torno do fato de que a maioria dos navegadores limitar o número de conexões simultâneas por servidor, a fim de ser bons cidadãos líquidos.

A descrição acima é não o que eu estou falando.

Não é simplesmente redirecionamento para uma rede de distribuição de conteúdo (ou talvez seja - ver parte inferior da pergunta)

O que eu estou falando Javascripts sobre hospedagem é especificamente sobre um domínio completamente diferente. Deixe-me ser específico. Apenas no último ano ou assim eu tenho notado que:

youtube.com se mudou seus arquivos js para ytimg.com

cnn.com se mudou seus arquivos js para cdn.turner.com

weather.com se mudou seus arquivos js para j.imwx.com

Agora, eu sei sobre redes de entrega de conteúdo, como Akamai que se especializam em terceirização deste para grandes websites. (O nome "CDN" em pistas de domínio especiais de Turner nos para a importância deste conceito aqui).

Mas nota com estes exemplos, cada site tem seu próprio domínio especificamente registrado para esta finalidade, e não é o domínio de uma rede de distribuição de conteúdo ou outro provedor de infra-estrutura. Na verdade, se você tentar carregar a página inicial a maior parte destes domínios de script, eles geralmente redirecionar de volta para o domínio principal da empresa. E se você inverter lookup os IPs envolvidos, eles às vezes ponto para servidores de uma empresa CDN, às vezes não.

aparecer

Por que eu me importo?

Tendo anteriormente trabalhou em duas empresas de segurança diferentes, I foram feitas paranóico de Javascripts maliciosos.

Como resultado, eu sigo a prática de whitelisting sites que eu permitirão Javascript (e outro conteúdo ativo como Java) para correr. Como resultado, para fazer um site como o cnn.com trabalho corretamente, eu tenho que colocar manualmente cnn.com em uma lista. É uma dor no traseiro, mas eu prefiro-o sobre a alternativa.

Quando as pessoas utilizado coisas como scripts.cnn.com para paralelizar, que funcionou bem com wildcarding apropriado. E quando as pessoas usadas subdomínios fora dos domínios da empresa CDN, eu poderia simplesmente permitir domínio principal da empresa CDN com um curinga na frente também e matar muitos pássaros com uma pedra (como * .edgesuite.net e * .akamai.com).

Agora eu descobri que (a partir de 2008) isso não é suficiente. Agora eu tenho que picar ao redor no código-fonte de uma página que eu quero whitelist, e descobrir o que "segredo" de domínio (ou domínios) que o site está usando para armazenar seus Javascripts diante. Em alguns casos, eu achei que eu tenho para permitir três domínios diferentes para fazer uma obra site.

Por que todos esses grandes sites de começar a fazer isso?

EDIT: OK como 'onebyone', destacou , parece estar relacionado com a entrega CDN de conteúdo. Então deixe-me modificar a pergunta ligeiramente baseado em sua pesquisa ...

Por que é weather.com usando j.imwx.com em vez de twc.vo.llnwd.net ?

Por que é youtube.com usando s.ytimg.com em vez de static.cache.l.google.com ?

Tem de um raciocínio por trás disso.

Answer 1

O seu follow-up questão é essencialmente:? Supondo que um popular site está usando uma CDN, por que eles usam seu próprio TLD como imwx.com em vez de um subdomínio (static.weather.com) ou domínio do CDN

Bem, a razão para usar um domínio que controlam contra o domínio do CDN é que eles manter o controle - eles poderiam até mudar CDNs inteiramente e só tem que mudar um registro DNS, contra ter que atualizar os vínculos em 1000s de páginas / aplicações.

Então, por que os nomes de domínio uso absurdo? Bem, uma coisa grande com arquivos auxiliares como js e CSS é que você quer que eles sejam armazenados em cache a jusante por proxies e navegadores das pessoas, tanto quanto possível. Se uma pessoa atinge gmail.com e todos os js é carregado para fora de seu cache do navegador, o site parece muito snappier a eles, e também economiza largura de banda na extremidade do servidor WINS (todos). O problema é que uma vez que você enviar cabeçalhos HTTP para cache muito agressivo (ou seja, cache de me para uma semana ou um ano ou para sempre), esses arquivos não são sempre confiável carregado a partir do servidor mais e você não pode fazer alterações / correções para -los, porque as coisas vão quebrar em navegadores das pessoas.

Então, o que as empresas têm de fazer é palco essas mudanças e realmente mudar as URLs de todos esses arquivos para navegadores força das pessoas para recarregá-las. Ciclismo através de domínios como "a.imwx.com", "b.imwx.com" etc. é como isso é feito.

Ao usar um nome de domínio absurdo, os desenvolvedores de JavaScript e seus Javascript sysadmin / contrapartes ligação CDN pode ter seu próprio nome de domínio / DNS que eles estão empurrando essas mudanças através, de que eles são responsáveis ??/ autónomo para.

Então, se qualquer tipo de cookie-bloqueio ou começos de bloqueio de script que acontecem no TLD, eles simplesmente mudar de um TLD absurdo kyxmlek.com ou qualquer outra coisa. Eles não têm que se preocupar com acidentalmente fazendo algo mal que tem efeitos colaterais contramedida em todos * .google.com.

Answer 2

tráfego de cookie limite?

Depois de um cookie é definido em um domínio específico, a cada pedido nesse domínio terá o cookie enviado de volta para o servidor. Cada pedido!

Isso pode acrescentar-se rapidamente.

Answer 3

Muitas razões:

CDN - um nome DNS diferente faz com que seja mais fácil de mudar ativos estáticas para uma rede de distribuição de conteúdo

O paralelismo - imagens, folhas de estilo, e estático javascript estiver usando duas outras ligações que não estão indo para bloquear outros pedidos, como retornos de chamada ajax ou imagens dinâmicas

tráfego

Cookie - exatamente correto - especialmente com sites que têm o hábito de armazenar muito mais do que um simples id de sessão em cookies

Load shaping - mesmo sem um CDN ainda há boas razões para hospedar os ativos estáticos em menos servidores web otimizado para responder muito rapidamente a um grande número de solicitações de arquivo de URL, enquanto o resto do site está hospedado em um número maior de servidores que respondem a mais solicitações dinâmicas processamento intensivo

---

Atualização - duas razões que você não usa o nome DNS do CDN. O nome dns cliente age como uma chave para o bom "colméia" de ativos do CDN é o cache. Também desde o CDN é um serviço de mercadoria que você pode alterar o fornecedor, alterando o registro DNS -. Para que você possa evitar qualquer alteração de página, reconfiguração, ou reafectação no seu site

Answer 4

Eu acho que há algo na teoria CDN:

Por exemplo:

$ host j.imwx.com
j.imwx.com              CNAME   twc.vo.llnwd.net
twc.vo.llnwd.net        A       87.248.211.218
twc.vo.llnwd.net        A       87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
  Limelight Networks Inc.
  2220 W. 14th Street
  Tempe, Arizona 85281-6945
  United States

Limelight é um CDN.

Enquanto isso:

$ host s.ytimg.com
s.ytimg.com             CNAME   static.cache.l.google.com
static.cache.l.google.com       A       74.125.100.97

Eu estou supondo que este é um CDN para conteúdo estático executado internamente pelo Google.

$ host cdn.turner.com
cdn.turner.com A record currently not present

Ah, bem, não pode ganhar 'em todos.

A propósito, se você usar o Firefox com o NoScript add-on, então ele irá automatizar o processo de caça através da fonte, e GUI-FY o processo de whitelisting. Basicamente, clique no ícone NoScript na barra de status, você está dado uma lista de domínios com opções para temporariamente ou permanentemente whitelist, incluindo "tudo sobre esta página".

Answer 5

I implementada esta solução de dois a três anos em uma empresa anterior, quando o site começou a ficar sobrecarregado devido a uma implementação de servidor web legado. Ao mover as imagens CSS e layout de folga para um servidor Apache, que reduziu a carga sobre o servidor principal e aumentou a velocidade sem fim.

No entanto, eu sempre fui a impressão de que funções Javascript só pode ser acessado de dentro do mesmo domínio como a própria página. sites mais novos não parecem ter essa limitação:. como você menciona, muitos têm arquivos JavaScript em sub-domínios separados ou domínios até mesmo completamente isoladas por completo

Alguém pode me dar um ponteiro sobre por que isso agora é possível, quando não era um par de anos atrás?

Answer 6

Não é apenas JavaScript que você pode mover para diferentes domínios, mas como muitos ativos quanto possível trará melhorias de desempenho.

A maioria dos navegadores têm um limite para o número de ligações simultâneas que você pode fazer para um único domínio (eu acho que é cerca de 4) assim quando você tem um monte de imagens, js, css, etc Há muitas vezes, mantenha-se em baixar cada arquivo .

Você pode usar algo como YSlow e Firebug para ver quando cada arquivo é baixado do servidor.

Por ter ativos em domínios separados lo a diminuir a carga em seu primário e podem ter conexões mais simultanious e fazer download de mais arquivos em um determinado momento.

Recentemente, lançamos um site realestate que tem um monte de imagens (das casas, duh: P), que utiliza este princípio para as imagens, por isso é muito mais rápido para listar os dados

.

Também usei isso em muitos outros sites que têm alta volumne ativos.

Answer 7

Eu acho que você respondeu sua própria pergunta.

Eu acredito que o problema é relacionado à segurança, ao invés de PORQUE.

Talvez uma nova tag META é a fim de que descreveria CDNs válidos para a página em questão, em seguida, toda a necessidade que é um navegador add-on para lê-los e agir em conformidade.

Answer 8

Seria por causa do bloqueio feito por filtros de spam e de conteúdo? Se eles usam domínios estranhos, então é mais difícil de descobrir e / ou você vai acabar bloqueando algo que você quer.

Não sei, apenas um pensamento.

Answer 9

Se eu fosse uma empresa grande nome, multi-marca, penso que esta abordagem faria sentido porque você quer tornar o código javascript disponível como uma biblioteca. Eu gostaria de fazer tantas páginas ser tão consistente quanto possível, a lidar com as coisas como endereços, nomes de estado, códigos postais. AJAX provavelmente faz essa preocupação proeminente.

No modelo atual de negócios de internet, domínios são marcas, não nomes de rede. Se você se comprado ou marcas de spin-off, você acaba com uma série de mudanças de domínio. Este é um problema, mesmo para os locais mais proeminentes.

Há ainda links que apontam para a documentos úteis no * .netscape.com e * .mcom.com que estão muito longe.

Netscape diz:

"Em 12 de outubro de 2004, o popular site desenvolvedor Netscape DevEdge foi fechado pela AOL. DevEdge era um recurso importante para tecnologias relacionadas à Internet, mantendo documentação definitiva no navegador Netscape, documentação sobre tecnologias associadas, como HTML e JavaScript, e artigos populares escritos por líderes da indústria e tecnologia, como Danny Goodman. Alguns conteúdos de DevEdge foi republicado no site da Mozilla. "

Então, isso seria, em menos de um período de 10 anos:

• Mosaic Communications Corporation
• Netscape Communications Corporation
• AOL
• AOL Time Warner
• Time Warner

Se você colocar o código em um domínio que não é um nome de marca, você reter uma grande quantidade de flexibilidade e você não tem que refazer todos os pontos de entrada, controle de acesso e referências de código quando os sites são re- nomeado.

Answer 10

Eu tenho trabalhado com uma empresa que faz isso. Eles estão em um datacenter w / bastante boa troca de tráfego, de modo que o raciocínio CDN não é tão grande para eles (talvez ele iria ajudar, mas eles não fazê-lo por essa razão). A razão é que eles executar vários servidores web em paralelo que lidar colectivamente as suas páginas dinâmicas (scripts PHP), e eles servem imagens e alguns javascript fora de um domínio separado em que eles usam um rápido, servidor web leve como lighttpd ou uso do tHttpd para servir imagens e javascript estático.

PHP requer PHP. Estática Javascript e imagens não fazer. Muita coisa pode ser retirados de um servidor web cheio de recursos quando tudo que você precisa fazer é o mínimo absoluto.

Claro, eles provavelmente poderia usar um proxy que redireciona solicitações para um subdiretório específico para um servidor diferente, mas é mais fácil simplesmente lidar com todo o conteúdo estático com um servidor diferente.