Speedclean

/speedclean

Use this for targeted performance cleanup in C:\Users\bradl\Documents\Codex\Det 430 App 2.0\det430-app-2.

Workflow

1. Measure before editing.

   • Use a real browser timing pass against http://localhost:3000.
   • Warm routes once, then measure the second pass.
   • Compare route timings with the Next dev log at %TEMP%\det430-next-dev.log.

2. Identify the delay class.

   • If next.js time is high, suspect dev compile/cache churn.
   • If proxy.ts time is high, inspect middleware/auth work.
   • If application-code time is high, inspect server loaders and Supabase waterfalls.
   • If the UI appears dead even when total time is unavoidable, add or improve route loading states.

3. Prefer safe server-data fixes.

   • Cache repeated reference reads with React cache() when they are stable within a server render.
   • Reuse shared loaders for active flights, user positions, and term memberships.
   • Parallelize independent Supabase reads with Promise.all.
   • Short-timeout nice-to-have dashboard data such as weather, banners, and small optional summaries.
   • Avoid schema, RLS, auth, or route architecture changes unless the user specifically asks.

4. Preserve product behavior.

   • Do not remove feature data to make a page look faster.
   • Do not hide errors by swallowing them, except for explicitly non-critical optional widgets with a visible fallback.
   • Do not change permissions, protected data handling, or report behavior during a speed pass.
   • Do not degrade the user experience to improve timing numbers. Keep the app complete, readable, trustworthy, and useful.
   • Do not remove helpful context, visual polish, navigation clarity, safety reminders, or commander/cadre-ready information unless the user explicitly approves that tradeoff.
   • Prefer staged loading, prioritization, caching, and render isolation over stripping the interface down.

5. Check UI responsiveness and render hygiene.

   • Treat an unresponsive render as a product bug, not just a performance annoyance.
   • Protect perceived quality: performance changes should make the app feel faster and better, not bare or unfinished.
   • Do not convert server components to client components unless actual browser-side interaction requires it.
   • Keep client components small and isolated around the interaction, such as tabs, toggles, charts, or form controls.
   • Remove unused imports, abandoned components, stale UI branches, duplicate helper functions, and leftover styling after redesigns.
   • Consolidate repeated one-off UI patterns into existing components when it reduces real duplication without changing behavior.
   • Avoid adding heavy libraries, large assets, or broad client-side state for small UI effects.
   • Check browser console warnings/errors, hydration issues, excessive rerenders, and slow click-to-response interactions.
   • For long lists, dense tables, feeds, and leaderboards, look for pagination, filtering, scoped rendering, or virtualization opportunities.
   • Keep images optimized, remote image domains intentional, and non-critical media out of the critical render path.
   • Prefer partial rendering, streaming-friendly boundaries, skeletons, and useful loading states so the app never feels frozen during slow data work.

6. Validate.

   • Use npm.cmd and npx.cmd on this Windows machine.
   • Run npm.cmd run typecheck, npm.cmd run lint, npm.cmd test, and npm.cmd run build.
   • Re-run the browser timing pass and summarize before/after numbers.
   • Include at least one browser interaction check for affected UI controls when frontend responsiveness was changed.

Known Good Pattern From May 12 2026

• Added shared cached reference loaders for active flights, user positions, and term memberships.
• Wired those loaders into dashboard-fed features: attendance, PFA, calendar, reports, WK, announcements, volunteer, weekly products, cadet profiles, and auth.
• Reduced dashboard weather blocking from 8 seconds to 1.2 seconds.
• Made announcement banner and volunteer summary non-blocking on the dashboard.
• Added a route loading state under src/app/(dashboard)/loading.tsx.
• Warmed local route timings improved from roughly 5-10 seconds to mostly 2.3-3.8 seconds, with dashboard/reports still the next best targets for summary-query work.

Next Escalation

If route timings remain above the user's tolerance after duplicate queries are removed, create lightweight dashboard/report summary queries or RPCs so the dashboard does not load full feature-page datasets just to show highlights.