The performance Skill — Optimization Patterns for Design and Review
How the performance skill gives Datarim agents a concise reference for lazy loading, caching, batching, database indexing, and frontend bundle optimization when designing or reviewing for performance.
Performance problems tend to appear late, when the cost of fixing them is high. A missing index is found in production under load. An N+1 query is caught during a load test. A bundle that takes six seconds to parse blocks every first-page visit. The performance skill loads these patterns at design and review time, before the problem is built in.
The skill covers three layers: general optimization patterns, database-specific guidance, and frontend-specific guidance. Each layer targets a different point where performance is decided.
Optimization patterns
Three patterns apply broadly across the stack. The first is lazy loading: load resources or modules only when they are needed. A module imported at the top level is always paid for; a module loaded on demand is paid for only when the user reaches the code path that needs it.
The second is caching. For operations whose result is expensive to compute and stable enough to reuse — a database query, an external API call, a computed aggregation — a caching layer like Redis or an in-memory store avoids repeating the work. The skill does not prescribe a specific TTL or invalidation strategy; those depend on how often the data changes and how much staleness the application can tolerate.
The third is batching. When an application makes many small database or API calls in a loop, replacing them with a single call that fetches all the data at once removes the per-call overhead. A loop that calls the database once per item is a candidate for batching.
Database
Two database rules cover most query performance problems. First: ensure indexes exist on columns that appear in query filters and joins. A full table scan on a large table is the most common cause of a slow query; the fix is an index, not a rewrite of the query logic.
Second: avoid N+1 queries. An N+1 query happens when code loads a list of N records and then issues one additional query per record to fetch a related resource. The fix is eager loading — either an include clause in the ORM call or a batch-load pattern that fetches all related records in a single query.
Frontend
Three frontend patterns apply at build and rendering time. Bundle size determines how long the browser takes to parse and execute JavaScript before the page becomes interactive. Keeping the bundle small — through tree-shaking, code splitting, and avoiding large dependencies with small-footprint alternatives — directly affects first-load time.
Image optimization means serving images in WebP format and loading them lazily. WebP produces smaller files than JPEG or PNG at equivalent visual quality. Lazy loading defers the download of images outside the initial viewport until the user scrolls to them, which reduces the data transferred on first load.
For pages that render long lists — search results, feed items, transaction histories — virtualization renders only the visible rows, not the full list. Rendering ten thousand DOM nodes for a list the user sees twenty at a time causes layout and paint overhead that virtualization eliminates.
Read what Datarim is for broader context, or see the related post on the network-exposure-baseline skill for another example of a constraint that is cheaper to check at design time than to fix later.