1183 sujets

Accessibilité du Web

JSON-LD ou Microdatas ?

Salut "world" !

Que devrais-je utiliser ? Vous êtes plutôt pour un, ou pour l'autre ? Entre le JSON-LD et les microdatas, quel est le "meilleur" choix (en fonction de ses avantages, inconvénients). À vrrai dire je ne sais pas lequel utiliser Smiley confus . Bref, si vous pouvez m'éclairer la-dessus, ce serait sympa.

Merchi
Salut en passant. Ayant beaucoup décroché du web ces deux dernières années, et ne faisant plus que de la veille de loin, la question m’intéresse au plus haut point (je ne connaissais même pas le JSON-LD).

Edit : je viens de trouver une réponse très intéressante, et assez complète, sur Stakoverflow.
Modifié par Olivier C (02 Jun 2019 - 14:53)
Olivier C a écrit :
Salut en passant. Ayant beaucoup décroché du web ces deux dernières années, et ne faisant plus que de la veille de loin, la question m’intéresse au plus haut point (je ne connaissais même pas le JSON-LD).

Edit : je viens de trouver une réponse très intéressante, et assez complète, sur Stakoverflow.


Merki de ta réponse. J'ai découvert le JSON-LD avec Alsacréations : https://www.alsacreations.com/article/lire/1780-donnees-semantiques-structurees-associees-le-choix-JSON-LD.html.
Bonjour,

sur la page dédié de google on trouve quelques avantages :
JSON-LD : Notation JavaScript intégrée dans une balise <script> dans l'en-tête ou le corps de la page. Le balisage n'est pas entrelacé avec le texte visible par l'utilisateur, ce qui permet d'exprimer plus facilement les éléments de données imbriqués, tels que le pays d'une adresse postale d'un événement musical. En outre, Google peut lire les données JSON-LD lorsqu'elles sont injectées de manière dynamique dans le contenu de la page (par exemple, avec du code JavaScript ou des widgets intégrés dans votre système de gestion de contenu).


https://developers.google.com/search/docs/guides/intro-structured-data#markup-formats-and-placement

A mon avis c'est aussi plus simple à maintenir car lorsque qu'on ajoute des microdonnées partout dans les balises cela peut devenir très confus.

Le 'défaut' de json est qu'on a logiquement un peu plus de code car on doit reprendre les données dans le json plutôt que d'ajouter des attributs aux balises.

Aussi rien n'empêche d'utiliser différents format sur une même page.
Yep, y'a des avantages comme des défauts, partout... Je crois que je vais me pencher sur le JSON-LD plutôt que les microdatas. Plus simple à la lisibilité, malgré qu'il faille reprendre les keys du JSON. Reste à voir comment je vais l'intégrer sur une application en React : un composant dédié avec un script type JSON-LD, avec NodeJS res.send et ses params (inclus le JSON), etc.
bacasable a écrit :
A mon avis c'est aussi plus simple à maintenir car lorsque qu'on ajoute des microdonnées partout dans les balises cela peut devenir très confus.

Le pire c'est que je liais intimement les microdata et le site schema.org que je croyais lié à ce format (je faisais la même confusion que le gars sur cette page), et lorsque je voyais des exemples en JSON sur ce site je me disais : "tiens les microdata peuvent s'implémenter en JSON maintenant, il faudra que me penche sur ce truc à la prochaine gosse MAJ de mon site". Et en fait... c'était déjà des exemples de JSON-LD.
Modifié par Olivier C (03 Jun 2019 - 23:07)
En voyant les exemples de schema.org sur le type Person, c'est vrai que je préfère de loin le JSON-LD, ça me paraît plus structuré, qui en découle, la lisibilité. Les microdatas et les RDFas sont so 2010, lol.

En revanche, une question qui m'embête, qu'est-ce que la différence entre les Microdatas et les RDFas ? C'est presque pareil, enfin presque...
Modifié par Soldat8889 (03 Jun 2019 - 23:20)
Soldat8889 a écrit :
Yep, y'a des avantages comme des défauts, partout... Je crois que je vais me pencher sur le JSON-LD plutôt que les microdatas. Plus simple à la lisibilité, malgré qu'il faille reprendre les keys du JSON. Reste à voir comment je vais l'intégrer sur une application en React : un composant dédié avec un script type JSON-LD, avec NodeJS res.send et ses params (inclus le JSON), etc.

Bonjour,
Je me suis penché récemment sur l'insertion de données pour mon générateur de sites web et, sauf erreur de ma part, il y a différentes façons de les intégrer :
a) "en ligne", c'est à dire au plus proche du composant pour lequel elles sont pertinentes (ex. en suivant le fil d'ariane ou "breadcrumb")
b) en fin de balise <body>
c) dans une balise <script> la section<head> de la page HTML
d) dans un script externe lié à la page via une balise <script> de la section <head>
Par contre, je n'ai pas trouvé d'article/ cours explicitant de façon claire quel avantage on peut, ou non, retirer de chaque position pour l'aspect SEO.
Dans le doute, j'ai donc mis en place une propriété qui me permet de basculer instantanément d'une configuration à l'autre.
Re-bonjour (oui je UP ce topic)

J'ai trouvé où placer le JSON-LD, il faudrait le placer dans la section <head>, parce que le JSON-LD est un élément qui complète les metadatas : StackOverflow.

NB : D'ailleurs, le JSON-LD n'est pas très jeune en fait, cette question de StackOverflow date d'il y a 4 ans (à l'heure où j'écris), lol.
Soldat8889 a écrit :
Re-bonjour (oui je UP ce topic)
J'ai trouvé où placer le JSON-LD, il faudrait le placer dans la section &lt;head&gt;, parce que le JSON-LD est un élément qui complète les metadatas : StackOverflow.
NB : D'ailleurs, le JSON-LD n'est pas très jeune en fait, cette question de StackOverflow date d'il y a 4 ans (à l'heure où j'écris), lol.

Effectivement, si l'on se base sur l'apport sémantique, il s'agit bien de métadonnées et leur place dans la section <head> est pertinente.
A contrario, si l'on privilégie l'aspect performance au chargement, on peut aussi considérer qu'il s'agit de parties de pages sans influence directe sur la présentation et qu'il convient donc de charger ce code le plus tard possible.
Les deux raisonnements se tiennent et ce sera sûrement à l'issue de tests qu'on prendra une décision.
Sujet clos
Aller à