Por qué tu miniatura nueva sigue mostrando la vieja

Lo primero, separa los dos problemas

«Mi miniatura no se actualiza» y «mi miniatura no se ve» parecen lo mismo desde fuera y no tienen nada que ver. La primera es una cuestión de caché y se resuelve sola; la segunda es una cuestión de archivo o de permisos y no se va a resolver hasta que hagas algo.

La prueba dura diez segundos: ¿se ve la imagen vieja, o no se ve ninguna imagen? Una imagen vieja significa una copia en caché, y aplica todo lo que viene en las próximas secciones. Un rectángulo gris, un fotograma negro o un cuadro del vídeo que no elegiste significan que la miniatura personalizada no está puesta en absoluto — salta a las dos últimas secciones. Si lo que quieres en realidad es sustituir una miniatura — los pasos, qué reinicia, si un vídeo antiguo lo merece —, eso está en la guía sobre cambiar la miniatura.

El número que lo explica

Las miniaturas se sirven desde i.ytimg.com, y ese host publica sus reglas de caché en cada respuesta. Pedí tres archivos distintos — un hqdefault.jpg estático, un maxresdefault.jpg estático y uno de los recortes WebP parametrizados que la interfaz usa de verdad — y los tres respondieron igual:

En la mayoría de los casos las dos horas son toda la historia. No es que YouTube tarde en procesar tu cambio: el cambio ya está hecho. Son todas las cachés entre el almacenamiento de YouTube y tus ojos, a las que se les ha dicho, correctamente, que pueden seguir sirviendo lo que tienen.

Y la URL nunca cambia

Esta es la parte que hace que las dos horas importen. Una miniatura vive en una ruta construida con el id del vídeo — i.ytimg.com/vi/<id>/hqdefault.jpg — sin nada que indique qué versión de la imagen es. Sustituyes la miniatura y la dirección queda idéntica byte a byte, así que una caché con los bytes viejos no tiene forma de saber que debería parar.

Comprobé si las variantes parametrizadas se comportan distinto, porque llevan lo que parecen firmas. No lo hacen: manipular el token rs devolvió igualmente una imagen válida, y manipular el parámetro sqp devolvió una imagen de otro tamaño en lugar de un error. Esos parámetros describen el recorte, no son un sello de versión. Nada en el espacio de URL lo es.

Lo que significa que el mecanismo no tiene un paso de invalidación que tú puedas disparar. Una miniatura en caché no se borra: caduca.

Quién tiene una copia

Cuatro cachés distintas, cuatro relojes distintos, y por eso la actualización parece tan incoherente — nueva en el móvil, vieja en el portátil, vieja para un amigo, nueva en una ventana de incógnito.

Tu navegador. Tiene la imagen en disco con la instrucción de las dos horas y no volverá a pedirla hasta que eso se agote.

El edge de la CDN que te respondió. El encabezado age dice lo vieja que era su copia al responder — en el mismo archivo vi valores de 0 a 2371 segundos. Otro edge, otra edad, así que dos personas en redes distintas ven legítimamente imágenes distintas.

Cualquier app que haya recogido una vista previa del enlace. Apps de mensajería, Slack, Discord y foros guardan su propia copia de la imagen de vista previa con sus propios plazos, que suelen ser mucho más largos de dos horas y no están bajo tu control.

Incrustaciones y clientes de terceros. Todo lo que use las rutas estáticas recibe la misma instrucción de dos horas, y todo lo que guarde su propia copia la conserva lo que quiera.

Cómo ver ahora mismo el archivo actual

No tienes que esperar para saber si tu cambio entró: solo tienes que esperar a que lo vean los demás. Tres comprobaciones, de la más barata en adelante, y la primera basta para casi todo el mundo.

El truco de la primera es que una caché indexa por la URL completa, query string incluida, así que cualquier parámetro que te inventes es una clave nueva y por tanto una descarga fresca garantizada. Lo verifiqué: hqdefault.jpg?cb=12345 respondió 200 con exactamente los mismos bytes que la URL limpia y el mismo etag, que es lo que quieres — una copia fresca de la verdad, no una imagen distinta.

1. Abre el archivo con un parámetro inventadoPega i.ytimg.com/vi/<id de tu vídeo>/maxresdefault.jpg?cb=1 en una pestaña nueva. Sirve cualquier cosa después del signo de interrogación; cámbiala cada vez. Lo que ves es lo que el almacenamiento de YouTube contiene ahora, sin cachés de por medio.
2. Comprueba el etag desde una terminal, si quieres pruebascurl -I sobre la misma URL imprime cache-control, etag y age. Apunta el etag, haz el cambio y vuelve a pedirlo: un etag distinto significa que el archivo almacenado es de verdad otra imagen, sea lo que sea que aún te muestre el navegador.
3. Solo entonces mira un feedCuando el archivo ya es el correcto, las diferencias que queden son edad de caché, no tu subida. Nada que le hagas al archivo hará caducar antes la copia de otra persona.

