El web públic respon ràpid, però després d’iniciar sessió les mateixes pàgines triguen i l’administrador resulta pesat. És una distinció freqüent: les peticions autenticades solen evitar la memòria cau de pàgina completa, carregar recursos addicionals i executar consultes específiques de l’usuari.
La solució ha de millorar aquest recorregut sense emmagatzemar contingut privat ni afeblir els controls d’accés.
Determinar quins perfils estan afectats
Prova la mateixa pàgina i acció amb administrador, editor o gestor de botiga, client o subscriptor i visitant desconnectat. Si només falla l’administrador, revisa la barra d’eines, ginys, avisos i comprovacions de permisos. Si tots els usuaris autenticats són lents, estudia l’exclusió de memòria cau i la feina de sessió.
No utilitzis un compte real de client sense permís. Crea un usuari controlat amb el rol mínim necessari.
Confirmar l’exclusió de memòria cau
La majoria de sistemes no serveixen HTML compartit quan detecten una galeta d’accés. Compara capçaleres i primer byte a Network amb sessió i sense. Un HIT públic ràpid davant d’un BYPASS o MISS autenticat lent apunta a la generació d’origen.
No forcis aquestes pàgines a la memòria cau pública. Mostrar la barra, cistella o dades d’una altra persona seria una filtració, encara que la resposta fos instantània.
Separar portada, administració i compte
«WordPress va lent quan em connecto» pot referir-se a veure el frontal amb barra, obrir /wp-admin/, editar, gestionar comandes o consultar El meu compte. Són plantilles i peticions diferents.
El frontal pot patir perquè no usa memòria cau; el tauler, per consultes o avisos remots; el compte WooCommerce, per comandes i baixades. Mesura cada recorregut per separat.
A Network, selecciona el document principal i compara “Waiting for server response”. Si el primer byte autenticat creix, investiga temps PHP, consultes MySQL, crides HTTP, encerts de memòria cau d’objectes, errors i *hooks*, no el pes de la imatge pública.
Revisar la barra i els connectors administratius
La barra afegeix HTML, CSS i JavaScript, i alguns connectors incorporen comptadors o estats costosos. En un entorn de proves o mitjançant un connector temporal controlat pots ocultar-la a un usuari de prova:
add_action( 'after_setup_theme', function () {
if ( current_user_can( 'manage_options' ) ) {
show_admin_bar( false );
}
} );No ho publiquis com a reparació permanent. Si millora, identifica l’element concret; si no, retira el codi i continua.
Connectors de seguretat, còpies, SEO, analítica i llicències poden treballar més per a usuaris privilegiats. Una aparició en una traça no demostra culpabilitat: relaciona una consulta, crida o *hook* amb temps mesurat i confirma el canvi mitjançant una prova reversible.
Comprovar la memòria cau d’objectes i les dades
Sense memòria cau de pàgina, Redis o Memcached poden reutilitzar consultes de forma segura. Confirma que el *drop-in* està connectat, encerts i errors, memòria, expulsions i si l’allotjament ja ofereix el servei. No instal·lis una segona implementació sobre la gestionada pel proveïdor.
La memòria cau d’objectes redueix repetició, però no corregeix automàticament una consulta mal dissenyada.
WordPress i WooCommerce emmagatzemen permisos, preferències, sessions i dades de connectors per usuari. Un sol compte pot ser lent per una sessió enorme, historial de comandes, metadades sobredimensionades o ginys propis del rol.
Compara dos comptes del mateix rol. No eliminis metadades per la mida: identifica el component propietari, fes còpia i comprova com es recrea.
Analitzar WooCommerce i el tauler
Un client connectat pot restaurar la cistella, aplicar preus personals, recuperar adreces, consultar comandes, subscripcions o membresies. Prova un compte nou i un altre amb historial. Optimitza consultes, paginació i processos en segon pla; no comparteixis mai HTML de compte o compra entre clients.
El tauler pot sol·licitar actualitzacions, seguretat, còpies, analítica, informes i llicències. Si l’HTML arriba aviat però els ginys continuen carregant, repara o retira el giny innecessari. Si el document triga, perfila PHP i MySQL en aquella pantalla.
Observa també admin-ajax.php i Heartbeat: freqüència, durada, acció i resposta. Heartbeat permet desament automàtic, bloqueig d’entrades i sessions; no el desactivis globalment per considerar-lo soroll.
Si va començar després d’una actualització
Conserva versions i reprodueix la pantalla abans de revertir. Busca avisos nous, comprovacions de capacitats, migracions, recursos administratius, accions programades i errors. Buidar la memòria cau pública pot no canviar res perquè la ruta autenticada l’evita.
Seqüència segura
Compara rols i visitant, registra memòria cau i primer byte, separa frontal, tauler i compte, i confronta un compte nou amb un d’antic. Després identifica consultes, *hooks*, crides externes i Ajax; canvia una sola causa i torna a provar privacitat, permisos i acció original.
Per a una avaluació, indica rol afectat, pantalla, retard, si passa en un o tots els comptes, canvis recents i si existeix Redis. Comparteix registres protegits sense secrets, però no credencials.
L’èxit no és conservar verda una prova pública: és accelerar el perfil i l’acció afectats sense exposar informació privada.