Deep Dive · 2024

Cricket Gully

A cricket platform optimized for traffic spikes and ad revenue

ROLEFrontend Engineer
DURATION4 months
TEAM1 designer · 2 frontend · 2 backend
TIMELINE2024
Next.jsTypeScriptEdge RuntimeTailwind

Challenge & Limitations

The operational hurdles, data boundaries, and strict service Level agreements of the system.

The Problem Statement

A high-traffic cricket news and live-scores site that struggled during match windows — slow loads, ad-driven layout shifts, and a Core Web Vitals profile that hurt both SEO and revenue. The brief: keep the product the same, make it feel twice as fast.

Rigid Constraints

  • ·Heavy ad inventory that couldn't be removed
  • ·Massive traffic spikes during live matches
  • ·SEO sensitivity — the team's primary acquisition channel was organic search
  • ·A small frontend team — solutions had to be simple enough to maintain

Design & Engineering Decisions

The tactical solutions mapping backend systems, developer experience, and interface layout.

Architecture

  • →Moved high-traffic pages to ISR with short revalidation windows tuned per page type
  • →Pushed personalization to the edge so the cached HTML stays cacheable for the long tail of users
  • →Carved out a strict client/server boundary so server components do the heavy data work and client components handle only what they must

UX & Interface

  • →Reserved space for every ad slot up-front so the page never reflows after ads load
  • →Used skeletons sized to match real content, including ad slots, to keep CLS at zero
  • →Surfaced live scores as the primary above-the-fold element on match days

Performance

  • →Cumulative Layout Shift driven down to ~0 on the highest-traffic templates
  • →Largest Contentful Paint under 1.8s on the article template at the 75th percentile
  • →Edge caching cut origin load by ~70% during peak match windows
Deliverables

The Outcome & Business Impact

Search rankings recovered within a release cycle. Ad revenue per session went up while ad inventory stayed the same — the gain was entirely on the engineering side.

<1.8sLCP at p75
≈0CLS
−70%Origin load at peak
Navigation

Interested in exploring other technical projects and DevOps systems?