How to Find and Fix Jank in Flutter

A Flutter application may work correctly but still feel slow. Scrolling can stutter, animations may skip frames, or the UI might freeze briefly while loading data.

This problem is commonly called jank.

Jank happens when Flutter cannot produce a frame within the available frame time. Instead of guessing which widget is responsible, Flutter developers should profile the application, identify expensive frames, find the operation causing them, and then optimize that specific area.

This guide explains how to find and fix jank in Flutter using practical techniques and Flutter DevTools.

What Is Jank in Flutter?

Flutter renders the UI as a sequence of frames.

For a display running at 60 Hz, a new frame is expected roughly every:

16.67 milliseconds

For a 120 Hz display, the available time is roughly:

8.33 milliseconds

If the application takes longer than its available frame budget, a frame may arrive late.

Users experience this as:

• Stuttering
• Laggy scrolling
• Choppy animations
• Delayed interactions
• Brief UI freezes
• Dropped or missed frames

That visible lack of smoothness is what developers commonly describe as jank.

Why Does Flutter Jank Happen?

Jank is not caused by one specific Flutter problem.

Common causes include:

• Expensive widget rebuilds
• Large synchronous calculations
• Parsing large JSON responses
• Rendering huge lists
• Oversized images
• Complex layouts
• Expensive clipping
• Excessive opacity
• Blur effects
• Heavy shadows
• Poorly optimized animations
• Too much work during scrolling
• CPU-intensive operations on the main isolate

The first step should therefore be measurement, not random optimization.

Never Measure Performance in Debug Mode

One of the most important Flutter performance rules is:

Do not judge production performance from a debug build.

Debug mode includes additional development checks and debugging functionality.

Instead, profile the application.

Run:

flutter run --profile

Or select a specific device:

flutter run --profile -d <device-id>

You can list available devices with:

flutter devices

For example:

flutter run --profile -d 00008110-001234567890001E

Profile mode gives a much more realistic picture of runtime performance.

For final verification, you should also test a release build.

Use Flutter DevTools to Find Jank

Flutter DevTools is the primary tool for investigating performance problems.

Start your application:

flutter run --profile

Then open DevTools from your IDE or Flutter tooling.

Useful DevTools areas include:

Performance
CPU Profiler
Memory
Network
Widget Inspector

For jank investigation, start with the Performance view.

Official documentation:

https://docs.flutter.dev/tools/devtools/performance

Record the Problem

Do not record random application activity.

Reproduce the exact interaction that feels slow.

For example:

Start recording
      ↓
Open product screen
      ↓
Scroll product list
      ↓
Run problematic animation
      ↓
Stop recording

DevTools then provides a timeline showing the work performed while those frames were rendered.

Look for unusually expensive frames and timeline events.

This is much more useful than simply saying:

My Flutter app feels slow.

Now you can identify where it becomes slow.

Understand Flutter Frame Performance

Flutter has work associated with building the UI and rendering it.

A simplified frame looks like:

Dart / UI Work
      ↓
Build
      ↓
Layout
      ↓
Paint
      ↓
Rasterization
      ↓
Display

If too much work happens during any important stage, the frame can miss its deadline.

When investigating DevTools, determine whether the problem comes mainly from application/Dart work or rendering/rasterization.

That distinction helps determine what you should optimize.

UI-Side Jank

Suppose your Dart code performs a large operation while Flutter is trying to render.

For example:

void processProducts() {
  for (int i = 0; i < 10000000; i++) {
    // Expensive calculation
  }
}

If this runs synchronously on the main isolate, UI responsiveness can suffer.

Other examples include:

Large JSON parsing
Sorting huge collections
Filtering huge datasets
Complex calculations
Large synchronous loops
Expensive widget builds

When profiling points to Dart execution, investigate these operations first.

Rendering-Side Jank

Sometimes Dart code is not the main problem.

Rendering itself may be expensive.

Common causes include:

Large blur effects
Complex clipping
Opacity layers
Huge images
Complex custom painting
Expensive shadows
Too many overlapping effects

For example:

