Cached
This filter works with the Largest Contentful Paint metric
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.
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 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 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
renderTimeattribute was guarded, leading to a less accurate LCP value.
Chrome 133 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.