Pourquoi déplacer vos fichiers Javascript vers un autre domaine principal que vous possédez également?

Question

J'ai remarqué qu'au cours de la dernière année environ, de nombreux sites Web majeurs ont modifié de la même manière la structure de leurs pages. Chacun d'entre eux a déplacé ses fichiers Javascript d'être hébergés sur le même domaine que la page elle-même (ou un sous-domaine de celui-ci) vers un autre nom de domaine.

Ce n'est pas simplement la parallélisation

Maintenant, il existe une technique bien connue consistant à répartir les composants de votre page sur plusieurs domaines afin de paralléliser le téléchargement. Yahoo le recommande , comme beaucoup d'autres. Par exemple, www.example.com héberge votre code HTML. Vous placez ensuite les images sur images.exemple.com et les javascripts sur scripts.exemple.com. . Cela évite le fait que la plupart des navigateurs limitent le nombre de connexions simultanées par serveur afin d’être de bons citoyens nets.

Ce qui précède n’est pas ce dont je parle.

Il ne s'agit pas simplement d'une redirection vers un réseau de diffusion de contenu (ou peut-être est-ce le cas - voir le bas de la question)

Ce dont je parle, c'est l'hébergement de javascripts spécifiquement sur un domaine entièrement différent. Laissez-moi être spécifique. Au cours de la dernière année environ, j'ai remarqué que:

youtube.com a déplacé ses fichiers .JS vers ytimg.com

.

cnn.com a déplacé ses fichiers .JS vers cdn.turner.com

.

weather.com a déplacé ses fichiers .JS vers j.imwx.com

.

Je connais maintenant des réseaux de diffusion de contenu tels que Akamai , spécialisés dans l'externalisation de sites Web volumineux. (Le nom "cdn" dans le domaine spécial de Turner nous indique l'importance de ce concept ici).

Toutefois, notez que, avec ces exemples, chaque site a son propre domaine spécifiquement enregistré à cette fin, et non le domaine d’un réseau de diffusion de contenu ou d’un autre fournisseur d’infrastructure. En fait, si vous essayez de charger la page d'accueil de la plupart de ces domaines de script, ils sont généralement redirigés vers le domaine principal de la société. Et si vous inversez la recherche des adresses IP impliquées, elles parfois semblent pointer vers les serveurs d'une société de CDN, parfois non.

Pourquoi est-ce que je m'en soucie?

Ayant travaillé dans deux entreprises de sécurité différentes, je suis devenu paranoïaque de javascripts malveillants.

En conséquence, je suis habitué à mettre en liste blanche des sites sur lesquels j’autorise le fonctionnement de Javascript (et d’autres contenus actifs, tels que Java). Par conséquent, pour qu'un site tel que cnn.com fonctionne correctement, je dois manuellement mettre cnn.com dans une liste. C'est une douleur dans le derrière, mais je le préfère à l'alternative.

Lorsque des personnes utilisaient des éléments tels que scripts.cnn.com pour se mettre en parallèle, cela fonctionnait sans problème avec un caractère générique approprié. Et lorsque les gens utilisaient des sous-domaines des domaines de la société CDN, je pouvais simplement autoriser le domaine principal de la société CDN avec un caractère générique devant et tuer de nombreux oiseaux d'une pierre (tels que * .edgesuite.net et * .akamai.com).

Maintenant, j'ai découvert qu'en 2008, cela ne suffisait pas. Maintenant, je dois fouiller dans le code source d'une page que je veux ajouter à la liste blanche et trouver ce que "secret" domaine (ou domaines) que ce site utilise pour stocker leurs Javascripts sur. Dans certains cas, j’ai constaté que je devais autoriser trois domaines différents à faire fonctionner un site.

Pourquoi tous ces sites majeurs ont-ils commencé à le faire?

EDIT: OK as " onebyone " souligné , cela semble être lié à la diffusion de contenu sur CDN. Alors permettez-moi de modifier légèrement la question en fonction de ses recherches ...

Pourquoi weather.com utilise-t-il j.imwx.com au lieu de twc.vo.llnwd.net ?

Pourquoi YouTube> utilise-t-il s.ytimg.com au lieu de static.cache.l.google.com ?

Il y a un raisonnement derrière cela.

Answer 1

Votre question suivante est essentiellement la suivante: en supposant qu'un site Web populaire utilise un CDN, pourquoi utiliseraient-ils leur propre TLD comme imwx.com au lieu d'un sous-domaine (static.weather.com) ou du domaine du CDN?