BackdropFilter(
  filter: ImageFilter.blur(
    sigmaX: 20,
    sigmaY: 20,
  ),
  child: content,
)

Blur effects can be visually attractive, but repeatedly applying large blurs across moving interfaces may be expensive.

Do not immediately remove every visual effect. Profile first and simplify the effects that are actually expensive.

Fix Unnecessary Widget Rebuilds

Large rebuilds are a common source of unnecessary work.

Consider:

setState(() {
  counter++;
});

If this state belongs to a huge page widget, Flutter may rebuild much more UI than necessary.

Instead of creating one enormous widget:

class DashboardPage extends StatefulWidget {
  // Entire dashboard
}

split it into smaller components:

Column(
  children: const [
    DashboardHeader(),
    DashboardSummary(),
    DashboardMenu(),
  ],
)

Keep frequently changing state close to the widget that actually needs it.

The goal is not simply to create more Dart files. The goal is to reduce unnecessary work when state changes.

Use const Where Appropriate

If a widget never changes, mark it const where possible.

Instead of:

Text('Dashboard')

use:

const Text('Dashboard')

Similarly:

const SizedBox(height: 16)

and:

const Icon(Icons.home)

Using const helps Flutter reuse immutable widget configurations and can reduce unnecessary object creation.

However, const is not a magic jank fix. If your real problem is a huge synchronous calculation, adding const to a few widgets will not solve it.

Avoid Heavy Work Inside build()

The build() method can execute many times.

Therefore, avoid expensive calculations inside it.

Bad example:

@override
Widget build(BuildContext context) {
  final filteredProducts = products
      .where((product) => product.price > 100)
      .toList();

  return ProductList(
    products: filteredProducts,
  );
}

Every rebuild performs the filtering again.

For a small list this may not matter, but large datasets can make repeated work expensive.

Calculate or cache derived data when appropriate.

For example:

late List<Product> filteredProducts;

void filterProducts() {
  filteredProducts = products
      .where((product) => product.price > 100)
      .toList();
}

Then rebuild only when the underlying data actually changes.

Use ListView.builder for Large Lists

Avoid creating hundreds or thousands of widgets immediately.

Bad:

SingleChildScrollView(
  child: Column(
    children: products.map((product) {
      return ProductCard(product: product);
    }).toList(),
  ),
)

If there are 2,000 products, you may create an unnecessarily large widget tree.

Prefer:

ListView.builder(
  itemCount: products.length,
  itemBuilder: (context, index) {
    return ProductCard(
      product: products[index],
    );
  },
)

For grids:

GridView.builder(
  itemCount: products.length,
  gridDelegate:
      const SliverGridDelegateWithFixedCrossAxisCount(
    crossAxisCount: 2,
  ),
  itemBuilder: (context, index) {
    return ProductCard(
      product: products[index],
    );
  },
)

Builder-based scrolling widgets create children lazily as they are needed.

This can make a major difference for large lists.

Provide itemExtent When Possible

If every item has a predictable fixed height, Flutter can sometimes perform less layout work when you provide that information.

For example:

ListView.builder(
  itemCount: users.length,
  itemExtent: 80,
  itemBuilder: (context, index) {
    return UserTile(
      user: users[index],
    );
  },
)

Flutter now knows that every row is:

80 logical pixels

rather than needing to determine each item’s size independently.

Use this only when your items actually have a predictable extent.

Optimize Images

Large images can create memory and rendering pressure.

Suppose your UI displays an image at:

300 × 200

but downloads and decodes:

4000 × 3000

That is unnecessary work.

Resize images appropriately before shipping them.

Prefer optimized formats such as WebP where suitable.

Useful image optimization tools:

https://squoosh.app

https://tinypng.com

Flutter also allows decode-size hints in appropriate cases.

For example:

Image.network(
  imageUrl,
  cacheWidth: 600,
)

The exact value should match your intended display size and device-pixel requirements.

Avoid Excessive Opacity

Using Opacity can sometimes require additional rendering work.

For simple colors, instead of wrapping a large subtree:

Opacity(
  opacity: 0.5,
  child: Container(
    color: Colors.black,
  ),
)

