El patrón que reduce tu LCP 4 veces sin reescribir tu sitio

TL;DR: No necesitas reescribir tu sitio para mejorar el LCP. Hay un patrón estable de cinco palancas (imagen del hero, fuentes, CSS crítico, scripts bloqueantes y TTFB) que, aplicadas en el orden correcto, reducen el LCP entre 3 y 5 veces. Son ajustes puntuales sobre lo que ya tienes, no una migración.

Una conversación que hemos tenido demasiadas veces.

“Tu sitio carga lento. Mide 4,8 segundos.”

“OK, ¿cuánto cuesta hacerlo de nuevo?”

La suposición de fondo es que mejorar performance requiere reescribir el sitio. Cambiar de plataforma. Empezar de cero. Y casi siempre, esa suposición es errónea.

En la mayoría de los casos, hay un patrón estable de optimizaciones que reduce el LCP entre 3 y 5 veces sin tocar la arquitectura del sitio. Cinco palancas, en un orden específico, que mueven la aguja sin necesidad de migración.

Si todavía no mediste tu LCP actual, conviene empezar por Mide tu sitio antes de invertir: la guía completa al baseline objetivo, antes de optimizar nada.

El patrón típico: anatomía de un LCP malo

Antes de hablar de soluciones, vale la pena entender de qué está compuesto el LCP. Cuando un sitio carga lento, hay tres bloques de tiempo que suman:

TTFB (Time to First Byte): lo que tarda tu servidor en responder al primer pedido del navegador. Si tienes hosting compartido viejo, este número solo puede ser 1 o 2 segundos.
Tiempo de descarga de recursos críticos: HTML, CSS, JavaScript y fuentes que el navegador necesita antes de poder mostrar tu contenido principal. Acá se acumula la mayor parte del problema en sitios modernos.
Render delay: el tiempo entre que el navegador tiene todo lo que necesita y efectivamente pinta el elemento más grande de la pantalla. Aquí entran los problemas de fuentes, layout shifts e imágenes mal configuradas.

Sumar 4 o 5 segundos de LCP típicamente significa: 1,5s de TTFB, 2s de recursos críticos, 1s de render delay. Si optimizas cada bloque, llegas a sub-1,5s total. Eso es la mejora 4 veces que comentamos arriba.

La buena noticia: ninguna de las optimizaciones requiere reescribir el sitio. Son ajustes quirúrgicos sobre lo que ya tienes.

Palanca 1: la imagen del hero

En el 70% de los sitios PyME chilenos, el elemento que define el LCP es la imagen principal del banner o hero. Es la imagen que ve el usuario apenas carga la página, y es típicamente la más pesada del sitio.

Tres ajustes resuelven el 80% de los casos:

Comprimir la imagen al peso correcto. Si tu hero es un JPG de 2,3MB, está sobre-dimensionado. Una imagen de hero bien optimizada pesa entre 80KB y 200KB en formato WebP o AVIF. Herramientas gratis para convertir: Squoosh de Google, TinyPNG, ImageOptim.

Servir el tamaño correcto según el dispositivo. No tiene sentido cargar una imagen de 2400px de ancho en un móvil que tiene viewport de 390px. Usar srcset con 2 o 3 versiones (mobile, tablet, desktop) reduce el peso descargado en mobile entre un 60% y un 80%.

Cargarla con prioridad alta. Por defecto, el navegador trata todas las imágenes con la misma prioridad. Marcar la imagen del hero con el atributo fetchpriority="high" y loading="eager" le dice al navegador “esta es la que importa, cárgala primero”. El resto de imágenes pueden ir con loading="lazy".

Una sola de estas tres optimizaciones, bien hecha, reduce el LCP entre 0,8 y 1,5 segundos. Las tres juntas, típicamente 1,5 a 2 segundos.

Palanca 2: las fuentes web

Las fuentes son el segundo gran culpable de LCP malo. El problema es típico: el navegador descarga el HTML pero no puede mostrar el texto hasta que descargue la fuente. Esos segundos cuentan.

Tres ajustes resuelven el problema en la mayoría de los casos:

