Copy and paste these prompts into Claude Code, Codex, Cursor, or any other coding agent. Run them one at a time, and test your app after each change.
1.Inline tiny critical SVGs and icons
Find small, critical SVG icons and graphics that are loaded as separate network requests on important pages. Inline the few that appear above the fold directly into the markup or a sprite so they render without extra round trips, while keeping larger or rarely-used graphics external. Avoid inlining large SVGs that would bloat the HTML. Verify the critical icons appear instantly with fewer requests.
2.Use database connection pooling
Check whether my app opens a fresh database connection per request or operation instead of reusing a pool. Configure a properly sized connection pool so connections are reused, with limits tuned to the database's capacity and the app's concurrency. In serverless or high-fan-out setups, ensure pooling works correctly (e.g., via a pooler). Verify connection overhead drops and the database isn't overwhelmed by connection churn under load.
3.Add an in-memory cache layer
Identify frequently accessed, slow-to-fetch data that would benefit from a fast in-memory cache (such as Redis or an in-process cache for single instances). Introduce the cache layer for those reads with clear keys, TTLs, and a safe miss-and-populate path, falling back to the source on cache failure. Be mindful of consistency across multiple server instances. Verify the cached reads are dramatically faster and source-system load drops.
4.Add a client-side request cache
Review how my client refetches data when users revisit screens or navigate back and forth, and find cases where it re-requests identical data unnecessarily. Introduce a client-side cache (or adopt a data-fetching library that provides one) keyed by request parameters, with sensible freshness and invalidation rules. Ensure mutations correctly invalidate affected cache entries. Verify revisiting screens reuses cached data and avoids redundant requests.
5.Cache repeated read queries
Identify read queries that run very frequently with the same or few distinct parameters and return data that changes slowly. Add a caching layer in front of them with keys based on the query parameters and TTLs matched to the data's volatility, plus invalidation on relevant writes. Ensure cache misses populate safely under concurrency. Verify database query volume for these reads drops sharply and response times improve.