Google ne mange pas des bébés, ils envoient juste des gens sur la lune. Perso je préfèrerais qu'ils mangent des bébés ça règlerait les problèmes de surpopulation mondiale et permettrait de réduire le réchauffement du CO2 (humour inside).
Pour le côté technique :
1. il a quand même raison la requête passe par google, donc google peut collecter des données (ça veux pas dire qu'ils le font, mais c'est possible).
2. c'est une mauvaise idée en terme de performances. Tu requête le site ted.com. Ton résolveur DNS a donc déjà ted.com en cache, ce qui fait que faire une requête sur ted.com sera plus rapide que faire une requête sur googletruc.com. Concernant le cache, si l'admin sys/dév web/webmaster/whatever du site ne sait pas configurer le cache de son serveur web, il ferait mieux de RTFM ASAP. Au niveau de la charge, on peut leur présenter nginx, mais de toutes façons c'est un fichier statique qui sera dans le cache du client, donc niveau charge ça devrait aller.
3. vu le nombre de fichiers JS et CSS qu'ils chargent de tous les côtés (TED.com, pas google hein), je pense pas que ça soit les performances du client qu'ils recherchent (de toutes manières on ne peux rien espérer de la part de gens qui mettent encore des img src="blank.gif" en 2010.
C'est un peu comme OpenDNS ou Google Public DNS, ils te racontent que c'est vachement plus rapide et tout, mais en fait non car rien ne sera plus rapide que ton DNS local ou celui de ton FAI qui est bien plus proche de toi qu'eux.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: Ou alors...
Posté par BohwaZ (site web personnel, Mastodon) . En réponse au journal NCIS. Évalué à 0.
Pour le côté technique :
1. il a quand même raison la requête passe par google, donc google peut collecter des données (ça veux pas dire qu'ils le font, mais c'est possible).
2. c'est une mauvaise idée en terme de performances. Tu requête le site ted.com. Ton résolveur DNS a donc déjà ted.com en cache, ce qui fait que faire une requête sur ted.com sera plus rapide que faire une requête sur googletruc.com. Concernant le cache, si l'admin sys/dév web/webmaster/whatever du site ne sait pas configurer le cache de son serveur web, il ferait mieux de RTFM ASAP. Au niveau de la charge, on peut leur présenter nginx, mais de toutes façons c'est un fichier statique qui sera dans le cache du client, donc niveau charge ça devrait aller.
3. vu le nombre de fichiers JS et CSS qu'ils chargent de tous les côtés (TED.com, pas google hein), je pense pas que ça soit les performances du client qu'ils recherchent (de toutes manières on ne peux rien espérer de la part de gens qui mettent encore des img src="blank.gif" en 2010.
C'est un peu comme OpenDNS ou Google Public DNS, ils te racontent que c'est vachement plus rapide et tout, mais en fait non car rien ne sera plus rapide que ton DNS local ou celui de ton FAI qui est bien plus proche de toi qu'eux.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)