Hospedar las fuentes localmente. Si estás cargando fuentes desde Google Fonts CDN, tu navegador hace una conexión adicional a otro dominio. Pasar a self-hosted (servir las fuentes desde tu propio dominio) elimina esa latencia. Diferencia típica: 150 a 300ms.

Preload de las fuentes críticas. Con <link rel="preload" href="..." as="font"> en el <head>, le dices al navegador “empieza a descargar esta fuente ya, no esperes a parsear el CSS”. Esto adelanta la descarga 300 a 500ms.

Font-display: swap. Esta directiva CSS le dice al navegador “si la fuente custom no llegó, muestra el texto con una fuente del sistema mientras llega”. Evita el famoso FOIT (flash of invisible text) que típicamente bloquea el LCP 1 a 2 segundos.

¿Cuánto LCP tiene tu sitio hoy? Mide primero, optimiza después. Es gratis y el reporte se entrega en minutos.

Medir mi sitio ahora →

Palanca 3: CSS crítico inline

El navegador no puede pintar tu hero hasta que parsea todo tu CSS. Si tu hoja de estilos pesa 200KB y se descarga de un archivo externo, ahí están otros 300 a 600ms.

La técnica es dividir tu CSS en dos:

CSS crítico: lo mínimo necesario para pintar el contenido above-the-fold (hero, primera sección, header). Típicamente 5 a 10KB. Va inline en el <head> del HTML.

CSS no crítico: el resto. Animaciones, footer, secciones inferiores. Va en archivo externo con media="print" onload="this.media='all'" o con rel="preload" + onload, que le dice al navegador “carga esto pero no bloquees el render”.

El resultado: el navegador puede empezar a pintar el hero apenas baja el HTML, sin esperar el CSS completo. Mejora de LCP típica: 400 a 700ms.

Es la optimización más técnica de las cinco. Los frameworks modernos lo hacen automático (Astro, Next.js con app router). Sitios WordPress y otros legacy requieren plugins específicos (WP Rocket, FlyingPress, NitroPack) o configuración manual.

Palanca 4: reducir scripts bloqueantes

Cada <script> sin atributo defer o async bloquea el parseo del HTML. Si tu sitio tiene 8 scripts cargados así en el <head>, el navegador se detiene 8 veces antes de mostrar cualquier cosa.

El patrón:

Identificar scripts críticos vs no críticos. Crítico = necesario para renderizar correctamente (raro). No crítico = analytics, chat, pixels, tags de marketing (la mayoría).

Mover no críticos a final del <body> con defer. Esto los carga después del contenido principal. El usuario ve la página, después se cargan los scripts. Sin impacto en funcionalidad, gran impacto en LCP.

Eliminar lo que no aporta. Auditar cada script. Si no estás usando los datos que produce (analytics secundarios, pixels de campañas pausadas, widgets olvidados), elimínalos.

En sitios PyME típicos, esta palanca sola libera 300 a 800ms de LCP. Y como bonus, los scripts bloqueantes también degradan tu INP, así que esta optimización mejora dos métricas al mismo tiempo. Más en INP: la métrica que está reescribiendo el ranking en 2026.

Palanca 5: TTFB (lo último, no lo primero)

El TTFB es el tiempo que tarda tu servidor en responder. Mucha gente lo ataca primero porque parece el problema obvio. Pero típicamente es la última palanca, porque las cuatro anteriores tienen impacto mayor con menos esfuerzo.

Cuando llegue tu turno de atacarlo:

Activar caching en el servidor. Si usas WordPress, plugins como W3 Total Cache o WP Rocket. Si usas hosting con caching integrado (Hostinger Pro, SiteGround GoGeek), activarlo.

Usar un CDN. Cloudflare gratuito, BunnyCDN, o el CDN incluido en tu hosting. Sirve el HTML desde una ubicación cercana al usuario, reduciendo latencia de red.

Optimizar la base de datos. Si tu sitio tiene años, hay tablas con datos basura (revisiones de posts, comentarios spam, datos de plugins desinstalados). Limpiarlas reduce el tiempo de cada query.

Esta palanca puede bajar el TTFB de 1,2s a 0,3s en sitios bien acumulados. Pero requiere acceso técnico al hosting, así que típicamente es la que más fricción tiene para implementar.

