Scaling Is Capacity, Performance Is Efficiency

Scaling Is Capacity, Performance Is Efficiency 🔗 **Source:** [Scaling Is Capacity, Performance Is Efficiency](https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/) > [!note]+ Document Notes > tags: [performance, scalability, WordPress] > author: Remkus > source: remkusdevries.com > reference: [https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/] > date created: 2026-01-20 00:00 > > # 🏷️ Title: Scaling Is Capacity, Performance Is Efficiency >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. --- ## 📝 Summary - What happened. - The author argues that teams conflate scaling with performance: “Scalability does not make systems faster. It makes them endure more load.” ([intro](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=00004_00002-001d&startLexposition=00000&emphasizeText=Scalability+does+not+make+systems+faster.+It+makes+them+endure+more+load.)) - Why it matters. - Misunderstanding this leads to overbuilt, expensive infrastructure, especially in WordPress hosting, instead of fixing slow code and queries. - Key stakeholders. - WordPress developers, site owners, hosting providers, performance and platform engineers. - Risks and tradeoffs. - Over-reliance on auto-scaling and caching hides inefficiencies; costs grow with traffic, financial fragility increases, and true performance work is deferred. - Bottom line. - Optimize work per request first; then use scaling as leverage. “A fast system scales cheaply. A slow system scales expensively.” ([cost section](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000U_00000-0011&startLexposition=0000G&emphasizeText=A+fast+system+scales+cheaply.+A+slow+system+scales+expensively.)) --- ## 📖 Main Content - Core arguments - Scalability = capacity: how many concurrent requests your system can endure. - Performance = efficiency: how much work each single request requires. - Horizontal scaling only “spreads requests across more machines, but it does not reduce the cost of handling each one.” ([work per request](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000E_00000-001z&startLexposition=00006&emphasizeText=Horizontal+scaling+spreads+requests+across+more+machines%2C+but+it+does+not+reduce+the+cost+of+handling+each+one.)) - When performance is poor, scaling becomes brute-force compensation: more workers, replicas, and caching layers instead of fixing the slow paths. This is “not optimization. It is insulation.” ([cost multiplier](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000U_00000-0011&startLexposition=0000G&emphasizeText=This+is+not+optimization.+It+is+insulation.)) - Context and definitions - Work per request: DB queries, PHP execution, template rendering, network hops; these are “non‑negotiable” for each request. - Modern cloud platforms encourage confusion: elastic scaling is marketed as *the* solution, dashboards highlight throughput, not latency. ([trap section](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000c_00000-004M&startLexposition=0000W&emphasizeText=Modern+platforms+encourage+this+confusion.+Cloud+providers+sell+elasticity+as+a+solution+but+introduce+inherent+latency.)) - Recommended sequence - “Performance first, then scale”: reduce work per request, shorten execution paths, eliminate unnecessary queries, simplify rendering. ([performance first](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000k_00000-003b&startLexposition=0000e&emphasizeText=Performance+First%2C+Then+Scale)) - Once performance is solid, scaling “amplif[ies] good performance, not compensate[s] for its absence” and keeps costs predictable. - Uncertainties / contested claims - The article is opinionated and qualitative; it doesn’t supply benchmarks or cost models. - In some real-world cases, temporary over-scaling *can* be the right bridge while performance work is in progress—but the author is arguing against treating that as the *strategy*. --- ### 🗒️ Notes - “Scalability does not make systems faster. It makes them endure more load. Performance, by contrast, determines how much work a system must do for a single request.” ([intro](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=00004_00002-001d&startLexposition=00000&emphasizeText=Scalability+does+not+make+systems+faster.+It+makes+them+endure+more+load.)) - “Every request that enters a system has a non-negotiable amount of work attached to it… None of that work disappears simply because you add more servers.” ([fixed cost](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000E_00000-001z&startLexposition=00006&emphasizeText=Every+request+that+enters+a+system+has+a+non-negotiable+amount+of+work+attached+to+it.)) - “A slow request on one server is still a slow request on ten servers. You have multiplied capacity, not efficiency.” ([capacity vs efficiency](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000E_00000-001z&startLexposition=00006&emphasizeText=A+slow+request+on+one+server+is+still+a+slow+request+on+ten+servers.)) - Poor performance plus scaling = cost multiplier: “The system survives traffic, but only because it consumes more resources per unit of usefulness.” ([cost multiplier](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000U_00000-0011&startLexposition=0000G&emphasizeText=The+system+survives+traffic%2C+but+only+because+it+consumes+more+resources+per+unit+of+usefulness.)) - Symptoms of this approach: more servers, larger DBs, heavy caching, increasingly complex infra “introduced purely to avoid fixing code.” - Modern cloud and auto-scaling tools “reward throughput numbers rather than latency improvements,” so teams celebrate handling load instead of reducing work per request. ([trap](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000c_00000-004M&startLexposition=0000W&emphasizeText=Auto-scaling+dashboards+look+reassuring.+Load+tests+reward+throughput+numbers+rather+than+latency+improvements.)) - Prescribed order: “reduce work per request, shorten execution paths, eliminate unnecessary queries, and simplify rendering. Only then does scaling become meaningful.” ([performance work](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000k_00000-003b&startLexposition=0000e&emphasizeText=reduce+work+per+request%2C+shorten+execution+paths%2C+eliminate+unnecessary+queries%2C+and+simplify+rendering.)) - The article plugs the author’s “Make WordPress Fast” course as a systematic exploration of performance levers for WordPress sites. - Closing contrast: “Scalability keeps systems alive under pressure. Performance determines how much they cost to keep alive.” ([closing](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000k_00000-003b&startLexposition=0000e&emphasizeText=Scalability+keeps+systems+alive+under+pressure.+Performance+determines+how+much+they+cost+to+keep+alive.)) --- ## 📚 References - Remkus de Vries – “Scaling Is Capacity, Performance Is Efficiency” – original article: https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/ - Author’s newsletters pitch section ([newsletter plug](https://read.readwise.io/read/01kfdpq19y2g1563865m6ny8jx?endLexposition=0000s_00000-002m&startLexposition=0000m&emphasizeText=If+you%27re+serious+about+building+faster%2C+more+secure%2C+and+more+reliable+WordPress+sites%2C+this+newsletter+is+for+you.)) --- ## 🗣️ Paraphrase - Paragraph A paraphrase. - Scaling is about handling more simultaneous traffic, not making each page load faster. Performance is about shrinking the work each request does; mixing them up leads to bad decisions. - Paragraph B paraphrase. - Adding servers doesn’t erase slow code, heavy queries, or chatty networks. If you use scaling to mask inefficiency, you trade outages for ever-growing bills instead of actually speeding things up. --- ## 📰 Newsletter In this week’s WordPress performance corner, Remkus reminds us that “just add more servers” is not a strategy. Scaling only buys capacity; it doesn’t shrink the work each request does. For teams leaning hard on auto-scaling and caching, it’s worth revisiting your slow queries, template rendering, and PHP hotspots. Fix those first, then let scaling amplify your wins. If you want to go deeper, keep an eye on performance-focused resources like the “Make WordPress Fast” course and similar profiling guides. --- ## ✅ Action Items #### DevRel - Highlight “capacity vs efficiency” in talks and blog posts, using concrete WordPress examples (heavy plugins, unindexed queries, slow loops). - Create a hands-on workshop on measuring “work per request” (query count, render time, network calls) before discussing scaling. - Add examples and quickstarts that profile a slow WP site and show cost impact of scaling without optimizing. - Run a small campaign around “Performance first, then scale” with code samples, case studies, and funnel metrics tied to perf improvements. - Facilitate community office hours for performance triage instead of infra upgrades. #### OSPO - Encourage OSS projects in the stack (plugins, themes, hosting tooling) to document performance characteristics and budgets. - Introduce basic performance CI checks (e.g., query count, TTFB thresholds) to complement license and security checks. - Promote upstream contributions that reduce default WordPress overhead instead of relying on infra workarounds. #### Community - Host maintainer clinics on identifying and fixing N+1 queries, slow hooks, and heavy admin pages. - Create a “first performance issue” track to help new contributors learn profiling tools. - Share sponsor stories that show cost savings from performance work vs throwing hardware at the problem. #### WordPress - Core: define default performance budgets for key flows (home, archive, single post, admin dashboard). - Core Performance: expand profiling coverage and public dashboards; link infra costs to performance metrics. - Core AI: ensure AI-related features respect performance budgets and don’t require disproportionate infra. - Core Program Team: build cross-team rituals around measuring and reporting work per request before choosing infra changes. - Mobile: profile sync and API calls to avoid assuming mobile slowness is purely network-related. - Playground: add labs that show scaling vs performance tradeoffs in a browser-based WP environment. - Community: bake performance topics into meetup/WC talk suggestions and mentorship tracks. - Training: ship lesson plans on “performance first, then scale” with WordPress-specific labs. - Marketing: frame performance improvements in business terms (conversion, infra cost, Core Web Vitals). - Support: create troubleshooting flows that prioritize profiling over suggesting bigger hosting plans. - Design: collaborate on UI changes that reduce render complexity and heavy DOM structures. - Documentation: clarify performance implications of common patterns (heavy options autoload, large menus, complex queries). - Photos: recommend image optimization defaults that reduce per-request work. - TV: curate talks and series focusing on real-world WordPress performance tuning. - Polyglots: consider performance implications of large translation sets and string loading. - Accessibility: ensure performance fixes do not compromise accessible patterns; measure both. - Meta: review .org backend performance and infra; avoid over-scaling to hide slow paths. - CLI: add commands for quick performance diagnostics (query counts, cache hits). - Hosting: collaborate on shared checklists that emphasize fixing inefficiency before adding servers. - Tide: integrate performance indicators into plugin/theme scoring where feasible. - Openverse: apply “performance first, then scale” to ingestion and search. - Themes: encourage lean defaults, efficient loops, and minimal queries. - Plugins: document performance characteristics; avoid patterns that require hosts to over-scale. #### The WPOCC - Fund performance-focused fellowships and microgrants for improving high-impact plugins/themes. - Sponsor cross-project sprints on query optimization, caching strategy, and render simplification. - Experiment with grants tied to measurable performance and infra-cost improvements. ### FAIR - Promote transparent reporting of hosting costs vs performance metrics for funded WP infrastructure. - Encourage governance artifacts (charters, scorecards) that distinguish scaling capacity from performance efficiency. --- ## 🧪 Hypotheses - H1: WordPress sites that prioritize reducing work per request will exhibit lower hosting costs per 1,000 requests than similarly sized sites that rely mainly on scaling. - H2: Teams exposed to explicit “capacity vs efficiency” training will make fewer infra-only changes to address performance incidents. - H3: Introducing basic performance budgets into WordPress projects will reduce long-term infra spend without harming reliability. - H4: WordPress hosts that market performance education alongside scaling will see lower churn in high-traffic customers. --- ### 📊 Methodology - Compare matched cohorts of WordPress sites: one group that conducted performance tuning (query optimization, caching strategy, render simplification), another that primarily upgraded plans or auto-scaling. Track infra costs, p95 latency, and uptime. - Run controlled training interventions with engineering teams and measure incident reports, remediation strategies, and infra changes pre/post. - Introduce performance budgets into selected WP projects and monitor infra utilization, response times, and user outcomes over time. --- ### ❓ Questions - How much infra spend is currently hiding avoidable inefficiency in large WordPress deployments? - Which WordPress patterns most often trigger “scale instead of optimize” responses (e.g., WooCommerce, page builders)? - How can dashboards better surface work-per-request metrics rather than just throughput? - What incentives would lead hosts and agencies to prioritize performance work over easy scaling? --- ### 🔮 Future Research - Quantitative studies on the cost elasticity of WordPress performance improvements vs infra scaling. - Tooling that automatically surfaces expensive code paths and associated infra costs in typical WP stacks. - Case studies of large WordPress sites that reversed infra sprawl through focused performance work. --- ### 💡 Implications - Practice: Developers should treat every additional DB query, loop, or network hop as a cost multiplier at scale. - Policy: Organizations may set performance budgets and require optimization before approving infra upsizing. - Security: Simplified, faster systems are often easier to secure and monitor than complex, over-scaled stacks. - Education: Performance should be framed as both UX and cost control, especially in WordPress training. - Funding: Grants and sponsorships could favor projects that deliver documented performance and cost wins. --- ### 🧠 Learning Styles Assessment - Reading level estimate - Roughly intermediate technical article (~8th–10th grade reading level by Flesch–Kincaid style estimation), but assumes basic infra/perf vocabulary. #### 👀 Visual learners - Present: Conceptual contrast between scaling and performance, but no diagrams. - Improve: Add diagrams showing request flow, work per request, and how scaling changes capacity but not per-request work. #### 🔊 Aural learners - Present: None noted. - Improve: Provide a short audio summary or podcast-style discussion on “capacity vs efficiency” in WordPress. #### 🗣️ Verbal learners - Present: Clear definitions and repeated contrasts (“A fast system scales cheaply. A slow system scales expensively.”). - Improve: Add more analogies (e.g., more lanes vs lighter cars) and a small glossary. #### 🧩 Kinesthetic learners - Present: Implied via reference to a performance course, likely hands-on. - Improve: Include step-by-step exercises profiling a WordPress site and applying optimizations. #### 🧠 Logical learners - Present: Causal chains (poor performance → more scaling → higher costs) and clear reasoning. - Improve: Provide tables comparing scenarios, and simple cost formulas linking latency to infra spend. #### 🧑‍🤝‍🧑 Social learners - Present: Invitation to newsletters and community learning. - Improve: Add discussion prompts and recommended group exercises (pair profiling sessions). #### 🧘‍♀️ Solitary learners - Present: Article format supports solo reading and reflection. - Improve: Include a short self-check list (“Can I explain capacity vs efficiency?”) and reflection prompts. #### 🌿 Naturalistic learners - Present: No explicit environmental framing. - Improve: Draw analogies to ecosystems (resource limits, carrying capacity) and mention energy efficiency of avoiding over-scaling. --- ### 📊 Accessibility Assessment *(Assuming a typical WordPress blog template; exact details not inspected here.)* #### Screen reader semantics - Present: Likely standard headings and landmarks from theme. - Improve: Ensure headings follow a logical hierarchy and images (if any) have descriptive alt text. #### Keyboard navigation - Present: Typical themes provide basic keyboard support. - Improve: Confirm visible focus states, skip links, and absence of keyboard traps. #### Contrast and readability - Present: Modern blogs often meet minimum contrast. - Improve: Verify 4.5:1 contrast, good line height, and avoid light-grey body text. #### Text resizing and reflow - Present: Responsive design likely supports zoom. - Improve: Check at 200% zoom and for prefers-reduced-motion. #### Media and captions - Present: Primarily text content. - Improve: If videos or images are added later, ensure captions and descriptions. #### Forms and interactions - Present: Newsletter signup forms likely exist. - Improve: Provide clear labels, error messages, and adequate hit targets. #### Standards reference - Map and test against WCAG 2.2 AA criteria, especially for text, navigation, and forms. --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: Focused on WordPress engineering; culturally neutral. - Improve: Highlight global hosting contexts and constraints (e.g., bandwidth/infra limits). #### Inclusive language - Present: Neutral, professional language; minimal jargon, mostly defined by context. - Improve: Add brief explanations for non-experts and avoid infra-specific shorthand without context. #### Neurodiversity support - Present: Short sections, clear through-lines. - Improve: Add more subheadings, summaries, and bullet lists for scannability. #### Representation - Present: Technical topic; no explicit human representation. - Improve: When adding examples, include diverse org sizes and geographies. #### Psychological safety - Present: Non-attacking, problem-focused tone. - Improve: Offer guidance without shaming teams that relied on scaling first. --- ### ✅ Logical Validity #### Strong reasoning - Causal reasoning: “When performance is poor, scaling compensates by brute force… every inefficiency is multiplied by traffic volume.” This is a sound causal chain explaining cost growth. - Analogy to physics: “You cannot distribute inefficiency away. You can only distribute it wider.” This clarifies that scaling doesn’t remove work, just spreads it. #### Fallacies - None obvious; the argument is strongly framed but doesn’t misrepresent opposing views. It does assume infra costs scale in a relatively linear way with inefficiency and load, which might be nuanced in practice. #### Tone of voice - Tone is practical, mildly opinionated, and pedagogical: “This is not optimization. It is insulation.” The closing is concise and prescriptive. --- ### 🛡️ DARVO Analysis - Deny: No denial or minimization of harm; instead it surfaces hidden costs. - Attack: No attacks on individuals or groups; critique is aimed at habits and tooling defaults. - Reverse victim/offender: Not present; the article doesn’t position engineers as victims, just as decision-makers who can change course. --- ## 🎯 Conclusion The article’s core message is that scalability is about capacity while performance is about efficiency. Using scaling to hide slow WordPress code and queries only multiplies cost and complexity. The practical next step for readers is to profile work per request—queries, render time, network calls—fix the slow paths, and only then rely on scaling to gracefully absorb traffic. --- ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] Performance-first scaling cuts WordPress infra costs > [!quote] [Scaling Is Capacity, Performance Is Efficiency](https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/) by [[Remkus]] via [[remkusdevries.com]]. Published 2026-01-18. Accessed . > “A fast system scales cheaply. A slow system scales expensively.” Two lines: context and use. Cite data if relevant. [view highlight](https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] Scaling hides inefficiency but multiplies cost > [!quote] [Scaling Is Capacity, Performance Is Efficiency](https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/) > “This is not optimization. It is insulation.” Two lines: context and use. [view highlight](https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Fast systems scale more cheaply than slow ones - Under similar traffic, optimized WordPress sites require fewer resources per request. - Pointer to page/time or dataset. - Links: [[Web-Performance]] [[WordPress-Hosting-Costs]] #### [Z2] Scaling compensates for inefficiency by multiplying cost - When performance is poor, auto-scaling and larger instances increase spend. - Pointer to page/time or dataset. - Links: [[Cloud-Infrastructure]] [[System-Design-Antipatterns]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Benchmark a current WordPress site before and after basic query and template optimizations — https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/ #fleeting #inbox - [F2] Draft a short talk: “Capacity vs Efficiency in WordPress Infrastructure” — https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/ #fleeting #inbox - [F3] Design a simple dashboard widget for work-per-request metrics — https://remkusdevries.com/scaling-is-capacity-performance-is-efficiency/ #fleeting #inbox ---