Todos dicen que optimizan para velocidad. Pocos pueden demostrarlo. Esta semana, completamos una revision de rendimiento completa para un clientes en el competitivo sector de comercio electronico de “Decoracion del Hogar”.
El punto de partida:
- Puntuacion móvil: 42/100
- LCP: 4,8s
- INP: 450ms (Deficiente)
- CLS: 0,25 (Cambios de diseño por todas partes)
El resultado (despues de 4 semanas):
- Puntuacion móvil: 100/100
- LCP: 1,2s
- INP: 48ms
- CLS: 0,00
Esto no fue magia. Fue ingenieria. A continuacion explicamos exactamente como lo logramos.
1. Corrigiendo el LCP (Largest Contentful Paint)
El villano: El Slider del hero. El clientes utilizaba un pesado Revolution Slider. Cargaba 4MB de JavaScript antes de mostrar la primera imagen.
La solución:
- Eliminar el Slider: Reemplazamos el slider con un diseño estatico basado en CSS Grid.
- Fetch Priority: Anadimos
<img fetchpriority="high">a la imagen principal del hero. Esto le indica al navegador “Descarga esto ANTES que el logotipo y el menú.” - Formato AVIF: Convertimos todos los PNG a AVIF. La imagen del encabezado de 800KB se convirtio en 45KB.
Resultado: El LCP bajo de 4,8s a 1,9s de forma instantanea.
La optimización del LCP es frecuentemente el cambio que produce el mayor impacto visible en la puntuacion de rendimiento. La razon es simple: el LCP mide el tiempo que tarda en renderizarse el elemento más grande visible en la ventana del navegador. En la mayoria de los sitios de comercio electronico, ese elemento es una imagen del hero. Si esa imagen depende de JavaScript para cargarse (como ocurre con los sliders), estamos anadiendo una cadena de dependencias que multiplica el tiempo de carga exponencialmente.
El cambio a un diseño estatico con CSS Grid no solo elimino la dependencia de JavaScript, sino que también proporciono una experiencia visual más limpia y profesional. Los sliders rotativos, que fueron populares durante años, tienen tasas de interacción inferiores al 1% según estudios de usabilidad recientes. Eliminarlos mejora tanto el rendimiento como la conversión.
2. Resolviendo el CLS (Cumulative Layout Shift)
El villano: Fuentes personalizadas y carga diferida (Lazy Loading).
- Fuentes: El texto aparecia, luego la fuente personalizada se cargaba, desplazando el diseño 10 pixeles.
- Imágenes: Las imágenes con carga diferida aparecian y empujaban el texto hacia abajo porque carecian de atributos
widthyheight.
La solución:
- Precarga de fuentes: Anadimos
<link rel="preload">para la fuente principal y utilizamosfont-display: optional. Si la fuente no se carga en 100ms, el navegador mantiene la fuente del sistema para siempre (sin desplazamiento). - Relación de aspecto: Aplicamos
aspect-ratio: 16/9;en todos los contenedores de imágenes en CSS. El navegador reserva el espacio en blanco incluso antes de que la imagen se descargue.
Resultado: El CLS bajo a 0,00.
El CLS es la metrica que más frustracion genera en los usuarios. Cuando un usuario esta leyendo un parrafo y de repente el contenido salta porque se cargo una imagen o un anuncio, la experiencia es profundamente negativa. Google lo sabe y por eso penaliza severamente los sitios con CLS alto.
La estrategia de font-display: optional es particularmente interesante porque representa un compromiso inteligente. En lugar de arriesgar un cambio de diseño visible, aceptamos que algunos usuarios veran la fuente del sistema si la fuente personalizada no se carga lo suficientemente rápido. En la práctica, con una CDN adecuada, la fuente personalizada se carga a tiempo en más del 95% de las visitas, y el 5% restante ve una experiencia perfectamente funcional sin ningun desplazamiento de diseño.
Para las imágenes, la técnica de reservar espacio mediante aspect-ratio es superior a las antiguas prácticas de usar width y height en atributos HTML porque funciona de forma nativa con diseños responsivos. No importa el tamaño de la pantalla del usuario, el navegador siempre sabe exactamente cuanto espacio reservar para cada imagen.
3. Aplastando el INP (Interaction to Next Paint)
El villano: Scripts de terceros. Widgets de chat, Facebook Pixel, Google Tag Manager, Hotjar. Todos competian por el hilo principal. Cuando un usuario hacia clic en “Menú”, el navegador estaba demasiado ocupado rastreando al usuario como para abrir el menú.
La solución: Partytown. Movimos todos los scripts de terceros a un Web Worker utilizando Partytown. Esto ejecuta el código pesado de seguimiento en un hilo secundario. El hilo principal (UI) permanece completamente fluido.
Resultado: El INP bajo de 450ms a 48ms.
El INP (Interaction to Next Paint) es la metrica que reemplazo a FID en 2024 y es significativamente más exigente. Mientras que FID solo media la primera interacción, INP mide todas las interacciones durante toda la sesion del usuario. Esto significa que no basta con optimizar la carga inicial; cada clic, cada toque, cada interacción con el teclado debe ser fluida.
Partytown funciona como un intermediario inteligente. Los scripts de terceros como Google Analytics, Facebook Pixel y Hotjar siguen funcionando normalmente, pero se ejecutan en un Web Worker separado del hilo principal del navegador. El resultado es que el usuario experimenta una interfaz perfectamente responsiva mientras todos los servicios de analítica continuan recopilando datos con normalidad.
La implementación de Partytown en un sitio WooCommerce tiene particularidades específicas. El boton de “Anadir al carrito” genera eventos AJAX que pueden bloquear el hilo principal si se combinan con scripts de seguimiento de conversión. Nuestra solución fue refactorizar el flujo del carrito para que la actualización visual sea inmediata (optimista) y la sincronizacion con el servidor ocurra de forma asincrona en segundo plano.
4. El arma secreta de 2026: La API de Speculation Rules
No solo queriamos que fuera rápido. Queriamos que se sintiera instantaneo. Implementamos la API de Speculation Rules.
Cuando un usuario pasa el cursor sobre una tarjeta de producto, el navegador:
- Precarga el HTML de la página siguiente.
- Pre-renderiza la página en una pestana oculta en segundo plano.
Cuando el usuario hace clic, la carga de la página es literalmente de 0ms. Ya esta ahi.
La API de Speculation Rules representa un avance fundamental respecto a las técnicas anteriores de precarga. Las soluciones previas, como <link rel="prefetch">, solo descargaban el HTML. La API de Speculation Rules va mucho más alla: renderiza completamente la página en segundo plano, incluyendo CSS, JavaScript e imágenes criticas. El resultado es una transicion entre páginas que se siente como una aplicación nativa, no como un sitio web.
Para un sitio de comercio electronico, el impacto es enorme. Los usuarios pueden navegar por el catálogo de productos sin percibir ningun tiempo de carga entre páginas. Esto reduce drasticamente la tasa de abandono y aumenta el número de productos vistos por sesion, lo que se correlaciona directamente con mayores tasas de conversión.
La implementación requiere cuidado para no desperdiciar ancho de banda. No pre-renderizamos todas las páginas posibles, sino solo aquellas con alta probabilidad de ser visitadas. Esto se determina mediante heuristicas basadas en el comportamiento del cursor y patrones de navegación históricos.
5. Optimización del lado del servidor (la infraestructura)
No se puede obtener una puntuacion de 100 con un servidor de 5 dolares. Migramos al clientes a una arquitectura de alto rendimiento tipo WordPress VIP.
- Redis Object Cache: Las consultas a la base de datos para el “Menú” y las “Opciones” se almacenan en cache en memoria.
- Edge Caching (Cloudflare Enterprise): El HTML de la página de inicio se sirve desde un servidor en Madrid, no desde el origen en Nueva York. El TTFB bajo de 600ms a 40ms.
La infraestructura del servidor es el fundamento sobre el cual se construyen todas las demás optimizaciones. Sin un TTFB rápido, es matemáticamente imposible alcanzar una puntuacion perfecta de LCP. El TTFB (Time to First Byte) mide cuanto tiempo tarda el servidor en comenzar a enviar la respuesta al navegador. Si ese tiempo ya consume 600ms de los 2500ms permitidos para un buen LCP, queda muy poco margen para la descarga y renderizado de imágenes.
Redis Object Cache elimina la necesidad de consultar la base de datos MySQL para información que cambia con poca frecuencia. En un sitio WooCommerce tipico, cada solicitud de página puede generar entre 50 y 200 consultas a la base de datos. Con Redis, las consultas repetitivas se sirven directamente desde la memoria, reduciendo el tiempo de generación de la página en un 80% o mas.
El Edge Caching lleva esto un paso más alla. En lugar de generar la página en el servidor de origen cada vez, Cloudflare almacena una copia del HTML completo en sus más de 300 puntos de presencia globales. Para los visitantes en Espana, la página se sirve desde un servidor en Madrid o Barcelona, no desde un centro de datos lejano. El resultado es un TTFB que frecuentemente baja de los 50ms.
6. Impacto en el negocio
Por que hicimos todo esto? No por metricas de vanidad.
- Tasa de rebote: Disminuyo un 18%.
- Gasto publicitario: El CPC bajo un 12% (la puntuacion de calidad de Google Ads mejoro gracias a la velocidad).
- Ingresos: El tráfico organico crecio un 40% en 2 meses mientras Google recompensaba las señales de “Experiencia de Página”.
Los números hablan por si solos. La reduccion del 18% en la tasa de rebote significa que miles de visitantes adicionales permanecen en el sitio en lugar de volver a los resultados de búsqueda. Cada uno de esos visitantes retenidos es una oportunidad de conversión adicional.
La mejora en el CPC de Google Ads es particularmente significativa. Google utiliza la experiencia de la página de destino como un factor en su calculo de Quality Score. Un Quality Score más alto significa que se paga menos por cada clic. Para un anunciante que invierte 50.000 euros mensuales en Google Ads, una reduccion del 12% en CPC representa un ahorro de 6.000 euros al mes, o 72.000 euros al año, simplemente por tener un sitio más rápido.
El crecimiento del 40% en tráfico organico demuestra que Google recompensa activamente los sitios que ofrecen una excelente experiencia de usuario. Los Core Web Vitals no son solo metricas técnicas; son señales que Google utiliza para determinar que sitios merecen mayor visibilidad en los resultados de búsqueda.
Conclusion: La velocidad no es deuda técnica. Es una palanca de ingresos.
Esta su sitio WooCommerce perdiendo dinero por lentitud? WPPoland optimiza para puntuaciones verdes y cuentas bancarias verdes.
