Visites qui dégringolent ... ou pas ?

[hubs]

Bonjour
je créé ce topic parce que celui que j'ai ouvert il y a 10 jours n'a pas recueilli le moindre avis. Je me suis certainement mal exprimé.
Les pages de mon site comportent les scripts de StatCounter et de Google Analytics.
Le 19 Octobre, les visites repérées par Stat Counter et par Google Analytics ont commencé à chuter dramatiquement :

Mais pour Search console, il n'y a pas de changement

(Sur ce dernier graphique, il manque les 2 derniers jours)

D'après Google, les stats rapportées par Search Console devraient être inférieures à celles d'Analytics. Or, ce n'est visiblement pas le cas.
Question 1 : Le nombre de visite chute-t-il réellement ?

Par ailleurs, StatCounter me dit que 78% des visiteurs utilisent IE :

ce qui me semble plutôt suspect : auparavant, mes visiteurs étaient représentatifs de la moyenne, avec Chrome + Firefox avoisinant les 75%.

Question 2 : quelqu'un aurait-il la moindre idée de ce qui se passe ?

En remerciant par avance toutes les bonnes volontés

 

[UsagiYojimbo]

As-tu vérifié que les 2 tags fonctionnent correctement et sont bien implémentés sur toutes tes pages ?

 

[hubs]

oui. Tout fonctionnait bien avant. Par acquis de conscience, j'ai tout réinstallé. Même StatCounter m'a renvoyé un script à mettre en place.

Sur StatCounter, dans la rubrique "Pages populaires", j'ai une proportion qui reste faible, mais qui augmente (13 sur les 200 dernières valeurs), de visites provenant de copies locales de mes pages (copies sur les postes des visiteurs). Ce qui me fait penser que quelque chose d'étrange se passe. Mais sur 2 compteurs en même temps ?

J'ajoute que j'arrive toujours en première page chez Google pour bon nombre des mos-clés que je cible ...

 

[rick38]

Curieux.
Se souvenir s'il y a eu une update du site le 18 ou 19 octobre (on sait jamais, un bug qui ferait foirer les scripts JS sur Chrome et Firefox, voir tout le site).
Regarder si en étant sous Chrome ou FF, et en étant dans le menu temps réel sur Google Analytics, vous voyez bien votre visite en cours.
Je ne vois pas trop d'explication.

 

[hubs]

le 16, j'ai ajouté la ligne
Header set Content-Security-Policy "script-src 'self' https://analytics.google.com https://www.google.com/maps http://maps.google.com https://maps.googleapis.com https://statcounter.com http://www.c.statcounter.com s7.addthis.com/js/300"
dans le .htaccess ("on" me dit que l'absence de cette ligne déplait à Google...)

J'ai bien sûr pensé que j’empêchais ainsi les scripts de s'exécuter, j'ai donc fait machine arrière, la ligne est précédée d'un # dans le fichier (mais je ne l'ai pas fait disparaitre).

Et quand je suis avec Chrome ou Firefox, sur une page "essai.html", que j'ai créée il y a quelques jours justement pour ce genre de vérifications, et qui est en noindex pour que je sois le seul à m'y promener, La page temps réel de GAnalytics ne me voit pas. Mais avec IE, si !

Je n'y comprends rien non plus.

 

[hubs]

je viens de tester le retour au code Google Universal (et pas le nouveau gtag.js) : pas de changement. GAnalytics ne me voit pas en temps réel.
Et j'ai supprimé le code Statcounter (des fois qu'il y aurait un mélange de karmas incompatibles entre les deux) : aucun changement.

 

[anemone-clown]

L'installation de règles CSP (Content-Security-Policy) doit bloquer certaines choses, notamment des sous-script installés à d'autres url que celles autorisées...

 

[UsagiYojimbo]

Ouais donc ça pue le souci technique on site.

 

[rick38]

En bref bonne nouvelle : les visites ne dégringolent pas.

 

[hubs]

Merci pour vos analyses. Ceci dit, souci technique on site : peut-être bien, mais :
1) j'ai supprimé le CSP sans résultat
2) IE aurait un comportement très différent des autres ? et il y aurait un comportement différent entre les différentes versions de Firefox ou de Chrome (puisque j'(ai tout de même quelques touches de ce côté là )?

et surtout
3) quelle piste explorer pour tout remettre au clair ?

