La rapidité d'un site n'est PAS (encore) un critère exploité par Google en SEO

[WebRankInfo]

Maile Ohye, ingénieur chez Google, a indiqué récemment dans une conférence SMX que les performances d'un site en termes de vitesse n'étaient pas exploitées dans l'algo actuel de ranking (référencement naturel). Par contre Google travaille à incorporer ce critère donc autant s'y préparer. A priori si Google l'utilise, il pourrait le dire officiellement.

As of today, performance is not a factor in organic ranking. If performance becomes a signal, we expect to notify webmasters. But, hint: Google is pushing the importance of speed.

Source

Cela dit pour plein d'autres raisons il est préférable d'avoir un site rapide, nous sommes bien d'accord.

 

[abdelseo]

avant ce post j'ai cru que les performances d'un site compté pour le référencement naturel.
merci olivier

 

[Evenstood]

Moi je crois surtout qu'a moins d'avoir un site extrêmement gros et lourd, ce facteur n'est d'un mirage...

 

[Dystopie]

Faut faire la par des choses quand on dis que le seo et la vitesse d'affichage d'un site son lié c'est surtout par ce que google au bout de 30 secondes il va se lassé

 

[Zecat]

soit dit en passant, le user se sera lassé bien avant. Moi perso j'ai une limite psycho a disons 10/15s ... si rien ne vient je ferme.

 

[raljx]

T es large dit donc moi je tiens pas plus de 5s

 

[joe coe]

bizarrement depuis que j'ai fait une grosse part d'optimisation (le plus urgent seulement) je constate du mieux.
De là à savoir si cela vient de la rapidité du site je ne sais pas ...

Ceci dit quand on parle du temps de chargement d'une page il faudra savoir de quoi on parle ou plutot de quoi google parle.
un script ajax par exemple vu par iSlow donne un temps de chargement qui se termine avec le script ajax (c'est ce que j'ai constaté du moins). un script qui boucle pour des raisons de service donne un temps de chargement indéfini donc.

webmastertools donne deux temps de chargement différents (temps de téléchargement des pages en milisecondes coté diagnostic et temps de chargement moyen des pages coté labo).

On met là le doigt sur ce que sera "la rapidité d'un site" et suivants les critères retenus ça ne sera pas le même travail.
Et pour les sites qui vendent de la visibilité, la galère de la gestion de la pub va commencer...
iframe ok mais pas de gestion de couplage dans ce cas, pas non plus de gestion d'expend... donc l'iframe pour certains, c'est mort.
La rapidité du site dépend alors des temps de chargement des pubs fournis pas les agences qui sont loin, très loin de ce genre de préoccupations.

Bref ça nous promet des soirées heureuses tout ça :mrgreen:

 

[HawkEye]

Attention: la rapidité d'un site ne fait peut-être pas partie de l'algorithme, mais elle a un impact évident puisque Google adapte la fréquence de crawl de GoogleBot en fonction de la réponse-serveur.

 

[celibataire]

La rapidité du site influe sur le comportement de l'internaute, ce qui fait varier le nombre de pages vues moyen par visite (plus c'est long, moins je reste sur le site), ce qui donc influence le positionnement.

C'est donc pour moi une non-news, puisque ce facteur joue déjà indirectement et que l'on se doit de depuis un certain temps le prendre en compte.

 

[WebRankInfo]

depuis quand le nb de pages vues moyen par visite influence le positionnement ?
Je ne pense pas qu'on puisse l'affirmer ?

 

[Evenstood]

depuis quand le nb de pages vues moyen par visite influence le positionnement ?
Je ne pense pas qu'on puisse l'affirmer ?

Même remarque, lorsque je fais une recherche précise sur un thème d'actualité et que je tombe nez à nez avec l'article,je t'assure que je fais un taux de rebond mais que j'ai eu ce que je souhaitais (tx rebond positif !)...alors il y a que le crawl et la perfomance du site qui ont un rapport, loin de là le chemin de l'internaute sur ton site...


