How to Talk About Performance and Speed in English at Work
ESL English learning: Master performance optimisation vocabulary—latency, throughput, response time—to discuss system speed confidently in tech workplaces.
Pronunciation Guide: Key Performance Terms
Mispronouncing technical terms can undermine your credibility in meetings. Here's how to pronounce key performance vocabulary correctly.
latency /ˈleɪ.tən.si/
LAY-ten-see
Saying 'lah-TEN-see' instead of 'LAY-ten-see'
throughput /ˈθruː.pʊt/
THROO-put
Pronouncing 'th' as 't' or 'f'
degradation /ˌdeɡ.rəˈdeɪ.ʃən/
deg-ruh-DAY-shun
Stressing the wrong syllable: 'DEG-ra-day-shun'
percentile /pəˈsen.taɪl/
per-SEN-tile
Saying 'per-sen-TEEL' or 'PER-cent-ile'
SLA /ˌes.elˈeɪ/
S-L-A (spell out)
Trying to pronounce it as a word: 'slah'
cache /kæʃ/
CASH
Pronouncing it as 'catch' or 'cash-AY'
Multiple choice
Choose the best answer.
How do you correctly pronounce 'latency' in English?
When Systems Speed Up: Verbs for Performance Gains
When performance improves, we need precise verbs to describe the change. In tech contexts, we adapt everyday 'speed' vocabulary to describe metrics, deployments, and system behaviour.
Use accelerate for gradual performance gains: 'After we migrated to the new CDN, page loads accelerated significantly.' Note that accelerate implies a continuous improvement curve, not a sudden jump.
Use rocket and soar for dramatic improvements—these verbs carry positive connotations and work well in executive summaries: 'Throughput rocketed after we optimised the database queries.' 'Response times soared past our Q3 targets.' (Note: when we say response times 'soared past targets,' we mean the performance exceeded expectations, not that times increased.)
For describing quick fixes during incidents, use zip informally: 'The hotfix zipped through QA and hit production in under an hour.'
| Verb | Tech Usage | Example Sentence |
|---|---|---|
| accelerate | Gradual performance improvement | Query performance accelerated after we added the index. |
| rocket | Dramatic metric improvement | Our Lighthouse scores rocketed from 45 to 92. |
| soar | Positive upward trend | User satisfaction soared after we reduced latency. |
| zip | Fast deployment/process (informal) | The PR zipped through review in ten minutes. |
Grammar Note: Transitive vs Intransitive
Accelerate can be both transitive and intransitive: 'We accelerated the deployment' (transitive) vs 'Deployment times accelerated' (intransitive). Rocket and soar are intransitive only—you cannot say 'We rocketed the metrics.'
When Systems Slow Down: Describing Degradation
Describing performance problems requires careful verb choice. The severity of the issue should match your vocabulary.
Use crawl for severely degraded but functional systems: 'The API is crawling—responses are taking 30 seconds.' This verb emphasises painful slowness while indicating the system hasn't completely failed.
Use creep for gradual degradation over time: 'Memory usage has been creeping up since the last release.' This verb suggests a slow, almost unnoticeable increase that accumulates into a problem.
Use plummet and plunge for sudden, severe drops: 'After the config change, throughput plummeted by 80%.' These verbs convey urgency and are appropriate for incident communications.
Use slump and tumble for significant but less catastrophic declines: 'Cache hit rates slumped during peak hours.' These are useful in postmortems when describing concerning but manageable degradation.
| Verb | Severity | Tech Context Example |
|---|---|---|
| crawl | Severe (ongoing) | Database queries are crawling under the current load. |
| creep (up/down) | Gradual | Latency has been creeping up over the past sprint. |
| plummet | Sudden, catastrophic | Availability plummeted to 60% during the outage. |
| plunge | Sudden, severe | The service plunged into an error state. |
| slump | Significant decline | Request success rates slumped after the deployment. |
| tumble | Rapid decline | Our SLO compliance tumbled below acceptable thresholds. |
Cultural Note: Choosing Severity in Incident Calls
In incident calls, match your verb intensity to the actual impact. Saying throughput 'plummeted' when it dropped 5% can make you seem alarmist. Reserve dramatic verbs for genuine emergencies to maintain credibility.
Core Performance Vocabulary: Latency, Throughput, and Response Time
Three terms form the foundation of performance discussions. Understanding their precise meanings helps you communicate accurately in design reviews and postmortems.
| Term | Definition | Example Usage |
|---|---|---|
| latency | Time delay before data transfer begins (often measured in milliseconds) | We need to reduce latency between our EU servers and US users. |
| throughput | Volume of data or requests processed per unit of time | The new architecture handles 10x the throughput of the legacy system. |
| response time | Total time from request initiation to complete response | P99 response times exceeded 500ms during the incident. |
| SLA (Service Level Agreement) | Contractual performance commitment | Our SLA guarantees 99.9% uptime and sub-200ms response times. |
| SLO (Service Level Objective) | Internal performance target | We're tracking against an SLO of P95 latency under 100ms. |
| P99/P95 | 99th/95th percentile of measurements | P99 latency is more meaningful than averages for user experience. |
- Latency focuses on the DELAY before anything happens—think of it as waiting time.
- Throughput focuses on VOLUME over time—how much work the system handles.
- Response time is END-TO-END—the complete user-perceived duration.
- SLAs are EXTERNAL commitments; SLOs are INTERNAL targets.
Multiple choice
Choose the best answer.
Which term best describes the total time from when a user clicks 'Submit' until they see a confirmation message?
Scenario: Explaining Performance Issues to Non-Technical Stakeholders
When discussing performance with product managers, executives, or customers, translate technical metrics into business impact. Avoid jargon and focus on user experience and business outcomes.
| Too Technical | Stakeholder-Friendly |
|---|---|
| P99 latency spiked to 2000ms due to connection pool exhaustion. | Page loads slowed significantly—about 1 in 100 users waited over 2 seconds, which typically causes drop-offs. |
| Throughput plummeted when the read replicas fell behind. | The system couldn't handle the traffic volume, so some users experienced errors or slow responses. |
| We're breaching our SLO on the checkout endpoint. | Checkout is slower than our target, which may be affecting conversion rates. |
| Memory usage has been creeping up, indicating a potential leak. | We've spotted early signs of a problem that could slow things down if we don't address it soon. |
Phrase Bank: Connecting Metrics to Business Impact
Use these bridging phrases: 'This translates to...', 'In practice, this means...', 'For our users, this looks like...', 'Historically, this level of degradation correlates with...'
Complete the sentence
Type the missing word or phrase.
Complete this stakeholder-friendly explanation: 'Response times have ______ from 200ms to 800ms, which means users are waiting noticeably longer for pages to load.'
Scenario: Discussing Performance in Design Reviews
In design reviews and RFCs, you need to discuss performance requirements, trade-offs, and expectations precisely. Here's vocabulary for these technical discussions.
| Phrase | Context | Example |
|---|---|---|
| under load | Describing performance at scale | How does this approach perform under load? |
| at the cost of | Discussing trade-offs | We gain throughput at the cost of increased latency. |
| scales linearly/logarithmically | Describing growth patterns | Memory usage scales linearly with connection count. |
| degrades gracefully | Failure mode discussion | The circuit breaker ensures the service degrades gracefully. |
| within acceptable thresholds | SLA/SLO compliance | P95 response times remain within acceptable thresholds. |
| Informal (Slack/Standup) | Formal (RFC/Design Doc) |
|---|---|
| This should be way faster than what we have now. | This approach should reduce P95 latency by approximately 40%. |
| It might get slow if we get hammered with traffic. | Performance may degrade under sustained load exceeding 10k RPS. |
| We're basically trading speed for consistency here. | This design prioritises throughput at the cost of strict consistency. |
| The fallback kicks in if things go sideways. | The circuit breaker activates when error rates exceed the configured threshold. |
Multiple choice
Choose the best answer.
Which phrase is most appropriate for a formal design document discussing performance trade-offs?
Scenario: Writing a Postmortem About a Performance Incident
Postmortems require precise, blameless language that accurately describes what happened. Choose verbs that convey the severity and nature of the incident without dramatisation or understatement.
- Use plummeted/plunged for sudden, severe degradation: 'Availability plummeted to 73% at 14:32 UTC.'
- Use crawled for sustained poor performance: 'API responses crawled, with P99 exceeding 15 seconds.'
- Use careered (British) for out-of-control escalation: 'The cascade failure careered through dependent services.'
- Use crept for gradual degradation that preceded the incident: 'Memory usage had been creeping up for several days before the OOM event.'
- Use rocketed/soared for recovery: 'After the fix deployed, success rates rocketed back to 99.9%.'
| Vague (Avoid) | Precise (Use) |
|---|---|
| Performance got bad. | P99 response times plummeted from 150ms to 4500ms. |
| Things slowed down gradually. | Latency crept up by 50ms per hour over the preceding 6 hours. |
| The system couldn't keep up. | Throughput tumbled to 20% of baseline capacity. |
| We fixed it and things got better. | After the hotfix deployed, response times accelerated back to baseline within 3 minutes. |
Culture Note: Blameless Postmortems
In blameless postmortem culture, focus on systems and processes, not individuals. Say 'The deployment process allowed the misconfiguration to reach production' rather than 'Someone deployed a bad config.' Your verb choices should describe events, not assign fault.
Common Mistakes: What We Hear vs Better English
| Heard at Work ❌ | Better English ✓ |
|---|---|
| The latency rocketed to 500ms. | The latency spiked to 500ms. (Rocket implies positive movement; latency increasing is negative.) |
| Response times are very slow. | Response times are crawling. / Response times have degraded significantly. |
| The performance plunged up. | Performance soared. / Metrics rocketed. (Plunge is always downward.) |
| Throughput creeped up. | Throughput crept up. (Crept is the correct past tense.) |
| We need to speed up the latency. | We need to reduce the latency. (Latency is a measurement—you reduce it, not speed it up.) |
| The SLA breached. | We breached the SLA. / The SLA was breached. (SLA doesn't breach itself—it's breached.) |
Grammar Trap: Creep → Crept (Not Creeped)
The past tense of 'creep' is 'crept,' not 'creeped.' This is a common error even among native speakers. Similarly: 'The bug crept into production,' not 'creeped into production.'