Pourquoi votre miniature affiche encore l'ancienne

D'abord, séparez les deux problèmes

« Ma miniature ne se met pas à jour » et « ma miniature ne s'affiche pas » se ressemblent de l'extérieur et n'ont rien à voir. La première est une question de cache et se règle toute seule ; la seconde est une question de fichier ou de droits et ne se réglera pas avant que vous fassiez quelque chose.

Le test prend dix secondes : voit-on l'ancienne image, ou aucune image ? Une ancienne image signifie une copie en cache, et tout ce qui suit s'applique. Un rectangle gris, une image noire ou une image extraite de la vidéo que vous n'avez pas choisie signifient que la miniature personnalisée n'est pas en place du tout — sautez aux deux dernières sections. Si ce que vous voulez vraiment, c'est remplacer une miniature — les étapes, ce que ça réinitialise, si une vieille vidéo en vaut la peine —, c'est dans le guide sur le changement de miniature.

Le nombre qui explique tout

Les miniatures sont servies depuis i.ytimg.com, et cet hôte publie ses règles de cache dans chaque réponse. J'ai demandé trois fichiers différents — un hqdefault.jpg statique, un maxresdefault.jpg statique et l'un des recadrages WebP paramétrés que l'interface utilise réellement — et les trois ont répondu la même chose :

Dans la plupart des cas, les deux heures sont toute l'histoire. Ce n'est pas YouTube qui met du temps à traiter votre changement : le changement est déjà fait. Ce sont tous les caches entre le stockage de YouTube et vos yeux à qui on a dit, à juste titre, qu'ils pouvaient continuer à servir ce qu'ils ont.

Et l'URL ne change jamais

C'est ce qui rend ces deux heures importantes. Une miniature vit à un chemin construit sur l'identifiant de la vidéo — i.ytimg.com/vi/<id>/hqdefault.jpg — sans rien qui indique de quelle version de l'image il s'agit. Remplacez la miniature et l'adresse reste identique octet pour octet : un cache qui détient les anciens octets n'a aucun moyen de savoir qu'il devrait s'arrêter.

J'ai vérifié si les variantes paramétrées se comportent différemment, puisqu'elles portent ce qui ressemble à des signatures. Non : altérer le jeton rs a tout de même renvoyé une image valide, et altérer le paramètre sqp a renvoyé une image d'une autre taille plutôt qu'une erreur. Ces paramètres décrivent le recadrage, ce ne sont pas un tampon de version. Rien dans l'espace d'URL ne l'est.

Autrement dit, le mécanisme n'a pas d'étape d'invalidation que vous pourriez déclencher. Une miniature en cache n'est pas effacée : elle expire.

Qui détient une copie

Quatre caches distincts, quatre horloges distinctes — d'où une mise à jour qui paraît si incohérente : nouvelle sur votre téléphone, ancienne sur votre portable, ancienne pour un ami, nouvelle dans une fenêtre privée.

Votre navigateur. Il a l'image sur disque avec l'instruction de deux heures et ne la redemandera pas avant l'échéance.

Le nœud du CDN qui vous a répondu. L'en-tête age indique l'âge de sa copie au moment de la réponse — sur le même fichier, j'ai vu des valeurs de 0 à 2371 secondes. Autre nœud, autre âge : deux personnes sur des réseaux différents voient légitimement des images différentes.

Toute application ayant récupéré un aperçu de lien. Messageries, Slack, Discord et forums conservent leur propre copie de l'image d'aperçu selon leur propre calendrier, en général bien plus long que deux heures, et qui ne dépend pas de vous.

Les intégrations et clients tiers. Tout ce qui utilise les chemins statiques reçoit la même instruction de deux heures, et tout ce qui stocke sa propre copie la garde autant qu'il veut.

Comment voir tout de suite le fichier actuel

Vous n'avez pas à attendre pour savoir si votre changement est passé : vous n'attendez que pour les autres. Trois vérifications, de la moins coûteuse à la plus, et la première suffit à presque tout le monde.

L'astuce derrière la première : un cache indexe l'URL entière, chaîne de requête comprise, donc tout paramètre que vous inventez est une nouvelle clé et donc un téléchargement frais garanti. Je l'ai vérifié : hqdefault.jpg?cb=12345 a répondu 200 avec exactement les mêmes octets que l'URL propre et le même etag — c'est ce qu'on veut, une copie fraîche de la vérité, pas une autre image.

1. Ouvrez le fichier avec un paramètre inventéCollez i.ytimg.com/vi/<identifiant de votre vidéo>/maxresdefault.jpg?cb=1 dans un nouvel onglet. N'importe quoi après le point d'interrogation fonctionne ; changez-le à chaque fois. Ce que vous voyez est ce que le stockage de YouTube contient à cet instant, sans cache au milieu.
2. Vérifiez l'etag depuis un terminal, si vous voulez une preuvecurl -I sur la même URL affiche cache-control, etag et age. Notez l'etag, faites le changement, redemandez : un etag différent signifie que le fichier stocké est vraiment une autre image, quoi que votre navigateur continue de vous montrer.
3. Seulement ensuite, regardez un filUne fois le fichier correct, les différences restantes relèvent de l'âge du cache, pas de votre envoi. Rien de ce que vous ferez au fichier ne fera expirer plus tôt la copie de quelqu'un d'autre.

