How to Cache Network Images in Flutter and Reduce Costs

Every uncached image request in a Flutter app is a network call that costs time and bandwidth – and costs user patience. In image-heavy applications, repeated reloading of the same assets is one of the most common and preventable causes of slow perceived performance. Users notice. On mobile, where connectivity is inconsistent, they notice more.

Flutter provides two main paths for handling this: a built-in mechanism with no configuration, and the cached_network_image package with full control over cache policy, expiry, and error handling. This post covers both and explains when each is the right choice. That guidance comes from Monterail's Flutter development team, which has been building image-heavy Flutter applications across healthcare, fintech, and consumer apps since 2019.

Why Uncached Images Cost You Money

Every repeated image download is a network round-trip your server or CDN pays for, and every user waits through.

On an image-heavy screen with 20 thumbnails, an uncached implementation refetches all 20 on every rebuild: a list scroll, a tab switch, a navigation pop.

Caching turns those 20 requests into one per session, cutting both CDN egress costs and the time-to-render that determines whether the screen feels instant or sluggish.

How much you save depends on two things: how often a request is answered from the cache instead of the network, and how long a cached copy stays usable before it has to be fetched again. Both have precise names in caching work, and Flutter's image APIs are built around them.

Three options:

For most production apps, cached_network_image is the default: full control without the maintenance cost of a custom implementation.

What Does Caching Mean Here?

AWS describes caching this way:

In computing, a cache is a high-speed data storage layer that stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than is possible by accessing the data’s primary storage location. Caching allows you to efficiently reuse previously retrieved or computed data.

Caching comes with terminology and concepts essential to understanding Flutter's capabilities. According to Cloudflare's Learning Center:

A cache hit occurs when "the cache already contained the desired information, and loading it from the real source of truth was unnecessary."

A cache miss occurs when "the cache was empty, and the desired data is loaded from the real source of truth, and then saved to the cache for future reads."

I also use a third useful definition. A stale cache occurs when the data within the source of truth has changed, putting the app at risk of rendering outdated information.

Verifying the cache's freshness usually takes as much time as reloading the entire data, which reduces the benefit of caching. For images, this is less frequently a problem because images often remain unchanged for long periods unless the application's primary purpose involves frequently updated images.

Why Cache Images in a Flutter App?

If an app is to attract and retain users, it must handle images well under real-world conditions: connection issues, slow networks, repeated navigation through image-heavy screens.

Caching network images in Flutter improves app performance and user experience in several ways:

• Once an image is loaded for the first time, it is cached locally. Subsequent requests load it from the cache instead of re-downloading it from the internet, saving time and data.

• The same image loaded repeatedly costs bandwidth only once, because a cache hit incurs no transfer cost.

• Cached images load in well under a second, providing a smooth experience for the end user.

• Flutter's caching mechanisms can show a placeholder when an image fails to load.

• Most caching implementations in Flutter prevent excessive memory or resource usage, which matters on low-end mobile devices.

How Does Image.network Cache Images by Default?

In Flutter, the Image.network constructor handles basic image caching.

By default, network images loaded using this constructor are cached to improve performance and reduce redundant network requests. All network images are cached regardless of HTTP headers. However, the caching mechanism for Image.network is not configurable and lacks flexibility.

The Image.network constructor uses both the ImageCache and ImageProvider under the hood. Here's how it works:

• ImageProvider: the Image.network constructor creates an instance of NetworkImage, which is a subclass of ImageProvider. It fetches the image from the network and provides it to the Flutter framework.

• ImageCache: the ImageProvider (in this case, NetworkImage) works with ImageCache to buffer the images. ImageCache is a utility class in Flutter that stores image references to avoid redundant loading and rendering, improving performance and reducing network usage.

While this built-in caching works without configuration, production applications often need more control.

According to the Flutter documentation:

