Porque é que a miniatura nova continua a mostrar a antiga

Primeiro, separe os dois problemas

«A miniatura não actualiza» e «a miniatura não aparece» parecem a mesma coisa de fora e não têm nada a ver. A primeira é uma questão de cache e resolve-se sozinha; a segunda é uma questão de ficheiro ou de permissões e não se resolve até fazer algo.

O teste leva dez segundos: vê-se a imagem antiga, ou não se vê imagem nenhuma? Uma imagem antiga quer dizer uma cópia em cache, e aplica-se tudo o que vem nas próximas secções. Um rectângulo cinzento, um fotograma negro ou uma imagem do vídeo que não escolheu querem dizer que a miniatura personalizada não está lá de facto — salte para as duas últimas secções. Se o que quer mesmo é substituir uma miniatura — os passos, o que isso reinicia, se um vídeo antigo o merece —, isso está no guia sobre mudar a miniatura.

O número que explica tudo

As miniaturas são servidas de i.ytimg.com, e esse servidor publica as suas regras de cache em cada resposta. Pedi três ficheiros diferentes — um hqdefault.jpg estático, um maxresdefault.jpg estático e um dos recortes WebP parametrizados que a interface usa de facto — e os três responderam da mesma maneira:

Na maioria dos casos as duas horas são a história toda. Não é o YouTube a demorar a processar a sua alteração: a alteração já está feita. São todas as caches entre o armazenamento do YouTube e os seus olhos a quem foi dito, corretamente, que podem continuar a servir o que têm.

E o URL nunca muda

É esta a parte que torna as duas horas importantes. Uma miniatura vive num caminho construído a partir do id do vídeo — i.ytimg.com/vi/<id>/hqdefault.jpg — sem nada que diga de que versão da imagem se trata. Substitua a miniatura e o endereço fica idêntico byte por byte, portanto uma cache com os bytes antigos não tem maneira de saber que devia parar.

Verifiquei se as variantes parametrizadas se comportam de outra forma, porque trazem aquilo que parecem assinaturas. Não: alterar o token rs devolveu ainda assim uma imagem válida, e alterar o parâmetro sqp devolveu uma imagem de outro tamanho em vez de um erro. Esses parâmetros descrevem o recorte, não são um selo de versão. Nada no espaço de URL o é.

O que quer dizer que o mecanismo não tem um passo de invalidação que possa accionar. Uma miniatura em cache não é apagada: expira.

Quem tem uma cópia

Quatro caches separadas, quatro relógios separados, e é por isso que a actualização parece tão incoerente — nova no telemóvel, antiga no portátil, antiga para um amigo, nova numa janela anónima.

O seu navegador. Tem a imagem em disco com a instrução das duas horas e não a volta a pedir antes disso.

O nó da CDN que lhe respondeu. O cabeçalho age diz o quão velha era a cópia dele quando respondeu — no mesmo ficheiro vi valores de 0 a 2371 segundos. Outro nó, outra idade, portanto duas pessoas em redes diferentes vêem legitimamente imagens diferentes.

Qualquer aplicação que tenha recolhido uma pré-visualização do link. Aplicações de mensagens, Slack, Discord e fóruns guardam a sua própria cópia da imagem de pré-visualização nos seus próprios prazos, que são normalmente muito mais longos do que duas horas e não estão sob o seu controlo.

Incorporações e clientes de terceiros. Tudo o que use os caminhos estáticos recebe a mesma instrução das duas horas, e tudo o que guarde uma cópia própria mantém-na o tempo que quiser.

Como ver já o ficheiro actual

Não tem de esperar para saber se a sua alteração entrou: só tem de esperar que os outros a vejam. Três verificações, da mais barata para cima, e a primeira basta a quase todos.

O truque da primeira é que uma cache indexa pelo URL inteiro, query string incluída, portanto qualquer parâmetro que invente é uma chave nova e por isso um descarregamento fresco garantido. Verifiquei-o: hqdefault.jpg?cb=12345 respondeu 200 com exactamente os mesmos bytes do URL limpo e o mesmo etag, que é o que se quer — uma cópia fresca da verdade, não uma imagem diferente.

1. Abra o ficheiro com um parâmetro inventadoCole i.ytimg.com/vi/<id do seu vídeo>/maxresdefault.jpg?cb=1 num separador novo. Serve qualquer coisa depois do ponto de interrogação; mude-a de cada vez. O que vê é o que o armazenamento do YouTube contém agora, sem cache pelo meio.
2. Confirme o etag num terminal, se quiser provacurl -I no mesmo URL imprime cache-control, etag e age. Aponte o etag, faça a alteração e peça outra vez: um etag diferente significa que o ficheiro guardado é realmente outra imagem, seja o que for que o seu navegador ainda lhe mostre.
3. Só depois olhe para um feedQuando o ficheiro já está certo, as diferenças que restam são idade de cache, não o seu carregamento. Nada do que faça ao ficheiro fará a cópia de outra pessoa expirar mais cedo.

