📚 Table of Contents
- The 100ms That Cost $1M
- Why Performance Is a Product Problem
- The Business Impact of Speed
- The Performance Metrics That Matter
- Core Web Vitals: The PM’s Guide
- Common Performance Problems and Their Fixes
- Performance vs. Features: The Roadmap Trade-off
- Building a Performance Culture
- Questions to Ask Your Engineering Team
- Your Performance Action Plan
- The Bottom Line
The 100ms That Cost $1M
In 2022, I worked with an e-commerce company that had a performance problem they didn’t know they had.
The situation: Checkout was taking 4.2 seconds on average.
The discovery: A junior engineer noticed during a routine investigation.
The fix: They optimized the checkout flow, bringing it down to 2.8 seconds. A 1.4-second improvement.
The business impact:
- Conversion rate increased from 3.2% to 3.8%
- That 0.6% improvement on 500,000 monthly visitors
- 3,000 additional conversions per month
- At $40 average order value = $120,000 additional revenue per month
- $1.44 million additional revenue per year
From 1.4 seconds of improvement.
The company had been debating a major redesign for months, expecting it to improve conversion. They spent $300,000 on the redesign. It improved conversion by 0.2%.
The performance fix cost $40,000 in engineering time. It improved conversion by 0.6%.
The naked truth: Performance optimization is often the highest-ROI investment you can make. But most PMs don’t know to prioritize it because they don’t measure it.
Why Performance Is a Product Problem
The Product Manager’s Performance Responsibilities
| Responsibility | Why It’s PM’s Job |
|---|---|
| Define performance targets | What’s acceptable speed for your users? |
| Measure performance impact | How does speed affect your metrics? |
| Prioritize performance work | Performance competes with features |
| Communicate to stakeholders | Why invest in “invisible” work? |
| Set performance budgets | What’s the maximum acceptable load time? |
The Performance Value Chain
Fast Loading → Better UX → Higher Engagement → More Conversions → More Revenue
Slow Loading → Poor UX → Lower Engagement → Abandonment → Lost Revenue
Every 100ms of improvement matters:
| Industry | Impact of 100ms Improvement |
|---|---|
| E-commerce | +1% conversion |
| SaaS | +2-3% engagement |
| Media | +5-10% page views |
| Mobile apps | +7% session length |
The Business Impact of Speed
The Research (That Should Convince Stakeholders)
Google Study:
- 53% of mobile users abandon sites that take >3 seconds to load
- Every 1-second delay reduces conversion by 7%
Amazon Study:
- 100ms of latency = 1% decrease in sales
- They estimated a 1-second slowdown would cost $1.6B/year
Walmart Study:
- Every 1-second improvement = 2% conversion increase
Pinterest:
- 40% reduction in perceived wait time = 15% increase in sign-ups
The Performance-Conversion Curve
┌─────────────────────────────────────────────────────────────┐
│ CONVERSION RATE BY PAGE LOAD TIME │
├─────────────────────────────────────────────────────────────┤
│ │
│ 100% ├─ │
│ │ │
│ 90% ├─────── │
│ │ \ │
│ 80% ├────────\ │
│ │ \ │
│ 70% ├───────────\ │
│ │ \ │
│ 60% ├────────────────\ │
│ │ \ │
│ 50% ├─────────────────────\ │
│ │ \_______ │
│ 40% ├───────────────────────────────\__________ │
│ │ │
│ └────────┬────────┬────────┬────────┬────────┬────────│
│ 0-1s 1-2s 2-3s 3-4s 4-5s >5s │
│ │
│ Optimal Good Acceptable Poor Unacceptable │
│ │
└─────────────────────────────────────────────────────────────┘
The Performance ROI Calculator
Your Current State:
├── Monthly visitors: 500,000
├── Average conversion rate: 3.2%
├── Average order value: $40
└── Current checkout time: 4.2 seconds
If you reduce checkout time by 1 second:
├── Expected conversion increase: 2-3%
├── New conversion rate: ~3.5%
├── Additional conversions: 1,500/month
└── Additional revenue: $60,000/month = $720,000/year
Investment required: $40,000 (engineering time)
ROI: 18x in first year
The Performance Metrics That Matter
The Three Levels of Performance Metrics
Level 1: Business Metrics (Start Here)
| Metric | What It Tells You |
|---|---|
| Conversion rate | Are slow pages hurting sales? |
| Bounce rate | Are users leaving before page loads? |
| Session duration | Are users engaging or leaving? |
| Pages per session | Is slowness limiting exploration? |
Level 2: User Experience Metrics
| Metric | What It Tells You | Target |
|---|---|---|
| Time to First Byte (TTFB) | Server response speed | <600ms |
| First Contentful Paint (FCP) | When content appears | <1.8s |
| Largest Contentful Paint (LCP) | When main content visible | <2.5s |
| Time to Interactive (TTI) | When page is usable | <3.8s |
| Total Blocking Time (TBT) | How long blocked | <200ms |
| Cumulative Layout Shift (CLS) | Visual stability | <0.1 |
Level 3: Technical Metrics (Engineers Track These)
| Metric | What It Tells You |
|---|---|
| P50 latency | 50% of requests faster than this |
| P95 latency | 95% of requests faster than this |
| P99 latency | 99% of requests faster than this |
| Error rate | Percentage of failed requests |
| Throughput | Requests handled per second |
The Metric That Matters Most for PMs
P95 latency = The experience of 95% of your users
Why P95 and not average?
- Average hides the slow experiences
- 5% of users having terrible experience = thousands of frustrated users
- P95 tells you what most users experience
Core Web Vitals: The PM’s Guide
What Core Web Vitals Are
Google’s standardized metrics for measuring user experience. They affect your SEO ranking.
The Three Core Web Vitals
1. Largest Contentful Paint (LCP)
What it measures: How fast the main content appears.
Target: < 2.5 seconds
Good for PMs to know: This is what users perceive as “page load time.”
Common causes:
- Large images
- Slow server response
- Render-blocking JavaScript
2. First Input Delay (FID) → Now Interaction to Next Paint (INP)
What it measures: How quickly the page responds to user interaction.
Target: < 200ms
Good for PMs to know: This is “responsiveness.” Can users click buttons immediately?
Common causes:
- Heavy JavaScript execution
- Too many event listeners
- Long tasks blocking the main thread
3. Cumulative Layout Shift (CLS)
What it measures: How much the page shifts while loading.
Target: < 0.1
Good for PMs to know: This is “stability.” Do elements jump around?
Common causes:
- Images without dimensions
- Ads injecting content
- Fonts loading late
Core Web Vitals Dashboard
┌─────────────────────────────────────────────────────────────┐
│ CORE WEB VITALS DASHBOARD │
├─────────────────────────────────────────────────────────────┤
│ │
│ LARGEST CONTENTFUL PAINT (LCP) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Current: 2.8s │ │
│ │ Target: <2.5s │ │
│ │ Status: ⚠️ NEEDS IMPROVEMENT │ │
│ │ Impact: SEO ranking, user perception │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ INTERACTION TO NEXT PAINT (INP) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Current: 150ms │ │
│ │ Target: <200ms │ │
│ │ Status: ✅ GOOD │ │
│ │ Impact: Click responsiveness │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ CUMULATIVE LAYOUT SHIFT (CLS) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Current: 0.15 │ │
│ │ Target: <0.1 │ │
│ │ Status: ⚠️ NEEDS IMPROVEMENT │ │
│ │ Impact: Visual stability, accidental clicks │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ SEO IMPACT: Moderate (2 metrics need improvement) │
│ │
└─────────────────────────────────────────────────────────────┘
Common Performance Problems and Their Fixes
Problem 1: Slow Page Load
Symptoms:
- High bounce rate
- Users leaving before page renders
- Poor conversion on landing pages
Common causes:
- Large, unoptimized images
- Too many HTTP requests
- No caching
- Slow server response
Fixes:
| Cause | Fix | Effort |
|---|---|---|
| Large images | Compression, lazy loading, WebP | Low |
| Too many requests | Bundle JavaScript, CSS | Medium |
| No caching | Implement browser caching | Low |
| Slow server | CDN, server optimization | Medium |
Problem 2: Slow API Responses
Symptoms:
- UI feels sluggish
- Actions take seconds to complete
- User frustration with “loading” states
Common causes:
- Unoptimized database queries
- Missing indexes
- No caching
- Too much data returned
Fixes:
| Cause | Fix | Effort |
|---|---|---|
| Slow queries | Query optimization, indexes | Medium |
| No caching | Redis, in-memory cache | Medium |
| Too much data | Pagination, field selection | Low |
Problem 3: Slow Mobile Experience
Symptoms:
- Mobile conversion much lower than desktop
- High mobile bounce rate
- Mobile users spend less time
Common causes:
- Desktop-only design
- Heavy JavaScript
- Large assets
- Poor mobile network handling
Fixes:
| Cause | Fix | Effort |
|---|---|---|
| Heavy JS | Code splitting, tree shaking | High |
| Large assets | Adaptive loading, compression | Medium |
| Network issues | Service workers, offline support | High |
Performance vs. Features: The Roadmap Trade-off
The Allocation Framework
Recommended split:
| Category | Allocation | Example |
|---|---|---|
| New features | 60-70% | New capabilities |
| Performance | 15-20% | Speed optimization |
| Technical debt | 10-15% | Code health |
The Performance Budget
What is a performance budget?
A limit on performance metrics that the team agrees not to exceed.
Example performance budget:
┌─────────────────────────────────────────────────────────────┐
│ PERFORMANCE BUDGET - Q1 2025 │
├─────────────────────────────────────────────────────────────┤
│ │
│ Page Load: │
│ └── Homepage: < 2s │
│ └── Product pages: < 2.5s │
│ └── Checkout: < 3s │
│ │
│ API Response: │
│ └── P95 latency: < 500ms │
│ └── Error rate: < 1% │
│ │
│ Bundle Size: │
│ └── Initial JS: < 200KB │
│ └── Initial CSS: < 50KB │
│ │
│ ENFORCEMENT: │
│ └── CI builds fail if budget exceeded │
│ └── PM review required to exceed budget │
│ │
└─────────────────────────────────────────────────────────────┘
Making the Trade-off Decision
When performance work conflicts with feature work:
- Measure current performance
- Calculate business impact of slow performance
- Estimate business value of the feature
- Compare ROI
Example decision:
Option A: Ship feature now, performance at 4s load time
├── Feature value: $100K in new revenue
└── Performance impact: -$50K in lost conversions
Option B: Fix performance first, ship feature next sprint
├── Performance improvement: +$80K in conversions
└── Delay feature cost: -$20K (2-week delay)
Decision: Option B has higher net value
Building a Performance Culture
The Performance Mindset Shift
From: “Performance is an engineering concern”
To: “Performance is a feature”
Weekly Performance Review
Add to your recurring meetings:
Weekly Performance Review (15 minutes)
├── P95 latency trend
├── Error rate
├── Core Web Vitals
├── Any performance incidents
└── Performance budget status
Performance in Feature Specs
Add to every feature spec:
## Performance Requirements
### Expected Impact
- Will this feature increase page weight? By how much?
- Will this feature add API calls? How many?
- What's the expected render time impact?
### Performance Budget
- Does this fit within our performance budget?
- If not, what trade-off are we making?
### Monitoring
- How will we measure performance impact?
- What alerts should we set up?
Questions to Ask Your Engineering Team
About Current Performance
- “What’s our P95 latency right now?”
- “What are our Core Web Vitals scores?”
- “Where are our performance bottlenecks?”
About Performance Impact
- “How will this feature affect page load time?”
- “What’s the performance cost of this approach?”
- “Is there a faster way to achieve the same result?”
About Performance Investment
- “What performance improvements would have the highest impact?”
- “What’s blocking us from being faster?”
- “What performance work should be on the roadmap?”
Your Performance Action Plan
Week 1: Measure
- Get access to performance dashboards
- Understand current Core Web Vitals
- Identify top 3 slowest pages/endpoints
- Calculate performance impact on conversion
Week 2: Prioritize
- Identify highest-impact performance improvements
- Estimate effort vs. impact
- Add top items to roadmap
- Set performance targets
Month 1: Optimize
- Implement top performance fixes
- Set up performance budgets
- Add performance to feature specs
- Establish weekly performance review
Quarter 1: Culture
- Performance is discussed in every planning
- Performance budgets are enforced
- Team is performance-conscious
- Performance metrics are visible
The Bottom Line
Performance is not a technical metric. It’s a business metric.
Fast products:
- Convert better
- Rank higher in Google
- Retain users longer
- Generate more revenue
Slow products:
- Lose users
- Rank lower
- Frustrate customers
- Leave money on the table
Your job as PM:
- Know your performance metrics
- Understand the business impact
- Prioritize performance work appropriately
- Make performance visible to stakeholders
The shift: When you treat performance as a feature, you build better products. Products that users love because they work fast.
Start today: Find out your current page load time. If it’s >3 seconds, you have a performance problem that’s costing you money.
What’s your slowest page? What would 1 second of improvement mean for your business?
Related Reading:
💬 Join the Conversation