El web funciona per Wi-Fi, però amb dades mòbils la portada queda incompleta, la imatge principal apareix tard o el menú no respon. Aquesta diferència és una prova útil: amplada de banda, latència, capacitat del telèfon o contingut condicional revelen un cost que el Wi-Fi amaga.
No comencis amb una optimització genèrica. Separa els factors per no comprimir una imatge quan el retard pertany al servidor ni migrar l’allotjament quan el navegador baixa diversos megabytes de vídeo.
Confirmar que canvia la connexió
Utilitza el mateix telèfon, navegador i URL. Obre una pestanya privada, prova dues vegades amb Wi-Fi, desactiva’l i repeteix amb dades mòbils. Anota què apareix tard i el tipus i intensitat de senyal.
No comparis un ordinador per Wi-Fi amb un altre dispositiu per 4G: canviaries connexió, maquinari i navegador alhora. Una cobertura interior feble també pot causar pèrdua de paquets i reintents, així que repeteix des d’una zona amb senyal estable.
Separar el primer byte de la resta
Mesura l’inici de la resposta i la mida baixada:
curl -s -o /dev/null
-w 'Primer byte: %{time_starttransfer}snTotal: %{time_total}snBaixat: %{size_download} bytesn'
https://example.com/pagina/La petició no imita un mòbil, però diferencia HTML tardà de feina posterior. Si el primer byte és lent en totes les connexions, revisa WordPress, PHP, MySQL i allotjament. Si arriba aviat i la pàgina mòbil continua incompleta, analitza recursos i renderitzat. Repeteix: l’operadora pot utilitzar una altra ruta fins al servidor.
Revisar els bytes enviats realment
A les eines del navegador aplica vista mòbil, obre Network i recarrega sense memòria cau per a aquesta prova. Ordena per mida transferida i comprova quin recurs forma el Largest Contentful Paint.
Revisa si el telèfon rep una imatge d’escriptori, si s’utilitzen mides generades per WordPress, si els fons CSS tenen alternativa mòbil, si realment es lliura WebP o AVIF i si un carrusel baixa diapositives ocultes.
L’extensió .webp no garanteix un fitxer lleuger. Ha de correspondre a les dimensions visibles i a una qualitat raonable.
Verificar srcset i sizes
WordPress sol generar imatges adaptables, però el tema o constructor pot ometre-les:
<img
src="/uploads/hero-1200.webp"
srcset="/uploads/hero-480.webp 480w,
/uploads/hero-768.webp 768w,
/uploads/hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 1200px"
width="1200"
height="700"
alt="Servei de rendiment WordPress"
>El navegador combina srcset, sizes, amplada de pantalla i densitat. Si sizes declara erròniament 1200 píxels al mòbil, triarà un fitxer excessiu. No copiïs un valor genèric per tot el tema: comprova l’amplada CSS real a cada punt de ruptura.
Tractar el vídeo com un pressupost independent
Un MP4 decoratiu necessita una decisió mòbil explícita. Comprova dimensions, taxa de bits, àudio innecessari, moment de reproducció, pòster i precàrrega:
<video muted loop playsinline preload="metadata"
poster="/media/hero-poster.webp" aria-hidden="true">
<source src="/media/hero-mobile.mp4" type="video/mp4">
</video>No és una regla universal: una demostració de producte pot requerir controls i text accessible. L’objectiu és no forçar una baixada completa abans del contingut principal.
Reduir el cost de fonts i tercers
Amb molta latència, cada font paga DNS i connexió. Revisa famílies, pesos, duplicats, memòria cau, CORS, font-display i precàrregues. Precarrega només la font que utilitza el text inicial; fer-ho amb tots els pesos competeix amb CSS i la imatge principal.
Agrupa per domini les peticions d’analítica, consentiment, xat, mapes, vídeos i publicitat. Pregunta si cada servei és necessari en aquella pàgina, si bloqueja menú, formulari o compra i què passa si no respon. No retardis scripts a cegues: podries trencar la funció que intentes protegir.
Mesurar JavaScript i contingut mòbil duplicat
El telèfon no només baixa més a poc a poc: també triga més a interpretar JavaScript. Grava una traça en carregar i obrir la interfície afectada. Relaciona les tasques llargues amb constructor, lliscador, animacions, variacions, consentiment o etiquetes duplicades.
Comprova si el tema genera seccions diferents per a escriptori i mòbil i n’amaga una amb CSS. display: none no evita necessàriament baixar imatges, vídeos o scripts. Busca duplicats de capçaleres, carrusels, menús i formularis.
Comparar el consentiment
Prova abans de decidir, després de rebutjar allò opcional, després d’acceptar i en una visita de retorn. Si el problema apareix només en acceptar, identifica els serveis afegits. Mantén el comportament de privacitat previst mentre retires feina innecessària.
Reparar amb canvis verificables
No activis alhora diversos connectors de memòria cau, imatges i minificació ni substitueixis tota la biblioteca multimèdia sense saber quins fitxers es lliuren. Registra l’estat inicial, canvia una causa demostrada i conserva una reversió.
Una reparació correcta inicia la resposta sense demora evitable, prioritza text i imatge principal, lliura mitjans adequats al mòbil i manté menú, formularis i compra utilitzables mentre carreguen elements opcionals.
Repeteix les proves per Wi-Fi i dades mòbils i comprova també escriptori, analítica i WooCommerce. Per a una avaluació inicial n’hi ha prou amb URL, model de telèfon, navegador, país i símptoma; no calen contrasenyes.