configuring-lazy-prefetch

name	configuring-lazy-prefetch
description	Use this skill to tune Jetpack Compose lazy-layout prefetch with LazyLayoutCacheWindow (Compose Foundation 1.9+, @ExperimentalFoundationApi) and pausable composition in prefetch (Compose Foundation 1.10+, default on). Covers configurable Dp-based ahead/behind cache windows plumbed through rememberLazyListState(cacheWindow = ...), NestedPrefetchScope for items containing inner lazy layouts (HorizontalPager inside a LazyColumn row), version requirements, and the trade-off between memory pressure and idle-frame work. Use when the developer mentions dropped frames at high scroll velocity, prefetch window, ahead/behind extents, LazyLayoutCacheWindow, NestedPrefetchScope, pausable composition for prefetch, or wants composition retained for items briefly scrolled past. Item-level fixes (keys, contentType) live in a sibling skill.
license	Apache-2.0. See LICENSE for complete terms.
metadata	{"author":"Jaewoong Eum (skydoves)","keywords":["jetpack-compose","performance","lazy-prefetch","lazy-layout-cache-window","pausable-composition","nested-prefetch","frame-timing","macrobenchmark"]}

Configuring Lazy Prefetch — Cache Window and Pausable Composition

Lazy layouts pre-compose items just outside the viewport so they're ready when the user scrolls. Compose Foundation 1.9 added LazyLayoutCacheWindow for configurable ahead/behind extents. Compose Foundation 1.10 made prefetch composition pausable by default — work spreads across multiple frames instead of one. Most apps still rely on legacy single-frame prefetch and unknowingly pay for it during heavy scrolling. This skill teaches Claude when (and only when) to widen the window or implement nested prefetch, and how to validate the change with Macrobenchmark.

When to use this skill

• Macrobenchmark FrameTimingMetric shows dropped frames at high scroll velocity even though item composables are skippable.
• Items are content-heavy: large images, decoded videos, nested grids, or expensive measurement work.
• The developer wants composition retained for items the user scrolled past briefly (e.g. flick-back gesture).
• An outer lazy layout contains items with their own inner lazy layouts (e.g. LazyColumn rows that each host a HorizontalPager or inner LazyRow).
• The developer mentions LazyLayoutCacheWindow, NestedPrefetchScope, "prefetch window", "ahead extent", or "pausable composition for prefetch".

When NOT to use this skill

• Items are cheap and short; default behavior is sufficient — do not pre-emptively configure a window.
• Item composables are non-skippable / unstable; widening the window only spreads the same waste over more frames. First fix ../optimizing-lazy-layouts/SKILL.md and the underlying stability via ../../stability/diagnosing-compose-stability/SKILL.md.
• The bottleneck is per-item layout or draw rather than composition. Use Android Studio Profiler / Layout Inspector to confirm; if measure or draw dominates, prefetch tuning will not help — adjust item content instead.
• Wrong-phase state reads inside items (animation reads state.value in Composition) — use ../../recomposition/deferring-state-reads/SKILL.md.

Prerequisites

• Compose Foundation 1.9+ for the LazyLayoutCacheWindow API. The cache window is a @ExperimentalFoundationApi factory LazyLayoutCacheWindow(ahead: Dp, behind: Dp) plumbed through rememberLazyListState(cacheWindow = ...) (or the equivalent grid/staggered-grid state). It is NOT a parameter on LazyColumn / LazyRow / LazyVerticalGrid / LazyHorizontalGrid directly. Every call site requires @OptIn(ExperimentalFoundationApi::class).
• Compose Foundation 1.10+ for pausable composition in prefetch by default. On 1.10+ the prefetch composer can pause and resume across frames, so a single heavy item no longer blows a frame budget.
• Item-level hygiene already in place: key, contentType, stable item composables. Run ../optimizing-lazy-layouts/SKILL.md first and confirm before tuning the window.
• Macrobenchmark module set up for FrameTimingMetric. See ../../measurement/generating-baseline-profiles/SKILL.md for the Macrobenchmark scaffold.

Workflow

• 1. Confirm Compose Foundation version. In gradle/libs.versions.toml or the relevant build.gradle.kts, verify androidx.compose.foundation:foundation is at 1.9.0+ (cache window) or 1.10.0+ (pausable prefetch on by default). If on 1.10+ and not measuring jank yet, MUST stop here — the default is good enough for most apps.

• 2. Re-validate item-level fixes are in place. Open ../optimizing-lazy-layouts/SKILL.md. Every items(...) call has stable key, mixed feeds have contentType, item composables are skippable. Without this baseline, prefetch tuning is treating the symptom.

• 3. Measure the baseline with Macrobenchmark FrameTimingMetric before changing anything. Skydoves hot take #5: debug builds lie. Always measure release + R8 + real device. Capture frameDurationCpuMs p50/p95/p99 over a fixed scroll journey so the after-comparison is meaningful. See ../../measurement/generating-baseline-profiles/SKILL.md.

