A Flutter application can be functionally correct and still feel slow.

You might notice:

• Scrolling suddenly stutters
• An animation freezes for a moment
• Page transitions are not smooth
• A list drops frames while loading data
• The first appearance of a complex screen feels heavy
• Animations run smoothly until a certain widget appears

These problems are commonly described as jank.

However, not all jank has the same cause.

Two important categories Flutter developers should understand are:

UI jank and raster jank.

At a high level:

UI Jank
→ Dart/UI work takes too long

Raster Jank
→ Rendering/rasterization work takes too long

Understanding the difference matters because optimizing the wrong part of the application may have little effect.

In this guide, we’ll explore Flutter’s frame pipeline, understand UI and raster jank, learn how to identify each one with Flutter DevTools, and look at practical ways to fix performance problems.

---

What Is Jank in Flutter?

Flutter needs to continuously produce frames while animations, scrolling, transitions, and other visual changes are happening.

For a 60 Hz display, the screen can refresh roughly 60 times every second.

That gives the application approximately:

1000 ms ÷ 60
≈ 16.67 ms

per frame.

Conceptually:

Frame 1 → ~16.67 ms
Frame 2 → ~16.67 ms
Frame 3 → ~16.67 ms

If a frame takes too long:

Frame 1 → 10 ms
Frame 2 → 12 ms
Frame 3 → 31 ms  ← Missed frame budget
Frame 4 → 14 ms

the user may notice a stutter.

That visible interruption is commonly called jank.

---

What About 120 Hz Displays?

Modern phones may use 90 Hz, 120 Hz, or other refresh rates.

At 120 Hz, the frame interval is approximately:

1000 ms ÷ 120
≈ 8.33 ms

That means there is less time available for each frame.

Compare:

Refresh Rate	Approx. Frame Interval
60 Hz	16.67 ms
90 Hz	11.11 ms
120 Hz	8.33 ms

Therefore, code that appears smooth at 60 Hz may become more demanding on higher-refresh-rate devices.

The exact scheduling and rendering behavior can vary by platform and device, but the principle remains the same:

Expensive frame work increases the chance of dropped frames and visible jank.

---

How Flutter Produces a Frame

Before understanding UI jank and raster jank, it helps to understand Flutter’s rendering pipeline.

A simplified frame pipeline looks like:

User Interaction / Animation
            ↓
        Dart Logic
            ↓
          Build
            ↓
          Layout
            ↓
          Paint
            ↓
     Layer / Scene Data
            ↓
       Rasterization
            ↓
           GPU
            ↓
         Display

Different parts of this pipeline perform different kinds of work.

For performance debugging, two areas are especially important:

UI work
+
Raster work

---

What Is the UI Thread in Flutter?

The UI isolate performs much of your Dart application work.

This includes work related to:

Dart code
Widget building
Layout
Animation callbacks
State updates
Event handling
Synchronous computations

For example:

setState(() {
  products = updatedProducts;
});

may trigger widget rebuilding and subsequent frame work.

If too much work happens before Flutter can prepare the frame in time, you can get UI jank.

---

What Is the Raster Thread?

After Flutter has prepared the scene, rendering work still needs to turn that scene into pixels.

Conceptually:

Widget Tree
    ↓
Layout
    ↓
Paint Information
    ↓
Scene
    ↓
Rasterization
    ↓
Pixels

Raster work can become expensive because of visual effects, large images, complicated painting, or other rendering-heavy operations.

When rasterization takes too long, you get raster jank.

---

UI Jank vs Raster Jank

The basic difference is:

UI Jank	Raster Jank
Dart/UI-side frame work is slow	Rendering/rasterization is slow
Often caused by expensive synchronous work	Often caused by expensive visual work
Widget build/layout may be expensive	Paint/raster work may be expensive
Large calculations can contribute	Large images/effects can contribute
Too many rebuilds may contribute	Complex clipping/shadows may contribute
Fix Dart/widget-side work	Fix rendering/visual complexity

This distinction is critical during performance optimization.

---

What Is UI Jank?

