Un sitio que carga rápido no se deja al azar.

Porque por debajo casi siempre hay un problema real: una imagen demasiado pesada, un script inútil, una petición lenta. 95/100 es el nivel en el que el sitio es bueno para el SEO, para la conversión y para el visitante. Hemos elegido un umbral que podemos mantener en todos nuestros sitios, y lo mantenemos: nada de anunciar 95 y tener 82 en producción.

Sí, porque es nativo en nuestro stack EaaS. No construimos un sitio y luego lo optimizamos: el rendimiento es una restricción de diseño desde la primera línea. Cada store que sale a producción sobre el stack arranca a 95/100 mínimo, sin fase de recuperación posterior.

Hay que mantenerlo, y ese es precisamente el papel de la suscripción EaaS. Cada nueva funcionalidad, cada módulo de pago, cada integración añadida puede degradar las puntuaciones. Como el sistema se mantiene y mejora de forma continua, las pruebas de rendimiento forman parte del ciclo de puesta en producción: el 95/100 no es algo adquirido, es un estándar que defendemos para todos los stores del stack.

TTFB, FCP, LCP y CLS: son las métricas que Google utiliza para evaluar la experiencia real de los visitantes. Las medimos en condiciones reales, no solo en desarrollo: es lo que cuenta para el posicionamiento y para sus visitantes. Un sitio que saca 90 en una prueba de desarrollo pero es lento sobre el terreno no convierte, y lo sabemos.

Sí, siempre que se configure bien. Ese es exactamente el punto: no ponemos en caché cualquier cosa. Las páginas de escaparate, categorías y productos se sirven desde la caché, y la invalidación es precisa: cuando cambia un precio o un stock, se regeneran las páginas afectadas, no todo el sitio. El cliente siempre ve los datos correctos, sin pagar el precio de una página generada al vuelo.

No, y es una decisión asumida. El rendimiento no se añade después sobre una plataforma existente: viene de la arquitectura, del renderizado, de la caché y de cómo el frontend carga sus assets. Por eso nuestros clientes llegan al stack mediante un re-platforming, no mediante una optimización de su sitio actual. Una vez en el stack, los rendimientos están ahí desde el lanzamiento.

No principalmente. Un servidor más potente no compensa una arquitectura mal pensada: muchos sitios lentos funcionan sobre una infraestructura potente simplemente mal configurada. Lo que cuenta es cómo se genera, se pone en caché y se sirve el contenido. En la suscripción EaaS, la infraestructura está incluida y dimensionada por nosotros, usted no tiene nada que configurar.

Es cierto, algunos scripts de terceros son lo que son. Como están integrados en el stack, los conocemos y los enmarcamos: carga diferida, alternativa más ligera cuando existe, o limitación al momento en que el script es realmente útil. Lo que no podemos mejorar, se lo decimos claramente con su impacto cifrado.