Eh bien, la raison d'utiliser un domaine qu'ils contrôlent par rapport au domaine du CDN est qu'ils conservent le contrôle - ils pourraient même potentiellement changer complètement les CDN et ne devoir modifier qu'un enregistrement DNS, au lieu de devoir mettre à jour des liens dans des milliers de pages / applications.

Alors, pourquoi utiliser des noms de domaine insensés? Eh bien, un gros problème avec les fichiers auxiliaires tels que .js et .css est que vous voulez qu'ils soient mis en cache en aval par les mandataires et les navigateurs des utilisateurs autant que possible. Si une personne accède à gmail.com et que tous les fichiers .js sont chargés hors de la mémoire cache de leur navigateur, le site semble beaucoup plus attrayant pour eux et permet également d'économiser de la bande passante côté serveur (tout le monde gagne). Le problème est qu’une fois que vous envoyez des en-têtes HTTP pour une mise en cache très agressive (c’est-à-dire une mémoire cache pendant une semaine, une année ou pour toujours), ces fichiers ne sont plus chargés de manière fiable à partir du serveur et vous ne pouvez plus y apporter de modifications / corrections. parce que ça va casser dans les navigateurs des gens.

Les entreprises doivent donc organiser ces modifications et modifier les URL de tous ces fichiers pour forcer les navigateurs à les recharger. Parcourir des domaines tels que "a.imwx.com", "b.imwx.com" etc., voici comment cela se fait.

En utilisant un nom de domaine insensé, les développeurs Javascript et leurs homologues de liaison Javascript / CDN peuvent avoir leur propre nom de domaine / DNS par lequel ils insèrent ces modifications, pour lequel ils sont responsables / autonomes.

Ensuite, si un blocage du cookie ou du script commence à se produire sur le TLD, il ne fait que passer d'un TLD non-sens à kyxmlek.com ou à un autre lieu. Ils n'ont pas à s'inquiéter de faire quelque chose de mal qui a des effets secondaires contre tous * .google.com.

Answer 2

Limiter le trafic de cookies?

Une fois qu'un cookie est défini sur un domaine spécifique, le cookie est renvoyé au serveur à chaque demande adressée à ce domaine. Chaque demande!

Cela peut s’ajouter rapidement.

Answer 3

Beaucoup de raisons:

CDN: un nom de DNS différent facilite le transfert d’actifs statiques vers un réseau de distribution de contenu

.

Parallélisme - les images, les feuilles de style et le javascript statique utilisent deux autres connexions qui ne vont pas bloquer les autres demandes, telles que les rappels ajax ou les images dynamiques

Trafic de cookies - tout à fait correct - en particulier pour les sites qui ont l’habitude de stocker beaucoup plus qu’un simple identifiant de session dans les cookies

Mise en forme de la charge - même sans CDN, il existe toujours de bonnes raisons d’héberger les actifs statiques sur moins de serveurs Web optimisés pour répondre extrêmement rapidement à un grand nombre de demandes d’URL de fichiers, le reste du site étant hébergé sur un plus grand nombre. des serveurs répondant à des requêtes dynamiques plus gourmandes en ressources processeur

update - deux raisons pour lesquelles vous n'utilisez pas le nom DNS du CDN. Le nom DNS du client agit comme une clé pour le bon "ruche". des actifs que le CDN met en cache. De plus, votre CDN étant un service de base, vous pouvez changer de fournisseur en modifiant l’enregistrement DNS. Vous éviterez ainsi tout changement de page, toute reconfiguration ou tout redéploiement sur votre site.

Answer 4

Je pense qu'il y a quelque chose dans la théorie CDN:

Par exemple:

$ 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 est un CDN.

Pendant ce temps:

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

Je suppose qu'il s'agit d'un CDN pour un contenu statique exécuté en interne par Google.

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

Eh bien, je ne peux pas tous les gagner.

En passant, si vous utilisez Firefox avec le module complémentaire NoScript, il automatisera le processus de recherche dans les sources et GUI-fy le processus de liste blanche. Pour résumer, cliquez sur l'icône NoScript dans la barre d'état. Une liste de domaines avec des options permettant d'ajouter une liste blanche de manière temporaire ou permanente, notamment "Tout sur cette page", vous est proposée.

Answer 5

J'ai mis en œuvre cette solution il y a environ deux ou trois ans chez un employeur précédent, lorsque le site Web a commencé à être surchargé en raison de la mise en œuvre d'un serveur Web hérité. En transférant le CSS et les images de présentation sur un serveur Apache, nous avons réduit la charge sur le serveur principal et augmenté la vitesse sans fin.