If cacheWidth or cacheHeight are provided, they tell the engine to decode the image at the specified size. The image will be rendered to the constraints of the layout or width and height, regardless of these parameters. These parameters are primarily intended to reduce the memory usage of ImageCache. (source: https://api.flutter.dev/flutter/widgets/Image/Image.network.html)

Note: For network images on the web platform, cacheWidth and cacheHeight are disregarded because the browser handles image decoding, where custom decode sizes are not supported.

Here you can see an example:

When Should You Use the CachedNetworkImage Package?

For more advanced caching needs, the cached_network_image package offers enhanced functionality. It is the standard solution for Flutter developers who need to customize caching policies, handle cache expiration, or manage network issues gracefully.

CachedNetworkImage Package

The cached_network_image package provides an enhanced way to load and cache network images, offering more features and flexibility compared to the default Image.network constructor.

How The CachedNetworkImage Package Works

1. Network request and image loading: the CachedNetworkImage widget uses a CachedNetworkImageProvider to fetch images from the network. When an image is requested, the provider checks if the image is already stored in the cache. If not, it initiates a network request to download it.

1. Caching mechanism: The package uses flutter_cache_manager to handle caching. flutter_cache_manager provides a CacheManager class that stores downloaded images in the device's file system. The cache manager can be configured to control cache duration, maximum cache size, and other parameters.

1. Cache key: Each image URL has a unique cache key that identifies and retrieves the image from the cache. By default, the URL itself is used as the cache key.

1. Custom cache manager (more below): developers can provide a custom cache manager to override the default caching behavior – useful for setting custom cache policies, such as cache duration, or implementing a custom eviction strategy.

You can use CachedNetworkImage directly or through ImageProvider. Note that both CachedNetworkImage and CachedNetworkImageProvider currently offer minimal support for the web and do not include caching capabilities in that environment.

For other platforms, cached network images use flutter_cache_manager to store and retrieve files in the app's cache directory.

How Do You Handle Placeholders and Load Errors?

In both Image.network and CachedNetworkImage, handling the loading state or errors is straightforward. Handle every state: a failed image load should show something useful.

CachedNetworkImage provides good support for placeholder and error widgets. These widgets give the user a visual cue while the image is being fetched or if fetching fails, and the placeholder and errorWidget parameters accept any widget you pass them.

A common pattern is a low-resolution blurred placeholder that swaps to the full image once it loads, and a retry icon in the error widget so the user can trigger another attempt without leaving the screen. They help maintain a consistent user experience by providing feedback during loading or error states, instead of a blank space or a broken-image icon that reads to the user as a bug in the app rather than a slow or dropped network connection on the user's end.

How Do You Configure the Cache Directory and Eviction?

Don't create more than one CacheManager instance with the same key, as they will interfere with each other.

By default, cached files are stored in the app's temporary directory so that the OS can delete them at any time. Information about the files is stored in a database using sqflite on Android, iOS, and macOS, or in a plain JSON file on other platforms. The database file name corresponds to the CacheManager's key, which is why it must be unique.

Files can be removed either by the cache manager or by the operating system. Typically, files are stored in a cache folder that may be cleaned periodically, for example, during an app update on Android.

The CacheManager uses two key variables to determine when to delete a file: maxNrOfCacheObjects and stalePeriod. During cache cleaning (which runs continuously), the manager deletes files that exceed the maximum number of cache objects (prioritizing those used least recently) and files that haven't been used beyond the stale period.

Example:

What Cache Settings Can You Configure?

CacheManager accepts these configuration parameters:

• Cache key (key): a unique key to identify the cache. Used for the folder to store files and for the database file name. Useful if you need to separate different caches within your app.

• Stale period (stalePeriod): the duration after which cached items are considered stale and may be refreshed from the network.

• Max number of cache objects (maxNrOfCacheObjects): the maximum number of items to keep in the cache. Files used least recently are removed first when the limit is exceeded.

• Cache info repository (repo): custom implementation of a repository to store cache metadata. Defaults to CacheObjectProvider (sqflite) on Android, iOS, and macOS; NonStoringObjectProvider on web; JsonCacheInfoRepository on other platforms.

• File service (fileService): custom file service for fetching files. Defaults to HttpFileService.

• File system (fileSystem): defines where cached files are stored.

Compared to Image.network, this provides substantially more configuration options. The fadeIn and fadeOut parameters also allow smooth animation during image loading.

How Do You Preload Images Before They Are Needed?

The precacheImage function loads images ahead of time and stores them in the cache. This is particularly useful because the initial load of an asset can sometimes cause a brief flicker.

By using precacheImage, subsequent requests for the same image are served directly from the cache, leading to faster load times and smoother user interactions.

What Else Improves Image Performance?

Beyond the core mechanisms covered above, a few additional practices can further improve performance:

1. Use appropriately sized images to reduce the amount of data that needs to be downloaded and cached.

2. Compress images to balance quality and file size.

3. Implement policies such as loading images only over Wi-Fi or ensuring the app handles slow network conditions gracefully.

4. Display low-resolution placeholders quickly while the main image loads.

What Has to Be True Before You Adopt cached_network_image?

Caching works reliably in production only when a few conditions hold.

Every CacheManager instance in the app needs its own key – reusing a key across two CacheManager instances makes them fight over the same database file and cache folder, corrupting both. If any part of the app runs on Flutter web, cached_network_image isn't the caching layer: CachedNetworkImage and CachedNetworkImageProvider both lack caching support on that platform, so web builds still hit the network on every request regardless of configuration.

Compliance and regulatory rules apply when cached images are user-specific.

A profile photo, an uploaded ID document, or a healthcare record thumbnail sitting in the device's cache directory after a user logs out or deletes their account is exactly the kind of retained personal data that GDPR's right to erasure and similar regimes require an app to clear from the device, in addition to the account record deleted on your server. Wiring a cache-manager clear call into the logout and account-deletion flows, the same call covered in the FAQ below, is the practical way to close that gap.

Check the package's maintenance cadence before depending on it for a long-lived app. cached_network_image's release history is uneven: version 3.4.1 shipped in August 2024, and the next release, 4.0.0, did not land until August 2026, a two-year gap followed by a major version bump in one step. That bump is not a drop-in replacement: 4.0.0 raises the minimum supported Flutter to 3.44.0 and Dart to 3.12.0, and swaps its internal use of flutter/material.dart for material_ui to support WebAssembly compilation.

Audit both requirements against your app's SDK constraints before upgrading, and pin the version you test against rather than floating on the latest release.

What Decides Whether Your Caching Strategy Works?

Caching network images in Flutter is one of the most reliable ways to improve app performance and user experience. Storing and reusing images locally cuts the number of network requests and speeds up loading.