Guía práctica de purga de caché: de las claves a la purga por variantes

"Purgé la caché, ¿por qué sigo viendo contenido antiguo?" Es una de las preguntas más habituales de los usuarios de CDN, y la respuesta casi siempre está en la clave de caché: el objeto que purgó y el objeto al que acceden los visitantes pueden ser distintos. Esta guía comienza por las claves de caché y después explica exactamente qué elimina una purga en Yeap CDN y cómo entregamos las solicitudes de purga internamente.

Claves de caché: cómo distingue los archivos el servicio perimetral

Cuando un nodo perimetral almacena una respuesta en caché, la identifica mediante una clave de caché. A grandes rasgos, la clave se compone de:

• el nombre de host, por ejemplo, www.example.com;
• la ruta, por ejemplo, /assets/app.js;
• la cadena de consulta normalizada, según el modo de consulta configurado para el dominio;
• y, cuando corresponda, dimensiones de variante como la codificación del contenido.

Dos solicitudes acceden al mismo objeto en caché solo si sus claves son idénticas. Por eso /app.js?v=1 y /app.js?v=2 son objetos distintos de forma predeterminada, y por eso un parámetro de versión hace que tanto los navegadores como la CDN obtengan el archivo nuevo.

Modos de cadena de consulta

En la página CDN → Dominios → Caché de la consola puede elegir cómo trata un dominio las cadenas de consulta. La página también muestra una vista previa de la clave de caché que se actualiza con la configuración actual:

Internamente, el servicio perimetral siempre decodifica los parámetros, los ordena por nombre (y ordena los valores repetidos de un mismo nombre) y después vuelve a codificarlos antes de construir la clave. Por tanto, en cualquier modo que conserve los parámetros, el orden nunca crea objetos duplicados. El paso de recodificación también es importante: garantiza que un & o un = dentro de un valor decodificado no produzca una cadena ambigua, de modo que dos solicitudes distintas nunca terminen compartiendo la misma clave de caché.

Una optimización habitual: los enlaces de marketing suelen incluir varios parámetros de seguimiento, y cada combinación distinta crea un objeto nuevo, lo que reduce su tasa de aciertos. Excluirlos con el modo de lista de bloqueados suele mejorar considerablemente esa tasa.

Qué elimina realmente una purga

Haga clic en Purgar caché en la esquina superior derecha de la página de configuración de caché y elija una de las dos opciones.

Purgar todo

Elimina todos los objetos del dominio almacenados en caché en todos los nodos perimetrales. Úselo para lanzamientos importantes o cuando no tenga claro qué ha cambiado. El costo es que, durante un tiempo, todas las solicitudes se dirigirán a su origen, por lo que su carga aumentará brevemente.

Purgar por URL

Introduzca una URL completa por línea. Estas reglas son fundamentales para entender el comportamiento de la purga:

• Sin cadena de consulta, por ejemplo, https://www.example.com/list: elimina todas las variantes de cadena de consulta de esa ruta, incluidas /list, /list?page=2, /list?page=3 y así sucesivamente.
• Con cadena de consulta, por ejemplo, https://www.example.com/list?page=2: elimina solo esa variante; /list?page=3 permanece en caché.

Cuando purga con una cadena de consulta, esta se normaliza con exactamente las mismas reglas que se usan para construir las claves de caché (mismo modo, mismo orden y misma codificación). Así, aunque la solicitud almacenada en caché fuera ?b=2&a=1, introducir ?a=1&b=2 la purga con precisión.

Implementamos este comportamiento en respuesta a los comentarios de los usuarios. Una versión inicial del índice de purga solo comparaba el host y la ruta, por lo que purgar ?a=3 podía indicar éxito mientras el objeto seguía generando aciertos, porque la clave de caché incluía la cadena de consulta y la comparación de purga no. Ahora cada entrada del índice de purga registra su cadena de consulta normalizada, y las purgas buscan coincidencias a nivel de variante.

El modelo de purga del servicio perimetral también admite coincidencias por prefijo, comodín y etiqueta; la consola ofrece actualmente purgas de todo el sitio y por URL.

Cómo llegan las solicitudes de purga a todos los nodos

Cuando confirma, la consola responde casi de inmediato, porque la purga no se entrega de forma síncrona dentro de su solicitud HTTP:

1. El plano de control coloca el trabajo de purga (dominio y lista de rutas) en una cola en segundo plano respaldada por Redis y responde de inmediato.
2. Los consumidores de la cola entregan el trabajo en paralelo a los nodos perimetrales que sirven ese dominio, con reintentos automáticos en caso de fallo.
3. Si la propia cola no está disponible, el plano de control recurre a la entrega síncrona, para que nunca se pierda una purga.

En un nodo perimetral, una purga completa consta de dos partes: encontrar todas las claves de almacenamiento coincidentes en el índice de purga y, después, eliminar esos objetos del almacenamiento de caché y del nivel de acceso rápido en memoria. Para evitar que los distintos canales de entrega interfieran entre sí, solo modifica el índice el canal que puede eliminar objetos del almacenamiento de forma fiable en un contexto asíncrono. Los demás realizan una búsqueda de coincidencias no destructiva que vacía el nivel de acceso rápido y deja el índice intacto. Independientemente de qué canal llegue primero, la purga acaba completándose.

Cómo verificarlo

Las respuestas del servicio perimetral incluyen un encabezado X-Cache-Status. Después de purgar, compruébelo con curl:

curl -sI "https://www.example.com/list?page=2" | grep -i x-cache-status
# first request after the purge: X-Cache-Status: MISS
# request again:                 X-Cache-Status: HIT

Si sigue viendo contenido antiguo después de una purga, compruebe lo siguiente en este orden:

• ¿Se trata de la caché del navegador? Una purga perimetral no modifica las copias ya almacenadas en los navegadores de los visitantes. Pruebe con curl o con una ventana privada.
• ¿La URL que introdujo utiliza el mismo nombre de host que la solicitud real? example.com y www.example.com tienen cachés distintas.
• ¿Su origen sigue sirviendo contenido antiguo? Después de una purga, el servicio perimetral vuelve a consultar el origen; si hay otra caché delante de él, también debe actualizarla.

Buena práctica: depender lo menos posible de las purgas

La purga es una herramienta útil, pero para los recursos estáticos el enfoque más fiable es hacer que la URL cambie con el contenido:

• Utilice nombres de archivo con un hash del contenido, como app.3f9a1c.js, y asígneles tiempos de vida largos en caché. Una versión nueva tiene una URL nueva, por lo que no hay nada que purgar.
• Asigne un tiempo de vida corto en caché a las páginas HTML de entrada para que incorporen rápidamente las nuevas URL de los recursos.
• Cuando necesite purgar, dé preferencia a la purga por URL y reserve las purgas de todo el sitio para cambios amplios.

Una vez que comprende la clave de caché, las purgas dejan de ser una cuestión de prueba y error: la clave que purga es la que se elimina.