UI jank occurs when the UI-side work required for a frame takes too long.

Imagine:

Frame Budget
──────────────

UI Work
██████████████████████████████
                               ↑
                         Too expensive

Flutter cannot prepare the frame quickly enough.

The result can be visible stuttering.

---

Common Causes of UI Jank

UI jank can come from several sources.

Common examples include:

Heavy synchronous calculations
Large JSON parsing
Expensive sorting
Large loops
Too many widget rebuilds
Complex build methods
Expensive layout
Synchronous file processing
Large data transformations
Repeated object creation
Poor state-management boundaries

Let’s examine the most important ones.

---

1. Heavy Computation on the UI Isolate

Consider:

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

If this work executes synchronously while the UI needs to produce frames, animation and scrolling can stall.

Conceptually:

UI Isolate

Frame
 ↓
Heavy Calculation
 ↓
Heavy Calculation
 ↓
Heavy Calculation
 ↓
Next Frame Delayed

The problem is not necessarily the loop itself.

The problem is performing too much synchronous work on the same isolate responsible for responsive application behavior.

---

2. Large JSON Parsing

Suppose an API returns a very large response.

Then you execute:

final data = jsonDecode(response.body);

followed by:

final products = data['products']
    .map<Product>(
      (json) => Product.fromJson(json),
    )
    .toList();

For small responses, this is usually fine.

For very large payloads, parsing and model conversion can consume enough time to affect responsiveness.

The flow becomes:

API Response
    ↓
Large JSON Decode
    ↓
Create Thousands of Models
    ↓
UI Isolate Busy
    ↓
Frame Delayed

---

Moving Heavy Work Off the UI Isolate

For sufficiently expensive CPU-bound work, Dart isolates can help.

Flutter provides convenient APIs such as compute() for suitable operations.

Example:

final products = await compute(
  parseProducts,
  response.body,
);

Then:

