Optimización de Velocidad de Sitio para Ecommerce

Google mide la experiencia de página a través de tres Core Web Vitals: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) y Cumulative Layout Shift (CLS). Cada métrica captura un aspecto diferente de cómo los usuarios experimentan tu tienda, y las tres alimentan el algoritmo de ranking de Google.

El LCP mide cuánto tarda en renderizarse el elemento visible más grande, típicamente una imagen hero o foto de producto. Google espera un LCP inferior a 2,5 segundos. Para ecommerce, el principal infractor son las imágenes de producto sin optimizar. Una sola imagen hero de 3 MB en una página de categoría puede llevar el LCP más allá de 4 segundos en conexiones móviles.

El INP reemplazó al First Input Delay en marzo de 2024 y mide la capacidad de respuesta durante toda la sesión de página, no solo la primera interacción. Cada toque, clic y entrada de teclado cuenta. Los sitios de ecommerce tienen dificultades aquí debido al JavaScript pesado de herramientas de analytics, widgets de chat y motores de recomendación. Cada script de terceros compite por el hilo principal, retrasando las interacciones del usuario.

El CLS rastrea los cambios de diseño inesperados durante la carga de página. En las páginas de producto, esto ocurre comúnmente cuando las imágenes cargan sin dimensiones definidas, cuando las etiquetas de precio se insertan después del renderizado inicial, o cuando las reseñas cargadas de forma diferida empujan el contenido hacia abajo. Google requiere un CLS inferior a 0,1 para una puntuación aprobatoria.

Las imágenes representan del 50 % al 70 % del peso total de página en la mayoría de sitios ecommerce. Una página de categoría mostrando 40 productos con imágenes sin optimizar puede superar fácilmente los 15 MB. La optimización adecuada de imágenes por sí sola puede reducir el tiempo de carga a la mitad.

Convierte todas las imágenes de producto al formato WebP o AVIF. WebP ofrece archivos entre un 25 % y un 35 % más pequeños que JPEG con calidad equivalente, y AVIF lleva el ahorro al 50 %. Todos los navegadores principales ahora soportan WebP, y el soporte de AVIF cubre más del 90 % de los usuarios. Sirve AVIF con fallback WebP usando el elemento HTML picture.

Redimensiona las imágenes para que coincidan con sus dimensiones de visualización. Una miniatura de producto mostrada a 300x300 píxeles no necesita un archivo fuente de 2000x2000. Genera múltiples tamaños en tiempo de compilación o a través de la API de transformación de imágenes de tu CDN. Sirve imágenes 1x a pantallas estándar y 2x a pantallas Retina usando atributos srcset.

Implementa carga diferida para imágenes debajo del pliegue. La primera fila de productos en una página de categoría debe cargar inmediatamente (carga eager), mientras que todo lo demás debe usar loading="lazy". Esto reduce el peso inicial de la página drásticamente. Una tienda de muebles que optimizamos pasó de cargar 80 imágenes en la carga inicial a 12, reduciendo el LCP de 4,8 segundos a 1,9 segundos.

La tienda de ecommerce promedio carga de 20 a 35 scripts de terceros: analytics, mapas de calor, widgets de chat, plataformas de reseñas, motores de recomendación, píxeles de retargeting y proveedores de pago. Cada script bloquea el hilo principal, retrasa la interactividad e infla el peso de la página. Auditar y gestionar estos scripts es una de las mejoras de velocidad con mayor impacto.

Comienza catalogando cada script que carga en tu tienda. Abre Chrome DevTools, ve a la pestaña Red, filtra por JS y recarga la página. Ordena por tamaño y tiempo de carga. Casi con certeza encontrarás scripts que ya no se necesitan, rastreadores duplicados o herramientas que se instalaron para una prueba y nunca se eliminaron.

