performance-patterns
/performance-patterns
Wskazuje antywzorce wydajności, takie jak zapytania N+1, nadmiar wywołań API i ciężkie renderowanie, oraz podpowiada poprawki.
- Autor
- hculap ↗
- Repozytorium
- better-code ↗
- Licencja
- MIT
- Ostatnia zmiana repozytorium
- 09.10.2026
Ocena i bezpieczeństwo
- Pliki w paczce
- 1
- Skrypty
- 0
- Komentarze HTML
- 0
- Adresy URL w SKILL.md
- 0
Brak sygnałów. Repozytorium zmienione 09.10.2026, bez odwołań do wycofanych modeli i API.
MIT, otwarta: można używać i zmieniać, z zachowaniem informacji o autorze.
Co robi i kiedy
Wskazuje antywzorce wydajności, takie jak zapytania N+1, nadmiar wywołań API i ciężkie renderowanie, oraz podpowiada poprawki.
Oryginalny opis (EN)
Use when user asks about N+1 queries, performance optimization, query optimization, reduce API calls, improve render performance, fix slow code, optimize database, or reduce bundle size. Provides guidance on identifying and fixing performance anti-patterns across database, backend, frontend, and API layers.
Jak działa
- N+1 Query Problem
- Over-Fetching
- Under-Fetching
- Missing Pagination
- Inefficient Algorithms
- Unnecessary Re-renders (Frontend)
- Sequential Async Operations
- Quick Reference by Layer
Podgląd SKILL.md
--- name: performance-patterns description: Use when user asks about N+1 queries, performance optimization, query optimization, reduce API calls, improve render performance, fix slow code, optimize database, or reduce bundle size. Provides guidance on identifying and fixing performance anti-patterns across database, backend, frontend, and API layers. allowed-tools: Read, Grep, Glob --- # Performance Anti-Patterns Reference ## N+1 Query Problem The N+1 problem occurs when code executes N additional queries to fetch related data for N items from an initial query. **Identification:** - Queries inside loops - Lazy loading of associations during iteration - GraphQL resolvers fetching per-item **Fix Strategies:** 1. **Eager Loading**: Load related data in initial query 2. **Batching**: Collect IDs, fetch all at once 3. **DataLoader**: For GraphQL, batch and cache per-request 4. **Denormalization**: Store computed/related data together **Severity**: HIGH - Scales linearly with data size, causes exponential slowdown ## Over-Fetching Retrieving more data than needed from API or database. **Identification:** - SELECT * queries - API endpoints returning full objects - No field selection support - Loading nested relations by default **Fix Strategies:** 1. **Field Selection**: Only query needed columns 2. **Sparse Fieldsets**: Support `?fields=id,name` parameter 3. **GraphQL**: Let clients specify exact fields 4. **DTOs**: Map to response-specific objects **Severity**: MEDIUM - Increases bandwidth, memory, serialization time ## Under-Fetching Requiring multiple requests to get needed data. **Identification:** - Waterfall requests (request depends on previous) - Multiple endpoints for related data - No include/expand support **Fix Strategies:** 1. **Compound Endpoints**: `/users?include=orders` 2. **GraphQL**: Single query for nested data 3. **BFF Pattern**: Backend aggregates for frontend 4. **Parallel Requests**: When dependencies allow **Severity**: MEDIUM - Increases latency, connection overhead ## Missing Pagination Returning unbounded result sets. **Identification:** - List endpoints without limit - `findAll()` without pagination - No cursor for large datasets **Fix Strategies:** 1. **Offset Pagination**: `?page=1&limit=20` 2. **Cursor Pagination**: `?cursor=abc&limit=20` (better for large sets) 3. **Default Limits**: Always apply max limit server-side 4. **Streaming**: For very large exports **Severity**: HIGH - Can crash server/client with large data ## Inefficient Algorithms O(n²) or worse complexity where better solutions exist. **Identification:** - Nested loops on collections - Repeated array.find/includes in loops - String concatenation in loops - Sort inside loops **Fix Strategies:** 1. **Use Maps/Sets**: O(1) lookup instead of O(n) 2. **Single Pass**: Combine operations 3. **Pre-compute**: Calculate once, reuse 4. **Better Algorithms**: Binary search for sorted data **Severity**: HIGH - Becomes unusable with large data ## Unnecessary Re-renders (Frontend) Components re-rendering when their output hasn't changed. **Identification:** - Inline objects/arrays in JSX - Inline function handlers - Missing React.memo/useMemo/useCallback - Context changes affecting all consumers **Fix Strategies:** 1. **Memoization**: React.memo for components 2. **Stable References**: useMemo for objects, useCallback for functions 3. **Context Splitting**: Separate frequently-changing state 4. **Selectors**: Only subscribe to needed state slices **Severity**: MEDIUM-HIGH - Causes janky UI, especially on lists ## Sequential Async Operations Running async operations one-by-one when parallel is possible. **Identification:** - Sequential await statements - Waterfall promises - Loop with await inside **Fix Strategies:** 1. **Promise.all**: Run independent operations in parallel 2. **Promise.allSettled**: When some can fail 3. **Batching**: Group operations efficiently 4. **Pipelining**: Stream processing **Severity**: MEDIUM - Multiplies latency ## Quick Reference by Layer ### Database | Issue | Detect | Fix | |-------|--------|-----| | N+1 queries | Query in loop | Eager load / batch | | Missing index | Slow WHERE/JOIN | Add index | | SELECT * | No column list | Specify columns | | No LIMIT | Unbounded query | Add pagination | ### Backend | Issue | Detect | Fix | |-------|--------|-----| | O(n²) loop | Nested iteration | Use Set/Map | | Sequential await | await in sequence | Promise.all | | Sync I/O | fs.readFileSync | Use async version | | No caching | Repeated computation | Memoize | ### Frontend | Issue | Detect | Fix | |-------|--------|-----| | Re-renders | Inline objects/functions | Memoize | | Bundle size | Large imports | Tree-shake/split | | Memory leak | No cleanup | useEffect cleanup | | Layout thrash | Read+write DOM | Batch DOM ops | ### API | Issue | Detect | Fix | |-------|--------|-----| | Over-fetching | All fields returned | Field selection | | Under-fetching | Multiple requests | Include/expand | | No pagination | Unbounded lists | Add limit/cursor | | N+1 calls | Fetch in loop | Batch endpoint |
Wersje
| Repozytorium | Wynik | Licencja |
|---|---|---|
| Ta strona · hculap/better-code | 90 | MIT |
| s-morgan-jeffries/apple-mail-fast-mcp | 100 | MIT |
Migawka bazy z 13.11.2026 · wersja paczki 1e86f3795fa9 (skrót SHA-256 całej paczki)
Pobrania w ostatnich 30 dniach: 1 · ranking
Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.
Podobne skille
- 100performance-optimization
Mierzy, znajduje wąskie gardła, naprawia, weryfikuje i pilnuje regresji wydajności: web vitals, wolne API, ciężkie notebooki i potoki oraz renderowanie wideo. - 100performance
Optymalizuje wydajność aplikacji webowych we frontendzie, backendzie i bazie danych: Core Web Vitals, bundle, lazy loading, cache, zapytania N+1 i wycieki pamięci. - 90Optimization
Prowadzi optymalizację wydajności opartą na pomiarach: profilowanie, wąskie gardła CPU, pamięci i I/O, cache oraz naprawy zapytań i sieci. - 100database-optimization
Optymalizuje zapytania SQL i indeksy, wykrywa problemy N+1 oraz wspiera przegląd wydajności i migracji baz danych. - 95wp-performance-review
Przegląda kod WordPress pod kątem wydajności: WP_Query, cache, skalowalność i typowe antywzorce przed wdrożeniem. - 100performance-optimization
Diagnozuje i naprawia problemy z wydajnością stron: Core Web Vitals (LCP, INP, CLS), rozmiar bundla, zasoby, renderowanie i wydajność w czasie działania.