performance-optimization

Replace per-record lookups with a single query that joins or includes the related data, such as an ORM include clause. Confirm the fix by checking the query log before and after to verify the query count dropped to one.

Measure first with Lighthouse or the web-vitals library to find the actual bottleneck. For LCP, optimize hero images with responsive srcset and fetchpriority; for INP, profile long tasks on the main thread and reduce heavy JavaScript or re-renders.

Only after running EXPLAIN ANALYZE and reading the query plan. Index for the shape of the query with equality columns first, and skip indexes for low-selectivity filters, leading wildcards, or write-heavy tables where the write cost outweighs the read gain.

Exhaustion usually means connections are held too long, not that the pool is too small. A larger pool just moves the queue to the database; instead find what holds connections, and for serverless use a proxy like pgbouncer or RDS Proxy.

Do not cache queries that are already fast, data whose staleness is a correctness bug like balances or permissions, or per-user data under a key that does not identify the user. Cache only what is expensive to produce and read far more often than it changes.

No. A neutral result is a revert, because code you keep must be maintained forever without paying for itself. Log the attempt with baseline and result numbers so the same failed idea is not retried later.