Why Does Home Assistant Perform Differently on LAN and Remote Connections?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

Home Assistant can feel fast on the LAN and slower remotely even when Core executes the same automation because the client connection takes a different path. A local browser may cross one switch to reach Home Assistant; a remote phone may resolve public DNS, cross mobile or office networks, traverse the ISP path, enter a cloud proxy, VPN, tunnel, or reverse proxy, then maintain a WebSocket session back to the server.

The performance difference should therefore be measured as client-to-server delivery, not immediately blamed on Home Assistant CPU. A physical automation can complete locally in the same time while the remote dashboard takes longer to show the new state.

LAN Access Has Fewer Network Stages

Inside the home, a client can use the server's private address or an internal DNS name and avoid the public internet. Round trips are short, and the connection is usually unaffected by ISP upload capacity or a remote relay.

The Home Assistant Companion networking model supports separate internal and external connection paths, including internal URLs, external URLs, split DNS, and WebSocket-aware reverse-proxy requirements.

A slow LAN session should therefore be debugged inside the home first: Wi-Fi, DNS, browser/client rendering, reverse proxy used internally, VLAN routing, or the Home Assistant host itself.

Remote Access Adds DNS, WAN, Encryption, and an Ingress Method

A remote client normally needs a public or overlay name, TLS, an external route, and an access boundary such as Home Assistant Cloud, VPN, reverse proxy, or tunnel. Each stage can add latency or a reconnect point.

Remote overlays can also use different connection types. Current Tailscale guidance explains that direct peer connections usually provide the lowest latency and highest throughput, while relayed connections are a fallback when direct connectivity is not possible. The route itself can therefore change perceived Home Assistant responsiveness without changing Core execution time.

Do not adopt a universal remote-latency threshold. Measure your own route from the places you actually use it—cellular, office Wi-Fi, travel networks, or a second home—and record whether the path is direct or relayed.

WebSocket Stability Matters After the Initial Page Loads

Home Assistant dashboards receive continuing state changes after the initial HTML and JavaScript load. A connection that repeatedly drops and reconnects can feel much worse than its average bandwidth suggests.

A reverse proxy or tunnel must preserve the WebSocket path correctly. The Companion networking guidance warns that self-managed reverse proxies need WebSocket support; otherwise the UI may connect partially while live updates behave poorly.

Watch reconnects, failed WebSocket upgrades, proxy logs, and mobile network transitions. A phone switching from Wi-Fi to LTE can change source address and route even while the Home Assistant server itself remains healthy.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

Remote Performance Can Be Limited by Home Upload

Home internet plans are often asymmetric. A remote dashboard request travels down to the home, but camera thumbnails, dashboard assets, state payloads, and streams must leave through the home's upload path.

High-bitrate camera views or several remote users can expose upload limits that no local client sees. A remote session that is slow only when a camera card opens is a different problem from an automation that takes too long to execute.

ZimaSpace's smart-home server workload guide makes the same distinction between core automation and heavier cameras, analytics, and companion services that add separate resource requirements.

Client Path Selection Can Make Two Phones Behave Differently

The Companion app chooses connection settings based on the configured Home network and URLs. A device that never recognizes the home network may continue using the external route even while sitting on the same Wi-Fi as Home Assistant.

A community support case shows the practical dependency: the app needs the correct external URL and home-network definition before the internal URL becomes the intended local path.

Compare the exact URL, DNS answer, proxy/VPN path, dashboard, and client when investigating performance. “Same Home Assistant server” is not the same test if the two clients use different ingress routes.

Measure Server Execution Separately From Client Delivery

Measurement	What it isolates
Automation trigger → service call	Home Assistant logic
Service call → physical device feedback	Local device transport
LAN client → Home Assistant response	Local network and client
Remote client → Home Assistant response	WAN, ingress, relay, TLS, proxy/VPN
Server state update → client render	WebSocket and frontend path

Call the server “slower remotely” only when the server-side execution itself changes. If the physical device responds on time but the remote screen updates later, the performance difference belongs after Core, on the remote delivery path.

FAQ

Why is the Home Assistant app fast on Wi-Fi but slow on mobile data?

Mobile data adds the public or private remote-access route, including ISP latency, DNS, TLS, and possibly a proxy, VPN, tunnel, or relay. The Home Assistant server may be executing at the same speed.