emmi-efficiency-dev

name	emmi-efficiency-dev
description	Emmi performance: easy wins applied by default, production-ready hardening on ship, deep work on request. No hard budgets — optimise what gives the best result.

Efficiency dev

When to do what

Performance work has three tiers. Know which tier applies before starting.

Tier	When	What
Easy wins	Always — baked into normal development	Low-effort, high-impact habits applied by default
Production-ready hardening	When making something production-ready	Bundle analysis, query review, image audit
Deep work	On explicit request or when something is measurably slow	Caching strategy, Redis, query optimisation, profiling

Never spend time on deep optimisation work unless asked or unless a specific slow point has been identified and measured. Optimise what gives the best result — not what is theoretically optimal.

---

Tier 1 — Easy wins (always apply)

These cost little and should be in place from the start.

Next.js / web

• Use next/image for every image. Never a raw <img> tag. Set width, height, priority on above-the-fold images.
• Dynamic import (next/dynamic) for heavy components not needed on initial load.
• Keep client components small. Push as much as possible to RSCs — they don't ship JS to the browser.
• loading="lazy" on all below-the-fold images not using next/image.
• Avoid importing large libraries client-side (date libraries, charting, etc.) without checking the bundle cost first.

Database (Prisma)

• Add indexes on every foreign key and every field used in a where clause at schema design time — not after queries get slow.
• Use select to fetch only the fields needed. Never return full models to the client when a subset will do.
• Avoid N+1 — use include or batch queries. If a loop calls db.* on each iteration, that is an N+1.

Mobile (Expo)

• Hermes engine always enabled.
• FlashList over FlatList for any list with more than ~20 items.
• expo-image over the built-in Image for automatic caching and performance.
• Never run heavy computation on the JS thread — offload with InteractionManager.runAfterInteractions or a worker if needed.

---

Tier 2 — Production-ready hardening (before ship)

Run these when preparing a feature or app for production.

Bundle analysis

ANALYZE=true pnpm build

Install @next/bundle-analyzer and configure in next.config.ts. Look for:

• Unexpectedly large chunks.
• Duplicate packages (two versions of the same lib).
• Client-side imports that should be server-only.
• Libraries that can be dynamically imported.

Image audit

• All images use next/image with correct sizes prop for responsive images.
• No uncompressed PNGs where WebP/AVIF would work.
• Hero and above-the-fold images have priority={true}.

Query review

• Run prisma studio or check Railway logs for slow queries.
• Confirm all where fields have indexes.
• Check for missing select — procedures returning more data than the client uses.

Core Web Vitals check

• Run Lighthouse or PageSpeed Insights on the production URL.
• LCP: largest image or text block loads fast. Usually fixed by priority on hero image and fast TTFB.
• CLS: no layout shifts. Usually caused by images without dimensions or fonts swapping.
• INP: interactions feel instant. Usually caused by heavy JS on the main thread.

Mobile startup

• Profile cold start time with Flipper or expo-dev-client.
• Defer anything not needed in the first 2 seconds.

---

Tier 3 — Deep work (on request or measured bottleneck)

Only do this work when asked or when a specific, measured problem exists.

Caching Choose the strategy that gives the best result for the specific data:

Data type	Strategy
Static or rarely changing	Next.js fetch cache or ISR with long revalidation
User-specific, frequently read	TanStack Query client cache with appropriate staleTime
Shared, frequently read, expensive to compute	Redis with explicit TTL and invalidation
Real-time	No cache — subscribe or poll

Redis is added per project when needed. Not a default. Common use cases: rate limiting, session store, expensive aggregations, pub/sub.

Database

• Run EXPLAIN ANALYZE on slow queries.
• Consider read replicas for read-heavy workloads.
• Pagination: cursor-based for large datasets, offset for small ones.
• Connection pooling: PgBouncer or Railway's built-in pooling for high-concurrency.

Bundle deep dive

• Tree-shake or replace libraries with lighter alternatives.
• Route-level code splitting — each page loads only what it needs.
• Move constants and config to server-side so they don't ship to the client.

---

Output

Always report before/after for any optimisation work:

Before: [metric and value]
After:  [metric and value]
Change: [what was done]
Risk:   [any regression risk or caveats]

No metric, no evidence it helped.