¿Con la plantilla Hyvä Magento 2 siempre funcionará más rápido que con cualquier otra plantilla?

Imagine dos tiendas Magento. La primera utiliza Hyvä, pero al entrar carga una docena de herramientas de marketing, descarga imágenes enormes y genera la página desde cero cada vez. La segunda tiene otro tema, cuidadosamente optimizado, una caché eficiente y solo los scripts que necesita el cliente.

¿Cuál será más rápida? El nombre de la plantilla no basta para responder.

Hyvä proporciona a Magento un muy buen punto de partida para construir una tienda rápida. Sin embargo, no ofrece una ventaja incondicional frente a cualquier otra implementación. El resultado depende de todo el recorrido entre hacer clic en un enlace y el momento en que el cliente ve el producto y puede comprarlo.

Por eso conviene combinar la implementación de Hyvä con una revisión del servidor, los módulos, las imágenes y el diseño de la interfaz. Entonces se puede trabajar hacia un objetivo ambicioso: 95–100 puntos en Google PageSpeed Insights, manteniendo las funciones necesarias para vender.

¿Qué significa realmente una puntuación de 95–100 en PageSpeed?

De forma coloquial hablamos de «100% en PageSpeed», pero la herramienta presenta puntos en una escala de 0 a 100. En la parte basada en Lighthouse evalúa cuatro áreas distintas:

Estas evaluaciones no se sustituyen entre sí. Una tienda rápida puede tener botones poco legibles. Una tienda técnicamente correcta puede descargar demasiado JavaScript. Lighthouse es una herramienta de diagnóstico, y el alcance de sus auditorías no cubre toda la calidad de la tienda. Descripción de Lighthouse.

La puntuación de Performance procede de una medición de laboratorio y puede variar entre pruebas. PageSpeed también muestra, si están disponibles, datos de usuarios reales de CrUX, recopilados en un periodo móvil de 28 días. Una nueva implementación no cambiará de inmediato todo ese conjunto de datos. Cómo funciona PageSpeed Insights.

En la práctica necesitamos dos objetivos: pruebas buenas de forma repetible y buenas experiencias para los clientes. Para Core Web Vitals esto significa:

• LCP hasta 2,5 s — aparición rápida del elemento más grande dentro del área visible;
• INP hasta 200 ms — respuesta eficiente a las interacciones;
• CLS hasta 0,1 — diseño de página estable.

Estos umbrales se evalúan en el percentil 75, por separado para dispositivos móviles y ordenadores. La prueba estándar de carga de Lighthouse no mide INP; para diagnosticar el bloqueo del navegador utiliza, entre otros, TBT. Un TBT bajo no confirma automáticamente un buen INP. Core Web Vitals.

¿Cómo ayuda Hyvä a acelerar Magento?

Hyvä reduce el peso del frontend en comparación con la Luma estándar. Utiliza Alpine.js para las interacciones y Tailwind CSS para los estilos. Menos código para descargar y ejecutar deja al navegador más margen para mostrar rápidamente la oferta. La documentación de Hyvä señala la reducción de JavaScript y CSS como una parte importante de esta arquitectura. Rendimiento de Hyvä.

Sin embargo, esta ventaja puede reducirse con facilidad. Basta con añadir a un frontend ligero un slider avanzado, un chat, varios trackers y módulos que arrastren dependencias antiguas del tema anterior.

Hyvä tampoco solucionará una consulta lenta a la base de datos, una caché que no funciona ni un servidor ocupado con una importación. Por eso, la pregunta antes de la implementación debería ser: ¿qué retrasa hoy la compra y cuáles de esos problemas resolverá el cambio de frontend?

1. Servidor: nginx y Varnish deben hacer el trabajo correcto

Antes de que el navegador muestre el producto, tiene que recibir el documento HTML. Si espera mucho tiempo al primer byte de respuesta, incluso un tema ligero empieza con retraso.

Nginx: entrega eficiente de recursos

En una arquitectura típica de Magento, nginx gestiona, entre otros, HTTPS, archivos estáticos y el reenvío de solicitudes a los siguientes servicios. Conviene comprobar la compresión de respuestas de texto, HTTP/2 y las cabeceras de caché para archivos CSS y JS versionados. Adobe ofrece una configuración de ejemplo de nginx como punto de partida para una implementación con Varnish. Configuración de Varnish en Adobe Commerce.

