GTSportMotorsport / mediaMarch 2026gtsport.es

GTSport: from vibe coding to a scalable product

The digital platform of one of Europe’s leading GT championship promoters. Built with Payload CMS and Next.js through vibe coding, the product worked — performance and cost did not. After a deep audit and an optimization plan, pages went from seconds to milliseconds and infrastructure cost dropped by half.

5–10s → ms

Page load time

−50%

Infrastructure cost

~€100 → <€10

AWS images / month

Who is GTSport

GTSport is one of the main promoters and organizers of motorsport competitions in Europe. Since 1998 it has run international GT championships, with race calendars at circuits such as Hockenheim, Barcelona, and other European venues.

Its public site (gtsport.es) is the brand’s digital front door: race calendar, news, championship information, and a private area. Traffic spikes around each event — news, photo galleries, and result updates — exactly the load pattern that punishes a stack without caches or a CDN.

They had shipped a new site with Payload CMS and Next.js built via vibe coding (AI tooling). Time-to-market was excellent; the production experience was not.

Client website: gtsport.es ↗

The challenge

The product was live, but every visit and every news publish exposed the typical technical debt of vibe coding without a performance audit: high latency, unoptimized assets, and a CMS that stalled under editorial load.

Content pages and news listings with 5–10 second load times (TTFB + render)
Race photos and galleries served without resizing or modern formats — tens of MB per page
Crashes and timeouts when publishing or updating news from Payload CMS
High infrastructure cost: ~€100/month on AWS image storage/servers alone, plus oversized compute
Uncached CMS API queries: every request rebuilt heavy payloads from scratch
No CDN or edge-caching strategy: all traffic hit the origin

Our approach

We did not rewrite the site. We started from the existing Payload + Next.js codebase, diagnosed bottlenecks, and ran an impact-ordered optimization plan: first what hurt users and cost the most, then structural stabilization.

Deep audit and analysis

We measured Core Web Vitals, TTFB, API response size, the image pipeline, and Payload’s publishing flow. We found N+1 queries, hundreds-of-KB JSON payloads, images without variants, and an origin with no cache layer.

Work plan and prioritization

We defined a short-sprint roadmap: infrastructure and CDN → image optimization → data/API caches → render and publishing refactor. Each phase had measurable before/after metrics.

Infrastructure changes

We redesigned hosting and asset delivery. We pulled images off the expensive path (mis-sized AWS compute + storage) and aligned the stack with real traffic: race-day spikes, heavy reads, occasional editorial writes.

Code and API optimization

We reduced Payload API response size, removed redundant fetches in the Next.js front end, stabilized news publishing, and avoided unnecessary synchronous work on every request.

Caches, CDN, and images

We implemented data and image caches, a CDN for static assets and cacheable HTML, conversion to modern formats (WebP/AVIF), responsive sizes, and invalidation policies when new content is published.

What we optimized in detail

These workstreams had the largest impact on latency, editorial stability, and monthly spend. Numbers reflect before/after measurements in equivalent production conditions.

Image pipeline and AWS storage

Circuit photos and galleries were served at full resolution from a poorly configured bucket/server. We added variants (thumb, card, hero), WebP/AVIF, lazy loading, and CDN delivery. The origin stopped serving megabytes per request.

AWS image cost: from ~€100/month to under €10/month (~−90%).

CDN and edge cache

Public pages (home, calendar, news) moved to edge delivery with aggressive TTLs and on-demand revalidation on publish. The origin only handles misses and editorial writes.

Typical TTFB on cached pages: from several seconds to tens of milliseconds.

Data caches and API responses

Payload returned full collections without projection or cache. We cached frequent queries (listings, home, news detail), trimmed JSON fields, and revalidated on CMS save.

Average listing API payload: ~70% smaller; less pressure on DB and compute.

Next.js rendering and Core Web Vitals

We removed client-side data waterfalls, favored SSR/ISR where appropriate, and cut non-critical JavaScript. LCP improved on image hero pages; CLS improved on listings.

Perceived page load: from 5–10 s to millisecond range on cache hits; LCP stable in the “good” range.

Stabilizing Payload’s editorial flow

Publishing hangs came from heavy hooks, synchronous regenerations, and timeouts. We moved heavy work (image processing, cache invalidation) off the save request and added controlled timeouts and retries.

Stable news publishing: no routine timeouts under daily editorial use.

Infrastructure right-sizing

With less origin load (CDN + caches), we could downsize instances and remove redundant image services. The savings were structural, not a one-off trim.

Total infrastructure cost: approximately −50%.

The results

The improvement was immediate and measurable: user experience went from multi-second waits to millisecond loads on cached pages, the editorial team could publish without hangs, and infrastructure spend dropped structurally.

For a motorsport promoter, the site is not a static brochure: on race weekends traffic spikes with news, photos, and updates. The previous stack failed exactly when it mattered most. The current stack absorbs those peaks without exploding cost.

The case illustrates the typical vibe-coding-in-production pattern: fast launch, but no caches, CDN, asset optimization, or cloud cost control. Transformation does not require throwing the code away — it requires audit, prioritization, and rigorous technical execution.