Performance Optimization in Development | Budgets Guide
Performance optimization requires measurement first. Set budgets for Core Web Vitals, bundle size, and API latency. Track improvements with GitScrum tasks.
8 min read
Performance is a feature. GitScrum helps teams track performance work alongside feature development and maintain performance budgets.
Performance Mindset
Why Performance Matters
PERFORMANCE IMPACT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ USER EXPERIENCE: │
│ │
│ Load time User perception │
│ ─────────── ────────────────────────────────────────── │
│ 0-100ms Instant │
│ 100-300ms Slight delay, acceptable │
│ 300-1000ms Noticeable, still OK │
│ 1-3s Sluggish, users notice │
│ 3-10s Frustrating, users leave │
│ >10s Unusable │
│ │
│ BUSINESS IMPACT: │
│ │
│ • 1 second delay = 7% conversion drop │
│ • 53% mobile users leave if > 3 seconds │
│ • Google ranks faster sites higher │
│ • Slow = perceived as unreliable │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PERFORMANCE ANTI-PATTERNS: │
│ │
│ ❌ "We'll optimize later" │
│ → Technical debt accumulates │
│ → Harder to fix when architecture is set │
│ │
│ ❌ "Premature optimization is evil" │
│ → Misunderstood quote │
│ → Don't micro-optimize, but design for performance │
│ │
│ ❌ "It's fast on my machine" │
│ → Test on real devices and connections │
│ → Use performance monitoring │
└─────────────────────────────────────────────────────────────┘
Performance Budgets
Setting Budgets
DEFINING PERFORMANCE BUDGETS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FRONTEND BUDGETS: │
│ │
│ Metric Budget Current Status │
│ ───────────────── ────────── ──────── ────── │
│ LCP (Largest Paint) < 2.5s 2.1s ✅ OK │
│ FID (Input Delay) < 100ms 85ms ✅ OK │
│ CLS (Layout Shift) < 0.1 0.05 ✅ OK │
│ Bundle size (JS) < 300KB 285KB ⚠️ Near limit │
│ Bundle size (CSS) < 50KB 42KB ✅ OK │
│ Total page weight < 1MB 920KB ⚠️ Near limit │
│ │
│ API BUDGETS: │
│ │
│ Endpoint Budget p95 Status │
│ ───────────────── ────────── ───────── ────── │
│ GET /api/users < 200ms 180ms ✅ OK │
│ GET /api/projects < 300ms 420ms ❌ Over │
│ POST /api/tasks < 500ms 350ms ✅ OK │
│ Search endpoint < 1s 1.2s ❌ Over │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ WHEN BUDGET EXCEEDED: │
│ │
│ 1. Flag in CI/CD pipeline │
│ 2. Create performance task in GitScrum │
│ 3. Must fix before or with next release │
│ 4. Review architectural impact │
└─────────────────────────────────────────────────────────────┘
Budget Enforcement
AUTOMATED BUDGET CHECKS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CI PIPELINE: │
│ │
│ Build │
│ ↓ │
│ Tests │
│ ↓ │
│ Performance Checks ←── GATE │
│ ↓ │
│ Deploy │
│ │
│ PERFORMANCE CHECK OUTPUTS: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 📊 Performance Budget Report ││
│ │ ││
│ │ Bundle Analysis: ││
│ │ ✅ main.js: 142KB (budget: 200KB) ││
│ │ ⚠️ vendor.js: 185KB (budget: 150KB) +35KB OVER ││
│ │ ││
│ │ Lighthouse Scores: ││
│ │ ✅ Performance: 87 (budget: 85) ││
│ │ ✅ Accessibility: 92 (budget: 90) ││
│ │ ││
│ │ Status: ❌ FAILED - vendor.js over budget ││
│ │ ││
│ │ Action: Review changes or update budget justification ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ GITSCRUM AUTO-TASK: │
│ When budget exceeded: │
│ → Create task: "Performance: vendor.js over budget" │
│ → Labels: performance, blocker │
│ → Priority: High │
└─────────────────────────────────────────────────────────────┘
Performance Tasks
Creating Performance Stories
PERFORMANCE STORY STRUCTURE:
┌─────────────────────────────────────────────────────────────┐
│ PERF-123: Improve Dashboard Load Time │
├─────────────────────────────────────────────────────────────┤
│ │
│ As a user │
│ I want the dashboard to load quickly │
│ So that I can start working without waiting │
│ │
│ ═══════════════════════════════════════════════════════════ │
│ │
│ CURRENT STATE: │
│ • Dashboard load: 4.2 seconds │
│ • LCP: 3.8 seconds │
│ • User complaints: 12 in last month │
│ │
│ TARGET STATE: │
│ • Dashboard load: < 2 seconds │
│ • LCP: < 2.5 seconds │
│ │
│ ANALYSIS: │
│ • Large initial bundle (450KB) │
│ • 8 API calls on load │
│ • Unoptimized images │
│ • No caching │
│ │
│ APPROACH: │
│ ☐ Code split dashboard components │
│ ☐ Implement lazy loading │
│ ☐ Consolidate API calls │
│ ☐ Add response caching │
│ ☐ Optimize images │
│ │
│ ACCEPTANCE CRITERIA: │
│ ☐ Dashboard loads in < 2 seconds on 3G │
│ ☐ LCP < 2.5 seconds │
│ ☐ Lighthouse score > 85 │
│ ☐ No regression in functionality │
│ ☐ Tested on mobile devices │
└─────────────────────────────────────────────────────────────┘
Profiling First
MEASURE BEFORE OPTIMIZING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ RULE: DON'T GUESS - MEASURE │
│ │
│ FRONTEND PROFILING: │
│ │
│ 1. Browser DevTools → Performance tab │
│ • Record page load │
│ • Identify long tasks │
│ • See what's blocking render │
│ │
│ 2. Lighthouse │
│ • Automated performance audit │
│ • Specific recommendations │
│ • Score tracking │
│ │
│ 3. Bundle analyzer │
│ • What's in your bundles? │
│ • What can be removed/split? │
│ │
│ BACKEND PROFILING: │
│ │
│ 1. APM tools (New Relic, Datadog) │
│ • Request tracing │
│ • Database query times │
│ • External call latency │
│ │
│ 2. Database EXPLAIN │
│ • Query execution plans │
│ • Missing indexes │
│ • Slow query log │
│ │
│ 3. Load testing │
│ • How does it behave under load? │
│ • Where are the bottlenecks? │
│ │
│ DOCUMENT FINDINGS IN GITSCRUM TASK: │
│ Before optimizing, attach profiling results │
│ Shows what to fix and proves the fix worked │
└─────────────────────────────────────────────────────────────┘
Common Optimizations
Quick Wins
HIGH-IMPACT OPTIMIZATIONS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FRONTEND: │
│ │
│ IMAGES: │
│ • Use modern formats (WebP, AVIF) │
│ • Responsive images (srcset) │
│ • Lazy load below-fold images │
│ → Often biggest win │
│ │
│ JAVASCRIPT: │
│ • Code split by route │
│ • Lazy load non-critical features │
│ • Remove unused dependencies │
│ • Tree shake properly │
│ │
│ CACHING: │
│ • Cache static assets aggressively │
│ • Use service workers │
│ • Cache API responses where appropriate │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ BACKEND: │
│ │
│ DATABASE: │
│ • Add missing indexes │
│ • Optimize N+1 queries │
│ • Use connection pooling │
│ • Cache expensive queries │
│ │
│ API: │
│ • Enable compression (gzip/brotli) │
│ • Paginate large responses │
│ • Use ETags for caching │
│ • Parallelize independent calls │
│ │
│ INFRASTRUCTURE: │
│ • CDN for static assets │
│ • Geographic distribution │
│ • Appropriate instance sizes │
└─────────────────────────────────────────────────────────────┘
Tracking Progress
Performance Dashboard
PERFORMANCE MONITORING:
┌─────────────────────────────────────────────────────────────┐
│ PERFORMANCE DASHBOARD │
├─────────────────────────────────────────────────────────────┤
│ │
│ WEB VITALS (Last 7 days) │
│ │
│ LCP: [████████████████████░░░░] 2.1s ✅ Good │
│ FID: [██████████████████████░░] 85ms ✅ Good │
│ CLS: [███████████████████████░] 0.05 ✅ Good │
│ │
│ TREND: ↗ Improving │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ API RESPONSE TIMES (p95) │
│ │
│ Endpoint Baseline Current Change │
│ ───────────────── ───────── ──────── ────── │
│ GET /api/projects 420ms 280ms ↓ 33% │
│ POST /api/tasks 350ms 320ms ↓ 9% │
│ Search 1.2s 800ms ↓ 33% │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ACTIVE PERFORMANCE TASKS: │
│ │
│ 🔴 PERF-124: Image optimization │
│ 🟡 PERF-125: Bundle splitting │
│ 🟢 PERF-126: API caching (completed) │
│ │
│ [View all performance tasks] │
└─────────────────────────────────────────────────────────────┘