Jank is the visible stutter, hitching or uneven motion that occurs when an app fails to produce a frame before the display’s refresh deadline, so the screen shows the previous frame again. In mobile performance, the term is used almost interchangeably with dropped frames, and it is one of the most noticeable signs of poor app quality during scrolling, animations and transitions.
Jank is measured against the frame budget: about 16.7 ms per frame at 60 Hz, 11.1 ms at 90 Hz and 8.3 ms at 120 Hz. Whenever the work needed to prepare a frame exceeds that budget, a frame is missed and the user perceives a jump instead of smooth movement.
How jank arises in the rendering pipeline
Jank arises because rendering on a mobile device is a pipeline synchronized to the display refresh, signaled by VSync. For each frame, the app processes input, runs animations, measures and lays out views, records drawing commands on the main (UI) thread, and then a render thread and the GPU turn those commands into pixels.
If any stage takes too long, the finished frame misses its VSync slot. The display repeats the old image, and the motion the user expects to be continuous becomes uneven. A single missed frame during a fast scroll is often visible; repeated misses make an interface feel sluggish and broken.
| Refresh rate | Frame budget | Practical consequence |
|---|---|---|
| 60 Hz | About 16.7 ms | Long-standing baseline for smooth motion |
| 90 Hz | About 11.1 ms | One third less time per frame |
| 120 Hz | About 8.3 ms | Half the 60 Hz budget, jank more likely |
| Adaptive refresh | Varies with content | Display lowers its rate when nothing moves |
High-refresh displays make motion smoother but also shrink the budget. Code that was smooth at 60 Hz can produce jank at 120 Hz, which is why performance work must be validated at the highest refresh rate a device supports.
Common causes of jank
Most jank comes from work on the main thread that does not belong there or that is more expensive than expected. Some causes are in app code; others are in the GPU, the system or the framework.
| Cause | Symptom | Typical fix |
|---|---|---|
| Blocking I/O on the main thread | Stutter when opening screens | Move disk and network access to background threads |
| Expensive layout passes | Jank while scrolling complex lists | Flatten view hierarchies, avoid repeated measurement |
| Image decoding and resizing | Hitches when images appear | Decode off the main thread, load correctly sized images |
| Overdraw | GPU-bound frames on busy screens | Remove hidden backgrounds and layers |
| Garbage collection pauses | Irregular hitches during animations | Reduce allocations in frequently called code |
| Shader compilation | Jank on first run of an animation | Precompile or warm up shaders |
Device conditions add to the picture. Thermal throttling, low battery modes and memory pressure reduce available CPU and GPU capacity, so the same screen can render smoothly on a cool device and stutter after ten minutes of gaming or navigation.
Measuring jank on Android and iOS
Jank should be measured with frame timing data, not judged only by eye. Both major platforms provide tools for development and metrics for production.
| Platform | Tool or metric | What it shows |
|---|---|---|
| Android | Perfetto system traces | Thread activity and frame deadlines in detail |
| Android | JankStats and Macrobenchmark frame metrics | Janky frames in code paths and test journeys |
| Android | Android vitals slow and frozen frames | Field data from real users |
| iOS | Xcode Instruments animation hitches | Hitches and their commit or render causes |
| iOS | Hitch time ratio in MetricKit and Xcode Organizer | Milliseconds of hitches per second of scrolling |
Android vitals treats a session as having slow rendering when a large share of frames exceed the budget, and counts frozen frames that take longer than about 700 ms. Apple expresses hitches as a hitch time ratio, in milliseconds of delay per second of motion, where lower values are better and values above roughly 10 ms per second are clearly noticeable.
Jank compared with related performance problems
Jank is a smoothness problem measured in milliseconds. It is related to, but distinct from, freezes and slow loading, which are measured in seconds and have different user consequences.
| Issue | Time scale | User experience |
|---|---|---|
| Jank | One or more missed frames, tens of milliseconds | Stutter during motion |
| Frozen frame | Hundreds of milliseconds | Interface visibly stops |
| ANR (application not responding) | Several seconds without input response | System dialog offers to close the app |
| Slow app startup time | Seconds before first usable frame | Waiting before the app can be used |
The same root cause, such as heavy main-thread work, can produce all four symptoms at different scales. Fixing jank therefore often improves responsiveness metrics as well.
Preventing jank in practice
Preventing jank starts with a simple rule: keep the main thread free for input, layout and drawing. Everything else, including parsing, database queries and image processing, belongs on background threads or coroutines.
- Profile on low-end devices, where the frame budget is hardest to meet, not only on flagship phones.
- Use list recycling and stable item identifiers so scrolling reuses views instead of creating them.
- Animate cheap properties such as translation, opacity and scale rather than layout-changing properties.
- Precompute and cache expensive work before the user scrolls to it.
- Track frame metrics in production to catch regressions that do not appear in the lab.
A frequent mistake is to optimize average frame time. Users notice the worst frames, so performance targets should use high percentiles, such as the 90th or 99th percentile frame duration, and the share of janky frames per screen.
Explained without jargon
Jank is the stutter you see when an app does not move smoothly. The screen updates many times every second. Each update must be ready on time. When the app is too busy, an update is skipped and the picture jumps.
It is like a flip book with some pages missing. The story still moves forward, but the motion looks jerky instead of fluid. Smooth apps keep their busy work in the background so every page is ready in time.
A typical use case
A shopping app receives reviews saying that the product feed stutters while scrolling, especially on mid-range phones with 120 Hz displays. A system trace shows that each new product card decodes a full-resolution photo on the main thread, taking 20 to 40 ms per image.
The team switches to an image loader that decodes images in the background at the exact size shown on screen, and adds a frame metric to the feed screen. The share of janky frames during scrolling drops sharply, and the next release’s production data confirms the improvement on the lowest-tier devices where complaints had been most common.