• 4. Construct a LazyLayoutCacheWindow only after measurement justifies it. Build the window with the top-level factory LazyLayoutCacheWindow(ahead: Dp, behind: Dp) and plumb it through rememberLazyListState(cacheWindow = window), then pass that state to LazyColumn(state = state) { ... }. The cache window is not a parameter on LazyColumn itself. Every call site needs @OptIn(ExperimentalFoundationApi::class).

// RIGHT — measured tall, image-heavy items benefit from a deeper ahead extent
@OptIn(ExperimentalFoundationApi::class)
@Composable
fun HeavyFeed(items: ImmutableList<HeavyItem>) {
    val state = rememberLazyListState(
        cacheWindow = LazyLayoutCacheWindow(ahead = 200.dp, behind = 100.dp)
    )
    LazyColumn(state = state) {
        items(items, key = { it.id }, contentType = { it::class }) { item ->
            HeavyItemRow(item, Modifier.animateItem())
        }
    }
}

• 5. Implement NestedPrefetchScope for items that host inner lazy layouts. When a LazyColumn row contains a HorizontalPager, inner LazyRow, or inner LazyVerticalGrid, the outer prefetch can warm only the row's outer composition by default. Implementing nested prefetch chains the work so the inner layout's first item composes during the outer prefetch slot, not on the user's first horizontal swipe.

• 6. Re-measure with the same Macrobenchmark journey. Compare frameDurationCpuMs p95/p99 before and after. If the rate did not decrease, MUST revert the window change and look elsewhere — likely measure or draw dominates, or item composition was already keeping up.

• 7. If still dropping frames on Compose Foundation 1.10+ with pausable prefetch, profile to confirm the bottleneck. Use Android Studio CPU profiler / system trace to determine whether composition, measurement, or draw is the dominant phase per frame. Prefetch tuning only addresses composition cost; for measure/draw, simplify item content (smaller images, fewer subcompositions, graphicsLayer for alpha/scale) instead.

• 8. Change one variable at a time. MUST NOT combine cache-window tuning with stability/key fixes in the same commit or PR. Profiling needs an isolated cause-and-effect comparison; bundling two changes makes the regression bisect impossible.

Patterns

Pattern: default vs configured

// OK — short, light items: default behavior is correct
LazyColumn {
    items(items, key = { it.id }, contentType = { it::class }) { Item(it) }
}

// RIGHT — measured-heavy items justify a wider ahead window (Compose Foundation 1.9+)
@OptIn(ExperimentalFoundationApi::class)
@Composable
fun HeavyFeed(items: ImmutableList<HeavyItem>) {
    val state = rememberLazyListState(
        cacheWindow = LazyLayoutCacheWindow(ahead = 200.dp, behind = 100.dp)
    )
    LazyColumn(state = state) {
        items(items, key = { it.id }, contentType = { it::class }) { HeavyItem(it) }
    }
}

Pattern: nested prefetch for inner lazy layouts

// RIGHT — the outer LazyColumn warms the inner pager's first item via nested prefetch
LazyColumn {
    items(rows, key = { it.id }, contentType = { it::class }) { row ->
        HorizontalPager(
            state = rememberPagerState(pageCount = { row.pages.size }),
            // Implement NestedPrefetchScope on the inner pager so outer prefetch chains in.
        ) { pageIndex ->
            PagerPage(row.pages[pageIndex])
        }
    }
}

Without nested prefetch, only the outer row warms — the user's first horizontal swipe still pays composition cost for the inner page. With nested prefetch, the inner first page is composed during the outer prefetch slot.

Pattern: anti-pattern — "be safe" wide window

// WRONG
@OptIn(ExperimentalFoundationApi::class)
@Composable
fun WideWindow(items: ImmutableList<Item>) {
    val state = rememberLazyListState(
        cacheWindow = LazyLayoutCacheWindow(ahead = 2000.dp, behind = 2000.dp)
    )
    LazyColumn(state = state) { /* ... */ }
}
// WRONG because: a 2000.dp ahead/behind window pre-composes a screenful of extra items on every scroll tick. Memory pressure rises (especially with image-heavy items) and a single direction-reverse wastes most of the prefetched work. Wide windows are not "safe defaults" — they are deliberate trade-offs that MUST be backed by Macrobenchmark numbers.

// RIGHT — start narrow, widen only if FrameTimingMetric demands it
@OptIn(ExperimentalFoundationApi::class)
@Composable
fun NarrowWindow(items: ImmutableList<Item>) {
    val state = rememberLazyListState(
        cacheWindow = LazyLayoutCacheWindow(ahead = 200.dp, behind = 100.dp)
    )
    LazyColumn(state = state) { /* ... */ }
}

