¿Por qué Home Assistant puede parecer menos receptivo en algunos clientes?
Home Assistant puede parecer menos receptivo en un cliente porque la ejecución del servidor es solo una parte del proceso; el renderizado, la caché, la ruta y las actualizaciones son específicos de cada cliente.
Un ordenador de sobremesa rápido y un teléfono lento no indican automáticamente un rendimiento incoherente de Home Assistant Core. El servidor puede entregar el mismo estado mientras la WebView móvil tarda más en crear un panel, procesar tarjetas personalizadas, mostrar imágenes o ponerse al día con los eventos en tiempo real. Diagnostica la diferencia midiendo por separado la respuesta del servidor y el renderizado del cliente; después, compara el mismo panel, URL y red antes de cambiar el host.
La causa raíz suele estar después de que Home Assistant Core haya respondido
La capacidad de respuesta del cliente incluye el establecimiento de la conexión, la autenticación, la transferencia inicial de datos, la ejecución de JavaScript, la disposición de los componentes, la decodificación de imágenes, las actualizaciones de las tarjetas, la gestión táctil y los eventos continuos de WebSocket. Core solo controla una parte de esa secuencia. Una actualización del servidor no puede solucionar un motor de navegador que sea el verdadero cuello de botella, del mismo modo que restablecer la caché no puede solucionar una consulta lenta a la base de datos.
Un caso de la comunidad de Home Assistant informó de un panel que era rápido en el ordenador, pero que se quedaba en blanco y se bloqueaba repetidamente al desplazarse en iOS, lo que ilustra cómo el renderizado móvil puede dominar la latencia percibida. La pista importante era el comportamiento específico del cliente con el mismo servidor y panel.
Primero compara un panel sencillo y uno complejo en ambos clientes. Si ambos clientes muestran la misma espera del lado del servidor, pero solo uno tiene problemas después de recibir el contenido, mantén la investigación en el frontend. Si todos los clientes son lentos antes de que lleguen los primeros datos, retrocede hacia Home Assistant, el almacenamiento, la red, el DNS o la ruta de integración.
Las cuatro causas de las diferencias de capacidad de respuesta entre clientes
Las causas principales son la capacidad de renderizado del cliente, el estado de la caché, las diferentes rutas de conexión y el coste de procesar muchas actualizaciones en tiempo real. Pueden coexistir, por lo que cambiar un ajuste a veces mejora el síntoma sin explicar toda la diferencia. Mantén constantes el panel y el servidor mientras pruebas cada variable.
Una guía de diseño de paneles señala que las plantillas personalizadas pesadas, los renderizados frecuentes de tarjetas y el hardware antiguo del cliente pueden aumentar considerablemente el coste de renderizado del lado del cliente. Lo importante no es una cifra universal de tiempo de carga, sino que el mismo servidor puede parecer diferente cuando los clientes renderizan cantidades de trabajo distintas o tienen recursos del dispositivo muy diferentes.
Usa las señales siguientes para decidir dónde se introduce la diferencia. Una causa solo es creíble cuando un cambio controlado altera el comportamiento del cliente lento mientras el host de Home Assistant y el otro cliente permanecen estables. Evita aplicar varias “soluciones de rendimiento” a la vez, porque eso destruye las pruebas necesarias para identificar el límite real.
Causa 1: El cliente tiene menor capacidad de renderizado
- Mecanismo: las tarjetas, las plantillas, las imágenes y el trabajo de disposición consumen recursos de CPU, memoria y GPU del dispositivo.
- Señal: las respuestas del servidor son similares, pero un teléfono o tableta tarda más en desplazarse, mostrar contenido o aceptar toques.
- SI–ENTONCES: si un panel mínimo es rápido en el mismo dispositivo, la carga de renderizado del cliente es la causa principal.
Causa 2: Los distintos clientes usan recursos almacenados en caché diferentes
- Mecanismo: un navegador, una WebView o una aplicación complementaria pueden conservar los recursos del frontend y el estado de forma diferente.
- Señal: una actualización completa, el restablecimiento de la caché del frontend o un perfil de navegador limpio cambia el comportamiento sin modificar el servidor.
- SI–ENTONCES: si solo mejora el cliente limpio, considera el estado de la caché como una prueba local del cliente, no de la capacidad del servidor.
Causa 3: Las rutas de conexión no son realmente iguales
- Mecanismo: un cliente usa una URL interna, mientras que otro accede mediante un proxy, una URL remota, una alternativa de DNS, una VPN o una ruta Wi-Fi diferente.
- Señal: el tiempo hasta la primera respuesta cambia antes de que comience el renderizado del panel.
- SI–ENTONCES: si ambos clientes se comportan de forma similar con la misma URL y red, la diferencia la creó la ruta, no Core.
Causa 4: El volumen de eventos cambia el coste de mantener la vista actualizada
- Mecanismo: un panel grande se suscribe a muchas entidades cambiantes y debe procesar actualizaciones repetidas de WebSocket.
- Señal: la página se vuelve más lenta después de permanecer abierta o durante periodos de gran actividad de los sensores.
- SI–ENTONCES: si reducir las tarjetas suscritas o las entidades con muchas actualizaciones elimina la lentitud, el procesamiento de actualizaciones es el coste dominante del cliente.
Distingue la caché del cliente de la capacidad del servidor
Las cachés activas pueden acelerar las cargas repetidas al conservar recursos del frontend y el estado de la aplicación, por lo que una segunda carga rápida no demuestra que el servidor tenga una gran capacidad. Por el contrario, una caché obsoleta puede hacer que un cliente se comporte incorrectamente o parezca lento después de las actualizaciones. Por tanto, la caché es una condición de prueba que debe controlarse, no el resultado de rendimiento en sí.
Una investigación del frontend de Home Assistant informa de una intensa actividad de eventos de WebSocket junto con un renderizado lento repetido después de que una aplicación Android vuelve al primer plano, lo que ilustra cómo el volumen de actualizaciones en tiempo real puede afectar al frontend después de la carga inicial. Esa es una ruta de recursos distinta de la latencia de ejecución de automatizaciones de Home Assistant.
Realiza pruebas tanto con la caché activa como con un cliente frío controlado. Si una carga en frío es lenta, pero los toques y las actualizaciones en estado estable son rápidos, predominan los recursos de inicio. Si la aplicación se vuelve más lenta cuanto más tiempo permanece suscrita, mide el procesamiento de eventos y las actualizaciones del panel. Si restablecer la caché cambia solo un dispositivo, no informes de ese resultado como prueba de una mayor capacidad del servidor.
Usa una matriz de clientes con la misma ruta y el mismo panel
Prueba el navegador de escritorio, el navegador móvil y la aplicación complementaria con la misma URL local en la misma Wi-Fi, usando un panel mínimo y el panel normal de producción. Una guía detallada de diseño de paneles móviles considera explícitamente la disposición adaptable y los límites del frontend como aspectos del cliente; por eso deben registrarse por separado el tiempo de conexión, la respuesta del servidor, el primer renderizado utilizable y la confirmación del dispositivo. Repite la prueba con la ruta remota en otro ensayo.
ZimaSpace explica la etapa de red anterior en la latencia del DNS en la LAN: un cliente puede esperar antes incluso de que la aplicación reciba una solicitud. Combina esa medición con las del frontend para no culpar al renderizado de un retraso causado por el resolvedor o el proxy.
Da por bueno el servidor cuando varios clientes muestran tiempos similares de API y de llamadas a servicios, aunque sus tiempos de renderizado difieran. Optimiza el panel del cliente lento cuando su renderizado o coste de actualización sea el valor atípico. Escala la investigación hacia Core, el almacenamiento o el rendimiento de la integración solo cuando el retraso exista antes de las etapas específicas del cliente. Así, “capacidad de respuesta” queda vinculada a un segmento medido en lugar de a la impresión subjetiva de una sola pantalla.
Productos recomendados
Centro de Tecnología e IA
Más para leer
¿Por qué cambia la arquitectura de Home Assistant a medida que un servidor doméstico añade más servicios?
Más servicios cambian la arquitectura de Home Assistant cuando añaden estado compartido, colas, dispositivos, ciclos de actualización o dominios de fallo, no simplemente más...
Cómo medir el rendimiento de Home Assistant sin confundir la caché con la capacidad
Un resultado favorable demuestra la reutilización, no la capacidad. Mide el arranque en frío, el estado estable en caliente, la carga repetida, la latencia...
¿Cuánta concurrencia de automatizaciones necesita Home Assistant para controlar toda la casa?
La mayoría de las automatizaciones para todo el hogar solo necesitan una superposición acotada; dimensiona la concurrencia a partir de la duración de ejecución...
