L’optimització deixa de ser fiable quan cada persona prova una altra pàgina, país, sessió o estat de memòria cau. Aleshores s’atribueix una puntuació millor a l’últim ajust encara que les condicions no fossin comparables.
No cal un laboratori: necessites un recorregut escrit, variables controlades i proves que puguis repetir després del canvi.
Començar per un símptoma comercial
Defineix el problema: el visitant nou espera el missatge principal, la imatge mòbil arriba tard, la compra recalcula a poc a poc, l’administrador triga a processar comandes o el formulari demora la confirmació.
«Millorar la puntuació» no identifica qui queda afectat ni quan es considerarà resolt.
Seleccionar poques URL representatives
Inclou portada, servei principal, article normal, pàgina pesada i, si entren dins l’abast, producte, cistella, compra, compte o administració. Explica per què s’hi inclou cadascuna.
No provis inicialment tot el lloc. Un conjunt curt permet atribuir els canvis; amplia’l quan el mètode sigui estable.
Definir l’estat del visitant
Registra usuari desconnectat, administrador o client; primera visita o retorn; consentiment acceptat, rebutjat o pendent; cistella buida o plena; idioma, moneda, dispositiu, xarxa i ubicació.
Aquests factors canvien memòria cau, scripts i feina del servidor. «Prova mòbil» és insuficient si una execució està neta i una altra conserva galetes de WooCommerce.
Separar rutes fredes i calentes
Utilitza almenys una visita amb navegador net i una altra de retorn. La primera elimina memòria cau i galetes del navegador, però pot rebre CDN o pàgina calenta; la segona reutilitza recursos i connexions.
Si importa l’origen, afegeix un MISS controlat. No purguis repetidament producció sense valorar la càrrega. Anota les capçaleres en cada execució.
Triar mètriques relacionades amb l’error
Per a la càrrega: primer byte, LCP, CLS, bytes i peticions. Per a interaccions: INP de camp, tasques llargues, temps Ajax/REST i resposta visual. Per a WooCommerce o formularis: actualització de la cistella, recàlcul, lliurament al pagament i enviament fins a confirmació.
Una puntuació de càrrega no valida una reparació del procés de compra.
Crear un full senzill
Desa una fila per execució:
| Camp | Exemple |
|---|---|
| Desplegament | release-2026-07-28 |
| URL | /services/wordpress-speed/ |
| Estat | desconnectat, navegador net |
| Dispositiu | simulació mòbil |
| Ubicació | Londres |
| Memòria cau | HTML HIT, navegador fred |
| Primer byte | 0,34 s |
| LCP | 2,2 s |
| Element LCP | imatge principal |
| Funció | menú i formulari correctes |
Conserva informes, captures o traces. La taula és l’índex, no el substitut de la prova.
Relaciona la referència amb un commit, desplegament, versions de connectors i tema, WordPress, PHP, data i zona horària. Sense això, el resultat posterior pot incloure actualitzacions alienes. No desis llicències ni secrets.
Mesurar el servidor per separat
Fes diverses mostres de baix volum:
curl -s -o /dev/null
-w 'status=%{http_code} dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}n'
https://example.com/pagina/L’ordre no renderitza, però estableix si WordPress comença a respondre amb regularitat. Conserva mediana, rang i estat de memòria cau.
Desar la cascada del navegador
Configura dispositiu, xarxa i memòria cau acordats, conserva el registre si hi ha navegació, recarrega i completa el recorregut. Desa HAR o traça de forma segura.
Un HAR pot incloure URL, capçaleres i dades enviades. Revisa’l abans de compartir i no capturis contrasenyes, pagaments ni informació de clients.
Afegir comprovacions funcionals
Cada prova ha de verificar navegació, consentiment, formularis, carrusels, galeries, cistella, compra i analítica que entrin dins l’abast. Una pàgina ràpida amb un formulari trencat falla.
En analítica utilitza mètodes de depuració que no contaminin conversions o ingressos reals.
Canviar una hipòtesi cada vegada
Escriu una afirmació verificable: «L’LCP mòbil arriba tard perquè es baixa una imatge de 2200 píxels abans de descobrir la candidata mòbil». Corregeix marcat o fitxer i repeteix exactament la prova.
No activis simultàniament memòria cau, minificació, conversió i retard de JavaScript. Si millora, no sabràs què ha ajudat ni què ha afegit risc.
Definir acceptació i reversió
Abans de treballar acorda, per exemple, mediana LCP sota un límit en la condició indicada, primer byte estable sense memòria cau, imatge dins del pressupost, recàlcul dins del temps, sense errors nous ni augment de CLS i llista funcional aprovada.
No prometis el mateix temps en qualsevol dispositiu i xarxa. Defineix la prova i observa després la tendència real.
Registra fitxers o ajustos modificats, valor anterior, còpia, passos de reversió, migració i purga necessària. Una còpia restaurada alguna vegada és més fiable que una que només existeix.
Repetir i conservar la referència
Utilitza diverses execucions abans i després, compara medianes i no descartis un error greu com una simple anomalia. Després comprova en usuaris reals per dispositiu, grup de pàgines i país quan sigui útil, respectant el consentiment i recollint el mínim.
Mantén la referència per a actualitzacions importants, migracions, canvis de DNS, analítica, consentiment o redissenys. Per a una avaluació aporta símptoma, URL, estats, informes i acció comercial que ha de continuar funcionant, sense contrasenyes.
Així el resultat final es pot revisar i repetir, en lloc de dependre d’una única puntuació favorable.