No se debe asignar el mismo tiempo de almacenamiento a todas las respuestas. Una hoja CSS versionada puede usarse durante mucho tiempo desde la caché del navegador. El precio, el contenido del carrito y la respuesta relativa a un cliente conectado requieren otro tratamiento.

Si el servidor selecciona WebP según la cabecera Accept, también hay que comprobar la clave de caché y la cabecera Vary: Accept. El navegador y las capas intermedias de caché deben distinguir las variantes de imagen.

Varnish: comprobamos los aciertos de caché, no solo que el servicio esté instalado

Varnish permite servir páginas públicas desde caché sin que Magento tenga que repetir todo el trabajo. Adobe recomienda su uso en entornos de producción. Gestión de caché de Magento.

La prueba práctica es sencilla: abrimos la misma URL pública varias veces y comprobamos si después de la primera respuesta aparecen aciertos HIT. Después comparamos el tiempo de respuesta desde caché y el tiempo de generación de la página con MISS.

Si una categoría popular evita constantemente la caché, hay que encontrar la causa: configuración, cookies, parámetros de URL, personalización o funcionamiento del módulo. Comprar un servidor más grande puede entonces limitarse a enmascarar el problema.

También es importante la corrección. La caché no puede entregar el carrito ni los datos de un cliente a otro usuario. Hay que probar variantes de tienda, divisas y grupos de clientes, así como la actualización del contenido tras modificar un producto. Un precio rápido pero desactualizado no es un éxito de optimización.

Además de nginx y Varnish, comprobamos PHP-FPM, OPcache, el backend cache compatible con la versión de Magento, la base de datos, cron y la indexación. El número de procesos PHP debe derivarse de la memoria disponible y de la carga real. Aumentarlo sin medición puede empeorar la situación.

2. Módulos para Hyvä: la compatibilidad es solo el principio

Un módulo puede funcionar correctamente con Hyvä y seguir haciendo demasiado trabajo al entrar en la página. Una buena optimización incluye, por tanto, tanto la función como el coste de ponerla en marcha.

En kowal.store adaptamos nuestros módulos a Hyvä y los desarrollamos pensando en mantener el rendimiento de este tema tras la instalación. Nos aseguramos de que las nuevas funciones no carguen innecesariamente el frontend, limitando dependencias y aplicando una forma adecuada de cargar JavaScript y CSS. Consulte nuestros módulos Magento 2 y elija extensiones para su tienda. Conviene confirmar el efecto de una implementación concreta mediante medición, porque también depende de la configuración y del resto de integraciones.

Tomemos el chat como ejemplo. Un cliente que navega por una categoría necesita al principio un botón para iniciar la conversación. La interfaz completa del chat y sus bibliotecas pueden descargarse al abrirlo. Del mismo modo, las sugerencias completas del buscador pueden prepararse al entrar en el campo de búsqueda, dejando visible y operativo desde el inicio el formulario.

Hyvä también describe este enfoque en sus recomendaciones sobre la carga de JavaScript externo.

defer, async y el retraso de un componente son cosas distintas

defer permite ejecutar un script clásico externo después de procesar el documento y mantener el orden de los scripts de ese tipo. async ejecuta el script cuando está listo, sin garantizar el orden respecto a otros. Ninguno de estos atributos significa por sí mismo que el archivo vaya a descargarse solo después de hacer clic.

Hyvä también ofrece x-defer, con el que se puede retrasar la inicialización de un componente Alpine, por ejemplo hasta que se acerque al área visible. Esto no aplaza automáticamente la descarga de todos sus archivos. También hay que tener en cuenta los eventos que el componente puede perder antes de inicializarse, por ejemplo los relacionados con los datos del cliente. Documentación de x-defer.

Los cambios deben comprobarse en el carrito, los filtros, los formularios y los eventos analíticos. La mera presencia del atributo defer no demuestra que el módulo esté bien optimizado.

CSS: el aspecto necesario debe estar listo antes del primer renderizado

