# Speedclean

> Use when the user says /speedclean, speedclean, or asks for a speed, responsiveness, loading, performance, or page-transition cleanup in the Det 430 App 2.0 Next.js/Supabase app. Focus on measuring real route timing, reducing duplicate server data work, preserving behavior, and validating with lint, typecheck, tests, build, and browser timing evidence.

- Skill: `oklahomie-580/speedclean` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add oklahomie-580/speedclean`
- Raw SKILL.md: https://api.skillmd.com/api/skills/oklahomie-580/speedclean/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: Oklahomie-580 (https://skillmd.com/u/oklahomie-580)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/oklahomie-580/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.