La primera visita triga diversos segons; en actualitzar, la pàgina apareix gairebé a l’instant. Això no demostra simplement que «la memòria cau funciona». Indica que es paga una vegada un cost que després es reutilitza: HTML generat, imatge, font, JavaScript, connexió o emmagatzematge del navegador.
La reparació depèn de quin d’aquests costos desapareix.
Reproduir sense confondre les memòries cau
En una petició poden participar la memòria cau del navegador, pàgina completa, objectes, codi PHP, CDN, DNS i connexions reutilitzades. Una finestra privada elimina part de les dades locals, però no buida necessàriament WordPress ni el node CDN.
En una pàgina autoritzada, registra la primera càrrega privada, recàrrega immediata, nova visita després de la caducitat habitual i primera càrrega des d’una altra ubicació. No purguis tot abans de cada petició: crearies un cas artificial i perdries la possibilitat d’identificar la capa que canvia.
Comparar capçaleres i primer byte
Consulta dues vegades l’HTML:
curl -I https://example.com/pagina/
curl -I https://example.com/pagina/Busca age, cache-control, cf-cache-status, x-cache, x-litespeed-cache, x-fastcgi-cache o la capçalera del proveïdor. Importa si la primera resposta és MISS i la segona HIT, no el nom concret.
Si totes dues són HIT i el navegador millora molt en recarregar, probablement es reutilitza un recurs o feina local. Si la primera és MISS i el primer byte triga, investiga la generació d’origen.
Pots mesurar diverses peticions amb un volum baix:
for i in 1 2 3; do
curl -s -o /dev/null
-w "petició $i: %{time_starttransfer}sn"
https://example.com/pagina/
doneUn resultat de 2,4 segons seguit de 0,2 suggereix feina del servidor desada en memòria cau. Temps semblants amb una millora visual indiquen una altra capa. Això és una comparació diagnòstica, no una prova de càrrega.
No amagar un origen lent
La memòria cau de pàgina completa evita que WordPress reconstrueixi l’HTML per a cada visita. És adequada, però la ruta sense memòria cau continua utilitzant-se en caducar, publicar, purgar, personalitzar o visitar cistella, compra i compte.
Si aquesta resposta triga diversos segons, revisa consultes MySQL, API externes, opcions amb càrrega automàtica, connectors que treballen en cada petició, processos PHP disponibles, sistema de fitxers i errors repetits.
Allargar la durada de la memòria cau redueix la freqüència del cost, però no el repara.
Detectar fragmentació innecessària
El lloc pot crear entrades diferents per paràmetres, idioma, moneda, dispositiu, galetes, campanya, sessió o variants d’URL. Així, la teva prova encerta la memòria cau mentre molts visitants reals obtenen un MISS.
Revisa especialment paràmetres publicitaris i barres finals. No combinis respostes realment personals o diferents: elimina claus sense significat, mai l’aïllament entre clients.
Revisar els recursos de la primera visita
Si el primer byte és ràpid en totes dues peticions, compara les cascades. A la primera càrrega anota bytes, imatge principal, fonts, CSS, JavaScript, tercers i vídeo. A la segona, observa què arriba des de memòria o disc.
Una imatge de 3 MB pot desaparèixer en recarregar i crear una falsa sensació de reparació. Per als visitants nous continua intacta. Corregeix dimensions i formats, srcset i sizes, taxa de bits dels vídeos, pesos de fonts i scripts que no s’utilitzen a la pàgina.
Defineix memòria cau llarga només per a fitxers estàtics versionats.
Comptar connexions, fonts i tercers
La primera visita resol DNS i negocia TCP/TLS per al domini i els serveis externs. Analítica, etiquetes, consentiment, xat, mapes, vídeo, fonts i publicitat multipliquen aquests inicis.
Redueix orígens prescindibles. Reserva preconnect per als dominis realment necessaris al principi.
Si el text queda invisible la primera vegada, revisa famílies, pesos, duplicats, política de memòria cau i font-display. Una regla bàsica pot utilitzar:
@font-face {
font-family: "Brand Sans";
src: url("/fonts/brand-sans-regular.woff2") format("woff2");
font-weight: 400;
font-style: normal;
font-display: swap;
}Comprova que el canvi de font no provoqui salts de disseny.
Comprovar estats especials
Un *service worker* pot servir recursos desats després de la primera visita. Revisa’l a Application: abast, URL controlades i estratègia d’actualització. Prova de desregistrar-lo només en una sessió diagnòstica, no per als usuaris reals.
Compara també visitant nou i recurrent, client connectat i administrador. La memòria cau sol excloure galetes de WordPress o WooCommerce. Si només les sessions obertes són lentes, optimitzar la memòria cau pública no ajudarà: cal revisar la petició dinàmica, la base de dades i els recursos d’aquell estat.
Precarregar sense sobrecarregar
El preescalfament pot reconstruir pàgines importants després d’un purgat, però ha de prioritzar URL valuoses, limitar concurrència i excloure compra, compte, filtres i contingut personal.
Recórrer milers de variants pot esgotar els processos PHP. Preescalfar complementa un origen eficient; no en substitueix la reparació.
No facis mai públicament emmagatzemables la cistella, la compra o el compte per accelerar-ne la primera visita. Verifica amb dues sessions independents que no es comparteixen dades i que la resposta dinàmica és ràpida.
Seqüència de reparació
Reprodueix la diferència, compara el primer byte, identifica HIT o MISS, revisa la cascada de recursos i localitza el cost més gran que desapareix. Canvia només aquella capa, conserva reversió i torna a provar primera visita, recàrrega i recorreguts dinàmics.
Per a una avaluació reuneix URL, temps, capçaleres, estat de sessió, dispositiu, navegador, ubicació i canvis recents. No enviïs contrasenyes. L’objectiu és reparar el cost original, no enterrar-lo sota més capes de memòria cau.