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:
curl -I https://example.com/pagina/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:
curl -s -o /dev/null
-w 'DNS: %{time_namelookup}snConnexió: %{time_connect}snTLS: %{time_appconnect}snPrimer byte: %{time_starttransfer}snTotal: %{time_total}sn'
https://example.com/pagina/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.