performance

Rules for making software faster by measuring real bottlenecks first, with advice for browsers, servers, databases, and load tests.

In plain words
What is it for?
Investigating slow web pages, APIs, database queries, and high-traffic behavior using tools such as browser profilers, pprof, EXPLAIN ANALYZE, and load tests.
Why use it?
They reduce wasted optimization work by requiring profiling, realistic conditions, specific performance targets, and before-and-after measurements.

Cursor rule

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/nedcodes-ok/cursor-doctor/performance
Clone the repo
git clone --depth 1 https://github.com/nedcodes-ok/cursor-doctor
Per session 1,051 This file is loaded in full into every session.
When invoked 1,051 The same file — it is already loaded in full.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.01051 $0.01051
Opus 5 $0.00526 $0.00526
Sonnet 5 $0.00210 $0.00210
Haiku 4.5 $0.00105 $0.00105

Measured yesterday against content hash 36f7a39f6c80, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

performance scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

pro-kit/templates/practices/performance.mdc · 40 lines

How it starts

The opening of the file, as written. The whole thing — 40 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Performance Rules

Measurement First

  • Profile before optimizing — intuition about bottlenecks is wrong more than half the time. The slow function is almost never where you think it is
  • Tools by context: Chrome DevTools Performance tab + Lighthouse for frontend, pprof/perf/flame graphs for backend, EXPLAIN ANALYZE for SQL, load testing (k6, Artillery) for throughput
  • Set specific budgets: "LCP under 2.5s," "API p95 under 200ms," "JS bundle under 200KB gzipped." Vague goals ("make it faster") lead to premature optimization
  • Measure in production conditions — dev machines with SSDs and fast networks hide real-world performance. Test with throttled network and realistic data volumes
  • Before/after numbers for every optimization. "I think it's faster" is not evidence. "p95 dropped from 340ms to 85ms" is

Database (most common bottleneck)

  • Missing indexes are the #1 performance problem in web applications. Index columns in WHERE, JOIN, ORDER BY. Composite indexes for multi-column queries — column order matters (most selective first)
  • EXPLAIN ANALYZE every slow query. Sequential scan on a large table = missing index. Nested loop join on large tables = missing index or wrong join strategy
  • N+1 queries: loading 50 users then making 50 queries for their orders. Fix with eager loading (JOIN, select_related, include). If you can't see N+1s in dev, use query logging to count queries per request
  • Pagination on every list endpoint — LIMIT + OFFSET for small datasets, cursor-based for large ones. OFFSET 100000 scans and discards 100K rows, cursor-based skips nothing
  • Connection pooling: set pool size based on expected concurrency × query duration. Too few connections = queuing. Too many = database overload. Most frameworks default to 5-10, which is fine for small apps and wrong for everything else

Frontend

  • Lazy-load below-the-fold content: React.lazy(), dynamic import(), loading="lazy" on images. The fastest code is code that doesn't execute
  • JavaScript is the most expensive asset byte-for-byte: it must be downloaded, parsed, compiled, and executed. CSS and images are cheaper. Analyze with source-map-explorer or bundleanalyzer — find the 200KB dependency you import for one function
  • Critical rendering path: inline critical CSS, defer non-critical JS with async/defer, preload fonts with <link rel="preload">. First paint should not wait for your analytics script
  • Images: use WebP/AVIF, serve responsive sizes with srcset, lazy-load below fold. An unoptimized 4MB hero image destroys your LCP score and costs users real money on metered connections
  • CDN for static assets — puts files physically closer to users. Without CDN, a user in Tokyo downloads from your US-East server at 200ms round-trip per request

Read the full file on GitHub · 40 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. yesterday First seen · 40 lines · 1,051 tokens per session scan A 36f7a39f6c80

Subscribe to this mod's changes

performance is a cursor rule published in the GitHub repository nedcodes-ok/cursor-doctor (9 stars, last pushed 5mo ago), licensed MIT. It adds 1,051 tokens to every session, about $0.0053 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.