El punto de partida: 35 en móvil y un LCP de 18,1 segundos

La medición inicial dejaba un diagnóstico incómodo: 35 sobre 100 en rendimiento y un Largest Contentful Paint de 18,1 segundos, cuando Google recomienda por debajo de 2,5. El bloqueo de la interfaz rozaba los 1.980 ms de Total Blocking Time. Un proyecto con contenido de sobra, pero técnicamente lastrado en cada visita desde el móvil.

El diagnóstico: el servidor no era el problema

El desglose del LCP fue revelador: el servidor respondía en 30 milisegundos, pero el elemento principal tardaba más de ocho segundos en pintarse. La causa no estaba en el hosting, sino en dos puntos concretos. Primero, el encabezado H1 —el elemento LCP— tenía una animación CSS propia (opacidad cero hasta que un script lo hacía visible), así que la pieza más importante de la página esperaba a JavaScript para aparecer. Segundo, un reproductor de vídeo de terceros incrustado en la página consumía 2.484 ms de CPU repartidos en quince scripts: un solo elemento externo gastaba más del triple que todo el resto del sitio junto.

Las acciones que movieron la aguja

Retiré la animación bloqueante del bloque principal para que el H1 se renderizara de inmediato (la puntuación subió de 35 a 55 solo con esto). Reorganicé la entrega de CSS: de catorce archivos bloqueantes a uno, con CSS crítico por URL, carga asíncrona del resto y font-display en modo swap para que las fuentes no frenaran el primer pintado. Minifiqué y aplacé el JavaScript —sin combinarlo, porque rompía el maquetador—, activé la carga diferida de imágenes e iframes y la conversión automática a WebP. Y el salto grande vino del patrón fachada en el vídeo: en lugar de cargar el reproductor de terceros de entrada, la página muestra una portada estática con botón de play y solo inyecta el reproductor real al hacer clic. Los quince scripts desaparecen de la carga inicial sin perder ni una funcionalidad.

Una prueba que salió mal (y por qué la cuento)

No todo lo que probé funcionó. Añadí directivas de preconexión hacia el proveedor de vídeo pensando en acelerar su carga, y el efecto fue el contrario: la puntuación bajó de 55 a 41 y el consumo de CPU del reproductor subió a 4.190 ms. La preconexión adelantaba justo los scripts que quería despriorizar. La revertí. Lo cuento porque un caso de éxito honesto también incluye lo que no salió: el resultado final es fruto de medir cada cambio, no de aplicar una receta a ciegas.

Resultado: las cuatro categorías en verde

Tras la intervención, la web pasó de 35 a 92 en rendimiento móvil, con el LCP reducido de 18,1 s a 2,6 s (−85,6%) y el Total Blocking Time de 1.980 ms a 130 ms (−93,4%). Accesibilidad, prácticas recomendadas y SEO quedaron en verde. La base técnica ya está sólida; a partir de aquí, el margen de crecimiento orgánico depende sobre todo de la autoridad del dominio y de la estrategia de contenidos y enlaces.