Un indicador verd "caché activat" no demostra que la resposta provada provingui de la memòria cau. Les galetes iniciades, les cadenes de consulta, les sessions de WooCommerce, les variants mòbils o una fallada de CDN poden enviar la sol·licitud de tornada a través de PHP i MySQL.
Traceu una resposta pública des de l’extrem fins a l’origen abans de canviar els connectors o l’hosting.
Definiu la resposta que esteu mesurant
Proveu un URL públic normal en una sessió privada. Utilitzeu l’adreça HTTPS canònica sense paràmetres de seguiment i feu dues o tres peticions separades per uns segons.
Inspeccioneu les capçaleres:
curl -sS -D - -o NUL https://example.com/service/A Windows, NUL descarta el cos; a Linux o macOS utilitzeu /dev/null. Executeu això només en un lloc que controleu.
Cerqueu capçaleres d’estat de la memòria cau, Age, temps del servidor i redireccions inesperades. Els noms de capçalera difereixen entre els amfitrions i els CDN, així que interpreteu-los mitjançant la documentació del proveïdor.
Separa un error d’un cop lent
La primera sol·licitud després d’una purga pot ser legítimament una falta mentre PHP genera la pàgina. Una segona sol·licitud idèntica normalment hauria de ser un èxit si la pàgina es pot guardar a la memòria cau.
Si es perd cada sol·licitud, cerqueu el motiu de la derivació. Si les capçaleres informen d’un èxit però el TTFB continua sent alt, inspeccioneu la ubicació del CDN, la configuració de la connexió i si la capçalera fa referència a una memòria cau interna mentre una altra capa lenta encara es troba al davant.
No feu la mitjana dels encerts i els errors junts. Descriuen dues experiències diferents dels visitants.
Comproveu les galetes i el contingut personalitzat
Les memòria cau de pàgines solen evitar els usuaris i visitants que han iniciat sessió amb galetes de carretó o sessió. Obre una finestra privada nova i inspecciona les galetes de sol·licitud.
Un connector de màrqueting o de consentiment pot establir una galeta que coincideixi involuntàriament amb una regla de bypass àmplia. Les pàgines de WooCommerce com ara el carretó, la compra i el compte no s’han d’emmagatzemar a la memòria cau com a HTML públic normal, però una pàgina de servei informatiu normalment ho hauria de fer.
No elimineu mai les exclusions de comerç electrònic només per crear una visita. Confirmeu si l’URL provat conté contingut personalitzat.
Inspeccioneu les variacions d’URL
Les barres inclinades posteriors, les redireccions d’HTTP a HTTPS, les variants de www i els paràmetres de seguiment poden crear claus de memòria cau separades. Una eina de rendiment pot provar un URL que primer redirigeix o mai escalfa la variant canònica.
Trieu una adreça canònica i feu que les cadenes de redirecció siguin directes. Decidiu si els paràmetres de màrqueting inofensius poden reutilitzar el mateix contingut a la memòria cau mitjançant controls de memòria cau o CDN compatibles.
No ignoreu els paràmetres globalment. Els paràmetres de cerca, moneda, idioma i previsualització poden alterar el contingut i necessitar una gestió independent.
Compareu CDN i l’origen amb cura
Si un CDN s’enfronta al lloc, un error públic encara pot arribar a una memòria cau ràpida del servidor o a una sol·licitud PHP sense memòria cau. Utilitzeu el diagnòstic del proveïdor o una prova autoritzada de fitxers d’hosts/origen per comparar capes.
No exposis una IP d’origen privada ni saltis els controls de seguretat sense permís. Quan les proves d’origen directe no estan disponibles, els registres del servidor i les capçaleres de temporització poden mostrar si la sol·licitud arriba a PHP.
Una memòria cau a prop d’una ubicació de prova no demostra un comportament equivalent a totes les regions. Comproveu una regió de visitant rellevant quan sigui possible.
Mesureu el camí sense memòria cau
Fins i tot la memòria cau de pàgines excel·lent necessita un camí d’error saludable per a purgues, pàgines noves i sol·licituds personalitzades. Perfil de WordPress en posada en escena o amb un seguiment de producció de baix cost.
Dividiu el temps en:
- servidor web i cua PHP;
- Bootstrap de WordPress;
- consultes a la base de dades;
- trucades d’API externes;
- renderització de plantilles;
- Emmagatzematge en memòria cau.
No instal·leu diversos connectors de creació de perfils en un lloc de producció ocupat. Utilitzeu una eina controlada i traieu-la o desactiveu-la després de recollir proves.
Verifiqueu l’escalfament i la invalidació de la memòria cau
Publiceu un canvi d’escenificació inofensiu i confirmeu que l’URL rellevant invalida, es regenera i després arriba a la memòria cau. Una memòria cau que no caduca mai serveix contingut obsolet; una memòria cau depurada per cada esdeveniment cron mai roman calent.
Reviseu si un connector esborra tota la memòria cau sempre que canviï el valor d’estoc d’un producte. La invalidació dirigida pot protegir tant la frescor com la taxa d’èxit.
Quan cal sol·licitar la reparació del rendiment
Sol·liciteu una avaluació quan les capçaleres no estiguin d’acord, cada sol·licitud anònima passa per alt la memòria cau o el camí d’error és inusualment lent. Compartiu l’URL públic, els temps de sol·licitud i les capçaleres de resposta amb els valors sensibles eliminats.
La reparació hauria d’identificar quina capa respon cada sol·licitud, conservar les exclusions de contingut personalitzat i millorar l’origen sense memòria cau en lloc d’informar només que un interruptor de memòria cau està activat.