List<Product> parseProducts(
  String responseBody,
) {
  final decoded =
      jsonDecode(responseBody);

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

This can prevent expensive parsing from blocking the main UI isolate.

Do not move every tiny operation to another isolate, though. Isolate communication itself has overhead.

Use it for work that is actually expensive enough to justify it.

---

3. Too Many Widget Rebuilds

Suppose you have:

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

inside a very large screen.

If the state change causes a large widget subtree to rebuild unnecessarily, UI work increases.

Conceptually:

Small State Change
       ↓
Huge Widget Tree Rebuild
       ↓
More Build Work
       ↓
Potential UI Jank

The solution is not to avoid setState() completely.

Instead, reduce the scope of unnecessary rebuilds.

---

GetX Example

Suppose you write:

Obx(
  () => Column(
    children: [
      Header(),
      ProductList(
        products:
            controller.products,
      ),
      Footer(),
      CartBadge(
        count:
            controller.cartCount.value,
      ),
    ],
  ),
);

If only cartCount changes, wrapping a large section in the same reactive builder may cause more rebuilding than necessary.

A better structure can be:

Column(
  children: [
    const Header(),

    Obx(
      () => ProductList(
        products:
            controller.products,
      ),
    ),

    const Footer(),

    Obx(
      () => CartBadge(
        count:
            controller.cartCount.value,
      ),
    ),
  ],
);

Now each reactive region is more focused.

---

4. Expensive Work Inside build()

Avoid:

@override
Widget build(BuildContext context) {
  final sortedProducts =
      products.toList()
        ..sort(
          (a, b) =>
              a.price.compareTo(b.price),
        );

  return ProductList(
    products: sortedProducts,
  );
}

if products is large and build() runs frequently.

Every rebuild performs sorting again.

Instead, prepare the data when the source changes:

Data Changed
    ↓
Sort Once
    ↓
Store Result
    ↓
Build Uses Prepared Data

Your build() methods should primarily describe UI rather than repeatedly performing expensive business/data processing.

---

5. Expensive Layout

Flutter also needs to calculate widget sizes and positions.

Some layouts can become expensive when deeply nested or repeatedly recalculated.

Be careful with unnecessary complexity involving:

IntrinsicHeight
IntrinsicWidth
Deeply nested layouts
Large dynamically measured trees
Repeated layout-dependent calculations

This does not mean these widgets are always bad.

It means they should be used intentionally, especially inside large scrolling interfaces.

---

6. Building Huge Lists at Once

Avoid:

Column(
  children: products
      .map(
        (product) =>
            ProductCard(product),
      )
      .toList(),
)

when products contains thousands of items.

This attempts to create a very large widget tree.

Use lazy list construction:

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

Now Flutter builds items as needed for the scrolling viewport.

---

7. Unnecessary State Updates During Animation

Suppose an animation causes application-wide state updates every frame.

For example:

Animation Tick
     ↓
Global State Update
     ↓
Large Widget Rebuild
     ↓
Next Animation Tick

This can become expensive.

Use Flutter’s animation widgets and tightly scoped rebuild mechanisms where appropriate rather than rebuilding unrelated application sections.

---

What Is Raster Jank?

Raster jank occurs when the rendering side takes too long to turn Flutter’s prepared scene into pixels.

Imagine:

UI Work
████████

Raster Work
████████████████████████████████
                                 ↑
                           Too expensive

The UI-side work may be fast enough, but the frame can still miss its deadline because rasterization is expensive.

---

Common Causes of Raster Jank

Typical causes include:

Large images
Oversized decoded images
Complex shadows
Blur effects
BackdropFilter
Expensive clipping
Complex CustomPainter operations
Large transparent layers
Certain saveLayer-triggering effects
Heavy visual compositions

These problems require different fixes from UI jank.

---

1. Large Images

Suppose your API provides a:

4000 × 4000

image.

Your Flutter UI displays it at:

100 × 100

The visual size may be small, but decoding and working with an unnecessarily large image can consume significant memory and rendering resources.

Instead, request appropriately sized images from your backend/CDN when possible.

You can also provide decode hints in suitable Flutter image APIs.

For example:

Image.network(
  imageUrl,
  cacheWidth: 300,
);

The appropriate dimensions depend on layout size and device pixel ratio, but the principle is simple:

Do not decode enormous images when only a small version is required.

---

2. Blur Effects

Blur can be visually attractive but expensive.

For example:

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

A large animated blur region can create significant rendering work.

Use blur only where it provides meaningful visual value.

Consider:

Reduce blur radius
Reduce affected area
Avoid animating large blur regions
Use simpler visual alternatives

when profiling shows the effect is expensive.

---

3. Complex Shadows

Consider:

BoxShadow(
  blurRadius: 40,
  spreadRadius: 20,
)

applied repeatedly across many list items.

One shadow may be fine.

Hundreds of complex shadows moving during scrolling can increase rendering cost.

For example:

ListView
 ↓
Card
  ↓ Shadow
 ↓
Card
  ↓ Shadow
 ↓
Card
  ↓ Shadow
 ↓
...

Always profile before removing design elements blindly, but large repeated effects are worth investigating when raster time is high.

---

4. BackdropFilter

BackdropFilter is useful for glassmorphism and blur effects.

For example:

ClipRRect(
  borderRadius:
      BorderRadius.circular(20),
  child: BackdropFilter(
    filter: ImageFilter.blur(
      sigmaX: 10,
      sigmaY: 10,
    ),
    child: Container(
      color: Colors.white
          .withValues(alpha: 0.1),
    ),
  ),
)

However, applying large backdrop filters throughout a scrolling screen can be expensive.

A design like:

List
 ↓
Blur Card
 ↓
Blur Card
 ↓
Blur Card
 ↓
Blur Card

deserves careful profiling.

---

5. Excessive Clipping

Flutter provides:

ClipRect
ClipRRect
ClipOval
ClipPath

Clipping is sometimes necessary.

However, complicated clipping paths or excessive clipping in frequently changing areas can increase rendering work.

Avoid clipping widgets simply by habit.

Use clipping when the visual output actually requires it.

---

6. Complex CustomPainter

CustomPainter is powerful.

For example:

class ChartPainter
    extends CustomPainter {
  @override
  void paint(
    Canvas canvas,
    Size size,
  ) {
    // Complex drawing
  }

  @override
  bool shouldRepaint(
    covariant ChartPainter oldDelegate,
  ) {
    return true;
  }
}

The biggest red flag here may be:

return true;

If the painter does not actually need to repaint every time, unnecessary paint work can occur.

Implement shouldRepaint() carefully:

@override
bool shouldRepaint(
  covariant ChartPainter oldDelegate,
) {
  return oldDelegate.data != data;
}

This avoids unnecessary repainting when nothing visually changed.

---

UI Jank and Raster Jank Can Happen Together

A screen can have both problems.

For example:

Product Screen
     ↓
Parse 5,000 products
     ↓
Build huge widget tree
     ↓
Display oversized images
     ↓
Add blur + shadows

This can create:

High UI Time
+
High Raster Time

Therefore, do not assume a performance issue has only one cause.

Measure the frame.

---

Flutter’s Frame Timeline

Flutter DevTools provides performance information for individual frames.

Conceptually, you may see:

Frame

UI
████████████████████

Raster
████████

Here, UI work is likely the primary bottleneck.

Another frame might show:

UI
██████

Raster
████████████████████████

Here, rasterization deserves more investigation.

This distinction prevents random optimization.

---

How to Detect Jank with Flutter DevTools

Run your application in profile mode when investigating realistic performance:

flutter run --profile

Avoid judging production performance primarily from debug mode.

Debug mode includes development overhead that can distort performance measurements.

Open Flutter DevTools and use the Performance tooling.

Then reproduce the issue:

Start Recording
     ↓
Scroll / Animate / Navigate
     ↓
Stop Recording
     ↓
Inspect Slow Frames

Look for frames that exceed their available frame budget.

---

Why Profile Mode Matters

Flutter has several common build modes:

Debug
Profile
Release

Debug mode is optimized for development features.

Profile mode is specifically useful for performance investigation.

Release mode represents production-oriented optimization but provides less profiling visibility.

A practical workflow is:

Develop
   ↓
Debug Mode

Investigate Performance
   ↓
Profile Mode

Ship
   ↓
Release Mode

---

Reading UI and Raster Times

Suppose DevTools shows a slow frame.

Example:

UI:      28 ms
Raster:   7 ms

At a 60 Hz frame interval, UI work is clearly suspicious.

Investigate:

Build
Layout
Dart computation
State updates
Parsing
Synchronous work

Another example:

UI:       5 ms
Raster:  25 ms

Now investigate rendering:

Images
Blur
Shadows
Clipping
Painting
Layers
CustomPainter

This is much more effective than changing random widgets.

---

Example: UI Jank

Imagine this code runs when opening a screen:

Future<void> loadProducts() async {
  final response =
      await repository.getProducts();

  final products =
      response
          .map(Product.fromJson)
          .toList();

  products.sort(
    (a, b) =>
        a.name.compareTo(b.name),
  );

  controller.products.assignAll(
    products,
  );
}

Suppose the response contains a very large dataset.

Potential UI-side work includes:

Decode
 ↓
Create models
 ↓
Sort
 ↓
Update state
 ↓
Rebuild widgets

If profiling shows UI jank, consider:

Pagination
Server-side filtering
Server-side sorting
Background isolate processing
Smaller rebuild regions
Lazy UI construction

rather than immediately changing visual effects.

---

Example: Raster Jank

Suppose every item contains:

Container(
  decoration: BoxDecoration(
    borderRadius:
        BorderRadius.circular(30),
    boxShadow: [
      BoxShadow(
        blurRadius: 40,
        spreadRadius: 10,
      ),
    ],
  ),
  child: ClipRRect(
    borderRadius:
        BorderRadius.circular(30),
    child: BackdropFilter(
      filter: ImageFilter.blur(
        sigmaX: 15,
        sigmaY: 15,
      ),
      child: Image.network(
        product.image,
      ),
    ),
  ),
)

Now imagine 20 of these cards moving during scrolling.

The Dart logic may be lightweight, but rendering can still become expensive.

If DevTools indicates raster pressure, simplify the visual composition and measure again.

---

RepaintBoundary

RepaintBoundary can isolate painting for certain widget subtrees.

Example:

RepaintBoundary(
  child: ComplexChart(),
)

Conceptually:

Parent Changes
      ↓
Without Boundary
      ↓
Chart May Repaint

With Useful Boundary
      ↓
Chart Can Be Isolated

However:

Do not wrap every widget in RepaintBoundary.

Extra layers also have costs.

Use it when profiling shows that an expensive subtree is repainting unnecessarily.

---

How to Detect Repaints

Flutter’s development tooling can help visualize repaint activity.

If a widget repeatedly repaints while nothing visually changes, investigate why.

For example:

Animation
    ↓
Parent Repaint
    ↓
Large Static Chart Repaints

A useful repaint boundary may isolate the static chart.

Again, measure before and after.

---

const Widgets and Jank

Using const constructors is good Flutter practice when widgets are truly constant.

For example:

const Text(
  'Welcome',
);

This can reduce unnecessary widget recreation in appropriate cases.

However, adding const everywhere will not magically fix raster jank.

Remember:

const
→ Widget/build optimization opportunity

Raster problem
→ Rendering workload

Always optimize the correct layer.

---

Avoid Premature Optimization

Suppose your screen is already smooth.

Replacing:

Container

with:

SizedBox

everywhere simply because one widget appears lighter is unlikely to produce meaningful performance improvements by itself.

Performance optimization should follow:

Measure
 ↓
Find Bottleneck
 ↓
Change
 ↓
Measure Again

not:

Guess
 ↓
Rewrite Everything

---

Use Pagination for Large Data

Instead of downloading:

10,000 Products

at once, load smaller pages.

For example:

Page 1 → 20
Page 2 → 20
Page 3 → 20

Benefits include:

Less network data
Less JSON parsing
Fewer models
Less memory
Smaller state updates
Less initial UI work

Pagination can therefore improve more than network performance.

---

Avoid Repeated API Processing

Suppose a screen rebuild causes:

Build
 ↓
Filter 5,000 records
 ↓
Sort 5,000 records
 ↓
Group 5,000 records

every time.

Move transformations to:

Repository
Controller
Use Case
Worker Isolate

depending on the responsibility.

Then let the UI consume prepared state.

---

Optimize Images Properly

For image-heavy Flutter apps, consider:

Correct image dimensions
Thumbnail endpoints
WebP/AVIF where your delivery stack supports them
CDN resizing
Decode-size hints
Lazy loading
Appropriate caching

Avoid sending a massive original image just to display a tiny thumbnail.

For example:

Original
4000 × 4000

Displayed
120 × 120

A backend-generated thumbnail is often a better solution.

---

Avoid Large Animated Blur Areas

A static blur may be acceptable.

Animating a full-screen blur every frame can be far more expensive.

For example:

Full Screen
    ↓
Backdrop Blur
    ↓
Animation Every Frame

If raster profiling shows this as a bottleneck, consider simplifying the effect or limiting its affected area.

---

Reduce Unnecessary Opacity Layers

Opacity effects can sometimes introduce additional rendering work.

Instead of applying large animated opacity widgets indiscriminately, consider whether the desired effect can be achieved more efficiently.

This does not mean Opacity should never be used.

It means performance-sensitive animations should be profiled.

---

Shader Compilation and First-Run Jank

Some visual effects may behave differently the first time they are rendered compared with later frames.

Historically, shader compilation has been an important source of first-run jank in Flutter rendering discussions.

Modern Flutter rendering increasingly uses Impeller on supported platforms to improve rendering predictability and address several historical shader-related issues.

However, rendering performance can still depend on:

Platform
Flutter version
Device GPU
Rendering backend
Visual complexity

Therefore, always profile on the actual platforms and representative physical devices you plan to support.

---

Test on Real Devices

Emulators and simulators are useful for development, but they do not perfectly represent real hardware.

Performance should be tested on physical devices, including:

Lower-end Android device
Mid-range Android device
Target iPhone
High-refresh-rate device

A screen that is smooth on a powerful development machine may perform differently on a budget phone.

---

UI Jank Troubleshooting Checklist

If DevTools shows high UI time, investigate:

Large build methods
Too many rebuilds
Heavy synchronous loops
Large JSON parsing
Sorting/filtering/grouping
Large model conversions
Expensive layout
Huge widget trees
Non-lazy lists
Frequent state updates
Work performed during animation

Potential fixes include:

Use lazy builders
Reduce rebuild scope
Move heavy CPU work to an isolate
Paginate large datasets
Precompute derived data
Optimize state management
Simplify layout
Avoid expensive work inside build()

---

Raster Jank Troubleshooting Checklist

If raster time is high, investigate:

Large images
Image decode sizes
BackdropFilter
Blur
Complex shadows
Clipping
CustomPainter
Repeated repainting
Large transparency effects
Expensive layers
Complex animations

Potential fixes include:

Resize images
Use thumbnails
Reduce blur area
Simplify shadows
Avoid unnecessary clipping
Optimize CustomPainter
Use RepaintBoundary selectively
Reduce expensive animated effects

---

UI Jank vs Raster Jank Example

Suppose a product list scrolls poorly.

Do not immediately assume:

ListView is slow.

Profile it.

Case A

DevTools shows:

UI:     31 ms
Raster:  6 ms

Investigate:

ProductCard rebuilds
Filtering
Sorting
JSON/model conversion
State updates
Layout

Case B

DevTools shows:

UI:      6 ms
Raster: 29 ms

Investigate:

Product images
Shadows
Blur
Clipping
Painting

Case C

DevTools shows:

UI:     27 ms
Raster: 24 ms

Both sides need attention.

This is why profiling is essential.

---

Performance with GetX

GetX itself does not automatically make an application fast or slow.

Performance depends on how reactive state is structured.

Avoid wrapping an entire page:

Obx(
  () => Scaffold(
    body: HugePage(),
  ),
);

when only one tiny value changes.

Prefer smaller reactive boundaries:

Scaffold(
  body: Column(
    children: [
      const Header(),

      Obx(
        () => CartBadge(
          count:
              controller.cartCount.value,
        ),
      ),

      ProductList(),
    ],
  ),
);

This can reduce unnecessary UI-side work.

---

Performance with ListView.builder

For large lists, prefer lazy construction.

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

rather than building every child upfront.

Also ensure each item itself is reasonably efficient.

A lazy list containing extremely expensive cards can still jank.

---

Performance with CustomPainter

If you are drawing charts, maps, graphs, signatures, or custom animations, inspect:

shouldRepaint()

Avoid:

@override
bool shouldRepaint(
  covariant CustomPainter oldDelegate,
) {
  return true;
}

unless every repaint is genuinely required.

Instead, compare the values that affect the drawing.

---

Measure Before and After Optimization

Suppose a frame takes:

UI: 28 ms
Raster: 8 ms

You optimize rebuilds.

Measure again:

UI: 9 ms
Raster: 8 ms

Now you have evidence that the change addressed the bottleneck.

Without measurement, you only know that the code changed—not that performance improved.

---

Debug Mode vs Profile Mode

Do not use debug-mode frame behavior as your final performance benchmark.

Debug mode includes:

Assertions
Debugging support
Development instrumentation
Hot reload infrastructure
Other development overhead

For performance analysis, use:

flutter run --profile

Then test the exact interaction that feels slow.

---

Common Flutter Performance Mistakes

Optimizing without profiling

Always find the bottleneck first.

Assuming every dropped frame is UI jank

Raster work may be the real issue.

Blaming rendering for heavy Dart computation

If UI time is high, changing shadows may accomplish very little.

Blaming state management automatically

GetX, Bloc, Riverpod, Provider, and other approaches can all be used efficiently or inefficiently.

Parsing huge responses on the UI isolate

Large CPU-bound transformations can block responsiveness.

Loading oversized images

Display size and source/decode size should be considered separately.

Building every list item immediately

Use lazy list/grid builders for large collections.

Overusing blur and complex effects

Visual complexity can create raster pressure.

Adding RepaintBoundary everywhere

Use it selectively based on repaint behavior.

Testing only on a powerful device

Performance needs to be representative of real users.

---

Recommended Performance Debugging Workflow

Use this process whenever a Flutter screen feels janky:

1. Reproduce the issue
        ↓
2. Run in Profile Mode
        ↓
3. Record with DevTools
        ↓
4. Find slow frames
        ↓
5. Compare UI vs Raster time
        ↓
6. Identify expensive work
        ↓
7. Optimize one bottleneck
        ↓
8. Record again
        ↓
9. Compare results

Do not begin by rewriting the entire screen.

---

If UI Time Is High

Focus on:

Dart computation
Widget rebuilds
Build methods
Layout
State updates
Parsing
Sorting/filtering
Large lists
Synchronous operations

Typical solutions:

Smaller rebuild regions
Lazy widgets
Pagination
Background isolates
Precomputed data
Better state boundaries
Simpler layout

---

If Raster Time Is High

Focus on:

Images
Paint
Effects
Layers
Blur
Shadows
Clipping
CustomPainter
Repaints
Animations

Typical solutions:

Resize images
Simplify effects
Reduce blur
Optimize painters
Avoid unnecessary clipping
Use repaint boundaries selectively
Reduce expensive visual animation

---

UI Jank vs Raster Jank: Final Comparison

Area	UI Jank	Raster Jank
Main bottleneck	UI/Dart-side frame work	Rendering
Heavy computation	Common cause	Usually not direct cause
Widget rebuilds	Important	Indirect impact possible
Layout	Important	Less direct
Large JSON parsing	Can cause it	No direct raster cause
Large images	Can affect overall app	Common rendering concern
Blur	Usually not primary UI issue	Can be expensive
Shadows	Usually not primary UI issue	Can be expensive
Custom painting	May involve UI setup	Can heavily affect raster
Fix focus	Code/build/layout	Paint/rendering
Diagnose with	DevTools Performance	DevTools Performance

---

Best Practices to Prevent Flutter Jank

For consistently smooth Flutter applications:

1. Profile before optimizing.
2. Test performance in profile mode.
3. Test on physical devices.
4. Keep expensive CPU work away from frame-critical UI execution.
5. Reduce unnecessary widget rebuilds.
6. Keep reactive state boundaries focused.
7. Use lazy lists and grids for large datasets.
8. Paginate large API responses where appropriate.
9. Avoid expensive calculations inside build().
10. Resize and optimize network images.
11. Avoid unnecessary blur, clipping, and complex shadows.
12. Optimize CustomPainter.shouldRepaint().
13. Use RepaintBoundary only when it solves an observed repaint problem.
14. Profile high-refresh-rate devices where relevant.
15. Measure performance again after every meaningful optimization.

---

Final Thoughts

The most important lesson about UI Jank vs Raster Jank in Flutter is that both can produce the same visible symptom:

Stuttering UI

but they require different solutions.

UI jank generally follows this pattern:

Heavy Dart / Build / Layout Work
             ↓
       UI Frame Delayed
             ↓
            Jank

Raster jank generally looks more like:

Complex Visual Scene
          ↓
Expensive Rasterization
          ↓
     Frame Delayed
          ↓
         Jank

Therefore, the correct optimization process is not:

App is slow
    ↓
Add const
    ↓
Add RepaintBoundary
    ↓
Remove random widgets

Instead, use:

App is janky
     ↓
Profile with DevTools
     ↓
Inspect Slow Frame
     ↓
UI or Raster?
   ↙          ↘
 UI          Raster
 ↓             ↓
Optimize     Optimize
Dart/Build   Rendering
     ↘       ↙
      Measure Again

Once you learn to distinguish UI jank from raster jank, Flutter performance debugging becomes much more systematic. Instead of guessing which widget or package is responsible, you can identify which part of the frame pipeline is missing its budget and optimize the code that actually matters.