A quel moment un crawler exécute le Javascript

[Rwann]

Bonjour,
j'ai appris via une des news de wri que les crawlers (tout au moins Googlebot) exécutaient le javascript présent dans une page.
J'ai donc une question suite à la mise en place d'un système de césure (génération d'un tiret en fin de ligne pour couper le mot quand l'alignement est justifié) en Javascript, ce qui peut poser des problèmes de référencement de certains mots.
Si je place ma référence au JS juste avant la fermeture du body (au lieu de le placer dans le head), est ce que le crawler lira le texte avec césures AVANT d'éxécuter le JS.
D'une manière général, est ce que le crawlers lit un document html de manière strictement linéaire (de haut en bas)?

Merci d'avance.

 

[Djibou_Te@M]

Sans aucune certitude, je dirais au moment ou ils le lisent ... !?

 

[Rwann]

Sans aucune certitude, je dirais au moment ou ils le lisent ... !?

Lol ça je je doute bien, mais dans quel ordre est lu le source?

 

[Leonick]

de toutes façons, l'appel et l'utilisation du js doivent être opérationnels pour l'internaute. Donc appeler les fonctions du js avant d'avoir fait la liaison avec le js va rendre ton js inopérationnel

 

[Rwann]

de toutes façons, l'appel et l'utilisation du js doivent être opérationnels pour l'internaute. Donc appeler les fonctions du js avant d'avoir fait la liaison avec le js va rendre ton js inopérationnel

La génération des césures n'étant pas vitales pour l'affichage du document, je préfère placer le JS en bas du source.
Ça ne répond pas à ma question.

 

[Rwann]

Personne d'autre? :?

 

[_Soul]

Regarde la console de développement de chrome, elle sait quand la page finit d'être chargé, et elle affiche le code source de la page. Je pars donc du principe que ce n'est pas cachable...

 

[zeb]

Si tu ajoute que GGBook est capable de les faire sauter dans ses "traductions OCR" ou qu'il sait proposer des synonymes tu peut te dire qu'a 80% ce problème n'est est pas un car il comprendra avec ou sans césure et que tu n'en a rien a faire (avis perso appuyé sur aucun test).
En revanche je voie pas trop l'utilité d'un tel code ... mais c'est une autre histoire

 

[Rwann]

Si tu ajoute que GGBook est capable de les faire sauter dans ses "traductions OCR" ou qu'il sait proposer des synonymes tu peut te dire qu'a 80% ce problème n'est est pas un car il comprendra avec ou sans césure et que tu n'en a rien a faire (avis perso appuyé sur aucun test).
En revanche je voie pas trop l'utilité d'un tel code ... mais c'est une autre histoire

Ok. Ça sert à justifier mon texte sans obtenir des espace intermot trop importants et trop hétérogènes...

 

[zeb]

sans obtenir des espace intermot trop importants et trop hétérogènes...

N'y a t il pas une solution CSS qui te permettrait de résoudre le problème ? (j'avoue ne m'être jamais penché sur la question)
Si tu as installé ce dispositif, je suppose que c'est car tu y tiens mais concrètement on est tous habitué a cet effet de la justification donc je ne pense pas que cela pose un problème a qui que ce soit de lire un texte de ce style.
Sinon pour en diminuer l'effet visuel il suffit de réduire la taille de la police et d'augmenter la taille du conteneur du texte. L'équilibrage est ainsi relativement moins important.

 

[Rwann]

N'y a t il pas une solution CSS qui te permettrait de résoudre le problème ? (j'avoue ne m'être jamais penché sur la question)

Si, la propriété CSS3 hyphens mais pas encore suffisamment implémentée : http://www.caniuse.com/#search=hyphens
Si je sujet t'intéresse : http://typographisme.net/post/De-la-cesure-et-du-Web

Si tu as installé ce dispositif, je suppose que c'est car tu y tiens mais concrètement on est tous habitué a cet effet de la justification donc je ne pense pas que cela pose un problème a qui que ce soit de lire un texte de ce style.
Sinon pour en diminuer l'effet visuel il suffit de réduire la taille de la police et d'augmenter la taille du conteneur du texte. L'équilibrage est ainsi relativement moins important.

C'est aussi et surtout pour des raisons esthétiques (je suis Web Designer) que je souhaite mette en place la césure.
Sans césure la justification en CSS sur des justif. (dans le sens largeur de colonne) courtes n'est pas conseillée aussi bien pour des raisons esthétiques que des raisons de confort de lecture. Avoir un corps de texte trop petit n'est pas conseillé non plus...
mais je comprends ce que tu veux dire, effectivement sur des justif. larges la mise en place de la césure est moins cruciale.

Merci quand même !

PS: j'ai trouvé une solution alternative : empêcher les robots d'indexer le JS appelé, grâce au robots.txt

 

[zeb]

Merci Rwann pour tes liens c'est bien documenté, instructif et ça me permet de t’apporter un élément de réponse.

