---
title: "Cached (Help Center / Filters / Metric)"
ai_context: "Use this article for questions about the RUMvision Cached filter, determining whether an image-based Largest Contentful Paint (LCP) resource was loaded from network, memory cache or disk cache, and understanding when cache status cannot be measured. It explains values such as `blocked`, `no`, `memory cache` and `disk cache`, how RUMvision derives cache information from the `PerformanceResourceTiming` API, and how `transferSize`, `requestStart`, `startTime` and `responseEnd` are used as signals. Relevant for questions about LCP caching, browser cache reuse, Resource Timing, `Timing-Allow-Origin` (TAO), cross-origin images, blocked timing details, memory versus disk cache heuristics, DevTools comparisons, Chrome 133 LCP timing changes and browser differences in exposed resource timing data."
canonical: "https://www.rumvision.com/help-center/filters/metric/cached/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > [Help Center](https://www.rumvision.com/help-center/?format=md) > [Filters](https://www.rumvision.com/help-center/filters/?format=md) > [Metric](https://www.rumvision.com/help-center/filters/metric/?format=md) > Cached

# Cached

> This filter works with the [Largest Contentful Paint metric](https://www.rumvision.com/help-center/glossary/metrics/largest-contentful-paint/?format=md)

If you want to know if a particular image is served from the cache, you can use the **cached** filter. The screenshot belows shows that the amount of times this LCP image comes out of the cache is pretty low.

[![cached-filter.png](https://www.rumvision.com/file/upload/img/cached-filter.png)](https://www.rumvision.com/file/upload/img/cached-filter.png)

the **cached** filter might show one or more of the following values:

- **blocked**  
     This means we could not determine the caching status of this image. This typically happens for LCP candidates that are served from a different domain, but didn't had additional headers to expose this kind of information.
- **no**  
     This means the image was not served from any cache and had to be downloaded from a server.
- **memory cache**  
     This means browsers were able to fetch the LCP image from memory cache. This typically happens on back-forward or reload attempts.
- **disk cache**  
     This means the browser was able to fetch the LCP from the user's disk. This typically happens when a user navigates to a page that served the same image before, resulting in the image being saved to the disk storage of the user's device.
 
## PerformanceResourceTiming API

We're using the [`PerformanceResourceTiming` API](https://developer.mozilla.org/en-US/docs/Web/API/PerformanceResourceTiming) data as exposed by the web-vitals library to draw conclusions about the caching status of the LCP image. For example, when the `transferSize` is equal to zero, there is a chance that the image was cached.

### Blocked

However, when transferSize equals zero, it might also just not be exposed via the `PerformanceResourceTiming` API. This could happen when the [`Timing-Allow-Origin` (TAO) header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Timing-Allow-Origin) isn't present or was not configured to expose all resource related information. This means that RUMvision also won't be able to track the caching status of an LCP image.

We are still able to determine if the TAO header was set correctly by also checking the `requestStart` value. If that value is empty too, the TAA header wasn't (properly) set and as a result, we will show **blocked** instead.

> WHen there's a blocking TAO in place for images served from a different origin, the `renderTime` attribute was guarded, leading to a less accurate LCP value.  
>  [Chrome 133](https://chromestatus.com/feature/5128261284397056) works around that, allowing RUM providers like RUMvision to get a way more accurate LCP value as well as breakdown for images.

### Memory vs disk cache

Once our JavaScript detected that the image was fetched from cache, it could still either be served from memory or disk cache. The same information is also exposed in the Network panel of DevTools.

However, memory cache vs. HTTP cache cannot be directly determined with JavaScript, as this is abstracted by the browser. Instead, we compare the `startTime` of the LCP image with the `responseEnd`. If these are the same, the image was likely served from memory cache. If not, the image was likely served from disk cache.

In the `PerformanceResourceTiming` API the caching status isn't exposed in the same way.

### Browser differences

Do note that as we're using data from the Resource Timing API, there could be differences between browsers as to what they expose. The above is tested in and should correctly apply to Chromium browsers.