Obres la portada, visites un producte i tot respon de seguida. Tanmateix, un client afirma que el web triga. Totes dues experiències poden ser certes: la teva visita utilitza el teu dispositiu, connexió, ubicació, galetes i, sovint, una memòria cau ja preparada. Un usuari nou amb un mòbil mitjà recorre un altre camí.
La investigació no consisteix a decidir qui té raó, sinó a trobar la condició que separa les visites ràpides de les lentes.
Definir exactament què significa «lent»
Demana una URL, una acció i un moment concrets. No és el mateix una pantalla en blanc inicial que una imatge principal tardana, un menú bloquejat, una cerca lenta o un procés de compra que s’atura després d’introduir l’adreça.
Cada símptoma apunta a una capa diferent. Un primer byte lent pot procedir de PHP, MySQL o una API; una pàgina que arriba ràpidament però triga a reaccionar sol exigir revisar imatges, CSS, JavaScript, fonts i tercers. Instal·lar un altre connector d’optimització abans d’aïllar el retard pot ocultar-ne la causa.
Comparar la memòria cau freda i calenta
Les teves visites repetides poden aprofitar HTML en memòria cau, recursos desats al navegador, DNS resolt, connexió TLS oberta i el node CDN ja poblat. El primer visitant potser no té cap d’aquests avantatges.
Prova l’URL exacta en una finestra privada, tot i que això no garanteix que la memòria cau del servidor o CDN estigui buida. Comprova les capçaleres:
Busca valors com cache-control, age, x-cache, cf-cache-status o la capçalera pròpia de l’allotjament. Si una petició repetida mostra HIT i la primera MISS, ja hi ha una diferència mesurable.
Separar el servidor de la càrrega visual
Mesura el temps fins al primer byte a part del temps total:
A PowerShell utilitza curl.exe. Repeteix el mesurament diverses vegades; una sola execució no demostra res. Si el primer byte és alt de manera consistent, revisa WordPress, PHP, consultes MySQL, crides externes i capacitat de l’allotjament. Si l’HTML comença aviat però la pàgina apareix tard, analitza el treball del navegador.
Provar des de la ubicació i el dispositiu del públic
Un web allotjat a Europa pot semblar immediat a Barcelona i trigar molt més a Amèrica o Austràlia. Prova des d’una regió semblant a la del visitant i compara primer byte, Largest Contentful Paint, bytes transferits, nombre de peticions, estat de memòria cau i recurs més lent.
Un portàtil modern amb fibra també oculta feina que un telèfon triga a descarregar, interpretar i dibuixar. A les eines del navegador aplica una vista mòbil i limitació raonable de CPU i xarxa. Revisa si:
la imatge principal comença a baixar massa tard;
s’envia una imatge d’escriptori a una pantalla estreta;
un script ocupa el fil principal;
les fonts bloquegen el text;
el gestor de consentiment retarda funcions;
el disseny salta quan arriben recursos tardans.
Comparar usuaris connectats i visitants nous
Els administradors solen provar amb la sessió oberta. Molts sistemes exclouen de la memòria cau les peticions amb galeta d’usuari; a més, la barra d’administració i certs connectors afegeixen recursos. Alhora, alguns anuncis, consentiments o scripts públics poden no executar-se per a l’administrador.
Compara quatre estats: administrador connectat, usuari desconnectat, primera visita sense galetes i visita repetida amb recursos desats. Optimitza el recorregut comercial afectat, no l’estat que produeixi la xifra més cridanera.
Entendre el laboratori i els usuaris reals
PageSpeed Insights pot mostrar una prova de laboratori controlada i dades de camp agregades de visites reals de Chrome. Poden discrepar perquè canvien dispositius, xarxes, ubicacions, pàgines, memòria cau, consentiment i període històric.
Comprovar plantilles i recorreguts diferents
WordPress no és una sola pàgina. Crea un conjunt reduït amb portada, pàgina de servei, landing més pesada, cerca, producte, cistella, procés de compra i àrea de compte quan existeixin.
Si només falla una plantilla, una migració o canvi global de memòria cau resulta excessiu. Un producte pot enviar totes les variacions mitjançant JavaScript mentre la resta del lloc funciona bé. Reparar aquella plantilla és més segur que reconstruir tota la configuració.
També busca pressió intermitent: còpies, cron, pics de trànsit o falta de processos PHP poden fer que el web funcioni bé just quan l’administrador el revisa.
Conservar proves abans de canviar
No apilis connectors, minificació i diverses memòries cau ni canviïs de servidor sense un cas ràpid i un altre de lent comparables. Aquests canvis poden trencar JavaScript, desar pàgines dinàmiques de WooCommerce i esborrar la prova original.
Anota URL, país, dispositiu, hora, primera o successives visites, estat de sessió, cascada disponible i canvis recents. Afegeix capçaleres d’una petició ràpida i una de lenta. No enviïs contrasenyes inicialment.
El resultat correcte no és que la portada arribi a 95 una vegada. És que el recorregut del visitant afectat millori de manera mesurable i se n’entengui el motiu. La solució pot ser reduir el primer byte, corregir imatges adaptables, retirar feina del navegador, excloure el procés de compra de la memòria cau o reprogramar una tasca pesada. El canvi mínim verificat sol ser més fiable que activar un paquet complet d’optimitzacions.
Observació de l’HTML i estats de visitant que falten per provar
El 24 d’octubre de 2026 a les 23:40 UTC vam fer tres GET per perfil de User-Agent a la versió anglesa d’aquesta guia, des d’un client Python sense cookies ni autenticació. Els sis van retornar 200. El temps fins al primer byte del cos va ser 149,99; 143,91 i 139,68 ms amb User-Agent d’escriptori, i 152,73; 130,82 i 149,49 ms amb el mòbil.
Aquest temps inclou connexió i preparació de la resposta. No és el TTFB de Navigation Timing, una càrrega completa ni una comparació de dispositius reals. No vam carregar recursos, executar JavaScript, buidar memòries cau de producció ni provar comptes connectats. Repetir peticions no demostra cau freda o calenta; les empremtes del cos van variar i tampoc no acrediten contingut idèntic.
La conclusió es limita a aquestes peticions anònimes d’HTML satisfactòries sota les condicions registrades. No descarten lentitud de menú, renderització mòbil o sessió personalitzada. L’explicació de web.dev sobre laboratori i camp ajuda a separar aquestes poblacions.
Conserva URL i contingut quan comparis una visita anònima nova, una recurrent, el consentiment i una sessió iniciada autoritzada. Registra navegador, viewport, xarxa i evidència de memòria cau. Els dos experiments de sota ja mesuren el consentiment desat i els estats nou, recurrent i autenticat amb perfils d’escriptori i mòbil emulat. El telèfon físic i l’acció afectada d’un client necessiten una reproducció representativa.
Sis càrregues reals en escriptori amb preferències desades diferents
El 25 d’octubre de 2026 vam carregar sis vegades la versió anglesa d’aquesta guia en Chrome 155 per a Windows, a 2560 × 1323 píxels CSS i relació de píxel 1. Vam alternar tres rebutjos i tres acceptacions desats mitjançant els controls del lloc, i vam recarregar des de dalt. Totes les observacions es van mantenir en primer pla i van fer servir el mateix contingut. Són visites recurrents d’escriptori, no sessions privades noves ni una comparació amb telèfon.
Un observador optatiu va registrar Navigation Timing, pintures, candidat a LCP i desplaçaments durant uns 15 segons des del seu inici, o 15,2–15,5 segons des de la navegació en aquesta sèrie. El TTFB de la taula va de l’inici de navegació a responseStart. L’observador i el seu petit control afegeixen feina. No es va buidar la memòria cau del navegador ni es va limitar xarxa o CPU; aquestes recàrregues no garanteixen cau freda.
Observacions alternades en escriptori, 25 d’octubre de 2026
Càrrega / elecció desada
TTFB de navegació (ms)
Candidat a LCP (ms)
Entrades de recursos Google
D1 · Rebuig
130.9
284
2
A1 · Acceptació
120.6
244
2
D2 · Rebuig
464.6
588
2
A2 · Acceptació
101.1
276
2
D3 · Rebuig
123.6
228
2
A3 · Acceptació
107.4
204
2
Els rebutjos van donar una mediana del candidat a LCP de 284 ms, amb rang de 228 a 588 ms; les acceptacions, 244 ms, entre 204 i 276 ms. L’element registrat va ser sempre el títol de l’article. Les medianes de primera pintura amb contingut van ser 284 i 204 ms, respectivament. El màxim de les finestres de desplaçament observat va oscil·lar entre 0 i 0,00291. Són observacions acotades, no Web Vitals de camp de tota la visita.
El rebuig més lent també va tenir una espera més gran fins al primer byte. Amb tres repeticions per grup i rangs de LCP superposats, la mostra no demostra que el consentiment causés la diferència. Aporta casos reals per investigar, en lloc de donar un veredicte per la sensació d’una persona.
Una petició del tag no identifica el consentiment
Tots dos grups van registrar dues entrades de recursos procedents de Google. La configuració servida fixa el consentiment inicial en denegat i actualitza l’elecció d’analítica quan s’accepta. La documentació de Consent Mode de Google distingeix bloquejar etiquetes de carregar-les amb valors inicials denegats. El patró observat encaixa amb la segona opció. Aquesta prova no va inspeccionar continguts de galetes ni càrregues de les peticions, de manera que no certifica cada senyal o proveïdor.
Vam afegir Preferències de galetes per reobrir els controls existents. Per repetir la comparació, tria un estat, torna a dalt, recarrega, mantén la pàgina visible i registra la mateixa finestra. Anota consentiment i comportament de peticions al costat del temps. Vam retirar el panell temporal de mesurament i vam restaurar el rebuig que tenia inicialment aquest navegador.
Aquest primer experiment compara opcions de consentiment desades en visites recurrents d’escriptori. El següent fa servir contextos aïllats per mesurar visites noves, recurrents i amb sessió iniciada en escriptori i mòbil emulat. Tots dos utilitzen la URL anglesa; les traduccions expliquen les mateixes observacions.
Visita nova, recurrent i amb sessió iniciada: 18 càrregues mesurades
Allò d’«a mi em va ràpid» necessitava una comparació amb condicions clares. El 25 d’octubre de 2026 vam carregar la versió anglesa d’aquesta guia amb un context anònim nou, una segona visita dins del mateix context i una sessió real de subscriptor de WordPress. Vam repetir tres vegades cada condició, tant en escriptori com en mòbil emulat. El contingut renderitzat de l’article va conservar la mateixa empremta SHA-256 a les 18 càrregues.
El perfil d’escriptori tenia 1440 × 900 píxels CSS i DPR 1. El de Pixel 7 feia servir 412 × 839, DPR 2,625, capacitat tàctil i User-Agent mòbil, dins de Chromium 152.0.7977.82 amb Playwright 1.63.0. Tots dos van utilitzar la mateixa xarxa del VPS, sense limitació de xarxa ni de CPU. És emulació del comportament responsive; no reprodueix un telèfon físic ni el seu processador. Playwright documenta l’abast dels perfils de dispositiu i l’aïllament de l’emmagatzematge entre contextos.
La revisió va descobrir un error de maquetació mòbil. Tot i configurar el perfil a 412 × 839, el viewport de disseny registrat es va ampliar a 1435 × 2921 a les nou càrregues mòbils. Els blocs llargs de codi eixamplaven una columna de la graella i el navegador reduïa la pàgina per encabir-la. La taula recull aquell comportament anterior a l’arranjament. Després vam limitar l’amplada de la columna i vam mantenir el desplaçament intern del codi i les taules. Una nova revisió visual comprova l’amplada corregida; aquests temps no són resultats posteriors a l’arranjament ni una millora de velocitat demostrada.
Tres càrregues per condició · candidat a LCP i CLS als primers 15 segons
Perfil i visita
LCP medià (rang), ms
TTFB medià, ms
CLS medià
Escriptori · Anònima nova
1108 (1100–1308)
182
0,0092
Escriptori · Anònima recurrent
460 (428–484)
86
0
Escriptori · Sessió iniciada
2224 (1364–2584)
170
0,009
Mòbil emulat · Anònima nova
1020 (1012–1828)
105
0
Mòbil emulat · Anònima recurrent
252 (204–276)
86
0
Mòbil emulat · Sessió iniciada
1104 (900–1308)
162
0
Les pàgines es van mantenir en primer pla. Un observador instal·lat abans dels scripts va recollir el candidat a LCP i la finestra més gran de CLS durant els primers 15 segons. El TTFB va de l’inici de navegació a responseStart. No hi va haver scroll, clics ni operacions comercials. El candidat a LCP va ser sempre l’H1. Són observacions acotades de laboratori; no equivalen a Core Web Vitals de camp ni mesuren INP.
Què ens diuen aquestes dades
La segona visita va ser més ràpida en les sis parelles. Va registrar set recursos amb zero bytes transferits i una mida descodificada positiva; els contextos anònims nous no en van registrar cap amb aquesta combinació. És un senyal compatible amb reutilització de recursos al navegador. No separa el paper de la memòria cau del DNS, les connexions, la variació de xarxa o l’ordre fix de primera i segona visita. Tampoc permet afirmar un HIT de memòria cau del servidor sense una capçalera que ho confirmi.
La sessió iniciada era real: les sis càrregues autenticades mostraven la barra de WordPress i l’enllaç de sortida. El document retornava directives de memòria cau privades i no-store. Aquest grup va registrar 15 recursos, davant dels set o vuit de la visita anònima nova. La interfície addicional canvia l’experiència mesurada; les xifres no demostren que una cookie o un plugin concret causin el retard. Vam utilitzar un subscriptor temporal sense permisos d’edició, que després vam eliminar revocant-ne les sessions.
La càrrega nova més lenta del mòbil emulat també va esperar 884 ms fins al primer byte. Una pantalla petita no estabilitza la xarxa. Si un client comunica lentitud, cal repetir la matriu en el seu dispositiu físic i la seva connexió, i afegir-hi l’acció afectada. Tornar a obrir una guia no representa un checkout, un filtre o una àrea de clients.
En totes les visites el consentiment d’analítica va continuar sense triar i l’avís inicial es va mantenir visible. La comparació entre acceptació i rebuig és al bloc anterior. No vam desplegar cap optimització durant les mesures. Aquesta versió catalana i la castellana expliquen l’experiment de la URL anglesa; no són mostres de rendiment independents.
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.