O que fazer, e o que não fazer

O que fazer é nada, durante duas horas. É uma frase insatisfatória e é também todo o remédio para o caso comum: a alteração já está guardada, e o relógio é a única coisa que falta.

O que não fazer é a parte que vale dizer. Não volte a carregar o vídeo — a miniatura é um objecto separado ligado ao mesmo id de vídeo, e um carregamento novo atira fora todas as impressões e todos os comentários que o vídeo tem, por um problema que a espera teria resolvido. Não mude a miniatura outra vez para «forçar», porque cada mudança não reinicia nada e abre uma janela nova de duas horas sobre uma imagem nova: é assim que um problema de dez minutos se torna uma tarde.

E se o vídeo estiver num teste activo de miniaturas, mudar algo a meio do voo é a única acção que lhe custa realmente algo mensurável, pelas razões do guia sobre testes A/B: deixa de saber que variante produziu os números que está a ler.

As pré-visualizações de links são uma cache que não controla

Quando um link para o seu vídeo é colado numa aplicação de mensagens, essa aplicação vai buscar a página uma vez, lê o og:image — que aponta para maxresdefault.jpg, como medido no guia sobre miniaturas desfocadas — e guarda a sua própria cópia da pré-visualização. A partir daí a aplicação mostra-lhe o instantâneo dela, não o ficheiro do YouTube.

Não há forma geral de limpar isso, e o cabeçalho das duas horas não se aplica a uma cópia que a aplicação guardou por si. Duas plataformas publicam uma ferramenta para reler a sua própria cache — o Sharing Debugger do Facebook e o Post Inspector do LinkedIn — e para todo o resto a resposta prática é que um link publicado antes da alteração mantém a imagem antiga, e um publicado depois recebe a nova.

Quando não é cache nenhuma

Se não há imagem antiga nem nova, a cache não está envolvida e esperar não ajuda. Três causas, na ordem em que costumam ser a resposta.

As miniaturas personalizadas não estão disponíveis na conta. O carregamento cai silenciosamente num fotograma gerado automaticamente. Tem um guia próprio, porque os requisitos mudaram e os conselhos antigos estão errados: porque falta a opção de miniatura personalizada.

O ficheiro foi rejeitado. Acima do limite do dispositivo de onde carregou — 50 MB no computador, 2 MB no telemóvel —, um formato não suportado, ou uma remoção por políticas. Um carregamento rejeitado deixa a miniatura anterior no lugar, o que se lê exactamente como «a minha alteração não foi aplicada»: verifique que o ficheiro está abaixo do limite e num dos formatos aceites, listados no guia de tamanhos e especificações.

A variante que está a ver não existe. Não existem todos os tamanhos para todos os vídeos: numa fonte com menos de 1280 píxeis de largura, o maxresdefault.jpg devolve 404 com um pequeno corpo de substituição. Verifiquei-o num carregamento de 2005 — maxres e sddefault ambos 404, hqdefault bem. Se está a testar com um URL em vez de na interface, esse 404 é sobre a variante, não sobre a sua miniatura. Uma remoção ao abrigo da política de miniaturas parece idêntica vista de fora e não é de todo um problema de cache.

O Studio não é prova, e o seu próprio feed também não

O Studio mostra-lhe o ficheiro que acabou de guardar, sem CDN pelo meio, portanto actualiza de imediato e não lhe diz nada sobre o que um espectador vê. O seu próprio feed é o contrário: é a superfície com mais probabilidade de ter uma cópia velha, porque foi você quem a visitou mais recentemente e por isso o seu navegador tem a imagem em cache mais antiga de todas.

É esta assimetria que torna normais, nas mesmas duas horas, tanto «para mim está actualizada mas para o meu subscritor não» como «para eles está mas para mim não» — e nenhuma das duas observações merece que faça algo.

A verificação que evita o problema todo

Quase toda a troca de miniatura feita em pânico é uma decisão que podia ter sido tomada antes de publicar. A razão por que as pessoas mudam a miniatura uma hora depois do carregamento é que o feed é o primeiro lugar onde a viram ao lado de outros vídeos — e a essa altura a alteração custa duas horas de caches velhas e, se houver um teste a correr, o teste.

Vê-la primeiro num feed é exactamente para o que serve a ferramenta de pré-visualização: a sua miniatura entre concorrentes verdadeiros, nos tamanhos realmente desenhados, antes de ter um vídeo ligado. A melhor cura para um problema de cache é não precisar do segundo carregamento.

As perguntas que todos fazem