Los estilos de la cabecera, la lista de productos y el diseño móvil son necesarios desde el principio. Cargarlos demasiado tarde puede provocar parpadeo de la página y desplazamiento de elementos. Al mismo tiempo, una categoría de productos no tiene por qué descargar todos los estilos de cada módulo instalado.

Conviene limitar las hojas globales, eliminar restos del tema anterior y comprobar el build de producción de Tailwind. En las clases creadas dinámicamente hay que asegurarse de que las reglas necesarias estén presentes en el CSS resultante. El CSS crítico incrustado en HTML puede ayudar, pero requiere mantenimiento y pruebas; no debería ser la primera respuesta a cada problema. Recursos que bloquean el renderizado.

La analítica y los datos SEO también tienen su coste

Al trabajar en la optimización de una tienda en Magento 2, comprobamos la carga de analítica en la página de categoría. GTM y gtag representaban aproximadamente 304 KB, es decir, el 44% de la transferencia registrada en la primera medición móvil. Es una buena razón para revisar etiquetas y activadores. No significa que deba retrasarse toda la analítica sin pensarlo: ese cambio puede modificar el número de visitas y eventos registrados.

También conviene revisar el propio HTML. Los datos JSON-LD extensos, la información duplicada sobre productos y las configuraciones de módulos aumentan la respuesta del servidor. JSON-LD no se ejecuta como un programa JavaScript normal, pero aun así debe enviarse. Los datos estructurados de una categoría deben corresponderse con la lista visible, su paginación y su orden.

3. Imágenes: importan el formato, el tamaño y el momento de descarga

Una imagen fuente de varios miles de píxeles de ancho no debería acabar innecesariamente en una pequeña tarjeta de producto. Preparamos variantes ajustadas al tamaño de visualización y a la densidad de pantalla, y srcset y sizes ayudan al navegador a elegir el archivo adecuado. Conviene comparar WebP o AVIF en cuanto a calidad y peso en imágenes concretas.

La distinción más importante se refiere a las imágenes visibles desde el inicio y a las que se encuentran más abajo. La imagen que es LCP debería ser fácil de descubrir en el HTML, sin loading='lazy'; puede estar justificado fetchpriority='high'. Las imágenes fuera de la primera pantalla son buenas candidatas para lazy loading. Sus dimensiones o proporciones les reservan espacio en el diseño. Imágenes responsive.

Sin embargo, no asignamos prioridad alta a todas las imágenes. El navegador necesita saber qué es realmente lo más importante. Fetch Priority.

También comprobamos banners CMS, logotipo, favicon, miniaturas de vídeos y gráficos de popups. La optimización debe abarcar el proceso de añadir nuevos archivos; de lo contrario, la siguiente campaña volverá a introducir imágenes pesadas.

Que una URL termine en .png no determina qué descarga el navegador. El servidor puede entregar WebP bajo esa misma URL. Verificamos Content-Type y la transferencia en la pestaña Network.

4. Colores: su mayor impacto lo verá en la accesibilidad

Cambiar un botón azul por uno verde no acelerará Magento. Sin embargo, el color tiene una gran importancia para la legibilidad y la puntuación de Accessibility.

Los problemas más habituales los causan descripciones en gris claro, botones pastel con texto blanco, etiquetas de promoción y texto sobre imágenes. Según WCAG, el contraste del texto normal debe ser de al menos 4,5:1, y el del texto grande de 3:1. Texto grande significa al menos 18 pt, es decir, aproximadamente 24 px, o 14 pt en negrita, es decir, aproximadamente 18,7 px. Requisitos de contraste del texto.

Para los elementos visuales importantes de los controles y los indicadores de su estado también se aplica el requisito de contraste 3:1 frente a los colores adyacentes, con las excepciones descritas en el estándar. Contraste de elementos no textuales.

Conviene definir la paleta de forma centralizada, por ejemplo mediante variables CSS o configuración del módulo de colores. Así, un cambio del color del texto o de los botones se aplica a toda la tienda. También hay que comprobar los estados hover, focus, errores de formularios y filtros seleccionados. Un borde rojo no debería ser la única información de que un campo contiene un error.