you may be able to express transparency directly in the color:

Container(
  color: Colors.black.withValues(
    alpha: 0.5,
  ),
)

The right solution depends on what is being made transparent.

The main rule is not:

Never use Opacity.

It is:

Avoid unnecessary expensive compositing when a simpler visual implementation produces the same result.

Be Careful With saveLayer()

Some Flutter operations can trigger offscreen rendering through saveLayer().

This can be expensive because Flutter may need to render content into an intermediate buffer before compositing it.

Operations involving certain combinations of:

• Clipping
• Opacity
• Filters
• Shadows
• Blending

can increase rendering cost.

Flutter DevTools includes tools that can help identify expensive rendering behavior.

Again, profile before rewriting your UI.

Avoid Unnecessary Intrinsic Layout

Widgets such as:

IntrinsicHeight
IntrinsicWidth

can require additional layout passes.

For small interfaces this may be perfectly acceptable.

However, using intrinsic layout repeatedly inside large scrolling lists can become expensive.

Instead of relying on intrinsic measurement everywhere, use known constraints whenever the design allows it.

For example:

SizedBox(
  height: 80,
  child: ...
)

can be much cheaper when the desired size is already known.

Optimize Animations

Animations should update only what actually needs to change.

Suppose an animation causes a large page to rebuild every frame.

That creates unnecessary work.

Widgets such as:

AnimatedBuilder

allow you to separate static content from animated content.

Example:

AnimatedBuilder(
  animation: animation,
  child: const ExpensiveStaticWidget(),
  builder: (context, child) {
    return Transform.scale(
      scale: animation.value,
      child: child,
    );
  },
)

The child does not need to be rebuilt for every animation tick.

This pattern is especially useful when the static subtree is expensive.

Use RepaintBoundary Carefully

RepaintBoundary can isolate parts of the UI into separate repaint regions.

Example:

RepaintBoundary(
  child: ExpensiveChart(),
)

This can help when one part of the interface changes frequently while another expensive section remains visually unchanged.

However, do not wrap every widget with RepaintBoundary.

Too many layers can introduce additional overhead.

Use it when profiling indicates that repaint isolation is beneficial.

Move CPU-Heavy Work Away From the Main Isolate

Suppose you receive a huge JSON response:

final data = jsonDecode(hugeResponse);

Large parsing or transformation work can block the main isolate long enough to cause visible jank.

For CPU-heavy operations, consider using another isolate.

Flutter provides utilities such as:

compute()

Example:

final result = await compute(
  parseProducts,
  responseBody,
);

Then:

List<Product> parseProducts(String body) {
  final json = jsonDecode(body);

  return (json['products'] as List)
      .map((item) => Product.fromJson(item))
      .toList();
}

This can move expensive CPU work away from the main isolate on supported platforms.

For more advanced workloads, you can work directly with Dart isolates.

Official documentation:

https://docs.flutter.dev/perf/isolates

async/await Does Not Automatically Prevent Jank

This is an important misunderstanding.

Consider:

Future<void> processData() async {
  heavyCalculation();
}

Adding async does not automatically move:

heavyCalculation();

onto another thread or isolate.

CPU-heavy synchronous work can still block the isolate.

async and await are excellent for waiting on operations such as:

Network requests
Database requests
File operations
Timers

but they do not automatically parallelize CPU-intensive Dart code.

Optimize JSON Parsing

API responses can become very large.

For example:

10 products     → usually trivial
100 products    → normally manageable
10,000 products → potentially expensive

Instead of downloading huge datasets, use API pagination.

For example:

GET /products?page=1&limit=20

Then load more data when needed.

This improves:

• Network performance
• JSON parsing time
• Memory usage
• Widget creation
• Scrolling performance

Often, the best Flutter performance optimization actually starts at the API level.

Avoid Repeated API Calls During Rebuilds

Never trigger an API request directly every time build() runs.

Bad:

@override
Widget build(BuildContext context) {
  loadProducts();

  return ...;
}

A rebuild can trigger another request.

