Case study · Updated 2026-05-14
BrightTech: 62 → 93 in one cycle
One ApexGEO closed-loop cycle lifted BrightTech from PageSpeed 62 to 93. The exhibit below is the same data the landing CustomerReceipts ticker exposes.
Real-result trajectory loading…
Three weeks. Five recommendations applied automatically. No additional human dev time.
The baseline
BrightTech's static-HTML marketing site sat at a PageSpeed Insights score of 62 — a credible, ordinary public site, but not fast. Render-blocking CSS, oversized hero imagery, missing structured data, no llms.txt. None of these were dire individually; collectively they were the difference between PSI 62 and 93.
The audit
ApexGEO's audit module crawled the BrightTech site and surfaced 14 recommendations ranked by expected score impact. The top three: defer hero image decoding, inline above-the-fold CSS, add Organization + Service JSON-LD. Each recommendation came with an expected score lift and the deploy-ready output to ship it.
The fixes
ApexGEO emitted patched HTML, inlined critical CSS, generated JSON-LD blocks, and produced an llms.txt. BrightTech deployed each patch as its own commit on the static-site repo. Total deploy time: 17 minutes. No bespoke development required — the platform's output was ship-ready.
The delta
Post-deploy PageSpeed Insights: 93. A 31-point lift in one cycle. The delta is independently verifiable — anyone can re-run PageSpeed against brighttech.co.za and the linked commits document exactly what changed.
What we learned
Static-HTML sites have the cleanest fix loop: no build pipeline, no SSR latency, no CDN cache invalidation drama. ApexGEO's fix model generalizes well from BrightTech to any static-HTML or Jamstack site. Dynamic sites (Next, Rails, Django) take longer per cycle but the same model applies.