D'où il provient et le temps passé à la limite, mais pas plus

 

[raljx]

depuis quand le nb de pages vues moyen par visite influence le positionnement ?
Je ne pense pas qu'on puisse l'affirmer ?

en effet, le temps de chargement influe actuellement "seulement" sur le trafic ... mais c'est déjà une très bonne chose...

 

[u8086]

Les temps de chargement des pages à un énorme impact sur les coûts de Google pour crawler du web.

A mon avis, Google a fait un coup d'esbroufe en disant qu'ils envisageaient (ils ont jamais dit autre chose) de faire de la vitesse de chargement un critère... et ainsi pousser les webmaster/référenceurs à se préoccuper du sujet et baisser leurs couts de crawl de quelques millions.

Force est de constater que Google est capable d'altérer la nature du web sur une simple action de communication.

 

[e-kiwi]

Google Webmaster Tools me donne en moyenne 7 secondes pour monter les pages, heureusement qu'il ne tient pas compte de ce facteur

 

[raljx]

C'est tres facile de voir les points qui bloquent en utilisant les plugins firefox (pagespeed pour google et yslow) mais ca reste des points qui ne permettent pas globalement d'avancer (les CDN, les JS (non compressés car pas en local (pour adsense par exemple [compressé par google notament]) j'ai voulu m'y interessé mais tu bloques sur une question de structure ...
il suffit que tu es 3 pavés adsense pour perdre des points sur pagespeed (pire quand c'est pas GG) et donc analytiquement parlant devenir 'slow' aux yeux de GG même si la page testée mets -de 2s a charger) ...
a croire que pour devenir high speed faut se caler sur la home de Google :lol: donc 0 partenariat ... professionnellement parlant ce n'est pas des outils réellement utile ... c'est vraiment trop globalisé pour être utilisé ... ca te donne des voies a respecter cependant et plus principalement sur des notions de requêtes http et compression gzip (par ex). la c'est important niveau temps de chargement ..

Une expérience comme ca : il suffit de travailler avec une régie (même une très bonne régie (lagardere en autre) pour te voir plomber les stats en terme de CDN ou de requêtes<- a aujourdhui elles en ont rien a foutre les régies pubs de l'optimisation des d'affichages (AMHA elles vont devoir ce bouger dans les années a venir (on en parle ensemble actuellement))

 

[u8086]

Moi, GG WebmasterTools me dit que je dois limiter le nombre de résolutions DNS... en appelant pas http://pagead2.googlesyndication.com/pagead/show_ads.js

 

[raljx]

Moi, GG WebmasterTools me dit que je dois limiter le nombre de résolutions DNS... en appelant pas http://pagead2.googlesyndication.com/pagead/show_ads.js

en recuperant le js en local tu n'as plus ce probleme portnawak :mrgreen:

 

[pcamliti]

soit dit en passant, le user se sera lassé bien avant. Moi perso j'ai une limite psycho a disons 10/15s ... si rien ne vient je ferme.

Moi je m'endors

 

[mipc]

Moi, GG WebmasterTools me dit que je dois limiter le nombre de résolutions DNS... en appelant pas http://pagead2.googlesyndication.com/pagead/show_ads.js

en recuperant le js en local tu n'as plus ce probleme portnawak :mrgreen:

+1 j'ai moi même mis mon script GA GA.JS en local sur le serveur via: http://195.20.239.29/ga.js

tiens d'ailleurs une âme charitable pourrait elle m'aider à fusionner:
http://195.20.239.29/ga.js
et
http://195.20.239.29/t.js

vue que dieu google dans pagespeed le recommande.

c'est tout de même dingue que se soit toujours les produits et services google qui plombent la vitesse de chargement des pages, et qu'ils ne daignent en rien obéir à leurs propre recommandation en terme d'optimisation.

 

[Leonick]

Moi, GG WebmasterTools me dit que je dois limiter le nombre de résolutions DNS... en appelant pas http://pagead2.googlesyndication.com/pagead/show_ads.js

en recuperant le js en local tu n'as plus ce probleme portnawak :mrgreen:

ça ne pose pas de problème d'exécution du script le fait qu'il ne soit pas sur le serveur de google ? entres autres pour une gestion de cookie et s'il y a des appels ajax ?

 

[mipc]

Moi, GG WebmasterTools me dit que je dois limiter le nombre de résolutions DNS... en appelant pas http://pagead2.googlesyndication.com/pagead/show_ads.js

en recuperant le js en local tu n'as plus ce probleme portnawak :mrgreen:

ça ne pose pas de problème d'exécution du script le fait qu'il ne soit pas sur le serveur de google ? entres autres pour une gestion de cookie et s'il y a des appels ajax ?

ben faut tester, forcément si tu teste pas tu peux pas savoir, enfin je dis ça je dis rien hein!!!? :lol: :mrgreen: :roll:

edit: de plus avant de faire quelque chose, tu peux demander sur le forum de goolge pour savoir si tu à la droit de la faire ou pas avant, ou encore si c'est techniquement possible!!!!

 

[u8086]

Me semblait que c'était interdit aussi...

 

[nervusdm]

En même temps si ton site met 3 heures à se charger ( exemple ), pas beaucoup d'internaute risquent d'aimer ;p

 

[Røi]

J'aimerais qu'on nous dise "Google prétends que"

Parce que jusqu'à présent tout ce que Google nous raconte par le biais de ses VRPs je ne l'ai jamais gobé.

 

[ortolojf]

Le problème...

La rapidité de chargement d'une page, dépend aussi du débit ( haut-débit, très-haut-débit ou autre... ) de la ligne.

Comme ce sont des serveurs de Google qui font le crawling des Robots, c'est sûr que la vitesse réelle est très rapide, puisque ce ne peut être que du trèa haut débit.

On peut penser d'autre part, que Google se soucierait de ce problème, vis-à-vis de la lisibilité d'un site pour les visiteurs.

Cependant, les progrès de la technologie aidant, les choses ne seront plus les mêmes, puisque la généralisation du très haut débit, va rendre ce type de problématique obsolète...

Donc, le fait pour Google de tenir compte de la rapidité de chargement d'une page dépend des conditions précises de chargement, qui dépendent aussi du client. Google mesurerait comment cette rapidité, qui dépendrait avant tout du débit de la ligne ?

Qu'en pensez-vous ?

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[u8086]

Qu'ils mesurent la rapidité de réponse du serveur et le poids de ce qui est envoyé.

 

[ortolojf]

Qu'ils mesurent la rapidité de réponse du serveur et le poids de ce qui est envoyé.

Bonjour MagicYoyo

Bon, admettons.

Mais, tu sais bien que le débit réel descendant entre un serveur et un client, dépend avant tout de la caractéristique de la ligne client.

Le serveur de chaque sites, lui peut servir un grand nombre de clients simultanément.

D'autre part, cette problématique n'aura plus lieu d'être, quand tout le monde sera en très haut débit ( ~ 100 Mbits/sec ), puisque l'affichage des pages sera alors instantané, et n'influera pas sur le confort des visiteurs.

...Et à supposer que Google mesure cette rapidité d'après la nature des éléments chargés, le coefficient de pondération en fonction des caractéristiques moyennes des lignes client, ne peut être que très variable dans le temps ?

Merci beaucoup de ta réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[HawkEye]

Google adapte la fréquence et le volume de crawl en fonction de la réponse (délai et débit) qu'il reçoit du serveur, simplement.
Il ne le fait pas pour l'internaute: il le fait pour lui-même.

Fais le test: allège tes scripts pour gagner disons 1 à 2 secondes de chargement, et tu verras le nombre de pages crawlées par jour augmenter

 

[daerf59]

Bonjour,

Je pense que la vitesse de chargement d'un site est un critère important dans la construction d'un site. Meme si Google dit ne pas en prendre compte pour le moment.
Par exemple le temps de chargement des pages de destination via une campagne Adwords est prise en compte, cela influe sur la QS.
Donc dans tous les cas, c'est un critère à soigner.

 

[Leonick]

étant donné que les bots ne font qu'uploader les pages html, et que le temps de chargement tient compte des js, des images, des éventuels éléments (flash, vidéo, musique, ..) ajoutés, que les js ils ne les exécutent pas, ils les interprètent juste (pour trouver de nouveaux liens), donc leur mesure ne peut être que très partielle.
Au niveau d'adword, c'est fait manuellement je pense. Mais ce que l'on peut faire manuellement pour quelques comptes clients et automatiquement pour des millions de sites web, ça n'est pas la même chose

 

[ortolojf]

Google adapte la fréquence et le volume de crawl en fonction de la réponse (délai et débit) qu'il reçoit du serveur, simplement.
Il ne le fait pas pour l'internaute: il le fait pour lui-même.

Fais le test: allège tes scripts pour gagner disons 1 à 2 secondes de chargement, et tu verras le nombre de pages crawlées par jour augmenter

Bonjour HawkEye

le GWT de mon site indique un temps moyen de chargement de 2,2 secondes, et me situe parmi les 64% de sites les plus rapides. Cependant celà varie légèrement de temps en temps.

Le temps de chargement de ma page d'accueil est lui de 4,1 secondes environ, à cause des liens vers d'autres sites que j'ai, et des images.

Je ne sais pas si la page d'accueil est prise en compte plus que les autres pages. Les autres pages sont en général en dessous de 2 secondes de temps de chargement.

J'ai fait en sorte de ne fournir que des pages compressées avec gzip ( ce sont toutes des pages dynamiques ).

J'envisage de charger le script Javascript de Google Analytics en local, ce qui évitera une requête DNS par page, comme conseillé par le GWT, mais je ne sais pas comment être tenu aucourant de l'évolution/modifications ultérieures de ce script. j'ai peur que du jour au lendemain mes mesures Google Analytics deviennent obsolètes. Peut-être ai-je une peur irraisonnée psycho-névrotique...

Pour les pages intérieures, c'est sûr que si j'avais le moyen de me passer de Xiti gratuit, je gagnerais beaucoup ( en plus du script GA local ) sur le temps de chargement. Mais les statistiques de Xiti gratuits me sont très utiles.

Je n'ai pas mis à jour mes scripts Javascript de Xiti gratuit depuis longtemps. Est-il vrai que dans la nouvelle version de Xiti gratuit, le nouveau serveur Xiti est plus rapide que l'ancien ?

Merci beaucoup de vos réponses.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[mipc]

perso j'ai mon fichier GA en local http://195.20.239.29/ga.js et même j'ai mis le script asynchrone dans un fichier js http://195.20.239.29/t.js

pour les problèmes avec les mises à jour du script, tu peux le charger tous les jours ou tous les mois, je suis sur qu'il serait possible de lancer un script dans FileZila ou autre qui irait charger touts les jours le fichier ga.js à http://www.google-analytics.com/ga.js et qui l'envoi dans ton serveur web via FTP.

de toute façon si y avais une mise à jour majeurs du script on serai prévenue je pense.

 

[ortolojf]

perso j'ai mon fichier GA en local http://195.20.239.29/ga.js et même j'ai mis le script asynchrone dans un fichier js http://195.20.239.29/t.js

pour les problèmes avec les mises à jour du script, tu peux le charger tous les jours ou tous les mois, je suis sur qu'il serait possible de lancer un script dans FileZila ou autre qui irait charger touts les jours le fichier ga.js à http://www.google-analytics.com/ga.js et qui l'envoi dans ton serveur web via FTP.

de toute façon si y avais une mise à jour majeurs du script on serai prévenue je pense.

Bonsoir mipc

Voilà maintenant j'ai trouvé : Il suffit de mettre un script php dans le répertoire /scripts/ de mon site, qui télécharge simplement ce fichier ga.js avec l'instruction file($url), et qui l'écrive sur ce répertoire.

Je peux même faire en sorte que ce script de chargement soit appelé tous les jours, très facilement. Il suffit de le lancer à la fin de la mise à jour des Courses du lendemain/après-midi, ou même... d'incorporer le code de chargement du script ga.js à l'intérieur de la fonction qui met à jour les Courses du lendemain/après-midi.

Et en plus c'est simple comme bonjour.

Merci beaucoup de m'avoir donné la solution du problème.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[mipc]

de rien j'en suis ravis, fait tournez le script!!!!

 

[ortolojf]

de rien j'en suis ravis, fait tournez le script!!!!

Bonsoir mipc

Voilà c'est fait.

Je vais voir après-demain si mes stats de GA sont correctes.

Mais... Le protocole peut être http ou https au niveau du chargement, je suppose que cela ne change rien au niveau du code du script ga.js ?

Et puis... Est-ce que je peux remplacer à ton avis, le code Javascript de Google en bas de chaque page de mon site, en chargeant le script ga.js comme un fichier Javascript local, et non pas comme un fichier distant ?

A ce moment-là il n'y a plus de modification du protocole http en https le cas échéant... A quoi sert ce protocole https, si mon site est toujours en http ? Et surtout, Google Analytics va-t-il rouspéter en voyant ce nouveau code Javascript "maison" en bas de chacune de mes pages ?

Je sais bien comment intégrer un script Javascript local à mon site... ;(

Merci beaucoup de ta réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[Leonick]

perso j'ai mon fichier GA en local http://195.20.239.29/ga.js et même j'ai mis le script asynchrone dans un fichier js http://195.20.239.29/t.js

et ça ne pose aucun problème au niveau de tes stats GA ? du genre pas comptabilisé car cookies non enregistrés ?

 

[mipc]

perso j'ai mon fichier GA en local http://195.20.239.29/ga.js et même j'ai mis le script asynchrone dans un fichier js http://195.20.239.29/t.js

et ça ne pose aucun problème au niveau de tes stats GA ? du genre pas comptabilisé car cookies non enregistrés ?

non non toujours aussi peux de visiteurs, et même ceux sous windows phone et autre pdaphone sont comptabiliser, dans l'ensemble les stats sont les mêmes pour le moment je note un plus grand nombre de visite provenant des moteur de recherche par rapport à avant, donc à mon avis c'est ni mieux ni moins bien!!!!!

 

[mipc]

de rien j'en suis ravis, fait tournez le script!!!!

Bonsoir mipc

Voilà c'est fait.

Je vais voir après-demain si mes stats de GA sont correctes.

Mais... Le protocole peut être http ou https au niveau du chargement, je suppose que cela ne change rien au niveau du code du script ga.js ?

Et puis... Est-ce que je peux remplacer à ton avis, le code Javascript de Google en bas de chaque page de mon site, en chargeant le script ga.js comme un fichier Javascript local, et non pas comme un fichier distant ?

A ce moment-là il n'y a plus de modification du protocole http en https le cas échéant... A quoi sert ce protocole https, si mon site est toujours en http ? Et surtout, Google Analytics va-t-il rouspéter en voyant ce nouveau code Javascript "maison" en bas de chacune de mes pages ?

Je sais bien comment intégrer un script Javascript local à mon site... ;(

Merci beaucoup de ta réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

pour le moment se que moi j'ai fais dont mes pages HTML dans le HEAD j'ai

<script type="text/javascript" src="http://195.20.239.29/t.js"></script></head>

dans mon fichier http://195.20.239.29/t.js j'ai :

var _gaq=_gaq||[];_gaq.push(['_setAccount','UA-XXXXXXX-X']);_gaq.push(['_trackPageview']);(function(){var ga=document.createElement('script');ga.type='text/javascript';ga.async=true;ga.src=('https:'==document.location.protocol?'https://ssl':'http://')+'195.20.239.29/ga.js';(document.getElementsByTagName('head')[0]||document.getElementsByTagName('body')[0]).appendChild(ga);})();

noté que là c'est pas la version de travail mais la version dite minified, ça revient au même.

 

[joe coe]

Le problème...

La rapidité de chargement d'une page, dépend aussi du débit ( haut-débit, très-haut-débit ou autre... ) de la ligne.

Comme ce sont des serveurs de Google qui font le crawling des Robots, c'est sûr que la vitesse réelle est très rapide, puisque ce ne peut être que du trèa haut débit.

On peut penser d'autre part, que Google se soucierait de ce problème, vis-à-vis de la lisibilité d'un site pour les visiteurs.

Cependant, les progrès de la technologie aidant, les choses ne seront plus les mêmes, puisque la généralisation du très haut débit, va rendre ce type de problématique obsolète...

Salut,

Sans vouloir faire mon rabat joie, je pense que le coeur du problème est ailleurs...
Google via youtube est régulièrement pointé du doigt par les opérateurs. Les réseaux commencent a être sur saturés et personne ne veut payer pour que youtube se développe correctement. Le passage à la HD bouffe une bande passante considérable, le développement du web mobile ne permet plus de supporter la bande passante nécessaire.

Mon avis est que Google veut se racheter une virginité en mettant en avant la bande passant gagnée "grace à lui".
Personne ne peut resté insensible aux déclarations de google (ok 1% des sites et je suis gentil). On est tous en pleine réflexion sur les sprites, la compression gzip... Bref ce que dit Google à mon avis c'est que précisément, si nous pouvions cesser de penser que la technologie permet de s'affranchir de notre bande passante, on se met le doigt dans l'oeil... GG ne manquera pas de nous le rappeler quand c'est nécessaire. Place à la vidéo, prière de compresser vos sites. amha.

 

[ortolojf]

pour le moment se que moi j'ai fais dont mes pages HTML dans le HEAD j'ai

<script type="text/javascript" src="http://195.20.239.29/t.js"></script></head>

dans mon fichier http://195.20.239.29/t.js j'ai :

var _gaq=_gaq||[];_gaq.push(['_setAccount','UA-XXXXXXX-X']);_gaq.push(['_trackPageview']);(function(){var ga=document.createElement('script');ga.type='text/javascript';ga.async=true;ga.src=('https:'==document.location.protocol?'https://ssl':'http://')+'195.20.239.29/ga.js';(document.getElementsByTagName('head')[0]||document.getElementsByTagName('body')[0]).appendChild(ga);})();

noté que là c'est pas la version de travail mais la version dite minified, ça revient au même.

Bonsoir mipc ( ou Bon Matin c'est selon )

Bof, j'ai squizzé le https, et j'ai mis simplement le même code, en enlevant la variable gaJsHost qui spécifie le protocole, et ramené l'url du src à : src='/google/ga.js'

Il n'y a pas de raisons pour que des visiteurs essayent de voir mon site en https , faudrait vraiment être tordu.

Je n'utilise pas le ssl, et je n'ai pas du tout l'intention de l'utiliser à terme.

Il est vrai que le code de Google pour interpréter le protocole, est une vraie contorsion qui refait passer par du Javascript. Bof, je pourrais tout aussi bien mettre simplement la ligne :

<script src="/google/ga.js" type="text/javascript"></script>

... suivie du reste du code.

La variable gsJsHost ne se trouve pas dans le code du script ga.js

Qu'en penses-tu ?

Pour un site sans ssl, cette simple ligne suffirait ?

Merci beaucoup de ta réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo


NB Je ne comprend pas pourquoi tu ne garde pas le code de Google, pour interpréter le protocole éventuellement https. Le code de Google est beaucoup plus simple...

 

[mipc]

je suis une tanche en tous, en plus particulier tous se qui touche de près ou de loin à la programmation, je ne fais que chiper des bout de code ça et la que je teste, pour le moment ça marche, hier j'ai appris à faire un liens JS et un popup c'est te dire le niveau.

je pille allègrement des bouts de code sans trop savoir se que je fais, et je lance firebug(je regarde le code HTML et JS, si la structure semble la même) et je regarde mes stats google voir si c'est cohérent avec les semaines précédente.

tu aura pus remarquer que j'ai utiliser le script asynchrone hors si le script js est dans un fichier, celui-ci ne devrait pas fonctionner en mode asynchrone pour le script GA.js c'est confirmer par firebug, preuve que je ne sais pas trop se que je fais, je teste à l'arracher et pour le moment ça fonctionne.

 

[Ukri]

je teste à l'arracher et pour le moment ça fonctionne.

:mrgreen: Je te vois trop à "balancer" des bouts de code au hasard et voir ce que ça donne lol

 

[ortolojf]

je suis une tanche en tous, en plus particulier tous se qui touche de près ou de loin à la programmation, je ne fais que chiper des bout de code ça et la que je teste, pour le moment ça marche, hier j'ai appris à faire un liens JS et un popup c'est te dire le niveau.

je pille allègrement des bouts de code sans trop savoir se que je fais, et je lance firebug(je regarde le code HTML et JS, si la structure semble la même) et je regarde mes stats google voir si c'est cohérent avec les semaines précédente.

tu aura pus remarquer que j'ai utiliser le script asynchrone hors si le script js est dans un fichier, celui-ci ne devrait pas fonctionner en mode asynchrone pour le script GA.js c'est confirmer par firebug, preuve que je ne sais pas trop se que je fais, je teste à l'arracher et pour le moment ça fonctionne.

Bon Matin mipc

En fait, tu utilises bien l'url complète avec l'adresse ip au lieu du nom de domaine alphabétique, comme c'est une url complète, tu peux très bien utiliser directement le code que Google préconise.

Voici le code :

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "domain.tld/google/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-XXXXXXX-X");
pageTracker._trackPageview();
} catch(err) {}</script>


Evidemment à la place de domain.tld tu mets ton nom de domaine ou ton adresse ip ( ça n'a pas d'importance, la requête DNS a déjà été faite et mémorisée par le navigateur ).

Au lieu de /google/ga.js tu met le répertoire dans lequel tu as mis le script ga.js

Et, évidemment, en mettant ton identificateur de site.

J'avais fait l'erreur de mettre une url non distante avec seulement le répertoire et le fichier. Ca ne pouvait pas marcher.

Le seul et unique problème, c'est d'éviter une requête DNS supplémentaire, et pour cela héberger le script ga.js sur son serveur.

Après, ça roule...

Merci beaucoup de ta réponse.

Bien à vous.

Amicalement.

Jean-François Ortolo

 

[mipc]

je teste à l'arracher et pour le moment ça fonctionne.

:mrgreen: Je te vois trop à "balancer" des bouts de code au hasard et voir ce que ça donne lol

se serai un problème si ça ne fonctionnait pas, la c'est le contraire, ça fonctionne!!!!! :mrgreen:

pour le moment mon script fonctionne je ne touche à rien, le nombre de visiteurs comptabiliser qu'ils soit sous IE ou FIREFOX ou même IE6 et opera semblent tous comptabiliser correctement, les chiffres sont cohérents donc que demander de plus, tant que ça marche on touche à rien, surtout et à plus forte raison si on ne sais pas comment ça marche :mrgreen: !!!