Pattern: tuning before fixing item stability

// WRONG
@OptIn(ExperimentalFoundationApi::class)
@Composable
fun Feed(items: List<Item>) {        // unstable parameter
    val state = rememberLazyListState(
        cacheWindow = LazyLayoutCacheWindow(ahead = 400.dp, behind = 200.dp)
    )
    LazyColumn(state = state) {
        items(items, key = { it.id }) { item -> ItemRow(item) }
    }
}
// WRONG because: pre-composing additional unstable rows just spreads the same wasted work over more frames. The cache window cannot fix non-skippable item composables.

// RIGHT — fix stability first, then leave the window at default; widen only if Macrobenchmark still shows jank
@Composable
fun Feed(items: ImmutableList<Item>) {
    LazyColumn {
        items(items, key = { it.id }, contentType = { it::class }) { item -> ItemRow(item) }
    }
}

Cross-reference: ../optimizing-lazy-layouts/SKILL.md and ../../stability/stabilizing-compose-types/SKILL.md.

Pattern: relying on pausable composition (Compose Foundation 1.10+)

// RIGHT — on 1.10+, prefetch composition is pausable by default; a single heavy item no longer blows the frame budget
// gradle/libs.versions.toml:
//   compose-foundation = "1.10.0"
LazyColumn {
    items(items, key = { it.id }, contentType = { it::class }) { HeavyItem(it) }
}

Pausable composition lets the prefetch composer suspend mid-item when the frame deadline approaches and resume on the next idle frame. PREFERRED: upgrade to Compose Foundation 1.10+ and benefit from this default before manually widening the cache window.

Mandatory rules

• MUST stay on default behavior unless a Macrobenchmark FrameTimingMetric baseline proves the prefetch window is the bottleneck. Premature tuning increases memory pressure without fixing jank.
• MUST state the Compose Foundation minimum version when introducing LazyLayoutCacheWindow (1.9+) or relying on pausable prefetch defaults (1.10+).
• MUST annotate any call site that uses LazyLayoutCacheWindow(...) with @OptIn(ExperimentalFoundationApi::class). Plumb the window through rememberLazyListState(cacheWindow = ...) (or the matching grid/staggered-grid state factory), then pass that state to the lazy layout — the cache window is not a parameter on LazyColumn / LazyRow / LazyVerticalGrid / LazyHorizontalGrid themselves.
• MUST express ahead/behind extents in Dp (the API takes Dp, not item counts).
• MUST complete ../optimizing-lazy-layouts/SKILL.md (keys, contentType, item stability) before tuning the cache window. Prefetch cannot fix non-skippable items.
• MUST NOT combine cache-window tuning with stability/key fixes in one PR — change one variable at a time, re-measure, then iterate. Skydoves hot take #5: always measure release + R8 + real device.
• MUST NOT widen the window "to be safe". Wider window = more memory + more wasted work on direction reversals.
• PREFERRED: upgrade to Compose Foundation 1.10+ to get pausable prefetch by default before manually tuning the window.
• PREFERRED: implement NestedPrefetchScope for any item that contains an inner lazy layout (HorizontalPager, inner LazyRow, inner LazyVerticalGrid) before widening the outer window.

Verification

• androidx.compose.foundation:foundation resolves to 1.9.0+ (cache window) or 1.10.0+ (pausable prefetch by default) in the dependency report.
• Macrobenchmark FrameTimingMetric frameDurationCpuMs p95 / p99 measurably decreases on the same scroll journey after the change, on a real device with R8 enabled.
• Layout Inspector shows prefetch items composing during idle frames (not piled into the same frame as user scroll input).
• Memory profiler does not show a regression after widening the window — heap and resident set sizes stay within budget.
• If NestedPrefetchScope was added, the user's first inner-pager swipe runs at native frame rate (no first-swipe stutter).
• No commit bundles cache-window tuning with key / contentType / stability fixes — each change ships and is measured in isolation.

References

• Android Developers — Lists and grids: https://developer.android.com/develop/ui/compose/lists
• Android Developers — Performance overview: https://developer.android.com/develop/ui/compose/performance
• Android Developers — What's new in Jetpack Compose (May 2025, 1.9): https://android-developers.googleblog.com/2025/05/whats-new-in-jetpack-compose.html
• Android Developers — What's new in Jetpack Compose (December 2025, 1.10): https://android-developers.googleblog.com/2025/12/whats-new-in-jetpack-compose-december.html
• Android Developers — Macrobenchmark FrameTimingMetric: https://developer.android.com/topic/performance/baselineprofiles/measure-baselineprofile
• Ben Trengrove — Why you should always test Compose performance in release: https://medium.com/androiddevelopers/why-should-you-always-test-compose-performance-in-release-4168dd0f2c71
• skydoves — compose-performance hub: https://github.com/skydoves/compose-performance