performance-optimization

Start by measuring with Lighthouse and the DevTools network waterfall to identify whether the bottleneck is bundle size, server response time, or render-blocking resources. Then apply targeted fixes like code splitting, image optimization, or caching, and measure again to confirm improvement.

Replace per-record queries with a single query using joins or ORM include statements, such as Prisma's findMany with include. Check your database query log to confirm the query count drops from N+1 to one.

Good thresholds are LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1. Values beyond 4.0 seconds LCP, 500 milliseconds INP, or 0.25 CLS are considered poor.

Do not optimize before you have profiling evidence of an actual problem. Premature optimization adds complexity that costs more than the performance it gains, so always measure first and fix only what data proves matters.

Use bundlesize to fail builds when JavaScript exceeds limits like 200KB gzipped, and run Lighthouse CI with lhci autorun to check performance scores on every commit. Set explicit budgets for CSS, images, fonts, and API response times.