WordPress era estable i, després d’actualitzar, les pàgines triguen, el tauler pesa o WooCommerce respon pitjor. El moment converteix l’actualització en una pista forta, no en un diagnòstic automàtic: també es pot haver purgat la memòria cau, augmentat el trànsit o produït un incident de l’allotjament.
La investigació ha de connectar un cost nou amb un canvi concret. Revertir-ho tot pot recuperar velocitat, però també retirar pedaços de seguretat i destruir proves.
Congelar les proves
Registra versions anterior i nova de WordPress, connector o tema, hora del canvi, memòries cau purgades, primera acció lenta, usuaris afectats, avisos i tasques fallides.
No actualitzis immediatament la resta «per compatibilitat»: ampliaries el conjunt de canvis. Abans de revertir, modificar codi o reparar la base de dades, confirma una còpia viable de fitxers i MySQL, especialment si hi va haver migració.
Reproduir una acció petita
Tria l’acció mínima que demostri el problema: carregar una pàgina, obrir Connectors, desar una entrada, cercar comandes, canviar una variació, obrir la compra o enviar un formulari. Repeteix-la i separa primera visita de memòria cau calenta.
Si és intermitent, anota hora, URL i sessió. Pot dependre de cron, trànsit, caducitat de memòria cau o dades específiques.
Confirmar què ha canviat
Compara versions mitjançant Git o paquets oficials baixats fora de producció. Revisa registre de canvis, requisits PHP, migracions, mòduls nous, recursos compilats, capes de compatibilitat eliminades i problemes reconeguts.
El registre orienta, però no demostra la causa a la teva instal·lació.
Separar servidor i navegador
Mesura diverses vegades l’URL i registra la memòria cau:
curl -s -o /dev/null
-w 'Primer byte: %{time_starttransfer}s Total: %{time_total}sn'
https://example.com/pagina-afectada/Si creix el primer byte, revisa PHP i MySQL. Si es manté semblant però la pàgina apareix més tard, compara Network i Performance.
Busca paquets JavaScript nous, recursos carregats on no s’usen, biblioteques duplicades, fonts, icones, mapes de desenvolupament, tercers i més execució de CSS o JS. No jutgis per quantitat de fitxers: relaciona cada canvi amb bytes, bloqueig de renderitzat o feina del fil principal.
Registra també el primer error de consola després d’una recàrrega neta. Retardar tot JavaScript pot amagar-lo i trencar menús, formularis, consentiment o compra.
Investigar consultes, *hooks* i migracions
En una finestra controlada, Query Monitor pot comparar temps de consultes, duplicats, crides HTTP, *hooks*, errors, plantilla i memòria cau. No deixis diagnòstic actiu a producció sense controlar sobrecàrrega i exposició.
La prova útil no és que el connector hi aparegui, sinó que una consulta o crida nova expliqui el temps afegit.
Algunes actualitzacions canvien taules o llancen processos de fons. Revisa esdeveniments, WooCommerce Scheduled Actions, cues del connector, errors MySQL, mides i índexs. No activis repetidament una migració si en desconeixes l’estat.
Revisar opcions amb càrrega automàtica
Una versió pot afegir configuracions o dades temporals a wp_options. Un administrador autoritzat pot llegir les més grans:
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 prefix i els valors possibles varien. Una opció gran no és necessàriament inútil: identifica’n propietari, necessitat i procés de recreació abans d’eliminar-la.
Distingir escalfament de regressió
Una actualització invalida pàgines, objectes, CSS generat, metadades, traduccions i transitoris. Mesura prou temps per saber si només s’escalfen o si cada caducitat repeteix la demora.
No conservis indefinidament una memòria cau antiga per evitar regenerar: cal servir el codi actualitzat correctament.
Revisa també registres protegits per avisos o funcions obsoletes. Una compatibilitat deficient pot funcionar i, alhora, escriure milers de missatges. Mantén els errors fora de la resposta pública i activa la depuració només en una finestra controlada.
Triar reversió, reparació o proveïdor
Reverteix quan l’error sigui crític, existeixi una versió anterior provada, la base de dades pugui tornar amb seguretat i s’entengui el risc de seguretat. Fes-ho preferentment en staging: fitxers antics sobre una base migrada poden ser incompatibles.
Una reparació puntual és millor si l’origen és configuració, recursos generats, un índex o integració corregible. Escala al proveïdor quan l’error es reprodueixi en una configuració admesa; envia versions, passos, registres i mesures.
Verificar tot el recorregut
Després del canvi, prova visita neta i calenta, administrador, mòbil, formulari o recorregut WooCommerce, processos programats i registres. Una pàgina pública ràpida no compensa una compra trencada o una migració incompleta.
Per a una avaluació aporta URL o acció, versions, data i mètode d’actualització, temps abans i després, memòria cau, PHP, WordPress i extractes protegits sense secrets. No enviïs contrasenyes.
La conclusió ha de decidir amb proves entre revertir, reparar o escalar, mantenint una via de recuperació a cada pas.