Why should you use const widgets in Flutter?
Short Answer
A `const` widget is created once at compile time and reused across rebuilds — Flutter can skip rebuilding it entirely because it knows the instance can never change.
When a widget's constructor and all its arguments are compile-time constants, marking it `const` tells Dart to create exactly one instance, shared everywhere it's used. During a rebuild, Flutter compares the new widget instance to the old one; if they're `==` (which `const` instances are, by identity), it skips rebuilding that subtree entirely instead of diffing it.
This matters most for static decoration — icons, dividers, fixed-text labels — nested deep inside frequently-rebuilding parents. It costs nothing to add and the Dart analyzer (`prefer_const_constructors` lint) will even suggest it for you.
Code Example
// Rebuilt fresh every time the parent rebuilds: Icon(Icons.star, color: Colors.amber) // Created once, reused forever: const Icon(Icons.star, color: Colors.amber)
Common Mistakes
- ×Not marking a widget `const` just because it "looks dynamic" when its actual arguments are all compile-time constants.
- ×Wrapping a `const`-eligible subtree in a non-const parent and assuming the optimization still applies — the analyzer will flag if it doesn't propagate.
Related Questions
How do you avoid unnecessary widget rebuilds in Flutter?
Scope state narrowly (so only the widgets that depend on it rebuild), use `const` constructors wherever possible, and split large build methods into smaller widgets so a change in one part doesn't force the whole tree to re-render.
Describe Flutter's architecture — how does a widget end up as pixels on screen?
Flutter has three parallel trees — Widget, Element, and RenderObject — where widgets are immutable configuration, elements are the mutable instances that manage the tree, and render objects handle layout, painting, and hit-testing.