En bref tu t'en moque complètement .... (avis perso)
Je me suis rendu sur la page qui montre différents exemples de techniques de césure.
J'ai sélectionné un passage avec césure a la souris, cliqué bouton de droite et cherché avec google.
J'ai appris que cet exemple était tiré d'un ouvrage d'Alphonse Daudet, mais ça tous le monde s'en moque.
Mais surtout j'ai trouvé la page d'exemple que j'ai pu consulter en preview et en cache

Comme tu pourra le constater les césures ne sont nulle part pour la version javascript "hyphenator.js" ce qui semble vouloir laisser penser que le javascript n'interviens pas dans l'analyse de la page.
De même, la colorisation des mots qui sont dotés d'une césure, par exemple dans la section "L'entité HTML ­" laisse a suposer que google sait très bien détecter la césure et comprendre le mot complet. (mais bon les histoire de mise en évidence des mots (gras ou couleurs) chez google c'est pas non plu gage de compréhension absolue)

Donc a priori mon avis est que c'est transparent.

 

[Rwann]

Ah oui tiens c'est pas bon le coup du cache, j'y avais pas pensé.
En fait l'appel au script se fait après le texte dans le code donc il est possible que google indexe le texte avant de tenir compte du JS.

Bon c'est plutôt une bonne nouvelle, Merci !

 

[zeb]

l'appel au script se fait après le texte dans le code ...

A titre personnel je pense surtout que l’analyse sémantique du texte faite par GG ne se fait que sur le contenu "texte / html" de l'url sans laisser javascript interpréter le contenu de quelque façon que ce soit. plusieurs indices le laissent supposer :
* la mode des sites javascript est finie on sait que cela posait beaucoup de problèmes de ref puisque le contenu n'était pas pris en compte (années 90 / 00)
* les techniques BH consistant a utiliser du texte transparent ou blanc sur blanc sont toujours considérées comme mauvaise chez GG ce qui tend a dire que GG prend en compte le texte dissimulé sans se soucier du CSS ou JS ... donc la encore ton texte est considéré comme "entier sans césure".

Bref tu ne devrais pas rencontrer de souci, n'hésite pas a faire un retour si tu détecte quelque chose.

Il serait peut être possible de faire un test avec un mot inconnu sur GG en mettant une césure en plein milieu et en faisant une recherche après indexation ;-) tu saura alors si GG est capable de réunir le mot pour le fournir.
Ce test serait d'ailleurs intéressant en déployant les diverses techniques proposées dans l'article que tu link (mais en choisissant un mot différent pour chaque cas).

 

[Rwann]

* la mode des sites javascript est finie on sait que cela posait beaucoup de problèmes de ref puisque le contenu n'était pas pris en compte (années 90 / 00)

Des techniques JS dédiés uniquement au SEO je connais pas mais dans l'absolu JavaScript n'a jamais été une mode en plus d'être encore plus utilisé qu'avant : multiplication des framework JS.

* les techniques BH consistant a utiliser du texte transparent ou blanc sur blanc sont toujours considérées comme mauvaise chez GG ce qui tend a dire que GG prend en compte le texte dissimulé sans se soucier du CSS ou JS ... donc la encore ton texte est considéré comme "entier sans césure".

Je n'aurais jamais deviné ce que signifie BH (BlackHat je suppose?) sans avoir suivi une conf. de SEO récemment
Tu veux dire qui tendait et prenait non?

Il serait peut être possible de faire un test avec un mot inconnu sur GG en mettant une césure en plein milieu et en faisant une recherche après indexation ;-) tu saura alors si GG est capable de réunir le mot pour le fournir.
Ce test serait d'ailleurs intéressant en déployant les diverses techniques proposées dans l'article que tu link (mais en choisissant un mot différent pour chaque cas).

Ça peut être une solution effectivement.

Merci

 

[zeb]

Des techniques JS dédiés uniquement au SEO je connais pas mais dans l'absolu JavaScript n'a jamais été une mode en plus d'être encore plus utilisé qu'avant : multiplication des framework JS.

Tu n'a peut être pas connu ou fait attention avant les années 2000 on trouvait pas mal de site donc le contenu était produit uniquement avec du javascript (genre document.write). j'ai d'ailleurs en mémoire une demande client qui avait été traité par un prestataire local avec cette technique (c'était visuellement très bien) mais don le souci premier était le visibilité sur les moteurs donc résultat hors sujet bien évidement.
Donc je parle de site qui était constituée de scripts générant côté client la mise en page et le contenu, pas bien sur des nombreux framework utilisés actuellement pour donner de l’effet a une page possédant son contenu propre.

Je n'aurais jamais deviné ce que signifie BH (BlackHat je suppose?) sans avoir suivi une conf. de SEO récemment
Tu veux dire qui tendait et prenait non?

BlackHat -> oui, j'en parle car ces pratiques sont encore réprouvées donc implicitement utilisées ce qui tend a faire penser que si GG demande leur non utilisation ou les sanctionne c'est qu'elles ont un effet. D’où la possible conclusion qu'un script qui générerait cette "optimisation" ne serai pas bien pris en compte / géré par google ce qui tendrait a dire que ton script de césure ne devrait pas perturber la reco des mots coupés.