TTFB y perfilado del backend
Perfilado con las herramientas que enseñan la verdad (Blackfire, xhprof, logs de consultas lentas) para encontrar a dónde se va el tiempo de verdad.
Rendimiento en Magento
Optimización de rendimiento en Magento
Emyrix hace rápidas las tiendas Magento 2 donde importa (tiempo de respuesta del servidor, cache, búsqueda y Core Web Vitals) para que las páginas carguen deprisa y el checkout aguante con tráfico real. Arreglamos el techo que ponen la infraestructura y el código, no solo la puntuación de Lighthouse.
Ingeniería en Magento y Adobe Commerce desde Massachusetts, para empresas de e-commerce de todo Estados Unidos.
Experiencia técnica
- Perfilado con Blackfire y xhprof
- Varnish, Fastly y full-page cache
- Redis para cache y sesiones
- Ajuste de OpenSearch / Elasticsearch
- Optimización de consultas e índices en MySQL
- PHP 8.x y OPcache/JIT
- Rendimiento de frontend en Hyvä
- Core Web Vitals (LCP/CLS/INP)
Resumen
Qué hacemos y por qué importa
La mayoría de los proyectos de rendimiento en Magento empiezan en el sitio equivocado: alguien pasa Lighthouse, lo ve en rojo y dedica semanas a minificar CSS mientras el servidor sigue tardando más de un segundo en devolver el primer byte de HTML. Nosotros empezamos por la capa que fija el techo de todas las páginas (TTFB, full-page cache, Redis, OpenSearch, PHP y la base de datos) y pasamos al trabajo por tipo de página y de frontend una vez que los cimientos están firmes.
El objetivo no es una subida puntual de la puntuación. Es una tienda que siga siendo rápida a medida que crece el catálogo y llegan los picos de tráfico, medida contra métricas de negocio reales y no contra una prueba sintética de laboratorio.
Servicios
Qué incluye
Full-page cache, Varnish y Fastly
Configuración correcta de FPC, Varnish y Fastly, cache warming y hole-punching para que los aciertos sean rápidos y los fallos raros.
Ajuste de Redis y sesiones
Redis para cache y sesiones, configurado y separado como corresponde en lugar de los valores por defecto que se atascan bajo carga.
OpenSearch / Elasticsearch
Búsqueda e indexación de catálogo ajustadas para que las páginas de categoría y de navegación por capas sigan siendo rápidas con catálogos grandes.
Base de datos e indexers
Optimización de consultas, gestión de índices y decisiones sobre el catálogo plano basadas en sus datos, no en la tradición oral.
Core Web Vitals
Trabajo de LCP, CLS e INP en páginas de categoría, de producto y de checkout, medido sobre tráfico real.
Extensiones, código a medida y llamadas a terceros
Módulos que lanzan una consulta por producto en una página de categoría, un ERP o una API de envíos llamados de forma síncrona en el checkout, y los scripts de frontend que añaden unos cientos de milisegundos cada uno.
Por qué Emyrix
Qué obtiene al trabajar con nosotros
La causa, no los síntomas
Perfilamos antes de tocar nada, para que el esfuerzo vaya donde se está gastando el tiempo de verdad.
Más rápido donde se convierte
Prioridad para las plantillas que traen ingresos: categoría, producto y checkout.
Sigue siendo rápido bajo carga
Las mejoras aguantan con el tráfico de temporada alta, no solo en un servidor de staging vacío.
Preguntas frecuentes
Preguntas frecuentes
¿Por qué va lenta mi tienda Magento?
Normalmente por el backend, no por el frontend: TTFB lento por un full-page cache ausente o mal configurado, un Redis o una base de datos sin ajustar, o código a medida pesado. Perfilamos para encontrar la causa real antes de recomendar trabajo.
¿Por qué va lento el checkout de Magento?
Normalmente porque el checkout es la única página a la que el full-page cache no puede ayudar, así que todos los problemas que el cache ocultaba aparecen ahí. Las causas habituales: tarifas de envío e impuestos consultadas a una API de terceros en cada paso, un módulo de pago haciendo más trabajo del necesario, peticiones de customer-section disparándose más veces de las debidas, y una base de datos bajo carga por una indexación o un informe corriendo a destiempo. Perfilamos un checkout real para ver cuál de ellas es.
¿Cómo sé si el full-page cache de Magento está funcionando?
Cargue una página de categoría dos veces y compare los tiempos de respuesta. Una página en cache vuelve en bastante menos de un segundo, a menudo por debajo de 200 milisegundos. Magento añade una cabecera X-Magento-Cache-Debug (HIT o MISS) en modo developer, y Varnish y Fastly ponen una cabecera Age en los aciertos. Si todas las peticiones son un miss, algo en la página la está marcando como no cacheable: un bloque con un valor específico del cliente, una sesión iniciada demasiado pronto, o un módulo de terceros con cacheable="false" en su XML de layout. Esto último está detrás de un número sorprendente de tiendas lentas.
¿Es Magento, o es el hosting?
A veces el hosting, y merece la pena descartarlo primero porque es barato de comprobar. El tiempo hasta el primer byte en una página cacheada dice casi todo: si una página que sabe que está en cache sigue tardando un segundo en empezar a llegar, el problema está delante de Magento, en el servidor, PHP-FPM o la red. Si las páginas cacheadas son rápidas y las no cacheadas lentas, es Magento, una extensión o la base de datos. Una tienda puede tener las dos cosas a la vez.
¿Pueden mejorar nuestros Core Web Vitals?
Sí. Trabajamos LCP, CLS e INP en las páginas de categoría, de producto y de checkout, usando datos de campo de usuarios reales.
¿De verdad ayuda a la conversión que las páginas sean más rápidas?
La velocidad es un factor entre varios, pero unas páginas de categoría y de checkout lentas cuestan ventas de forma medible. Damos prioridad a las plantillas que traen ingresos para que el trabajo se pague solo.
¿Optimizan storefronts en Hyvä y en Luma?
En los dos. Ajustamos tiendas Luma existentes y, cuando es la mejor decisión a largo plazo, migramos a Hyvä para tener un frontend más ligero.
Relacionado
Siga explorando
Trabaje con Emyrix
Cuéntenos sobre su tienda
Envíenos la URL y la revisaremos —versión y estado de los parches, velocidad, caché, indexación, checkout— y le contaremos lo que encontramos.