I Spent 200 Hours Optimizing My Flutter App (Medium)
A practitioner post by Chirag Prajapati (a self-described Flutter specialist) on optimizing a Flutter app’s performance — the wiki’s first UI-performance source and first Flutter source. Partial ingest: the article is Medium member-only; even via the author’s free friend-link, only the intro and the first technique were recoverable — the remaining numbered sections are behind the paywall. So this captures the thesis and section 1, flagged.
The thesis (recovered)
The lesson isn’t how to optimize but what deserves attention. The author’s first mistake was optimizing everything — every rebuild, animation, network call, package, millisecond — before measuring whether a problem existed. His corrected rule: profile first, then fix real bottlenecks, not imagined ones. “You can’t improve what you haven’t measured.” An explicit warning against over-optimization — much of the 200 hours was wasted on things that didn’t move the needle.
Technique captured
- Reducing unnecessary widget rebuilds — called one of the biggest wins. The framing matters: rebuilds aren’t inherently bad, they’re how Flutter works (see flutter‘s reactive rebuild model). The optimization is cutting the unnecessary ones, not avoiding rebuilds. The later sections (implied by the intro’s list: animations, network calls, package weight) weren’t recoverable.
Tier & standing
T4 — a single practitioner’s Medium post, self-reported, no benchmark numbers in the recovered portion, and only partially readable. It’s useful as the spoke’s entry point into UI performance as a subject and as the anchor for the flutter node, not as a rigorous optimization reference. If a fuller, free performance source lands, deepen the rebuild/profiling substance there.