El orden importa más que la técnica

Acá está el patrón completo, en el orden que recomendamos aplicar:

Auditar la imagen del hero (1 a 2 horas, gran impacto)
Optimizar las fuentes (1 hora, impacto medio-alto)
Mover scripts bloqueantes (2 a 3 horas, impacto medio-alto)
Dividir CSS crítico vs no crítico (3 a 5 horas, impacto medio)
TTFB y caching (variable según hosting, impacto variable)

Después de cada paso, vuelve a medir con el auto-diagnóstico. No avances al siguiente paso si el anterior no mostró mejora. A veces, con los primeros dos pasos ya estás en zona verde.

Cuándo este patrón NO aplica

El patrón funciona en el 80% de los casos. No funciona si:

Tu sitio está construido sobre un framework JS pesado mal configurado. Si es un Single Page Application en React o Vue sin SSR, el LCP problem es estructural. Ahí sí puede que necesites refactor o migración, y conviene revisar cómo está armado dentro de nuestros servicios de presencia digital.

Tu hosting es muy malo. Si tu TTFB es de 3 o 4 segundos consistentemente, ninguna optimización front-end lo arregla. Necesitas mover de hosting.

Tu sitio tiene problemas en el rendering server-side. Si el HTML que llega al navegador no contiene tu hero, el navegador no puede mostrarlo “rápido” porque no existe en el primer payload. Esto pasa con setups custom mal configurados.

Has acumulado más de 50 plugins sin control. Llegado un punto, optimizar uno por uno toma más tiempo que rehacer la base. Pero ese punto típicamente está en sitios con +5 años de acumulación sin mantenimiento.

Antes de pensar en reescribir

Si tu LCP es malo, mide primero. Aplica el patrón en orden. Re-mide después de cada paso. En la mayoría de los casos, vas a llegar a zona verde sin tocar la arquitectura.

Si después de aplicar las cinco palancas sigues fuera de zona verde, ahí sí conviene hablar de cambios mayores. Pero solo después de descartar lo simple.

Reescribir un sitio es caro, riesgoso y largo. El patrón anterior es barato, seguro y rápido. Empieza por ahí. Y si prefieres delegar la implementación, puedes ver los productos que ofrecemos para tu presencia digital y dejar que nosotros lo aterricemos.

Preguntas frecuentes

¿Cuánto cuesta aplicar este patrón completo en un sitio típico?

Depende de quién lo aplique. Si tienes desarrollador interno, entre 10 y 20 horas de trabajo total. Si lo encargas a una agencia, el rango típico en Chile es de $400.000 a $1.500.000 CLP para sitios medianos. Comparado con un rediseño completo (típicamente $3M a $10M o más), es una fracción.

¿Funciona en WordPress?

Sí. La mayoría de las cinco palancas se pueden implementar en WordPress con plugins (WP Rocket, FlyingPress, Perfmatters) o manualmente. La parte de CSS crítico es la más técnica, pero hay plugins que lo automatizan.

¿Funciona en Shopify, Wix o sitios construidos con builders?

Parcialmente. Algunas palancas (imagen del hero, fuentes preload) son aplicables. Otras (CSS crítico custom) están limitadas por la plataforma. En esos casos, sueles llegar a 60% o 70% de la mejora máxima, no a 4 veces. Igual vale la pena, pero no esperes los mismos resultados que en un sitio con control total del código.

¿Cuánto demoro en ver impacto en SEO después de optimizar el LCP?

Google reindexa típicamente en 1 a 3 semanas. El impacto en ranking típicamente se ve a las 4 a 8 semanas, dependiendo del volumen de keywords y la competencia. Lo que sí ves inmediato es la mejora en conversión y reducción de bounce rate, porque eso es UX, no ranking.

¿Debería medir antes de cada cambio o solo al final?

Antes de cada cambio. Es la única manera de saber qué movió la aguja y qué no. Sin medición incremental, no sabes si las cinco palancas aportaron, si solo aportaron dos, o si una de tus optimizaciones rompió algo y perdiste rendimiento.