La foto principal pesa menos que antes, pero el encabezado sigue apareciendo tarde. Volvés a comprimir y el producto empieza a perder detalle. Si la demora está en descubrir la imagen o en mostrarla después de descargarla, seguir reduciendo calidad puede cambiar el archivo sin resolver la espera.
LCP, Largest Contentful Paint, registra cuándo se presenta el elemento de contenido más grande dentro de la vista durante la carga, bajo las reglas de la métrica. Puede ser una imagen o un bloque de texto. Este taller se concentra en el caso de una imagen principal: vamos a identificarla, seguir su carga y elegir el arreglo según dónde se consume el tiempo.
Primero comprobá cuál es el elemento LCP
No asumas que es la foto que el equipo llama “hero”. En móvil, un título puede ocupar más espacio; en otra plantilla puede ser la imagen del producto. Revisá el elemento señalado por las herramientas de rendimiento y repetí la prueba en las vistas relevantes.
Usá PageSpeed Insights para mirar datos de campo cuando existan y una captura de laboratorio para investigar. Comprobá si la información real corresponde a esa URL o al origen. El objetivo de buen LCP es hasta 2,5 segundos al percentil 75 de las visitas observadas; una ejecución aislada de tu equipo no describe a todos los usuarios.
Registrá URL, vista, caché y condiciones. Si cambian el elemento LCP o el archivo entre pruebas, dejalo anotado. Comparar una portada de escritorio con un título móvil puede llevarte a celebrar una optimización que todavía no fue evaluada en el mismo escenario.
Seguí una carga completa antes de tocar el archivo
En DevTools, abrí Network y una captura de rendimiento. Ubicá el documento HTML, la solicitud de la imagen que corresponde al elemento LCP y el momento de presentación. La investigación parte de una secuencia: llega el HTML, se descubre el recurso, se descarga y finalmente puede mostrarse.
Vamos a usar un ejemplo hipotético de 3,4 segundos. El primer byte del documento llega a los 0,7 s. La imagen empieza a descargarse a los 1,6 s, termina a los 2,2 s y aparece a los 3,4 s. Eso deja cuatro tramos: 0,7 s de respuesta inicial, 0,9 s de demora de inicio, 0,6 s de descarga y 1,2 s de espera de presentación.
La imagen no está consumiendo 3,4 segundos en descargarse. Si reducís su transferencia de 0,6 a 0,3 s, todavía tenés que investigar el retraso para mostrarla. En el ejemplo, un script mantiene oculto el encabezado hasta terminar una animación de entrada. El archivo más liviano podría terminar antes y pasar más tiempo esperando oculto.
Intervención uno: que el navegador la encuentre a tiempo
Buscá la URL de la imagen en el HTML inicial. Si está en un elemento img con src o srcset, puede descubrirse sin esperar a que un script construya el encabezado. Si solo aparece después de una petición de datos o dentro de un fondo CSS, la secuencia puede empezar más tarde.
Revisá si una herramienta de optimización convirtió el origen en data-src o marcó la imagen principal con carga diferida. Para una imagen visible y candidata a LCP, esa espera suele ser contraproducente. Conservá el lazy loading donde aporta, como imágenes más abajo, y excluí el recurso crítico correspondiente.
Si la imagen de fondo necesita seguir siendo un fondo, una precarga bien elegida puede adelantar su descubrimiento. Antes de agregarla, verificá recurso final, formato y variante. Precargar una imagen de escritorio que el móvil no va a usar puede consumir ancho de banda sin ayudar.
Intervención dos: una salida HTML que represente el diseño
Este ejemplo supone una fotografía que conserva la proporción en todos sus tamaños y ocupa todo el ancho en móvil, con un máximo de 1200 píxeles CSS en pantallas grandes. Las rutas y dimensiones son ilustrativas; tienen que coincidir con tus archivos reales.
<img
src="/media/taller-1200.webp"
srcset="/media/taller-640.webp 640w,
/media/taller-1200.webp 1200w,
/media/taller-1800.webp 1800w"
sizes="(max-width: 1200px) 100vw, 1200px"
width="1800"
height="1125"
fetchpriority="high"
alt="Mesa de trabajo con muestras de cerámica">srcset ofrece candidatos; sizes comunica el espacio de presentación previsto. El navegador elige considerando esas señales y la densidad de pantalla. Si la foto ocupa media pantalla y declarás ancho completo, podés inducir una descarga mayor de la necesaria. La corrección consiste en describir el layout, no en copiar el atributo de otra web.
Los valores width y height expresan la proporción intrínseca y ayudan a reservar espacio. No obligan a mostrar 1800 píxeles de ancho si el CSS hace la imagen fluida. Conservá reglas como ancho máximo del contenedor y altura proporcional; si recortás con object-fit, revisá que el producto o la persona no queden cortados en móvil.
fetchpriority="high" es una indicación de prioridad, no una descarga garantizada ni una solución para todos los recursos. Aplicala al candidato crítico que comprobaste. Marcar varias imágenes secundarias como urgentes puede hacerlas competir con la que realmente importa.
Intervención tres: elegí tamaño y compresión mirando el resultado
Partí de una imagen maestra y generá variantes coherentes con el espacio de uso. No envíes por costumbre una foto de varios miles de píxeles a una tarjeta pequeña. Tampoco fuerces un único archivo diminuto para todas las pantallas si la imagen necesita mostrar detalles de un producto.
Compará formatos apropiados para el contenido y los navegadores que atendés. WebP o AVIF pueden ofrecer buenas opciones para fotografías, pero el resultado depende del archivo, la configuración y la escena. Una ilustración plana, una fotografía con textura y una imagen con texto requieren revisiones diferentes.
Miralas en el tamaño real del diseño y en una pantalla de mayor densidad. Buscá pérdida de bordes, manchas en fondos, degradados rotos y detalles que afectan la compra. Un número de kilobytes menor no compensa que el acabado del producto se vea incorrecto.
Guardá una decisión verificable: archivo seleccionado, dimensiones, peso y dónde se usa. Así, cuando alguien reemplace la portada desde el CMS, puede mantener el criterio sin volver a investigar todo. Evitá reglas universales de peso que ignoran composición, resolución y contexto.
Intervención cuatro: dejá que se muestre cuando esté lista
Si la descarga termina temprano pero la imagen aparece tarde, revisá CSS, scripts y tareas de presentación. Una animación que arranca con opacidad cero, un slider que espera inicialización o un encabezado escondido hasta resolver varios recursos pueden extender la demora.
En el ejemplo de 3,4 segundos, el equipo decide mostrar el contenido principal sin esperar la animación. Puede mantener movimiento decorativo en otro elemento, siempre que no vuelva a bloquear información importante. La decisión visual se evalúa junto con la carga y con preferencias de movimiento reducido.
También comprobá si existen versiones separadas de escritorio y móvil cargadas a la vez aunque una quede oculta. Usar dos elementos y esconder uno con CSS no garantiza evitar su descarga. Para recortes realmente diferentes, una implementación con picture puede expresar mejor la selección, con sus fuentes y proporciones revisadas.
La demora de presentación puede incluir trabajo excesivo del hilo principal. Si la página además se traba cuando tocás controles, continuá con el análisis de INP. LCP e INP no son intercambiables, aunque una misma tarea pesada pueda influir en ambas experiencias.
Qué revisar si el sitio usa WordPress
Inspeccioná la etiqueta que realmente sale al visitante. WordPress, el tema, un constructor y un plugin de optimización pueden modificar carga, tamaños o prioridades. Que una opción del panel diga “optimizado” no confirma que esté afectando a la imagen correcta.
Comprobá si el tema usa las variantes generadas en la biblioteca de medios o fuerza el tamaño original. Revisá el ancho efectivo del contenedor y la coherencia de sizes. Si la imagen se usa como fondo de un constructor, puede no seguir el mismo circuito que una imagen insertada desde la biblioteca.
Al cambiar un archivo, probá la versión pública con la caché actualizada y verificá la URL solicitada. Una miniatura anterior puede seguir sirviéndose mientras el editor muestra la nueva. Asegurate además de que el sistema no genere dos precargas para el mismo recurso con configuraciones que provoquen transferencias redundantes.
Repetí la medición cambiando una causa por vez
Volvamos al caso hipotético. Primero el equipo excluye la imagen principal de carga diferida y comprueba que la solicitud empiece antes. Después retira la espera de animación y verifica que disminuya la demora de presentación. Finalmente ajusta los candidatos para móvil y comprueba qué archivo descarga el navegador.
Si todo cambia a la vez, podés obtener una mejora sin saber qué la produjo ni qué decisión conviene conservar. Anotá cada intervención y compará varias ejecuciones en condiciones iguales. Revisá también una página que comparta la plantilla: una regla puede afectar más de una portada.
- El recurso elegido corresponde al elemento LCP de la vista probada.
- La solicitud empieza antes si ese era el cuello de botella.
- La variante descargada tiene sentido para su tamaño de presentación.
- La imagen mantiene legibilidad, encuadre y calidad en móvil y escritorio.
- El contenido puede mostrarse sin una espera visual innecesaria.
- La observación posterior de campo se interpreta con su ventana y alcance.
Si el primer byte del HTML es el tramo dominante, la próxima tarea puede estar en servidor, caché o redirecciones, aunque la imagen ya esté bien resuelta. La guía de revisión técnica de una web ayuda a ubicar ese hallazgo dentro del sitio completo.
Optimizaste la imagen principal cuando podés explicar qué recurso se descarga, por qué empieza en ese momento y qué permite que aparezca. Esa explicación protege tanto el rendimiento como el diseño: el próximo cambio de portada puede conservar lo aprendido en lugar de volver al punto de partida.