Peut-on imaginer quelque chose chez sivit (mon hébergeur, en mutualisé) ?

pour info, mon htaccess comporte ça aujourd'hui :

Header set X-XSS-Protection: "1; mode=block"
Header set X-Frame-Options: DENY
Header set X-Content-Type-Options: nosniff
Header set Referrer-Policy: strict-origin-when-cross-origin
#Header set Content-Security-Policy "script-src 'self' https://analytics.google.com https://www.google.com/maps http://maps.google.com https://maps.googleapis.com https://statcounter.com http://www.c.statcounter.com s7.addthis.com/js/300"


Sinon, je pense comme vous que les visites ne dégringolent pas, et que ce sont les compteurs qui ne voient pas tout. Mais ça ne me satisfait pas.

 

[hubs]

J'ai trouvé (enfin, je crois)

J'ai modifié le .htaccess en supprimant la directive content-security-policy. Et là tout refonctionne de manière quasi-instantanée: StatCounter et Analytics voient de nouveau les utilisateurs de Chrome et de Firefox. En 3 heures, j'ai presque autant de pages vues que le total d'hier + avant-hier. Et j'ai un site plutôt consulté par des professionnels au boulot ou des étudiants, surtout en semaine, peu le week-end, peu pendant les vacances. Donc pour un dimanche après-midi, c'est plus que bien.

Moralité :
1) un # n'invalide pas une ligne dans le htaccess
2) sauf pour IE - et pour quelques autres navigateurs

Moralité de la moralité : à quand une norme en béton, comprise et appliquée de la même manière par tout le monde ?

merci aux contributeurs qui m'ont fait réfléchir.

 

[UsagiYojimbo]

Les directives du .htaccess se jouent côté serveur, pas côté navigateur. Aucune chance que le # ne soit pas interprété comme un commentaire sur tous les navigateurs existants (qui n'ont pas accès à ce fichier de toute manière).

 

[hubs]

Oui, c'est ce que j'avais lu aussi.

Je suis un partisan du rasoir d'Occam (c'est la solution la plus simple, celle qui fait appel au plus petit nombre d'hypothèses, qui est la bonne), alors j'accepterai toute explication rationnelle qui explique comment :
1) supprimer la ligne "de commentaire" a eu un effet instantané
2) seuls les visiteurs utilisant IE (ou presque seuls) renvoyaient les codes js .

pour ce soir, on va oublier.

 

[rick38]

Moi je préfère croire aux hypothèses les plus rationnelles que la non-prise en compte du # :
* Peut-être que l'upload du .htaccess n'a pas fonctionné
* Peut-être que le serveur a gardé un cache du .htaccess et n'a pas vraiment pris en compte sa nouvelle version
* Peut-être qu'il était présent dans un répertoire parent et aussi dans le sous-dossier (le dossier pointé étant prioritaire au parent) sous deux versions différentes

 

[hubs]

bonjour
moi aussi, j'aimerais bien que l'upload ait mal fonctionné, ou qu'il y ait eu un une copie en cache quelque part. Mais je n'arrive pas à voir comment cela permettrait la présence ultra majoritaire de visiteurs sous IE. A cette heure (6 h 53, soit 16 heures après que les choses soient rentrées dans l'ordre), IE ne représente déjà plus que 52% des visiteurs, pour les 500 dernières pages vues (contre 78% juste avant la modif). D'ici ce soir, je parie que ce sera inférieur à 20%, valeurs traditionnelle.

Mais ceci dit, je m'en moque un peu. L'important est que tout roule désormais.
Merci encore, et bonne journée !

 

[UsagiYojimbo]

Tout dépend de la manière dont les différents navigateurs gèrent le cache...

 

[hubs]

Oui, peut-être.Je pensais que le 'ExpiresByType text/html "access plus 3600 seconds" ' était fait pour ça. Mais bon, je ne vais pas me mettre ta rate au court-bouillon : tout roule à présent.

 

[hubs]

la rate...