Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Measurement And Symptom Isolation

PageSpeed apareix aprovat però WordPress continua semblant lent

Un resultat aprovat de PageSpeed no explica tots els retards. Aprèn a mesurar navegació, formularis, compra i interaccions de WordPress.

PageSpeed Insights mostra les mètriques web principals en verd, però el menú triga a obrir-se, els filtres dubten o el procés de compra s’atura entre passos. No hi ha cap contradicció: l’informe acredita unes mesures concretes, no cada pàgina, visitant i acció del lloc.

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 -I https://example.com/
curl -I https://example.com/checkout/

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.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència