Performance Optimization Using Cursor

Your SaaS dashboard loads in 6 seconds. The product page takes 3 seconds to become interactive. The API endpoint that powers the billing dashboard has a p95 latency of 2.4 seconds, and the database CPU spikes to 80% every time someone opens the “Usage Analytics” tab. Users are complaining. Your CTO wants a 50% improvement by end of month.

Performance optimization is a diagnosis-first discipline. The biggest waste of time is optimizing the wrong thing — shaving 50ms off a render that was never the bottleneck while the real problem is a database query that runs 47 times per page load. Cursor’s strength here is its ability to analyze large amounts of profiling data, spot patterns across hundreds of lines of metrics output, and suggest targeted fixes with specific before/after expectations.

What You’ll Walk Away With

• A profiling workflow that identifies the actual bottleneck before you touch any code
• A prompt for analyzing database query logs and catching N+1 patterns automatically
• A bundle analysis prompt that finds the largest dependencies and suggests tree-shaking opportunities
• A React rendering optimization prompt that identifies unnecessary re-renders and memoization opportunities
• A before/after benchmarking technique that proves your optimization actually worked

The Workflow

Step 1: Measure before optimizing

The cardinal rule of performance work: measure first. Use Ask mode to set up profiling so you have a baseline to compare against.

Tip

Copy-paste prompt — Profiling setup:

@src/app @src/api @package.json

Set up performance measurement for this application:

1. Backend: Add request timing middleware that logs method, path, duration, and database query count for every API request. Output as structured JSON to stdout.
2. Database: Enable Drizzle query logging that captures every SQL query with execution time. Group by request using a correlation ID.
3. Frontend: Add Web Vitals measurement (LCP, FID, CLS, TTFB, INP) using the web-vitals library. Log to console in development, POST to /api/metrics in production.
4. Bundle: Add @next/bundle-analyzer to the Next.js config. Add a script to package.json: “analyze”: “ANALYZE=true next build”.

Do not optimize anything yet. We are only measuring.

Run your application with profiling enabled. Load the pages that are slow. Collect at least 5 minutes of data or 100 requests, whichever is more.

Step 2: Identify the bottleneck

Feed the profiling data into Ask mode and let the AI find the pattern.

Tip

Copy-paste prompt — Bottleneck analysis:

Here is the request timing log from the last 100 requests to the billing dashboard API:

[paste the structured JSON logs]

Analyze this data and tell me:

1. What is the median and p95 response time?
2. Which endpoints are the slowest?
3. For the slowest endpoint: how many database queries does it execute per request?
4. Is there an N+1 pattern? (Same query executed repeatedly with different parameters)
5. What percentage of the total response time is spent in database queries vs. application code?
6. Are there any outlier requests that are dramatically slower? What do they have in common?

Rank the top 3 optimization opportunities by expected impact.

In most applications, one of these three is the bottleneck: N+1 database queries, missing indexes, or overly broad queries that fetch more data than needed. The AI will identify which one and point you to the specific code.

Step 3: Fix N+1 queries

N+1 queries are the most common backend performance problem. Instead of loading related data in a single query with a JOIN, the code loads the parent records and then runs a separate query for each child record.

@src/api/billing/usage.ts @src/db/schema.ts

This endpoint loads organization usage data with an N+1 pattern:
- First query: SELECT * FROM organizations WHERE plan = 'enterprise'
- Then for EACH org: SELECT SUM(amount) FROM usage WHERE org_id = ? AND month = ?

This executes 1 + N queries where N is the number of enterprise organizations (currently 340).

Rewrite this to use a single query with a JOIN and GROUP BY.
Requirements:
- The response format must stay exactly the same (don't break the frontend)
- Use Drizzle's query builder, not raw SQL
- Add an index on usage(org_id, month) if it doesn't already exist
- Log the query execution time before and after so I can verify the improvement

Step 4: Optimize the frontend bundle

For frontend performance, bundle size is often the biggest lever. A 500KB JavaScript bundle takes seconds to parse on a mid-range phone.

Tip

Copy-paste prompt — Bundle optimization:

@package.json @next.config.js

I ran the bundle analyzer and found these issues:

• Total client-side JS: 487KB gzipped
• lodash (full): 71KB (we use 3 functions)
• moment.js: 66KB (used for one date format call)
• chart.js: 52KB (only used on one page)
• Three date picker libraries (react-datepicker, react-day-picker, @mui/x-date-pickers): 94KB total

Optimize the bundle:

1. Replace lodash with lodash-es and import only the functions we use (tree-shakeable)
2. Replace moment.js with date-fns (tree-shakeable, 3KB for one format function)
3. Lazy-load chart.js using next/dynamic so it only loads on the analytics page
4. Remove the 2 unused date picker libraries (keep react-day-picker, remove the others)
5. Add the @next/bundle-analyzer check to our CI pipeline that fails if the bundle exceeds 300KB gzipped

Show me the expected bundle size reduction for each change.

Step 5: Fix React rendering performance

If the frontend is slow despite a reasonable bundle size, the problem is usually unnecessary re-renders. The React DevTools Profiler can show you which components re-render on every state change, but analyzing that output is tedious. Feed it to Cursor.

@src/components/billing-dashboard.tsx @src/components/usage-chart.tsx @src/hooks/use-billing-data.ts

The billing dashboard re-renders the entire page every time the usage chart tooltip
appears (mouse hover). The React Profiler shows these components re-rendering:
- BillingDashboard (40ms)
- UsageChart (25ms)
- InvoiceList (15ms) -- this one should NOT re-render on chart hover
- UsageSummary (10ms) -- this one should NOT re-render either

Fix the unnecessary re-renders:

1. Identify which state change is triggering the full re-render
2. Split the tooltip state so it only triggers re-render in UsageChart
3. Memoize InvoiceList and UsageSummary with React.memo (add proper comparison)
4. If the billing data hook is causing re-renders, stabilize its return value with useMemo
5. Do NOT memoize everything blindly -- only the components that are expensive to re-render

Explain your reasoning for each change. Wrong memoization is worse than no memoization.

Step 6: Verify with benchmarks

After optimization, prove the improvement with numbers. Do not just “feel like it’s faster.”

@src/api/billing/usage.ts @src/components/billing-dashboard.tsx

Create a before/after performance comparison:

Backend:
1. Run 100 requests against the billing endpoint
2. Report: median, p95, p99 latency
3. Report: database query count per request
4. Report: total database time per request

Frontend:
1. Run a Lighthouse performance audit on the billing dashboard
2. Report: LCP, TBT, CLS, Speed Index
3. Report: JavaScript bundle size
4. Report: number of render cycles on initial page load

Compare against the baseline measurements from Step 1.
Format as a table showing before, after, and percentage improvement.

When This Breaks

Premature optimization of non-bottlenecks. The AI will happily optimize anything you point it at, whether or not it matters. Always start with profiling data. If a function takes 2ms and the total request takes 2000ms, optimizing that function is a waste of time.

Memoization that makes things slower. React.memo, useMemo, and useCallback have overhead. If the component is cheap to re-render (simple JSX, no expensive calculations), adding memoization adds memory pressure and comparison cost for zero benefit. Only memoize components that are measurably expensive.

Database indexes that slow writes. Every index speeds up reads but slows writes. For a table that receives 10,000 writes per second (like a usage tracking table), adding 5 indexes means 5 additional B-tree insertions per write. Use Ask mode to analyze the read/write ratio before adding indexes.

Bundle splitting that increases total download size. Lazy-loading a component adds a new HTTP request and a separate chunk. If the component is small (under 10KB) and loaded on most page views, the overhead of the additional request exceeds the savings. Only split chunks that are large AND rarely loaded.

Optimized code that is harder to maintain. A hand-rolled SQL query with 4 subqueries and 3 CTEs might be faster than the ORM query, but if nobody on the team can understand or modify it, you have traded runtime performance for development velocity. Use the ORM by default and drop to raw SQL only for proven hot paths with measured performance requirements.

What’s Next

Security Audit After optimizing for speed, audit for security to ensure performance shortcuts did not introduce vulnerabilities.

Database Design Revisit your schema design with performance data to inform indexing and denormalization decisions.

Bug Hunting Performance changes can introduce subtle bugs -- use the debugging workflow to verify correctness.