Qué hacer y qué no hacer

Qué hacer: nada, durante dos horas. Es una frase insatisfactoria y es también todo el remedio para el caso común: el cambio ya está guardado y el reloj es lo único que queda.

Qué no hacer es la parte que merece decirse. No vuelvas a subir el vídeo — la miniatura es un objeto aparte asociado al mismo id de vídeo, y una subida nueva tira todas las impresiones y todos los comentarios que el vídeo tiene, por un problema que una espera habría arreglado. No cambies la miniatura otra vez para «forzarla», porque cada cambio no reinicia nada y abre una ventana nueva de dos horas sobre una imagen nueva: así es como un problema de diez minutos se convierte en una tarde.

Y si el vídeo está en una prueba activa de miniaturas, cambiar algo a mitad de vuelo es la única acción que de verdad te cuesta algo medible, por las razones de la guía sobre pruebas A/B: ya no sabes qué variante produjo los números que estás leyendo.

Las vistas previas de enlaces son una caché que no controlas

Cuando alguien pega un enlace a tu vídeo en una app de mensajería, esa app descarga la página una vez, lee og:image — que apunta a maxresdefault.jpg, como se midió en la guía sobre miniaturas borrosas — y guarda su propia copia de la vista previa. Desde ese momento la app te muestra su instantánea, no el archivo de YouTube.

No hay una forma general de vaciar eso, y el encabezado de las dos horas no se aplica a una copia que la app ha guardado por su cuenta. Dos plataformas publican una herramienta para volver a escanear su propia caché — el Sharing Debugger de Facebook y el Post Inspector de LinkedIn — y para todo lo demás la respuesta práctica es que un enlace publicado antes del cambio conserva la imagen vieja, y uno publicado después recibe la nueva.

Cuando no es una caché en absoluto

Si no hay imagen vieja pero tampoco nueva, la caché no está implicada y esperar no ayuda. Tres causas, en el orden en que suelen resultar ser la respuesta.

Las miniaturas personalizadas no están disponibles en la cuenta. La subida cae silenciosamente en un fotograma generado automáticamente. Tiene su propia guía, porque los requisitos cambiaron y los consejos viejos están equivocados: por qué falta la opción de miniatura personalizada.

El archivo fue rechazado. Por encima del límite del dispositivo desde el que subiste — 50 MB en ordenador, 2 MB en móvil —, un formato no admitido o una retirada por políticas. Una subida rechazada deja en su sitio la miniatura anterior, lo que se lee exactamente como «mi cambio no se aplicó»: comprueba que el archivo esté por debajo del límite y en uno de los formatos aceptados, listados en la guía de tamaño y especificaciones.

La variante que estás mirando no existe. No todos los tamaños existen para todos los vídeos: en una fuente de menos de 1280 píxeles de ancho, maxresdefault.jpg devuelve 404 con un cuerpo pequeño de relleno. Lo verifiqué en una subida de 2005 — maxres y sddefault dieron 404, hqdefault bien. Si estás probando con una URL en vez de en la interfaz, ese 404 es sobre la variante, no sobre tu miniatura. Una retirada según la política de miniaturas se ve idéntica desde fuera y no es un problema de caché en absoluto.

Studio no es prueba, y tu propio feed tampoco

Studio te muestra el archivo que acaba de guardar, sin CDN de por medio, así que se actualiza al instante y no te dice nada sobre lo que ve un espectador. Tu propio feed es lo contrario: es la superficie con más probabilidades de tener una copia vieja, porque eres quien la ha visitado más recientemente y por tanto tu navegador tiene la imagen en caché más antigua de todas.

Esta asimetría es la razón de que «para mí está actualizada pero para mi suscriptor no» y «para ellos sí pero para mí no» sean ambas normales en las mismas dos horas, y de que ninguna de las dos observaciones merezca que actúes.

La comprobación que evita todo el problema

Casi todo cambio de miniatura hecho con prisa es una decisión que podía haberse tomado antes de publicar. La razón de que la gente cambie la miniatura una hora después de subir es que el feed es el primer sitio donde la vio junto a otros vídeos — y a esas alturas el cambio cuesta dos horas de cachés viejas y, si hay una prueba en marcha, la prueba.

Verla primero en un feed es exactamente para lo que sirve la herramienta de vista previa: tu miniatura entre competidores reales, a los tamaños renderizados reales, antes de que tenga un vídeo detrás. El mejor arreglo para un problema de caché es no necesitar la segunda subida.

Las preguntas que hace todo el mundo