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

Images Responsive Media

La càrrega diferida d’imatges retarda el contingut principal

Diagnostica la càrrega diferida de WordPress que retarda el hero o imatge principal i exclou només el mitjà crític sense desactivar-la a tot el web.

La càrrega diferida estalvia feina sota el primer plec. Si s’aplica a la primera imatge significativa, el navegador pot descobrir-la massa tard i mostrar un hero buit mentre baixa recursos secundaris.

La solució no és desactivar lazy loading a tot el lloc. Identifica la imatge principal, demostra què la retarda i exclou únicament els mitjans que han d’arribar immediatament.

Reproduir una visita freda

Obre l’URL en una finestra privada amb memòria cau desactivada, aplica una limitació mòbil raonable i recarrega des de dalt. Anota quina regió queda en blanc.

A Elements, determina si és <img>, <picture>, fons CSS o lliscador generat per JavaScript. Després consulta a Network quan comença la petició, la prioritat i l’iniciador.

Així diferencies càrrega diferida de servidor lent, fitxer enorme o renderitzat JavaScript tardà. Una imatge que comença aviat però triga a baixar-se necessita una altra reparació.

Detectar sistemes superposats

WordPress pot afegir loading="lazy" nadiu; tema, constructor, CDN i connectors també poden incorporar atributs de dades i scripts:

<img
  src="placeholder.svg"
  data-src="/wp-content/uploads/hero.webp"
  class="lazyload"
  loading="lazy"
  alt="Reparació urgent de WordPress"
>

L’URL real queda a data-src fins que JavaScript la mou a src. Afegir-hi també càrrega diferida nadiua no accelera res. Esbrina quin component controla el comportament abans de crear exclusions.

Confirmar si és l’element LCP

Grava Performance o revisa Largest Contentful Paint en una prova de laboratori. No suposis que qualsevol hero gran és LCP.

Si la primera imatge de contingut ho és, normalment no s’hauria de carregar de forma diferida. Ha d’exposar src o <source> des de l’HTML inicial i oferir candidats adaptables:

<img
  src="/wp-content/uploads/repair-team-1280.webp"
  srcset="/wp-content/uploads/repair-team-640.webp 640w,
          /wp-content/uploads/repair-team-1280.webp 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Especialista en reparació de WordPress"
>

Utilitza fetchpriority="high" només en el recurs realment crític. Diverses prioritats altes competeixen amb CSS, fonts i el mateix LCP.

Excloure l’objectiu mínim

La majoria d’eines permeten excloure per classe, fragment d’URL, ID o posició. Prefereix un selector estable assignat només al hero. No excloguis totes les imatges de la capçalera si només una és crítica.

Després inspecciona l’HTML final d’un visitant desconnectat. L’URL principal ha d’estar disponible sense esperar el desplaçament; les imatges inferiors han de conservar la càrrega diferida.

Documenta l’exclusió si el constructor regenera el marcat. Un canvi de plantilla pot substituir la classe o el giny.

Revisar lliscadors i heroes creats amb JavaScript

Un lliscador pot retardar la primera diapositiva fins i tot després de retirar loading="lazy". Algunes biblioteques injecten les URL des de JSON, esperen l’esdeveniment de document o calculen dimensions després de les fonts.

Prova en staging una primera imatge estàtica. Si apareix abans, la inicialització del lliscador és el coll d’ampolla. No precarreguis totes les diapositives: transferiries imatges que molts visitants no veuran mai.

Una solució robusta sol renderitzar la primera imatge en HTML i millorar després la resta de diapositives.

Preservar dimensions i retalls

En retirar un sistema de placeholders poden faltar width i height. Afegeix dimensions intrínseques o una proporció estable per reservar espai.

Compara retalls d’escriptori i mòbil. El constructor potser seleccionava una altra font o aplicava object-fit. L’optimització no ha d’estirar retrats, ocultar productes ni introduir CLS.

Verificar més que la puntuació

Després de netejar una vegada memòria cau de pàgina, CDN i recursos generats, repeteix una visita mòbil freda. Confirma que la petició crítica comença abans, la seva URL és al marcat inicial, només ella rep prioritat alta i els mitjans inferiors continuen esperant.

Revisa LCP, CLS, menús, formularis i lliscador. Prova diverses plantilles: una exclusió global de «primera imatge» pot prioritzar el logotip o una miniatura en lloc del contingut.

Demana una avaluació si diverses eines reescriuen imatges, la primera diapositiva neix en JavaScript o les exclusions canvien segons la plantilla. Aporta URL, dispositiu i ajustos ja provats, mai contrasenyes inicialment.

La reparació correcta deixa un únic propietari de la càrrega diferida, protegeix l’LCP real i conserva l’estalvi sota el primer plec.

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