Instead, load the data through lifecycle/state-management logic.

For example:

@override
void initState() {
  super.initState();
  loadProducts();
}

Or manage the request through your architecture, such as:

• Riverpod
• Bloc
• Provider
• GetX

The state-management package itself does not automatically improve performance. Correctly controlling updates and side effects does.

Optimize State Management

A common mistake is rebuilding an entire screen when only one value changes.

Suppose your dashboard contains:

Header
User profile
Revenue chart
Notifications
Orders
Messages

If a notification count changes, there is usually no reason to rebuild every expensive chart and list.

Whether you use Provider, Riverpod, Bloc, GetX, or another solution, subscribe widgets only to the state they actually need.

For example, with GetX, a small reactive section might be:

Obx(
  () => Text(
    controller.notificationCount.value.toString(),
  ),
)

Keep reactive boundaries focused instead of wrapping huge page sections unnecessarily.

Watch for Memory Problems

Not every slowdown comes directly from frame rendering.

Memory leaks and excessive allocation can eventually cause:

• Higher memory usage
• More garbage collection
• Slower performance
• Application crashes

Common Flutter mistakes include failing to dispose:

AnimationController
ScrollController
TextEditingController
FocusNode
StreamSubscription

For example:

@override
void dispose() {
  scrollController.dispose();
  textController.dispose();
  animationController.dispose();

  super.dispose();
}

Use the Memory view in Flutter DevTools when memory continuously grows unexpectedly.

Official documentation:

https://docs.flutter.dev/tools/devtools/memory

Use the CPU Profiler

If DevTools shows that Dart execution is expensive, use the CPU Profiler.

Record the slow operation and inspect which functions consume the most CPU time.

For example, you might discover:

parseResponse()
      38%

sortProducts()
      24%

calculatePrice()
      17%

Now you have something concrete to optimize.

Instead of randomly changing widgets, you can focus on the expensive functions.

Official documentation:

https://docs.flutter.dev/tools/devtools/cpu-profiler

Test Scrolling Performance

Scrolling is one of the easiest places for users to notice jank.

When a list feels slow, investigate:

How many widgets are being created?
Are images oversized?
Are items rebuilding unnecessarily?
Are expensive effects inside every row?
Is layout unusually complex?
Is synchronous work happening during scrolling?

For example, avoid doing expensive calculations inside:

ListView.builder(
  itemBuilder: (context, index) {
    final result = expensiveCalculation(
      products[index],
    );

    return ProductCard(
      data: result,
    );
  },
)

Precompute or cache the result if possible.

First-Run Shader Jank and Impeller

Historically, shader compilation could cause noticeable first-run animation jank in Flutter applications.

Flutter’s modern rendering architecture includes Impeller, which was designed partly to provide more predictable rendering performance and avoid runtime shader compilation behavior associated with older rendering paths.

Impeller is used by default on supported modern Flutter platforms.

Therefore, if you encounter rendering jank, first confirm:

• Flutter version
• Platform
• Renderer
• Device
• Exact frame timeline

Do not automatically assume every animation stutter is shader compilation.

Official Impeller documentation:

https://docs.flutter.dev/perf/impeller

Debug Performance Overlay

Flutter also provides a performance overlay that can help visualize frame performance.

You can enable it from Flutter tooling or use:

MaterialApp(
  showPerformanceOverlay: true,
  home: const HomePage(),
)

This displays performance graphs over the application.

It is useful for quickly spotting frame-budget problems while reproducing an interaction.

For detailed diagnosis, however, DevTools Performance view is much more useful.

Debug Flags for Rebuild Investigation

During development, Flutter provides debugging tools that can help identify excessive rebuilding or repainting.

For example:

debugPrintRebuildDirtyWidgets = true;

can help expose widgets that rebuild.

Other Flutter debugging tools can visualize repaint behavior.

These options are intended for development diagnostics rather than production code.

Use them temporarily while investigating a specific problem.

Common Jank Example

Imagine a product screen containing:

500 products
Large network images
Blurred cards
Multiple shadows
Filtering inside build()

The page stutters badly while scrolling.

