WordPress era estable y, tras actualizar, las páginas tardan, el administrador pesa o WooCommerce responde peor. El momento convierte la actualización en una pista fuerte, no en un diagnóstico automático: también pudo purgarse la caché, subir el tráfico o producirse un incidente del hosting.
La investigación debe conectar un coste nuevo con un cambio concreto. Revertir todo puede recuperar velocidad, pero también retirar parches de seguridad y destruir evidencias.
Congelar las evidencias
Registra versiones anterior y nueva de WordPress, plugin o tema, hora del cambio, cachés purgadas, primera acción lenta, usuarios afectados, avisos y tareas fallidas.
No actualices de inmediato el resto «por compatibilidad»: ampliarías el conjunto de cambios. Antes de revertir, modificar código o reparar base de datos, confirma una copia viable de archivos y MySQL, especialmente si hubo migración.
Reproducir una acción pequeña
Elige la acción mínima que demuestre el problema: cargar una página, abrir Plugins, guardar una entrada, buscar pedidos, cambiar una variación, abrir checkout o enviar un formulario. Repítela y separa primera visita de caché caliente.
Si es intermitente, anota hora, URL y sesión. Puede depender de cron, tráfico, caducidad de caché o datos específicos.
Confirmar qué cambió
Compara versiones mediante Git o paquetes oficiales descargados fuera de producción. Revisa registro de cambios, requisitos PHP, migraciones, módulos nuevos, recursos compilados, capas de compatibilidad eliminadas y problemas reconocidos.
El registro orienta, pero no demuestra la causa en tu instalación.
Separar servidor y navegador
Mide varias veces la URL y registra la caché:
curl -s -o /dev/null
-w 'Primer byte: %{time_starttransfer}s Total: %{time_total}sn'
https://example.com/pagina-afectada/Si crece el primer byte, revisa PHP y MySQL. Si permanece parecido pero la página aparece más tarde, compara Network y Performance.
Busca nuevos paquetes JavaScript, recursos cargados donde no se usan, librerías duplicadas, fuentes, iconos, mapas de desarrollo, terceros y mayor ejecución de CSS o JS. No juzgues por cantidad de archivos: relaciona cada cambio con bytes, bloqueo de renderizado o trabajo del hilo principal.
Registra además el primer error de consola tras una recarga limpia. Retrasar todo JavaScript puede esconderlo y romper menús, formularios, consentimiento o checkout.
Investigar consultas, *hooks* y migraciones
En una ventana controlada, Query Monitor puede comparar tiempo de consultas, duplicados, llamadas HTTP, *hooks*, errores, plantilla y caché. No dejes diagnóstico activo en producción sin controlar sobrecarga y exposición.
La evidencia útil no es que el plugin aparezca, sino que una consulta o llamada nueva explique el tiempo añadido.
Algunas actualizaciones cambian tablas o lanzan procesos de fondo. Revisa eventos, WooCommerce Scheduled Actions, colas del plugin, errores MySQL, tamaños e índices. No pulses repetidamente una migración cuyo estado desconoces.
Revisar opciones con carga automática
Una versión puede añadir configuraciones o datos temporales a wp_options. Un administrador autorizado puede leer las mayores:
wp db query "
SELECT option_name, LENGTH(option_value) AS bytes
FROM wp_options
WHERE autoload IN ('yes','on','auto-on','auto')
ORDER BY bytes DESC
LIMIT 20;
"El prefijo y los valores posibles varían. Una opción grande no es necesariamente inútil: identifica propietario, necesidad y proceso de recreación antes de borrarla.
Distinguir calentamiento de regresión
Una actualización invalida páginas, objetos, CSS generado, metadatos, traducciones y transitorios. Mide el tiempo suficiente para saber si solo se recalientan o si cada caducidad repite la demora.
No conserves indefinidamente una caché antigua para evitar regenerar: debe servirse el código actualizado correctamente.
Revisa también registros protegidos por avisos o funciones obsoletas. Una compatibilidad deficiente puede funcionar y, aun así, escribir miles de mensajes. Mantén los errores fuera de la respuesta pública y activa depuración solo durante una ventana controlada.
Elegir reversión, reparación o proveedor
Revierte cuando el fallo sea crítico, exista una versión anterior probada, la base de datos pueda regresar con seguridad y se entienda el riesgo de seguridad. Hazlo preferentemente en staging: archivos antiguos sobre una base migrada pueden ser incompatibles.
Una reparación puntual es mejor si el origen es configuración, recursos generados, un índice o integración corregible. Escala al proveedor cuando el fallo se reproduzca en una configuración soportada; envía versiones, pasos, registros y medidas.
Verificar todo el recorrido
Tras el cambio, prueba visita limpia y caliente, administrador, móvil, formulario o recorrido WooCommerce, procesos programados y registros. Una página pública rápida no compensa un checkout roto o una migración incompleta.
Para una evaluación aporta URL o acción, versiones, fecha y método de actualización, tiempos antes y después, caché, PHP, WordPress y extractos protegidos sin secretos. No envíes contraseñas.
La conclusión debe decidir con evidencias entre revertir, reparar o escalar, manteniendo una vía de recuperación en cada paso.