El rendimiento puede verse afectado por la forma de implementar el aspecto: hojas adicionales, un script que cambia colores tras la carga o efectos visuales pesados. Sin embargo, la paleta por sí sola no sustituye la optimización de JS, imágenes y servidor.

¿Por qué no basta con un buen resultado?

Al optimizar una tienda Magento 2 con Hyvä, realizamos dos mediciones locales de Lighthouse para la misma página de categoría. En mobile obtuvimos 94 y 73 puntos. El LCP fue de 2,5 y 5,7 s respectivamente, aunque en ambos casos correspondía a la misma imagen del primer producto. Desktop alcanzó 100 puntos.

Todas esas ejecuciones notificaron que se había superado el límite de tiempo de carga, por lo que tratamos los resultados como diagnósticos y potencialmente incompletos. No eran resultados confirmados de PageSpeed Insights ni datos de CrUX. Tampoco se trata de una comparación de Hyvä con otro tema.

En la prueba más débil, la imagen se descargó rápido, pero se mostró más tarde. Esto demuestra por qué hay que separar el tiempo de descarga del tiempo de renderizado. Seguir comprimiendo el archivo no explica por sí solo un problema de este tipo. Análisis de las fases de LCP.

Al trabajar en una tienda comparamos varias pruebas, la mediana y la dispersión, manteniendo las mismas condiciones. No tratamos los informes con errores como un punto de referencia estable. También comprobamos el comportamiento después de aceptar cookies, tras abrir el buscador y después de añadir un producto al carrito.

Checklist Magento y Hyvä: camino hacia 95–100 puntos

La siguiente lista ayuda a planificar la auditoría y la recepción de los trabajos. No es una garantía de cuatro resultados 100/100. La puntuación depende de la página, la configuración, las condiciones de la prueba y la versión de Lighthouse. Un resultado verde tampoco sustituye las pruebas manuales de accesibilidad, una auditoría de seguridad ni una estrategia SEO.

Medición y punto de referencia

• Se han analizado la página de inicio, la categoría, el producto, el buscador y los pasos clave de compra.
• Se han realizado mediciones separadas para mobile y desktop, en varias pruebas comparables.
• Se han registrado la versión de la herramienta, el perfil del dispositivo, el estado de consentimientos y el rango de resultados; se han explicado los timeouts.
• Se han comprobado LCP, INP y CLS con CrUX o monitorización propia, si están disponibles.
• Se han distinguido los datos de una URL concreta de los datos de todo el dominio.
• Se han probado la primera visita, el regreso del usuario y el comportamiento tras la interacción.

Servidor, nginx y Varnish — Performance

• Magento funciona en modo producción, con los recursos estáticos correctamente preparados.
• Las páginas públicas alcanzan Varnish HIT; también se ha comprobado el tiempo de respuesta con MISS.
• La caché distingue correctamente las variantes de tienda y los datos privados no llegan a una respuesta compartida.
• El cambio de producto, precio o contenido invalida correctamente la caché correspondiente.
• Nginx comprime los recursos de texto adecuados y admite un protocolo HTTP moderno.
• Los archivos versionados tienen cabeceras de caché adecuadas; HTML y las respuestas privadas tienen una política independiente.
• PHP-FPM, OPcache y backend cache están configurados de acuerdo con la versión de Magento y los recursos del servidor.
• Cron, indexación, importaciones y bots no provocan picos en el tiempo de respuesta.

Módulos, JavaScript y CSS — Performance

• Cada módulo activo tiene una justificación de negocio; se han eliminado duplicados de funciones innecesarios.
• Las integraciones Hyvä no reintroducen sin necesidad dependencias pesadas del frontend anterior.
• El JS y CSS de los módulos solo llegan a las páginas que usan sus funciones.
• Los scripts se han diferido respetando dependencias, orden y eventos de inicialización.
• Se ha probado x-defer selectivo y la carga de componentes al usarlos.
• Los estilos críticos están disponibles antes del primer renderizado; no aparece parpadeo del diseño.
• GTM, píxeles, chat y widgets tienen revisados los activadores y el coste de puesta en marcha.
• Los cambios de analítica mantienen el comportamiento de consentimientos acordado y eventos e-commerce correctos.
• HTML, DOM y JSON-LD no contienen datos innecesarios ni duplicados.
• El carrito, los filtros, la ordenación, la paginación y el checkout funcionan tras la optimización.

