What Does Home Assistant Actually Cache, and Which Repeated Requests Get Faster?

“Home Assistant is faster the second time” can describe several different mechanisms. A browser may reuse frontend assets, an already-open dashboard may receive live state through WebSocket instead of rebuilding the page, the operating system may keep database or configuration pages in memory, and an integration may reuse an established connection.

Calling all of those effects “the Home Assistant cache” hides where the speedup occurs. The useful model is to name the repeated request, then identify which layer can avoid work on the second run.

The Browser Cache Speeds Frontend Assets

JavaScript, styles, icons, custom cards, and other frontend resources can remain in a browser cache so a repeated page load avoids downloading or rebuilding the same assets from scratch.

Home Assistant's current browser guidance explicitly notes that the user interface caches many things in the browser to make it fast. That same cache can become stale after updates or custom-card changes, which is why a hard refresh can fix a UI that behaves incorrectly.

This cache changes page startup and rendering, not physical device-control speed. Clearing it is a frontend test, not a general server-performance reset.

An Open Dashboard Reuses a Live WebSocket State Path

Once the frontend is connected, it does not need to refetch the entire smart-home state for every change. It receives updates and subscriptions over the WebSocket API and updates the relevant interface components.

The current frontend architecture describes how the frontend receives core state through a shared hass object and keeps additional subscribed data synchronized through WebSockets. A wall tablet that stays connected therefore has a different repeated-request path from a phone opening the dashboard cold each morning.

Do not interpret that reuse as proof that many more clients will scale linearly. Every additional client can still add serialization, subscriptions, history requests, and client-side rendering work.

Linux Page Cache Speeds Repeated File and Database Reads

Normal filesystem reads pass through the Linux page cache. Recently used database pages, configuration files, and static assets may remain in memory and avoid another physical storage read on a repeated request.

Current Linux kernel documentation explains that normal file reads populate the page cache so subsequent reads can avoid more expensive storage access. That means a repeated History query can benefit from memory even when Home Assistant did not implement a special application-level cache for that exact query.

This is why SSD versus HDD differences can look smaller in a warm test than after reboot, cache eviction, or a much larger working set.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Warm Data Does Not Mean the Underlying Query Became Cheaper

A History request can still scan or index the same logical amount of data while the pages it needs happen to be resident in memory. A dashboard can still request the same entities while assets and connection state are already available.

The related ZimaSpace benchmark guide on separating warm-cache performance from actual capacity shows the operational consequence: cache is useful, but a capacity claim must survive realistic cache pressure and sustained workload.

A cache hit removes one cost from one request. It does not remove CPU, memory, network, database, or integration work that belongs to other stages of the path.

Different Repeated Requests Warm Different Layers

• Reloading the same dashboard: browser assets and client runtime may be warm.
• Keeping a wall tablet open: WebSocket state and subscriptions remain live.
• Repeating the same History range: database and filesystem pages may remain in memory.
• Calling the same local service: established integration or network connections may already exist.
• Opening after reboot: several of those layers may be cold at once.

Measure the layer that corresponds to the user's action instead of clearing every cache and calling that “scientific.”

FAQ

Does clearing the browser cache make Home Assistant Core slower?

It mainly changes the frontend load path. Core still runs the same server logic, but the browser may need to download and rebuild assets again, making the first interface load slower.

Is a warm History query useless for benchmarking?

No. Warm queries represent a real operating condition. The mistake is treating the warm result as the only capacity result when memory pressure, restart, or a larger working set can remove the same cache advantage.