A poor response would be:

Flutter is slow.

Instead, profile the page.

You may discover:

Large images
      +
All 500 widgets created immediately
      +
Repeated filtering
      +
Expensive blur

Then optimize each verified bottleneck.

For example:

Large PNG
   ↓
Optimized WebP

Column with 500 items
   ↓
ListView.builder

Filtering inside build()
   ↓
Precomputed filtered data

Blur on every card
   ↓
Simpler card design

The result can be dramatically smoother without changing your entire architecture.

A Practical Jank Debugging Workflow

When a Flutter application feels slow, use this process:

Notice Jank
     ↓
Run in Profile Mode
     ↓
Open Flutter DevTools
     ↓
Record the Slow Interaction
     ↓
Find Expensive Frames
     ↓
Determine UI/CPU or Rendering Cost
     ↓
Inspect the Expensive Operation
     ↓
Optimize It
     ↓
Profile Again

The final step is extremely important.

After making a change, measure again.

Otherwise, you do not know whether your optimization actually helped.

Flutter Jank Fix Checklist

When investigating performance, check these areas:

• Run in profile or release mode
• Use Flutter DevTools
• Record the exact slow interaction
• Check expensive frames
• Inspect CPU usage
• Reduce unnecessary rebuilds
• Use const where appropriate
• Keep expensive calculations outside build()
• Use ListView.builder() and GridView.builder()
• Optimize large images
• Avoid excessive blur and opacity
• Avoid unnecessary intrinsic layouts
• Keep animations focused
• Use RepaintBoundary only when appropriate
• Move CPU-heavy operations to isolates
• Paginate large API responses
• Avoid repeated network calls
• Keep state subscriptions focused
• Dispose controllers and subscriptions
• Test on real devices
• Measure again after every meaningful optimization

Frequently Asked Questions

What is jank in Flutter?

Jank is visible stuttering or lack of smoothness caused when an application cannot complete the work required for a frame within its available frame budget.

How do I find jank in Flutter?

Run your application in profile mode:

flutter run --profile

Then use Flutter DevTools’ Performance view to record the problematic interaction and inspect expensive frames.

How much time does Flutter have to render a frame?

On a 60 Hz display, the frame interval is approximately:

16.67 ms

On a 120 Hz display, it is approximately:

8.33 ms

The actual performance target depends on the device’s refresh rate.

Can setState cause jank?

setState() itself is not inherently bad.

The problem occurs when a state change causes unnecessarily expensive rebuilding, layout, painting, or related work.

Keep the affected subtree as focused as practical.

Does const fix Flutter jank?

const can reduce unnecessary widget creation and is a good optimization practice.

However, it will not fix major problems such as huge images, expensive CPU calculations, large synchronous JSON parsing, or complex rendering.

Does async/await fix UI freezing?

Not automatically.

await is excellent for asynchronous waiting, but CPU-heavy synchronous work still executes on an isolate and can block responsiveness.

For expensive CPU processing, consider another isolate.

Should I use RepaintBoundary everywhere?

No.

RepaintBoundary can reduce unnecessary repainting in the right situation, but adding many unnecessary boundaries can increase layer and memory overhead.

Profile first.

Which tool is best for finding Flutter performance problems?

Start with Flutter DevTools Performance view.

Then use the CPU Profiler, Memory view, Network tools, and Widget Inspector depending on what the initial profile reveals.

Conclusion

Fixing jank in Flutter should not begin with random code changes.

Start by running the application in profile mode, reproduce the slow interaction, and inspect it using Flutter DevTools.

Once you identify the bottleneck, the solution usually falls into one of several categories:

Reduce rebuilds
Optimize rendering
Optimize images
Lazy-build large lists
Move CPU-heavy work away from the main isolate
Reduce unnecessary layout work
Optimize animations
Improve API/data handling

Most importantly, profile again after making the change.

The best Flutter performance workflow is simple:

Measure
   ↓
Find
   ↓
Fix
   ↓
Measure Again

When you optimize based on actual profiling data rather than assumptions, Flutter jank becomes much easier to diagnose and fix.