Ce qu'il faut faire, et ne pas faire

Ce qu'il faut faire, c'est rien, pendant deux heures. La phrase est frustrante et c'est aussi tout le remède dans le cas courant : le changement est déjà stocké, il ne reste que l'horloge.

Ce qu'il ne faut pas faire mérite d'être dit. Ne renvoyez pas la vidéo — la miniature est un objet distinct rattaché au même identifiant, et un nouvel envoi jette toutes les impressions et tous les commentaires de la vidéo pour un problème qu'une attente aurait réglé. Ne changez pas la miniature une deuxième fois pour « forcer » : chaque changement ne réinitialise rien et ouvre une nouvelle fenêtre de deux heures sur une nouvelle image — c'est ainsi qu'un problème de dix minutes devient un après-midi.

Et si la vidéo est dans un test de miniatures en cours, changer quelque chose en plein vol est la seule action qui coûte vraiment quelque chose de mesurable, pour les raisons exposées dans le guide sur les tests A/B : vous ne savez plus quelle variante a produit les chiffres que vous lisez.

Les aperçus de liens sont un cache que vous ne contrôlez pas

Quand un lien vers votre vidéo est collé dans une messagerie, celle-ci récupère la page une fois, lit og:image — qui pointe vers maxresdefault.jpg, comme mesuré dans le guide sur les miniatures floues — et conserve sa propre copie de l'aperçu. À partir de là, l'application vous montre son instantané, pas le fichier de YouTube.

Il n'existe pas de moyen général de vider cela, et l'en-tête de deux heures ne s'applique pas à une copie que l'application a stockée elle-même. Deux plateformes publient un outil pour réanalyser leur propre cache — le Sharing Debugger de Facebook et le Post Inspector de LinkedIn — et pour tout le reste, la réponse pratique est qu'un lien publié avant le changement garde l'ancienne image, et qu'un lien publié après reçoit la nouvelle.

Quand ce n'est pas un cache du tout

S'il n'y a ni ancienne image ni nouvelle, le cache n'est pas en cause et attendre ne servira à rien. Trois causes, dans l'ordre où elles se révèlent être la réponse.

Les miniatures personnalisées ne sont pas disponibles sur le compte. L'envoi retombe silencieusement sur une image extraite automatiquement. Cela a son propre guide, car les conditions ont changé et les anciens conseils sont faux : pourquoi l'option de miniature personnalisée est absente.

Le fichier a été refusé. Au-delà de la limite de l'appareil utilisé — 50 Mo sur ordinateur, 2 Mo sur téléphone —, un format non pris en charge, ou un retrait pour non-conformité. Un envoi refusé laisse la miniature précédente en place, ce qui se lit exactement comme « mon changement ne s'est pas appliqué » : vérifiez que le fichier est sous la limite et dans un des formats acceptés, listés dans le guide des tailles et spécifications.

La variante que vous regardez n'existe pas. Toutes les tailles n'existent pas pour toutes les vidéos : sur une source de moins de 1280 pixels de large, maxresdefault.jpg renvoie 404 avec un petit corps de remplacement. Je l'ai vérifié sur un envoi de 2005 — maxres et sddefault en 404, hqdefault correct. Si vous testez avec une URL plutôt que dans l'interface, ce 404 concerne la variante, pas votre miniature. Un retrait au titre du règlement sur les miniatures a exactement la même apparence de l'extérieur et n'est pas du tout un problème de cache.

Studio n'est pas une preuve, et votre fil non plus

Studio vous montre le fichier qu'il vient de stocker, sans CDN au milieu : il se met à jour immédiatement et ne dit rien de ce que voit un spectateur. Votre propre fil est l'inverse : c'est la surface la plus susceptible d'avoir une copie périmée, parce que c'est vous qui l'avez visitée le plus récemment et que votre navigateur détient donc l'image en cache la plus ancienne de tous.

Cette asymétrie explique pourquoi « c'est à jour chez moi mais pas chez mon abonné » et « c'est à jour chez eux mais pas chez moi » sont tous deux normaux dans les mêmes deux heures, et pourquoi aucune de ces observations ne mérite qu'on agisse.

La vérification qui évite tout le problème

Presque tout changement de miniature fait dans la précipitation est une décision qui pouvait être prise avant publication. Si les gens changent de miniature une heure après l'envoi, c'est que le fil est le premier endroit où ils l'ont vue à côté d'autres vidéos — et à ce stade le changement coûte deux heures de caches périmés et, si un test tourne, le test.

La voir d'abord dans un fil est exactement à quoi sert l'outil d'aperçu : votre miniature parmi de vrais concurrents, aux tailles réellement rendues, avant qu'une vidéo y soit attachée. Le meilleur remède à un problème de cache est de ne pas avoir besoin du second envoi.

Les questions que tout le monde se pose