Si el panell d’usuaris reals de PageSpeed aprova, però el menú, els filtres o el checkout continuen lents, revisa per separat l’abast de l’informe i l’acció afectada. Una puntuació verda de rendiment de laboratori també és un resultat diferent d’aprovar Core Web Vitals de camp.
El pas següent no és perseguir una puntuació més alta, sinó identificar el retard que aquella prova no representa.
Entendre quines dades estàs veient
PageSpeed pot mostrar dades de camp procedents de visites reals de Chrome, una execució de laboratori o totes dues. Comprova si les dades corresponen a l’URL o a tot el domini, mòbil o escriptori, quin període cobreixen i si l’URL provat inclou l’idioma i les redireccions correctes.
Les dades d’origen poden barrejar moltes pàgines senzilles i ocultar un producte o procés de compra lent. Una prova de laboratori, per la seva banda, no representa directament la varietat de dispositius, connexions, galetes i ubicacions reals.
Convertir «sembla lent» en una acció
Completa la frase: «El web sembla lent quan…». Pot ser en obrir el menú, triar una variació, aplicar un cupó, enviar un formulari, cercar productes, acceptar les galetes o desplaçar-se per una pàgina amb vídeos.
Moltes d’aquestes accions passen després que Largest Contentful Paint ja hagi acabat. Poden dependre de JavaScript, Ajax, una consulta MySQL o una API externa; una bona puntuació de càrrega no les descarta.
Provar el recorregut complet
En un web de serveis, reprodueix l’arribada a la landing, navegació, obertura del formulari i enviament d’una prova segura. A WooCommerce, recorre producte, variació, cistella, procés de compra, adreça, mètodes d’enviament i pagament.
Anota el moment exacte en què comença l’espera. Si triar el producte és immediat però recalcular el transport triga, comprimir la imatge principal no resoldrà la queixa.
No facis comandes reals ni enviïs contactes falsos sense acord. Utilitza un entorn de proves, un producte de prova o una sol·licitud interna clarament identificada.
Investigar interaccions i INP
Interaction to Next Paint resumeix la capacitat de resposta observada en moltes interaccions, però una mitjana aprovada no garanteix que cada clic important sigui ràpid. Obrir un menú gran, recalcular fragments de WooCommerce o validar un formulari complex pot continuar bloquejant l’usuari.
Grava aquella acció al tauler Performance de Chrome. Busca una tasca llarga que comenci a prop del clic i identifica si pertany al tema, un connector, analítica, consentiment o recàlcul del disseny. No eliminis un fitxer només per la mida: un script petit pot provocar molta feina al DOM.
Revisar la petició durant l’espera
Obre Network, conserva el registre i repeteix el problema. Filtra per fetch i xhr. A WordPress solen aparèixer admin-ajax.php, rutes /wp-json/, peticions de cistella o compra i serveis de pagament, mapes o CRM.
Una fase llarga d’espera del servidor apunta a PHP, MySQL, crides externes o capacitat de l’allotjament. Una resposta ràpida seguida d’una interfície congelada torna l’atenció a JavaScript i renderitzat.
Desa l’estat i la resposta abans de canviar res. Un avís HTML retornat amb codi 200 pot ser interpretat malament per JavaScript i semblar un problema de velocitat.
Comparar pàgines desades i dinàmiques
La memòria cau de pàgina completa pot accelerar enormement una landing, però no ha de servir de la mateixa manera la cistella, la compra o el compte:
curl -q --silent --show-error --max-time 20 --dump-header - --output /dev/null https://example.com/
curl -q --silent --show-error --max-time 20 --dump-header - --output /dev/null https://example.com/checkout/Són capçaleres de dos GET del document, sense seguir redireccions ni executar el navegador. HEAD pot seguir una altra ruta del servidor. Estat i capçaleres de memòria cau són observacions, no una prova de la causa de lentitud del recorregut.
No facis públic i emmagatzemable el procés de compra per igualar la portada. Comprova si la petició dinàmica acaba en un temps raonable i revisa processos PHP disponibles, consultes lentes, sessió de WooCommerce, accions programades, API de pagament o transport i errors repetits.
Provar estats de consentiment
Una prova automàtica pot no triar les mateixes galetes que un visitant. Després d’acceptar analítica, anuncis, xat o vídeo, la pàgina pot adquirir força feina addicional.
Compara abans de triar, després de rebutjar allò opcional, després d’acceptar les categories normals i en una visita de retorn. Les funcions essencials han de continuar disponibles. No avancis scripts subjectes a consentiment només per millorar la puntuació.
Mesurar resultats comercials
Les mètriques web principals són valuoses, però no confirmen quant triga una cerca, un formulari, l’actualització de l’enviament o el lliurament al proveïdor de pagament. Afegeix mesures com:
- enviament del formulari fins a la confirmació visible;
- canvi d’adreça fins a mostrar transportistes;
- clic a «Fer la comanda» fins a obrir el pagament;
- selecció de filtre fins a actualitzar els resultats.
Segmenta quan sigui possible per dispositiu, navegador, país, pàgina, idioma i visitant nou o recurrent, sense recollir dades sensibles. Una mitjana saludable pot amagar un grup mòbil lent en un mercat concret.
Canviar només amb una hipòtesi
Abans d’optimitzar, registra l’acció afectada, on es consumeix el temps, el canvi proposat, la millora esperada, la reversió i la prova final. Si no pots relacionar la modificació amb el retard, encara no està justificada.
No apilis minificació, retards de JavaScript o memòries cau addicionals per millorar una mètrica ja aprovada. Pots trencar CSS, consentiment o compra sense tocar la causa.
Per a una avaluació, reuneix URL, acció exacta, dispositiu, navegador, ubicació aproximada, estat de consentiment, gravació i cascada o traça si existeixen, a més de canvis recents. No enviïs contrasenyes inicialment.
La reparació correcta millora el recorregut sense espatllar les mètriques que ja funcionaven. Després del canvi, repeteix tota l’acció i torna a comprovar la pàgina amb Core Web Vitals.
Exemple observat: escriptori 99, mòbil emulat 79 i sense dades de camp
Vam mesurar la versió anglesa d’aquesta guia a PageSpeed Insights el 25 d’octubre de 2026, amb captura marcada a les 01:38 CEST. L’informe d’escriptori va mostrar rendiment 99, LCP 0,8 s, FCP 0,7 s, TBT 50 ms i CLS 0,025. L’informe mòbil emulat va mostrar rendiment 79, LCP 4,0 s, FCP 3,1 s, TBT 40 ms i CLS 0. El perfil mòbil era un Moto G Power emulat amb 4G lenta; tots dos van mesurar càrrega inicial amb Lighthouse 13.5.0.
Tots dos panells d’usuaris reals indicaven que no hi havia dades. No és un cas d’aprovació de Core Web Vitals de camp: mostra que una puntuació verda d’escriptori no representa l’altre perfil provat. Una altra sol·licitud d’informe va retornar el mateix minut de captura i valors; no la comptem com a prova independent de repetibilitat.
No vam aplicar una optimització entre perfils. Aquestes observacions no estableixen causa, millora, rendiment d’un telèfon físic, efecte del consentiment ni temps de menú o checkout. TBT és la mètrica de laboratori mostrada, no un INP mesurat en usuaris reals.
Per continuar, registra URL, versió, perfil, consentiment i sessió, i grava per separat l’acció afectada. La documentació oficial de recorreguts Lighthouse diferencia navegació, interval i captura d’estat: el mode escollit ha de poder observar la pregunta. Una captura d’estat no aporta el temps d’una interacció que no ha registrat.
Fes servir la guia per comparar condicions de visitants ràpids i lents i demana una avaluació de rendiment WordPress amb l’acció concreta i l’informe. Comença descrivint-ho; les traces i l’accés gestionat s’acorden sense enviar contrasenyes ni dades de clients en un formulari públic.
Per contractar la intervenció, la guia de pressupost d’optimització WordPress per al 2027 relaciona el retard observat amb abast, lliurables, validació i costos addicionals.