A Flutter app can have fast API calls, clean state management, and efficient Dart code but still suffer from stuttering animations or scrolling.
One possible reason is raster jank.
Raster jank happens when Flutter prepares a frame on time, but the rendering work required to turn that frame into pixels takes too long.
A simplified Flutter frame pipeline looks like this:
Dart / UI Work
↓
Build
↓
Layout
↓
Paint
↓
Scene
↓
Rasterization
↓
GPU
↓
Display
When the expensive part is near:
Paint
↓
Rasterization
↓
GPU
you need to investigate rendering rather than spending all your time optimizing API calls or state management.
This guide explains how to identify and fix raster jank in Flutter using practical techniques such as image optimization, repaint reduction, RepaintBoundary, blur optimization, clipping improvements, CustomPainter optimization, and Flutter DevTools.
What Is Raster Jank in Flutter?
Flutter needs to continuously produce frames while the user scrolls, navigates, or watches animations.
On a 60 Hz display, a new frame opportunity occurs approximately every:
16.67 ms
On a 120 Hz display, that interval is roughly:
8.33 ms
If rasterization takes too long, Flutter may miss the expected presentation time.
For example:
Frame 1
UI → 6 ms
Raster → 7 ms
may be fine.
However:
Frame 2
UI → 5 ms
Raster → 27 ms
shows that rendering is the likely bottleneck.
The user may experience:
Scrolling
↓
Smooth
↓
Stutter
↓
Smooth
That is the type of problem we want to investigate.
UI Jank vs Raster Jank
Before fixing raster jank, make sure rasterization is actually the problem.
Consider:
UI: 30 ms
Raster: 6 ms
This points more strongly toward UI-side work.
You might investigate:
- Widget rebuilding
- Layout
- Large synchronous computations
- JSON processing
- State updates
Now consider:
UI: 6 ms
Raster: 29 ms
Here the raster side deserves attention.
Common suspects include:
- Oversized images
- Blur
- Backdrop filters
- Complex shadows
- Expensive painting
- Excessive clipping
- Unnecessary repaints
- Complex visual effects
Optimizing the correct side of the frame pipeline is essential.
First: Measure Raster Performance
Do not start by randomly removing widgets.
Run the application in profile mode:
flutter run --profile
Then open Flutter DevTools and use the Performance tooling.
Reproduce the exact problem:
Start Recording
↓
Open Problem Screen
↓
Scroll / Animate
↓
Stop Recording
↓
Inspect Slow Frames
Look at the UI and raster timings of problematic frames.
If raster time is consistently high, continue investigating rendering.
Why You Should Not Profile Mainly in Debug Mode
Debug builds contain development overhead.
Therefore:
Debug Mode
→ Development
Profile Mode
→ Performance investigation
Release Mode
→ Production
A screen that appears slow in debug mode may behave differently in a production-oriented build.
Use profile mode when diagnosing Flutter rendering performance.
1. Optimize Oversized Images
Images are one of the first things worth investigating when raster time becomes high.
Suppose your server returns:
4000 × 4000 image
while the application displays it at:
150 × 150
The visible widget may be small, but working with an unnecessarily large decoded image can consume much more memory and rendering resources than required.
Conceptually:
Large Source Image
↓
Decode Large Image
↓
Display Tiny Thumbnail
This is wasteful.
Request Smaller Images from the Server
The strongest solution is often to request images close to the required display size.
Instead of:
https://example.com/product-original.jpg
your image service or CDN might provide a resized variant:
Product Image
↓
CDN Resize
↓
300 × 300
↓
Flutter
This can reduce:
- Network transfer
- Decode work
- Memory usage
- Image processing overhead
For product grids and lists, use thumbnail-sized assets whenever possible.
Use cacheWidth and cacheHeight
When appropriate, Flutter can receive decode-size hints.
For example:
Image.network(
imageUrl,
width: 120,
height: 120,
fit: BoxFit.cover,
cacheWidth: 300,
)
or:
Image.asset(
'assets/images/product.webp',
cacheWidth: 300,
)
The exact value should account for the actual rendered size and device pixel ratio.
Do not blindly use:
Widget width = 100
cacheWidth = 100
on every device.
A higher-density screen may need more physical pixels for a sharp image.
Understand Image Memory
A compressed image file might only be a few hundred kilobytes on disk.
However, decoded image memory is a different matter.
A rough RGBA memory estimate is:
width × height × 4 bytes
For a:
4000 × 4000
image:
4000 × 4000 × 4
= 64,000,000 bytes
which is roughly 64 MB in decimal terms for one decoded image.
Several unnecessarily large images can quickly create substantial memory pressure.
That is why optimizing image dimensions matters even when the compressed file itself looks small.
2. Use Modern, Appropriately Compressed Assets
Where your platform and asset pipeline support them, efficient image formats can reduce download and storage size.
For many Flutter projects, WebP is a practical option.
For example:
product_image.png
↓
product_image.webp
However, compression format alone does not solve oversized decoding.
A:
4000 × 4000 WebP
is still a 4000 × 4000 image after decoding.
Therefore, optimize both:
File Compression
+
Image Dimensions
3. Avoid Expensive Blur Everywhere
Blur effects can make interfaces attractive, but they may increase rendering work.
For example:
BackdropFilter(
filter: ImageFilter.blur(
sigmaX: 20,
sigmaY: 20,
),
child: Container(
color: Colors.white.withValues(
alpha: 0.1,
),
),
)
A single small blur may be fine.
A large animated blur across most of the screen can be much more demanding.
Problematic Pattern
Imagine a product list:
ListView
↓
Blur Card
↓
Blur Card
↓
Blur Card
↓
Blur Card
↓
Blur Card
During scrolling, many expensive visual regions may need to be rendered.
If profiling identifies them as a bottleneck, simplify the design.
Reduce Blur Area
Instead of:
Full Screen Blur
consider:
Small Header Blur
or another smaller region.
Reducing the number of pixels affected by an expensive effect can make a significant difference.
Reduce Blur Intensity
Instead of:
ImageFilter.blur(
sigmaX: 30,
sigmaY: 30,
)
try a smaller value if the design still works:
ImageFilter.blur(
sigmaX: 8,
sigmaY: 8,
)
Do not choose a particular number solely for performance.
Profile the actual interface and find a balance between visual quality and rendering cost.
Avoid Animating Large Blur Regions
This can be especially expensive:
Animation
↓
Large BackdropFilter
↓
Re-render Every Frame
If an animation lasts:
500 ms
Flutter needs to render many intermediate frames.
Expensive full-screen effects can make those frames difficult to produce smoothly.
4. Simplify Complex Shadows
Consider:
Container(
decoration: BoxDecoration(
borderRadius:
BorderRadius.circular(30),
boxShadow: [
BoxShadow(
blurRadius: 40,
spreadRadius: 15,
offset: const Offset(0, 15),
),
],
),
)
Now repeat it throughout a scrolling list.
Card → Heavy Shadow
Card → Heavy Shadow
Card → Heavy Shadow
Card → Heavy Shadow
The visual effect can become expensive.
If raster profiling points to these cards, consider reducing:
Blur radius
Spread radius
Number of shadows
Number of shadowed elements
or using a simpler visual design.
5. Avoid Unnecessary Clipping
Flutter provides several clipping widgets:
ClipRect
ClipRRect
ClipOval
ClipPath
Clipping is useful when the design genuinely requires it.
For example:
ClipRRect(
borderRadius:
BorderRadius.circular(16),
child: Image.network(imageUrl),
)
may be perfectly reasonable.
Problems appear when clipping is added throughout a complex screen without a real visual need.
Avoid Clipping by Habit
Do not write:
ClipRRect(
borderRadius:
BorderRadius.circular(0),
child: SomeWidget(),
)
when nothing needs clipping.
Every additional rendering operation should have a reason.
This becomes particularly important inside:
Long Lists
Animations
Complex Grids
Scrolling Dashboards
6. Watch for Expensive Layer Operations
Some visual effects may cause Flutter to create intermediate rendering layers.
Conceptually:
Widgets
↓
Offscreen Layer
↓
Apply Effect
↓
Composite Result
These operations can become expensive when used over large or frequently changing areas.
Effects worth investigating include:
- Certain opacity compositions
- Backdrop filters
- Complex clipping
- Blend effects
- Some shader effects
- Complex overlapping transparency
This does not mean these APIs are inherently bad.
It means they should be investigated when profiling shows high raster cost.
7. Optimize Opacity Animations
Suppose you animate a large subtree:
Opacity(
opacity: opacity,
child: VeryLargeWidgetTree(),
)
Depending on the rendering situation, transparency can require additional compositing work.
For standard fade transitions, Flutter provides animation-specific widgets such as:
FadeTransition(
opacity: animation,
child: const MyWidget(),
)
The important point is not simply to replace every Opacity widget.
Instead:
Profile
↓
Identify expensive effect
↓
Use the most suitable rendering approach
8. Optimize CustomPainter
Custom painting can produce extremely efficient interfaces when implemented correctly.
It can also become expensive.
Consider:
class GraphPainter
extends CustomPainter {
@override
void paint(
Canvas canvas,
Size size,
) {
// Hundreds or thousands
// of drawing operations.
}
@override
bool shouldRepaint(
covariant GraphPainter oldDelegate,
) {
return true;
}
}
The biggest issue may be:
return true;
This tells Flutter that repainting is always required when comparing painter delegates.
Implement shouldRepaint() Properly
Instead:
class GraphPainter
extends CustomPainter {
final List<double> points;
GraphPainter(this.points);
@override
void paint(
Canvas canvas,
Size size,
) {
// Draw graph.
}
@override
bool shouldRepaint(
covariant GraphPainter oldDelegate,
) {
return oldDelegate.points != points;
}
}
Now unchanged data does not automatically request unnecessary repainting through the painter comparison.
For more advanced models, use appropriate equality rather than blindly comparing mutable list references.
Reduce Drawing Operations
Suppose your painter performs:
10,000 individual draw operations
on every animation frame.
Investigate whether you can:
- Simplify paths
- Cache static calculations
- Reduce unnecessary drawing
- Precompute geometry
- Separate static and dynamic sections
- Draw only what is visible
A chart containing thousands of points does not necessarily need every detail rendered at every zoom level.
9. Use RepaintBoundary Selectively
RepaintBoundary can isolate a subtree into a separate repaint boundary.
Example:
RepaintBoundary(
child: ExpensiveChart(),
)
Suppose:
Parent Animation
↓
Parent Repaints
↓
Static Chart Repaints Too
If the chart itself is not changing, unnecessary repainting can be wasteful.
A useful boundary can create:
Parent Repaint
↓
Parent Changes
Chart Boundary
↓
Chart Does Not Need Repaint
When RepaintBoundary Helps
It can be useful when:
Expensive Widget
+
Widget Rarely Changes
+
Parent Frequently Repaints
Examples may include:
- Charts
- Complex illustrations
- Static custom painting
- QR codes
- Signatures
- Expensive decorative widgets
Do Not Add RepaintBoundary Everywhere
This is a common optimization mistake:
RepaintBoundary(
child: RepaintBoundary(
child: RepaintBoundary(
child: Widget(),
),
),
)
Additional boundaries can create additional layers and memory overhead.
Use them after identifying unnecessary repaint behavior.
10. Separate Static and Animated Content
Suppose you have:
Complex Background
+
Animated Indicator
and both repaint together.
You may be able to separate them:
Static Background
↓
RepaintBoundary
Animated Indicator
↓
Repaints Independently
This prevents expensive static artwork from being redrawn simply because a small animation changes.
11. Avoid Repainting Entire Screens
Consider:
AnimatedBuilder(
animation: animation,
builder: (
context,
child,
) {
return HugeScreen(
animation.value,
);
},
)
If only one small icon needs animation, rebuilding/repainting a much larger area can be unnecessary.
Instead, isolate the animation:
Screen
├── Static Header
├── Static Content
└── Animated Icon
Keep frequently changing visual areas as small as practical.
12. Use child in AnimatedBuilder
A useful pattern is:
AnimatedBuilder(
animation: animation,
child: const ExpensiveStaticWidget(),
builder: (
context,
child,
) {
return Transform.scale(
scale: animation.value,
child: child,
);
},
)
The static child does not need to be reconstructed inside the builder on every animation tick.
This primarily helps UI/build work, but keeping animation boundaries clean can also make the overall rendering architecture easier to optimize.
13. Optimize Long Scrolling Lists
Raster jank frequently becomes noticeable during scrolling.
Use lazy construction:
ListView.builder(
itemCount: products.length,
itemBuilder: (
context,
index,
) {
return ProductCard(
product: products[index],
);
},
)
instead of:
SingleChildScrollView(
child: Column(
children: products
.map(
(product) =>
ProductCard(product: product),
)
.toList(),
),
)
for very large datasets.
Lazy construction mainly reduces UI and memory pressure, but it also prevents the app from managing an unnecessarily huge visual tree.
14. Optimize Each List Item
Using ListView.builder is not enough if each card contains:
Huge Image
+
BackdropFilter
+
Multiple Shadows
+
ClipPath
+
Opacity
+
Complex CustomPainter
A list can be lazy and still render poorly.
Inspect the design of each visible item.
A simpler card might use:
Proper Thumbnail
+
Simple Border Radius
+
Light Shadow
+
Text
instead of several expensive layered effects.
15. Use itemExtent When Appropriate
If every list item has a fixed height, you may be able to provide that information.
For example:
ListView.builder(
itemExtent: 80,
itemCount: items.length,
itemBuilder: (
context,
index,
) {
return ItemTile(
item: items[index],
);
},
)
Knowing item dimensions can help Flutter perform certain scrolling/layout calculations more efficiently.
This is more closely related to UI/layout performance than rasterization, but smooth scrolling often requires optimizing both sides.
16. Reduce Overdraw
Overdraw happens when the same screen pixels are painted multiple times because layers overlap.
Conceptually:
Background
↓
Large Container
↓
Another Opaque Container
↓
Image
↓
Overlay
↓
Effect
Some overlapping is normal.
However, excessive visual layering can create unnecessary rendering work.
Simplify layouts where possible.
17. Avoid Invisible Expensive Widgets
A widget may be visually hidden but still exist in the tree depending on how you hide it.
For example, simply making something transparent is not always equivalent to removing it from rendering/layout work.
If a complex component is genuinely unnecessary in the current state, consider whether it should remain mounted at all.
Choose visibility techniques according to whether you need to preserve:
State
Layout
Animation
Semantics
rather than automatically setting opacity to zero.
18. Optimize Page Transitions
Raster jank may appear only during navigation.
For example:
Home
↓
Complex Blur Transition
↓
Product Screen
A custom transition involving:
Blur
+
Scale
+
Opacity
+
Large Image
+
Shadow
can be much more expensive than a simpler transition.
Start with Flutter’s optimized transition primitives when possible:
FadeTransition(
opacity: animation,
child: child,
)
or:
SlideTransition(
position: animation,
child: child,
)
Then profile custom visual effects before shipping them widely.
19. Optimize Hero Animations
Hero animations are useful for smooth transitions between screens.
Example:
Hero(
tag: product.id,
child: Image.network(
product.image,
),
)
However, animating a very large image or an expensive subtree can increase rendering cost.
Keep Hero content reasonably lightweight.
A useful structure is:
Hero
↓
Optimized Image
rather than:
Hero
↓
Blur
↓
Shadow
↓
Huge Image
↓
Complex Overlay
unless profiling confirms the more complex version performs well.
20. Cache Network Images Correctly
Repeated image downloads and decoding can make image-heavy screens feel unstable.
Use an appropriate caching strategy so that the same image does not need to be repeatedly fetched unnecessarily.
Flutter already maintains an in-memory image cache for decoded image resources in common image-provider flows.
For more advanced disk/network caching requirements, you may use a dedicated image caching solution.
However, caching does not replace image resizing.
You still want:
Correct Size
+
Efficient Format
+
Caching
rather than:
Huge Image
+
Cache Huge Image
21. Precache Important Images
Suppose a screen transition immediately needs a hero image.
You can sometimes preload it:
await precacheImage(
NetworkImage(imageUrl),
context,
);
Then navigate.
This can reduce visible loading during the transition.
However, do not precache hundreds of large images.
Use it for a small number of assets that are highly likely to be needed soon.
22. Watch Memory Pressure
Raster performance and memory usage can interact.
Suppose your application keeps many huge decoded images alive:
Image 1 → 40 MB
Image 2 → 35 MB
Image 3 → 50 MB
Image 4 → 45 MB
Memory pressure can make the overall experience unstable.
Therefore, image optimization should consider:
Network Size
Decoded Size
Cache Size
Number of Images
Widget Lifetime
not merely download speed.
23. Reduce Unnecessary Repaints from State Changes
Imagine:
cartCount changes
↓
Entire Product Screen Repaints
↓
Images
Cards
Shadows
Charts
even though only the cart badge changed.
Keep state updates and visual dependencies focused.
With GetX, for example:
Obx(
() => CartBadge(
count:
controller.cartCount.value,
),
)
is preferable to wrapping a huge screen in one reactive region when only the badge depends on that value.
24. Use DevTools to Identify Repaint Problems
Do not guess whether a widget is repainting too often.
Flutter’s development tooling provides options that can help visualize rendering and repaint activity.
A useful investigation might reveal:
Scrolling
↓
Small Animation Changes
↓
Huge Static Widget Repaints
Now you have a concrete optimization target.
Possible solutions include:
RepaintBoundary
Smaller animation area
Separate static content
Reduce visual complexity
25. Profile Expensive Frames Individually
Suppose you see:
Frame 142 → Raster 31 ms
Inspect what happened during that frame.
Ask:
- Did a new large image appear?
- Did a blur start?
- Was a route transition active?
- Did a custom painter redraw?
- Did a list of shadowed cards move?
- Did a new layer become visible?
- Was a Hero animation running?
Performance work becomes much easier when you connect a slow frame with a specific visual event.
26. Raster Jank During First Animation
Sometimes an animation stutters the first time but becomes smoother afterward.
Rendering pipelines can have first-use costs related to preparing graphics resources or rendering operations.
Historically, shader compilation was a major topic in Flutter performance optimization.
Modern Flutter uses Impeller across supported configurations to make rendering more predictable and reduce several historical shader-related problems.
Still, performance can vary based on:
Flutter version
Platform
Device GPU
Rendering backend
Visual effect
Test the actual application on representative devices instead of assuming every rendering problem has the same cause.
27. Keep Flutter Updated
Rendering infrastructure continues to evolve.
A newer stable Flutter release may include improvements to:
Rendering
Impeller
Image handling
Engine performance
Platform integration
Before spending days building workarounds for an unusual rendering issue, check whether you are using an appropriately current stable Flutter version for your project.
Always test upgrades before releasing them to production.
28. Test on Physical Devices
Raster performance depends heavily on GPU capabilities.
A powerful development machine may hide problems that appear on lower-end phones.
Test on:
Low-end Android
Mid-range Android
High-end Android
Target iPhone
High-refresh-rate device
when those device categories represent your users.
29. Test Different Screen Refresh Rates
A screen may run acceptably at 60 Hz but struggle to consistently take advantage of a 120 Hz display.
Approximate frame intervals are:
60 Hz
→ 16.67 ms
120 Hz
→ 8.33 ms
Higher refresh rates provide less time between display refresh opportunities.
Therefore, performance testing should include relevant high-refresh-rate hardware when your target users use such devices.
30. Do Not Optimize Only the Average Frame
Suppose:
Average Raster:
6 ms
That sounds good.
However:
Frame 1 → 5 ms
Frame 2 → 6 ms
Frame 3 → 7 ms
Frame 4 → 42 ms
Frame 5 → 5 ms
Frame 4 can still produce a visible stutter.
Look for:
Slow Frames
Worst Frames
Repeated Spikes
Transition Spikes
Scroll Spikes
rather than relying only on an average.
Example: Fixing a Janky Product Card
Suppose your original card looks like:
ClipRRect(
borderRadius:
BorderRadius.circular(30),
child: BackdropFilter(
filter: ImageFilter.blur(
sigmaX: 20,
sigmaY: 20,
),
child: Container(
decoration: BoxDecoration(
boxShadow: [
BoxShadow(
blurRadius: 40,
spreadRadius: 15,
),
],
),
child: Image.network(
product.imageUrl,
),
),
),
)
Now imagine dozens of these cards.
Potential problems include:
Large image
+
Blur
+
Large shadow
+
Clipping
+
Repeated scrolling
A simpler version could be:
Container(
decoration: BoxDecoration(
borderRadius:
BorderRadius.circular(16),
boxShadow: const [
BoxShadow(
blurRadius: 8,
offset: Offset(0, 3),
),
],
),
clipBehavior: Clip.antiAlias,
child: Image.network(
product.thumbnailUrl,
fit: BoxFit.cover,
cacheWidth: 400,
),
)
The exact implementation should match your design and profiling results.
The important improvement is reducing unnecessary rendering work rather than applying arbitrary “performance widgets.”
Example: Isolating an Expensive Chart
Suppose:
Column(
children: [
AnimatedHeader(),
ComplexChart(),
],
)
The header changes frequently.
If profiling shows the chart is repainting unnecessarily, consider:
Column(
children: [
AnimatedHeader(),
RepaintBoundary(
child: ComplexChart(),
),
],
)
Now the expensive chart has a clearer repaint boundary.
Again, verify the improvement using profiling tools.
Example: Optimizing a CustomPainter
Before:
class SignaturePainter
extends CustomPainter {
final List<Offset> points;
SignaturePainter(this.points);
@override
void paint(
Canvas canvas,
Size size,
) {
for (int i = 0;
i < points.length - 1;
i++) {
canvas.drawLine(
points[i],
points[i + 1],
paint,
);
}
}
@override
bool shouldRepaint(
covariant SignaturePainter oldDelegate,
) {
return true;
}
}
If the points have not changed, repainting may be unnecessary.
Improve the decision:
@override
bool shouldRepaint(
covariant SignaturePainter oldDelegate,
) {
return oldDelegate.points != points;
}
For mutable collections, design equality/change tracking carefully so Flutter can reliably determine when painting is actually necessary.
Example: Optimizing Image Lists
Instead of loading full-resolution assets:
Image.network(
product.originalImage,
)
use a thumbnail URL where available:
Image.network(
product.thumbnailImage,
width: 120,
height: 120,
fit: BoxFit.cover,
cacheWidth: 300,
)
Architecture:
Original Image
4000 × 4000
↓
Image Server / CDN
↓
Thumbnail
300 × 300
↓
Flutter List
This is much more scalable for image-heavy lists.
Raster Jank Checklist
When DevTools indicates high raster time, inspect these areas:
- Large network images
- Oversized decoded images
- Large asset images
- Repeated blur
BackdropFilter- Complex shadows
- Large shadow blur radii
- Excessive clipping
- Complex
ClipPath CustomPaintershouldRepaint()- Repeated repaints
- Large opacity effects
- Layer-heavy compositions
- Hero animations
- Complex route transitions
- Large animated regions
- Overdraw
- Expensive list-item designs
Do not change all of them at once.
Find the expensive part first.
Practical Raster Optimization Workflow
A reliable workflow is:
App Feels Janky
↓
Run Profile Mode
↓
Record Performance
↓
Find Slow Frame
↓
Check UI vs Raster
↓
Raster Is High
↓
Inspect Visual Work
↓
Identify Specific Bottleneck
↓
Optimize
↓
Profile Again
For example:
Raster = 32 ms
↓
Inspect screen
↓
Large BackdropFilter found
↓
Reduce blur area
↓
Profile again
↓
Raster = 10 ms
Now you have evidence that the optimization helped.
What Not to Do
Do not immediately:
Add const everywhere
Add RepaintBoundary everywhere
Replace every Container
Remove every animation
Change state-management package
Rewrite entire screen
Those changes may have little relationship to rasterization.
Instead:
Measure
↓
Locate
↓
Understand
↓
Optimize
↓
Measure Again
Raster Optimization Priority
When raster time is high, a useful investigation order is:
1. Images
↓
2. Blur / BackdropFilter
↓
3. Shadows
↓
4. Repaints
↓
5. CustomPainter
↓
6. Clipping
↓
7. Opacity / Layers
↓
8. Complex animations
↓
9. Overdraw
↓
10. Device-specific rendering
This is not a universal ranking, but it provides a practical starting point for many visually complex Flutter screens.
UI Optimization vs Raster Optimization
Keep the distinction clear.
If you have:
UI = 30 ms
Raster = 6 ms
focus on:
Dart
Build
Layout
State
Parsing
Computation
If you have:
UI = 6 ms
Raster = 30 ms
focus on:
Images
Painting
Effects
Layers
Blur
Shadows
Clipping
Repaints
If both are high:
UI = 28 ms
Raster = 26 ms
you need to optimize both parts of the frame.
Best Practices to Prevent Raster Jank
For smoother Flutter rendering:
- Profile in profile mode before optimizing.
- Inspect UI and raster frame timings separately.
- Use appropriately sized images.
- Request thumbnails from the backend/CDN.
- Use decode-size hints such as
cacheWidthwhen appropriate. - Avoid unnecessary full-screen blur.
- Keep repeated shadows reasonably simple.
- Avoid unnecessary clipping.
- Optimize
CustomPainterandshouldRepaint(). - Isolate expensive static painting with
RepaintBoundarywhen profiling justifies it. - Keep animated regions as small as practical.
- Avoid unnecessary layer-heavy visual effects.
- Optimize list items individually, not only the list itself.
- Use lazy scrolling widgets for large collections.
- Precache only important upcoming images.
- Monitor decoded-image memory.
- Test transitions and Hero animations.
- Test on physical devices.
- Include lower-end hardware in performance testing.
- Measure again after every significant optimization.
Final Thoughts
Fixing raster jank in Flutter is primarily about understanding what the rendering pipeline is doing.
The wrong approach is:
Scrolling is slow
↓
Change random Dart code
↓
Add const everywhere
↓
Add RepaintBoundary everywhere
↓
Hope it becomes faster
A better process is:
Raster Jank
↓
Flutter DevTools
↓
Find Slow Raster Frame
↓
Identify Expensive Visual Work
↓
Images / Blur / Shadows / Paint / Layers
↓
Optimize Specific Bottleneck
↓
Profile Again
For image-heavy screens:
Large Images
↓
Resize / Thumbnail
↓
Decode at Suitable Size
↓
Cache Appropriately
For effect-heavy interfaces:
Blur + Shadows + Clipping
↓
Reduce Visual Complexity
↓
Reduce Affected Area
For repaint-heavy screens:
Frequent Repaint
↓
Find Repaint Source
↓
Separate Static/Dynamic Content
↓
RepaintBoundary When Useful
For custom graphics:
CustomPainter
↓
Reduce Drawing Work
↓
Correct shouldRepaint()
↓
Avoid Unnecessary Repainting
Most importantly, do not assume every Flutter performance issue is raster jank. Confirm it with profiling first.
Once the raster side is identified as the bottleneck, focus on the pixels Flutter has to produce: image dimensions, painting complexity, blur, shadows, clipping, layers, repaints, and animations.
That measurement-first approach is far more effective than applying generic Flutter performance tips to every screen.