Difiere los scripts no críticos usando el atributo defer o async. Los píxeles de analytics y marketing no necesitan cargar antes de que la página se renderice. Muévelos debajo del pliegue o cárgalos después del evento DOMContentLoaded. Para widgets de chat, retrasa la inicialización hasta que el usuario haga scroll o después de un tiempo de espera de 5 segundos.

Considera usar un gestor de etiquetas como Google Tag Manager con carga basada en disparadores. En lugar de ejecutar cada script al cargar la página, configura disparadores para que los píxeles de retargeting solo se activen en páginas de producto, los widgets de chat carguen después de 10 segundos de inactividad y los widgets de reseñas carguen solo cuando la sección de reseñas entre en el viewport. Este enfoque redujo el tiempo de bloqueo del hilo principal en un 40 % en una tienda de artículos para el hogar que optimizamos.

El Time to First Byte (TTFB) mide cuánto tarda tu servidor en responder con el primer byte de HTML. Google recomienda un TTFB inferior a 800 milisegundos, pero los mejores sitios de ecommerce logran menos de 200 milisegundos. Un TTFB lento retrasa todo lo que sigue: renderizado, carga de recursos e interactividad.

Los planes de hosting compartido no pueden ofrecer un TTFB consistente para tiendas con más de unos pocos cientos de productos. Las consultas de base de datos necesarias para construir páginas de categoría con filtrado, ordenamiento y verificaciones de inventario demandan recursos dedicados. Actualiza a un VPS, servidor dedicado o una plataforma de ecommerce gestionada que maneje el escalado de infraestructura.

Implementa caché de página completa para páginas de categoría y producto. La mayoría de las páginas de producto cambian infrecuentemente, y servir una respuesta HTML en caché elimina las consultas de base de datos por completo. Varnish, Redis o la capa de caché integrada de tu plataforma pueden reducir el TTFB de 1,5 segundos a menos de 100 milisegundos para páginas en caché.

Usa un CDN con caché en el borde para servir assets estáticos y páginas en caché desde ubicaciones cercanas a tus clientes. Un CDN reduce la latencia entre un 50 % y un 80 % para visitantes geográficamente distantes. Para tiendas internacionales, esto es esencial. Un cliente británico accediendo a una tienda alojada en EE.UU. sin CDN añade de 150 a 250 milisegundos de latencia en cada solicitud.

La ruta de renderizado crítico es la secuencia de pasos que el navegador sigue para convertir HTML, CSS y JavaScript en píxeles renderizados. Optimizar esta ruta significa asegurar que el navegador pueda mostrar contenido significativo lo más rápidamente posible, incluso mientras recursos adicionales aún se están cargando.

Incrusta tu CSS crítico directamente en el head HTML. El CSS crítico es el conjunto mínimo de estilos necesarios para renderizar el contenido visible sobre el pliegue. Herramientas como Critical o Penthouse pueden extraerlo automáticamente. Al incrustar de 10 a 15 KB de CSS crítico, el navegador puede pintar la vista inicial sin esperar descargas de hojas de estilo externas.

Precarga recursos clave que el navegador descubre tarde en el proceso de análisis. Las fuentes web, imágenes hero y bundles de JavaScript críticos deben usar etiquetas link rel="preload" en el head HTML. Sin precarga, el navegador solo descubre estos recursos después de analizar archivos CSS o JavaScript, añadiendo cientos de milisegundos de retraso.

Elimina recursos que bloquean el renderizado difiriendo CSS y JavaScript no críticos. Carga tu hoja de estilos completa de forma asíncrona usando el truco de media="print" con un controlador onload que la cambia a media="all". Esto permite al navegador renderizar la página usando CSS crítico incrustado mientras la hoja de estilos completa se descarga en segundo plano.

Para tiendas Shopify, las plantillas Liquid del tema y los bloques de aplicaciones a menudo inyectan scripts y estilos que bloquean el renderizado. Audita tu archivo theme.liquid y mueve los scripts de aplicaciones no esenciales a carga diferida. Cada recurso que bloquea el renderizado añade de 100 a 300 milisegundos al renderizado inicial.