GTSport: de vibe coding a producto escalable
La plataforma digital de uno de los principales promotores de campeonatos GT en Europa. Construida con Payload CMS y Next.js mediante vibe coding, el producto funcionaba — el rendimiento y los costes no. Tras una auditoría profunda y un plan de optimización, las páginas pasaron de segundos a milisegundos y el coste de infraestructura se redujo a la mitad.
5–10s → ms
Tiempo de carga
−50%
Coste de infraestructura
~100€ → <10€
AWS imágenes / mes
Quién es GTSport
GTSport es uno de los principales promotores y organizadores de competiciones de motorsport en Europa. Desde 1998 organiza campeonatos internacionales de GT, con calendarios de carreras en circuitos como Hockenheim, Barcelona y otros escenarios europeos.
Su web pública (gtsport.es) es el escaparate digital de la marca: calendario de carreras, noticias, información de campeonatos y área privada. El tráfico se concentra en picos alrededor de cada evento — noticias, galerías de fotos y actualizaciones de resultados — exactamente el tipo de carga que castiga a un stack sin caches ni CDN.
Habían lanzado una web nueva con Payload CMS y Next.js construida con vibe coding (herramientas de IA). El time-to-market fue excelente; la experiencia en producción, no.
Web del cliente: gtsport.es ↗
El reto
El producto estaba en producción, pero cada visita y cada publicación de noticia evidenciaban deuda técnica típica del vibe coding sin pasar por una auditoría de rendimiento: latencia alta, assets sin optimizar y un CMS que se colgaba bajo carga editorial.
- Páginas de contenido y listados de noticias con tiempos de carga de 5 a 10 segundos (TTFB + render)
- Imágenes de carreras y galerías servidas sin redimensionar ni formatos modernos — decenas de MB por página
- Cuelgues y timeouts al publicar o actualizar noticias desde Payload CMS
- Coste de infraestructura elevado: ~100 €/mes solo en servidores/almacenamiento de imágenes en AWS, más compute sobredimensionado
- Consultas a la API del CMS sin cache: cada request regeneraba payloads pesados desde cero
- Sin CDN ni estrategia de edge caching: todo el tráfico golpeaba el origen
Nuestro enfoque
No reescribimos la web. Partimos del código existente (Payload + Next.js), diagnosticamos cuellos de botella y ejecutamos un plan de optimización por impacto: primero lo que más dolor y coste generaba, luego estabilización estructural.
Auditoría y análisis en profundidad
Medimos Core Web Vitals, TTFB, tamaño de respuestas de API, pipeline de imágenes y el flujo de publicación en Payload. Identificamos N+1 en consultas, payloads JSON de cientos de KB, imágenes sin variantes y un origen sin capa de cache.
Plan de trabajo y priorización
Definimos un roadmap en sprints cortos: infraestructura y CDN → optimización de imágenes → caches de datos/API → refactor de renderizado y publicación. Cada fase con métricas antes/después medibles.
Cambio de infraestructura
Replanteamos hosting y entrega de assets. Sacamos el servicio de imágenes del camino caro (compute + storage mal dimensionados en AWS) y alineamos el stack con el patrón real de tráfico: picos en días de carrera, lecturas masivas, escrituras editoriales puntuales.
Optimización de código y APIs
Redujimos el tamaño de las respuestas de la API de Payload, eliminamos fetches redundantes en el front Next.js, estabilizamos el flujo de publicación de noticias y evitamos trabajo síncrono innecesario en cada request.
Caches, CDN e imágenes
Implementamos cache de datos e imágenes, CDN para estáticos y HTML cacheable, conversión a formatos modernos (WebP/AVIF), tamaños responsivos y políticas de invalidación al publicar contenido nuevo.
Qué se optimizó en detalle
Estas son las líneas de trabajo que más impacto tuvieron en latencia, estabilidad editorial y factura mensual. Los números reflejan mediciones antes/después en entornos de producción equivalentes.
Pipeline de imágenes y almacenamiento AWS
Las fotos de circuitos y galerías se servían a resolución completa desde un bucket/servidor mal configurado. Implementamos generación de variantes (thumb, card, hero), formatos WebP/AVIF, lazy loading y entrega vía CDN. El origen dejó de servir megabytes por request.
Coste de imágenes AWS: de ~100 €/mes a menos de 10 €/mes (−90 % aproximado).
CDN y cache en edge
Páginas públicas (home, calendario, noticias) pasaron a servirse desde edge con TTLs agresivos y revalidación bajo demanda al publicar. El origen solo procesa miss y escrituras editoriales.
TTFB típico en páginas cacheadas: de varios segundos a decenas de milisegundos.
Caches de datos y respuestas de API
Payload devolvía colecciones enteras sin proyección ni cache. Añadimos caching de queries frecuentes (listados, home, detalle de noticia), reducción de campos en JSON y revalidación al guardar en el CMS.
Payload medio de API en listados: reducción estimada del ~70 %; menos presión en DB y compute.
Renderizado Next.js y Core Web Vitals
Eliminamos waterfalls de datos en el cliente, priorizamos SSR/ISR donde correspondía y recortamos JavaScript no crítico. Mejoramos LCP en páginas con hero de imagen y CLS en listados.
Carga percibida de página: de 5–10 s a rango de milisegundos en hits de cache; LCP estable en rango “bueno”.
Estabilización del flujo editorial en Payload
Los cuelgues al publicar noticias venían de hooks pesados, regeneraciones síncronas y timeouts. Separamos trabajo pesado (procesado de imágenes, invalidación de cache) del request de guardado y añadimos timeouts y reintentos controlados.
Publicación de noticias estable: sin timeouts habituales bajo el flujo editorial diario.
Derecho-sizing de infraestructura
Con menos carga en origen (gracias a CDN + caches), pudimos bajar el tamaño de instancias y eliminar servicios redundantes de imágenes. El ahorro no fue un recorte puntual: es estructural.
Coste total de infraestructura: aproximadamente −50 %.
Los resultados
La mejora fue inmediata y medible: la experiencia de usuario pasó de esperas de varios segundos a cargas en milisegundos en las páginas cacheadas, el equipo editorial pudo publicar sin cuelgues, y la factura de infraestructura bajó de forma estructural.
Para un promotor de motorsport, la web no es un brochure estático: en fines de semana de carrera el tráfico se dispara con noticias, fotos y actualizaciones. El stack anterior colapsaba precisamente cuando más valor aportaba. El stack actual absorbe esos picos sin disparar el coste.
El caso ilustra el patrón típico del vibe coding en producción: velocidad de lanzamiento alta, pero sin caches, CDN, optimización de assets ni control de coste cloud. La transformación no exige tirar el código — exige auditoría, priorización y ejecución técnica rigurosa.
5–10s → ms
Carga de página
−50%
Coste de infraestructura
~100€ → <10€
AWS imágenes / mes
Stack técnico
Preguntas frecuentes
El vibe coding permite construir prototipos y webs rápidas con IA (Cursor, Bolt, v0, etc.). En GTSport funcionó para lanzar Payload CMS + Next.js en poco tiempo, pero sin auditoría de rendimiento, caches, CDN ni pipeline de imágenes, el producto no aguantó producción: páginas de 5–10 s, imágenes caras en AWS y cuelgues al publicar noticias.
No. Partimos del código existente, auditamos en profundidad y optimizamos de forma progresiva: infraestructura, APIs, caches, CDN e imágenes. Se preservó la funcionalidad (calendario, noticias, área privada) mientras se recuperaba el rendimiento.
En este caso se redujo a la mitad el coste general de infraestructura. El capítulo de imágenes en AWS pasó de casi 100 € mensuales a menos de 10 €, gracias a variantes, formatos modernos, CDN y dejar de servir assets a resolución completa desde el origen.
GTSport.es es la plataforma digital de un promotor de campeonatos GT en Europa: calendario de carreras, noticias, contenidos de motorsport y área privada. El perfil de tráfico — picos en eventos, muchas imágenes y actualizaciones editoriales — exige cache, CDN y un CMS estable.
Depende del estado del código y de la infraestructura. En proyectos similares, una auditoría profunda más un primer bloque de wins (CDN, imágenes, caches) suele verse en pocas semanas; la estabilización completa del flujo editorial y el right-sizing de costes se planifican por fases medibles.
¿Tu producto de vibe coding no aguanta producción?
Como con GTSport, podemos auditar tu stack, estabilizar el rendimiento y bajar costes cloud. Solicita una auditoría técnica gratuita.