Cependant, j'ai toujours eu l'impression que les fonctions Javascript ne sont accessibles qu'à partir du même domaine que la page elle-même. Les sites Web les plus récents ne semblent pas avoir cette limitation: comme vous le dites, beaucoup ont des fichiers Javascript sur des sous-domaines distincts, voire même des domaines complètement détachés.

Quelqu'un peut-il me dire pourquoi cela est maintenant possible, alors que ce n'était pas le cas il y a quelques années?

Answer 6

Le javascript ne permet pas uniquement de passer à différents domaines, mais le plus grand nombre d'actifs possible apportera des améliorations de performances.

La plupart des navigateurs ont une limite au nombre de connexions simultanées que vous pouvez établir vers un seul domaine (je pense que c'est environ 4) alors quand vous avez beaucoup d'images, js, css, etc., le téléchargement de chaque fichier est souvent long. .

Vous pouvez utiliser quelque chose comme YSlow et FireBug pour voir quand chaque fichier est téléchargé à partir du serveur.

En disposant des ressources sur des domaines distincts, vous réduisez la charge de votre serveur principal. Vous pouvez disposer de connexions plus simultanées et télécharger plus de fichiers à tout moment.

Nous avons récemment lancé un site Web immobilier contenant de nombreuses images (des maisons, duh: P) qui utilise ce principe pour les images. Il est donc beaucoup plus rapide de répertorier les données.

Nous l'avons également utilisé sur de nombreux autres sites Web à fort volume d'actifs.

Answer 7

Je pense que vous avez répondu à votre propre question.

Je pense que votre problème est lié à la sécurité plutôt qu'à POURQUOI.

Une nouvelle balise META est peut-être en ordre pour décrire les CDN valides pour la page en question. Dans ce cas, tout ce dont nous avons besoin est un module complémentaire du navigateur pour les lire et se comporter en conséquence.

Answer 8

Cela serait-il dû au blocage effectué par les filtres anti-spam et de contenu? S'ils utilisent des domaines étranges, il est alors plus difficile de comprendre et / ou de bloquer quelque chose que vous voulez.

Nul, juste une pensée.

Answer 9

Si j’étais un grand nom et une entreprise multimarques, je pense que cette approche serait logique car vous souhaitez que le code javascript soit disponible sous forme de bibliothèque. Je voudrais que le plus grand nombre de pages possible soit aussi cohérent que possible dans la gestion de choses telles que les adresses, les noms d'états et les codes postaux. AJAX met probablement cette préoccupation en avant.

Dans le modèle économique Internet actuel, les domaines sont des marques et non des noms de réseau. Si vous obtenez des marques achetées ou dérivées, vous vous retrouvez avec beaucoup de changements de domaine. C'est un problème même pour les sites les plus en vue.

Il existe encore des liens pointant vers des documents utiles dans * .netscape.com et * .mcom.com qui ont disparu depuis longtemps.

Wikipedia pour Netscape dit:

  

"Le 12 octobre 2004, le populaire site Web pour développeurs Netscape DevEdge a été fermé par AOL. DevEdge était une ressource importante pour les technologies liées à Internet, en conservant une documentation définitive sur le navigateur Netscape, une documentation sur les technologies associées telles que HTML et JavaScript, ainsi que des articles populaires écrits par des chefs de file du secteur et des technologies, tels que Danny Goodman. Certains contenus de DevEdge ont été republiés sur le site Web de Mozilla. "

Donc, ce serait, dans moins de 10 ans:

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

Si vous placez le code dans un domaine qui n'est PAS une marque, vous conservez une grande flexibilité et vous n'avez pas à refactoriser tous les points d'entrée, le contrôle d'accès et les références de code lorsque les sites Web sont restaurés. nommé.

Answer 10

J'ai travaillé avec une entreprise qui le fait. Ils sont dans un centre de données avec un assez bon peering, donc le raisonnement CDN n'est pas aussi grand pour eux (cela aiderait peut-être, mais ils ne le font pas pour cette raison). La raison en est qu'ils exécutent en parallèle plusieurs serveurs Web qui gèrent collectivement leurs pages dynamiques (scripts PHP), et qu'ils servent des images et du javascript à partir d'un domaine séparé sur lequel ils utilisent un serveur Web léger et rapide, tel que lighttpd ou thttpd. images et javascript statique.

PHP nécessite PHP. Javascript statique et les images non. Il est possible de supprimer un serveur Web complet lorsque tout ce que vous devez faire est le minimum absolu.

Bien sûr, ils pourraient probablement utiliser un proxy qui redirige les demandes vers un sous-répertoire spécifique vers un autre serveur, mais il est plus facile de gérer tout le contenu statique avec un autre serveur.