Lista de verificación de caché en producción

Completa esta revisión en staging o durante una ventana de lanzamiento controlada. Un acierto de caché correcto en una sola página es solo el comienzo; la aprobación para producción debe cubrir la seguridad del contenido, la invalidación, el alcance multisitio, el JSON progresivo y el límite del CDN.

1. Propiedad de la configuración

• [ ] wp-config.php, .htaccess y wp-content/advanced-cache.php tienen copias de reversión actuales.
• [ ] El equipo sabe quién es responsable de actualizar el drop-in y las reglas de reescritura.
• [ ] Ningún segundo plugin de caché de páginas posee advanced-cache.php.
• [ ] POM Cache está activo en la instalación prevista y activo en red cuando el despliegue multisitio lo requiere.
• [ ] La licencia del sitio o de la red muestra un estado válido y el dominio correcto.
• [ ] Los enlaces permanentes personalizados están activos.

2. Estado del entorno

Abre POM Cache → Advanced y confirma:

• [ ] Drop-in muestra OK.
• [ ] POM_CACHE_HOME muestra OK y apunta al directorio del plugin desplegado.
• [ ] WP_CACHE muestra OK.
• [ ] Cache Location es la base persistente prevista.
• [ ] PHP puede escribir en el directorio y Apache puede leerlo.
• [ ] El bloque de reescritura HTML aparece antes de las reglas estándar de WordPress.
• [ ] Se ha revisado el comportamiento de host y ruta para cada patrón de mapeo de dominio en uso.
• [ ] Cada nodo de origen ve un estado de caché e invalidación coherente.

3. Decide la política de invalidación de HTML

Para Purge HTML on post changes, registra si el alcance es Entire site, Edited post single only o Disabled, y por qué. Registra por separado el estado activado o desactivado de Purge HTML on term changes.

• [ ] Publicar, actualizar, enviar a la papelera y restaurar contenido público representativo produce el resultado previsto.
• [ ] Editar un término de taxonomía actualiza cada vista pública afectada cuando la purga de términos está activada.
• [ ] Cuando la purga automática está desactivada, los editores disponen de un paso de purga manual documentado.
• [ ] Una purga del sitio actual no elimina inesperadamente la caché de otro subsitio.
• [ ] Un cambio de diseño en toda la red o de contenido compartido tiene un plan de purga deliberado por sitio o programático.

POM Cache no caduca los archivos por antigüedad, por lo que una política de invalidación indefinida es un bloqueo para producción.

4. Prueba una matriz de rutas

Utiliza sesiones de navegador privadas y autenticadas. Para cada ruta pública cacheable, confirma que la primera solicitud crea un archivo y que una solicitud posterior lo reutiliza.

• [ ] Página de inicio/portada.
• [ ] Una página estándar.
• [ ] Una entrada pública individual o un elemento de contenido personalizado.
• [ ] Un archivo de tipo de contenido.
• [ ] Un archivo de taxonomía.
• [ ] Un archivo paginado.
• [ ] Una ruta de subsitio con dominio mapeado o subdirectorio.

Luego confirma el comportamiento de omisión o de no caché donde corresponda:

• [ ] Administración de WordPress y vistas previas.
• [ ] Vista editorial con sesión iniciada.
• [ ] Contenido protegido por contraseña.
• [ ] Comportamiento de búsqueda, feed, REST, redirección y 404 normal.
• [ ] URL con parámetros de consulta funcionales.
• [ ] Las solicitudes de POST, PUT y DELETE nunca reciben una página estática compartida desde PHP, Apache o el CDN.
• [ ] Rutas de cuenta, carrito, pago, membresía u otras rutas personalizadas.
• [ ] WooCommerce con una sesión activa o un carrito no vacío.

Inspecciona el contenido real además del indicador de acierto. Una respuesta rápida no es aceptable si pertenece a otro visitante, sitio, idioma o host.

5. Decide si se necesita JSON progresivo

Si el sitio no utiliza archivos progresivos compatibles:

• [ ] Progressive JSON cache permanece desactivado.
• [ ] No se ha añadido innecesariamente ninguna regla de reescritura JSON.

Si es necesario:

• [ ] El interruptor principal y JSON writes están activados intencionadamente.
• [ ] PHP early static serving y WordPress read fallback coinciden con el diseño de entrega.
• [ ] Maximum JSON file size acepta respuestas reales sin permitir archivos irrazonables.
• [ ] JSON Cache-Control header coincide con la política de frescura del CDN.
• [ ] Los interruptores de purga de entradas, términos y traducciones coinciden con el modelo de contenido.
• [ ] Una primera respuesta JSON escribe un archivo y una solicitud posterior lo reutiliza.
• [ ] Delete Progressive JSON Cache deja intacto el HTML.
• [ ] La acción Delete Cache de la barra de administración elimina ambas capas para el sitio actual.

6. Verifica el CDN y la compresión por separado

• [ ] El comportamiento del origen quedó demostrado antes de activar o confiar en la caché de borde.
• [ ] Las claves de caché del CDN conservan las distinciones de host, ruta, idioma y consulta que requiere el sitio.
• [ ] Las cookies y respuestas privadas no se comparten en el borde.
• [ ] Una purga del origen va acompañada de invalidación en el borde cuando es necesario.
• [ ] Brotli o Gzip es suministrado por el CDN/servidor web sin compresión duplicada.
• [ ] Cache-Control, Vary, el tipo de contenido y los códigos de estado son correctos para HTML y JSON.
• [ ] Las reescrituras WebP existentes en la misma carpeta recurren a la imagen original cuando no existe ninguna alternativa.

7. Ensaya la reversión

El orden de reversión debe conocerse antes del lanzamiento:

1. invalida o omite el CDN;
2. elimina o desactiva los bloques de reescritura de Apache de POM Cache;
3. elimina los archivos HTML y JSON del sitio actual;
4. desactiva los interruptores de tiempo de ejecución de POM Cache correspondientes;
5. restaura el drop-in anterior o los archivos del servidor solo cuando el plan de reversión lo requiera.

• [ ] La reversión se ensayó sin eliminar archivos no relacionados.
• [ ] El equipo entiende que la sola desactivación del plugin puede dejar archivos existentes accesibles a través de las reglas de Apache.
• [ ] Una ruta conocida sin caché permanece disponible para comparación.

8. Registra la línea base de lanzamiento

Conserva evidencia no sensible de:

• [ ] versiones del plugin, WordPress y PHP;
• [ ] interruptores de POM Cache activados;
• [ ] tiempos de respuesta dinámicos y en caché representativos;
• [ ] recuentos y tamaños de archivos HTML y JSON;
• [ ] cabeceras de respuesta en el origen y en el CDN;
• [ ] la última prueba de purga y regeneración correcta.

No registres la clave de licencia, datos privados de cuenta, credenciales del servidor ni cookies sin censurar.

El sitio está listo cuando cada ruta de caché intencionada es reutilizable, cada ruta privada permanece privada y los editores pueden predecir cómo un cambio de contenido se vuelve visible.