Taille d'image Open Graph : un seul fichier pour toutes les plateformes

Une seule image en 1200 par 630 pixels, en PNG ou JPEG, sous environ 1 MB, avec le contenu important à l'intérieur du centre de 1080 par 600. Ce fichier s'affiche correctement sur Facebook, LinkedIn, X, Slack, Discord, WhatsApp et iMessage, ce qui constitue toute la réponse à la question de la taille d'image Open Graph pour presque tous les sites.

Les dimensions sont la partie facile. Ce n'est généralement pas non plus ce qui casse. Ce qui casse, c'est un texte trop proche d'un bord qu'une plateforme rogne, une image qui ne se met jamais à jour parce qu'un robot d'exploration a mis en cache l'ancienne il y a des mois, ou une carte qui s'affiche sans aucune image parce que le fichier faisait 4 MB sur une origine lente. La question de la taille d'image OG en est en réalité trois, et une seule concerne les pixels. Ce guide couvre les spécifications, la zone de sécurité, le comportement de mise en cache qui pousse les gens à croire que leurs balises sont fausses, et comment les aperçus se résolvent quand ce qui est partagé est un lien court. Si votre aperçu est totalement absent plutôt que mal rogné, aperçu du lien non affiché est le guide de diagnostic.

La taille, et pourquoi c'est cette taille

Le rapport 1.91:1 vient de la carte de lien de Facebook, et il s'est imposé parce que tous les autres ont adopté une mise en page compatible plutôt que d'en inventer une nouvelle. Le protocole Open Graph lui-même ne dit absolument rien sur les pixels ; il définit og:image comme une URL et laisse le rendu au consommateur, ce qui explique exactement pourquoi une norme de facto s'est formée autour d'une taille pratique.

Les propres directives de Facebook sur le partage d'images fixent le minimum à 200 par 200 et recommandent le fichier plus grand pour les écrans haute résolution, et X documente le balisage des cartes séparément, ce qui est le seul endroit où vous avez besoin d'une balise spécifique à la plateforme plutôt que d'un fichier spécifique à la plateforme.

La zone de sécurité dont personne ne parle

Une carte est rarement affichée dans le rapport pour lequel vous l'avez conçue. Les applications de messagerie rognent vers un format carré pour la vignette, certains fils d'actualité rabotent les côtés sur les fenêtres étroites, et un coin arrondi mange les derniers pixels d'un logo placé dans l'angle.

Gardez tout ce qui doit survivre à l'intérieur du centre de 1080 par 600, centré, et traitez la bande extérieure comme une décoration que vous pouvez vous permettre de perdre. En pratique, cela signifie que le titre est placé au centre-gauche plutôt que collé au bord, que le logo vit à l'intérieur de la marge plutôt que dans le coin, et qu'il n'y a pas de bordure fine, car une bordure est l'élément de design qui paraît cassé dès qu'il est rogné.

Le contraste compte aussi plus qu'il n'y paraît. Les cartes s'affichent sur fond blanc dans un client et presque noir dans un autre, donc une image qui compte sur l'arrière-plan environnant pour se démarquer perd ses contours dans la moitié des cas.

Les balises autour de l'image

Quatre balises font le travail. Deux d'entre elles sont celles que les gens sautent.

<meta property="og:image" content="https://example.com/og/spring-launch.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta
  property="og:image:alt"
  content="Spring launch: 30 percent off through May"
/>
<meta name="twitter:card" content="summary_large_image" />

L'URL doit être absolue, schéma et hôte inclus, car le robot d'exploration lit la balise sans contexte de page pour résoudre un chemin relatif. La largeur et la hauteur permettent à la plateforme de réserver le bon espace avant que le fichier n'arrive, ce qui fait la différence entre une carte qui apparaît instantanément et une qui se redispose. Et og:image:alt est la balise d'accessibilité qui ne coûte rien et qui manque presque partout.

Pourquoi votre nouvelle image ne s'affichera pas

C'est celle qui génère des tickets de support. Vous avez corrigé l'image, vous pouvez voir le nouveau fichier à son URL, et la carte affiche toujours le design du trimestre dernier.

Les robots d'exploration sociaux mettent en cache de façon agressive, et sans aucune subtilité. Une fois qu'une URL a été explorée, c'est la version stockée qui est affichée pour les partages suivants, parfois pendant des semaines, et rien dans la modification de votre HTML ne leur indique de regarder à nouveau. Trois solutions, dans l'ordre où je les essaierais :

• Forcez une nouvelle exploration avec l'outil propre à la plateforme : le Sharing Debugger de Facebook et le Post Inspector de LinkedIn récupèrent tous deux la page à la demande.
• Publiez l'image sous un nouveau nom de fichier, ce qui constitue une URL différente et n'a donc aucune entrée de cache. C'est la solution fiable.
• Changez l'URL partagée elle-même, ce qui est trivialement simple quand ce que vous partagez est un lien court que vous contrôlez plutôt qu'une adresse de page permanente.

Avant de publier quoi que ce soit, le vérificateur Open Graph vous montre la carte exactement comme un robot d'exploration la construirait, ce qui prend dix secondes et évite le repartage gênant.

Les aperçus quand vous partagez un lien court

Un lien court n'a pas de balises Open Graph propres et n'en a pas besoin. Le robot d'exploration suit la redirection, atterrit sur la destination, et construit la carte à partir des balises qui s'y trouvent, ce qui signifie qu'une URL raccourcie hérite de l'aperçu qu'a la page cible. Si la carte est incorrecte, ce sont les balises de la destination qui sont incorrectes.

Deux choses dépendent bien de la couche du lien. La redirection doit pouvoir être suivie par un robot d'exploration, ce qui est le cas normal pour un saut côté serveur mais pas pour une redirection JavaScript, une raison de plus pour garder la chaîne courte et côté serveur. Et comme l'aperçu appartient à la destination, repointer un lien court change aussi son aperçu, une propriété discrètement utile quand une page de campagne est remplacée après que le lien a déjà été partagé.

Si vous voulez le lien, la carte et les données de clics au même endroit, démarrez un espace de travail sur votre propre domaine et vérifiez la carte avec l'outil avant l'envoi plutôt qu'après.

Une liste de contrôle à garder

• 1200 par 630, PNG ou JPEG, sous 1 MB, URL HTTPS absolue. C'est toute la décision de taille d'image OG.
• Rien d'important en dehors du centre de 1080 par 600, pas de bordures fines.
• og:image:width, og:image:height et og:image:alt présents.
• twitter:card défini sur summary_large_image si vous voulez la grande carte sur X.
• Nouvelle image, nouveau nom de fichier, puis nouvelle exploration avant d'annoncer quoi que ce soit.

Réglez ces cinq points correctement une fois, intégrez-les en modèle dans l'en-tête de votre page, et les images Open Graph cessent d'être une chose à laquelle vous pensez. Ce qui est exactement la bonne dose d'attention à leur accorder.

Lire la série pilier

Cet article s'inscrit dans le cluster tutoriels. Pour les aperçus qui échouent complètement plutôt que d'être mal rognés, aperçu du lien non affiché est le correctif plateforme par plateforme, et comment créer un lien cliquable couvre la couche sous-jacente.

À lire sur le blog

• Aperçu du lien non affiché ? Causes et comment y remédier
• Raccourcir un lien pour X (Twitter) : ce que fait t.co
• Comment suivre les liens des réseaux sociaux : les clics par canal
• Qu'est-ce qu'un lien de marque, et pourquoi il convertit mieux
• Comment rediriger une URL : six méthodes, et quand utiliser chacune
• Liens courts sur domaine personnalisé : DNS, TLS et la périphérie