Imágenes y estabilidad del diseño — Performance

• Los gráficos tienen dimensiones, calidad y formato adecuados; se ha verificado la transferencia real.
• Las variantes responsive de las imágenes corresponden a los tamaños de visualización.
• Se ha identificado el elemento LCP por separado para mobile y desktop.
• La imagen LCP no se retrasa por lazy loading ni por inicialización JS innecesaria.
• Se ha asignado alta prioridad solo a recursos justificados.
• Las imágenes, banners y contenidos incrustados tienen espacio reservado en el diseño.
• Se han comprobado el logotipo, favicon, gráficos CMS e imágenes añadidas por módulos.
• El proceso de publicación de nuevas imágenes incluye la generación de variantes optimizadas.

Colores y manejo de la interfaz — Accessibility

• Texto, precios, botones y mensajes tienen el contraste requerido sobre fondos reales.
• Se ha comprobado el contraste de controles importantes y la visibilidad del foco de teclado.
• Error, promoción y selección no se comunican únicamente mediante color.
• Enlaces y botones tienen nombres accesibles comprensibles; los formularios tienen etiquetas.
• Las imágenes informativas tienen un texto alternativo adecuado y las decorativas un alt vacío.
• Menú, filtros, popups y carrito se pueden manejar con teclado.
• Se han comprobado la ampliación de la página, la pantalla pequeña y el uso básico con lector de pantalla.

Calidad técnica — Best Practices

• La página y sus recursos funcionan mediante HTTPS, sin mixed content.
• Se han explicado los errores de consola, solicitudes fallidas y advertencias indicadas por la auditoría.
• Las bibliotecas y módulos se mantienen; se han revisado las vulnerabilidades notificadas.
• Las imágenes mantienen proporciones y las funciones no utilizan innecesariamente API obsoletas.
• La puntuación alta se ha confirmado junto con pagos, formularios y consentimientos operativos.

Visibilidad técnica — SEO

• Las páginas destinadas a indexarse devuelven el estado correcto y no tienen un noindex accidental.
• robots.txt no bloquea páginas ni recursos necesarios.
• El título y la meta description corresponden al contenido de la página.
• El canonical es correcto; se han revisado por separado las versiones lingüísticas y hreflang.
• Los enlaces de navegación son legibles para los robots y la paginación funciona correctamente.
• Los datos estructurados se han verificado con una herramienta independiente y corresponden al contenido visible.
• Se han revisado el mapa del sitio y la indexación en Search Console, también fuera del alcance de la puntuación de Lighthouse.

Las pruebas automáticas de accesibilidad solo cubren una parte de los posibles problemas. Incluso una puntuación de 100 requiere complementarse con una prueba manual. Cómo se calcula la accesibilidad en Lighthouse.

¿Por dónde empezar a trabajar en su tienda?

Primero determinemos qué espera el cliente. Si espera la respuesta del servidor, empezamos por el backend y la caché. Si espera una imagen, comprobamos su detección, descarga y visualización. Si la página es visible, pero responde con retraso, analizamos el trabajo de JavaScript y los componentes.

Después implementamos un grupo lógico de mejoras y repetimos las mediciones y las pruebas de compra. Así sabemos qué ha ayudado y si el coste del cambio estaba justificado. Alcanzar los umbrales de Core Web Vitals por sí solo no garantiza una puntuación de 95: Performance se calcula a partir de varias métricas ponderadas. Reglas de puntuación de Lighthouse.

Hyvä permite empezar con un frontend ligero. Mantener esa ventaja requiere decisiones conscientes en cada módulo, banner y herramienta de marketing posteriores. Por eso conviene tratar el rendimiento como un criterio de aceptación de las siguientes implementaciones, no como un proyecto puntual cerrado con una captura de pantalla de un resultado verde.

Si está planificando una implementación de Hyvä o quiere acelerar una tienda existente, contacte con el equipo de kowal.store. El punto de partida debería ser una auditoría de páginas concretas y del proceso de compra, con una lista de causas, prioridades y mediciones antes y después de los cambios.