Performance en sitios editoriales: cómo llegamos a 92 en Lighthouse

Los sitios web editoriales y las revistas digitales enfrentan un desafío técnico único: deben cargar una cantidad masiva de contenido visual, fuentes personalizadas y scripts de terceros (anuncios, analíticas) sin arruinar la experiencia del usuario. En un proyecto reciente en codeX, nos enfrentamos a una plataforma que tardaba más de 6 segundos en ser interactiva. Nuestro objetivo era drástico: superar los 90 puntos en Google Lighthouse en la métrica móvil.

Aquí te detallamos la hoja de ruta técnica que seguimos para lograr un sólido 92, reduciendo el Largest Contentful Paint (LCP) y eliminando el molesto salto de página (Cumulative Layout Shift - CLS).

1. La guerra contra el peso visual: Formatos modernos

El 70% del peso inicial de la página provenía de imágenes no optimizadas subidas por los editores. Implementamos una canalización (pipeline) automatizada en el servidor que interceptaba cada archivo y hacía lo siguiente:

• Conversión a WebP y AVIF: Redujimos el peso de las imágenes hero en un 45% sin pérdida perceptible de calidad.
• Atributos srcset: Configuramos la entrega dinámica de imágenes para que un teléfono móvil no descargara nunca la versión de escritorio de 1920px.
• Preload del LCP: Le indicamos al navegador que descargara la imagen principal del artículo de forma ultra prioritaria, inyectando una etiqueta de preload en el head.

2. Estabilizando el CLS (Cumulative Layout Shift)

No hay nada más frustrante para un lector que intentar hacer clic en un enlace y que la página "salte" porque acaba de cargar un banner publicitario. Para llevar el CLS casi a cero, aplicamos una regla estricta: reserva explícita de espacio.

Aseguramos que todas las imágenes, iframes y contenedores de anuncios tuvieran atributos de ancho y alto explícitos, combinados con la propiedad de CSS aspect-ratio. El navegador ahora sabe exactamente cuánto espacio dejar vacío en el lienzo antes de que el recurso termine de descargar.

3. JavaScript: Diferir y dividir (Code Splitting)

El hilo principal del navegador estaba bloqueado por pesados paquetes de JavaScript. La estrategia aquí fue la "carga perezosa" extrema:

"Si el usuario no lo necesita para visualizar el primer pantallazo (above the fold) en el primer segundo, no lo cargues todavía."

Diferimos la ejecución de todos los scripts de seguimiento y aplicamos Code Splitting para que cada URL solo descargara el código necesario para funcionar, reduciendo el tiempo de bloqueo a un nivel imperceptible.

El impacto real en el negocio

Alcanzar un 92 en Lighthouse no es solo una métrica de vanidad para los ingenieros. En el mes posterior al despliegue, el sitio experimentó un aumento del 22% en el tiempo de sesión por usuario y un incremento sustancial en el tráfico orgánico, ya que Google premia activamente los Core Web Vitals saludables en su algoritmo.

Si tu plataforma o tienda online está perdiendo ventas por tiempos de carga lentos y altas tasas de rebote, nuestro equipo de Desarrollo Web puede realizar una auditoría de performance profunda. Hablemos de cómo acelerar tu negocio.