¿Por qué Immich parece menos receptivo en distintos clientes?
Immich puede sentirse más lento en un cliente porque el renderizado del lado del cliente, la decodificación de imágenes, el estado de la caché y la ruta de red añaden trabajo después de que el servidor responde.
Una familia puede explorar la misma biblioteca desde un navegador de escritorio, un teléfono antiguo y una tableta, mientras el servidor de Immich, el almacenamiento y la base de datos permanecen sin cambios. Aun así, un dispositivo puede abrir las líneas de tiempo o las vistas previas más tarde, porque la solicitud de extremo a extremo incluye trabajo fuera del servidor. Por lo tanto, la comparación útil es entre el tiempo de respuesta del servidor y el tiempo adicional que cada cliente dedica a recibir, decodificar, almacenar en caché y dibujar el resultado.
El cliente cambia el trabajo después de que Immich responde
Una solicitud de Immich no termina cuando el servidor ha preparado el JSON, una URL de miniatura o una respuesta de imagen. El cliente todavía tiene que procesar esa respuesta, actualizar su interfaz, programar el renderizado y reaccionar a la interacción del usuario. Por eso, un servidor rápido puede coexistir con un cliente que parece lento cuando el dispositivo o el navegador dedica más tiempo a convertir los datos devueltos en una pantalla visible e interactiva.
Esta distinción es especialmente importante en los navegadores, donde JavaScript, la gestión de eventos, el cálculo de estilos, el diseño y buena parte del pintado compiten por el trabajo del hilo principal. Si un teléfono antiguo o un navegador ocupado mantiene ese hilo ocupado durante más tiempo, los toques y el desplazamiento pueden sufrir retrasos aunque la API de Immich haya terminado aproximadamente al mismo tiempo que en un escritorio más rápido.
Por eso, comparar únicamente la CPU del servidor o la latencia de la base de datos deja fuera parte de la experiencia. El análisis de ZimaSpace sobre los clientes nativos y de navegador muestra el mismo principio de sistemas: un backend puede alimentar distintas rutas de ejecución del cliente. En Immich, la primera pregunta de diagnóstico es si el retraso ocurre antes de que llegue la respuesta o después de que el cliente comienza a procesarla.
El renderizado de imágenes puede hacer que las respuestas rápidas parezcan lentas
La navegación por fotos hace más visible la diferencia entre clientes, porque una galería no contiene únicamente texto y metadatos de la API. Un cliente puede solicitar muchas miniaturas o una vista previa más grande, mantener algunas en la memoria, decodificar datos de imagen comprimidos, escalarlos para la ventana gráfica y componer varias imágenes mientras el usuario continúa desplazándose. La cantidad y el momento de ese trabajo local pueden variar mucho entre dispositivos incluso cuando solicitan el mismo recurso de Immich.
Los formatos comprimidos, como JPEG y WebP, deben pasar por la decodificación de imágenes antes de que puedan mostrarse los píxeles. Las CPU más rápidas, los decodificadores mejor optimizados, una mayor cantidad de memoria disponible y distintos motores de navegador pueden acortar esa etapa. En un cliente más débil, la red puede terminar primero, mientras que la decodificación y el pintado se convierten en la parte que el usuario realmente espera.
La consecuencia práctica es que una vista previa más grande o nítida no es gratuita simplemente porque el servidor pueda generarla rápidamente. Las imágenes de mayor resolución requieren más memoria para los píxeles decodificados y más trabajo para escalarlas y dibujarlas. Si un cliente se vuelve lento principalmente al abrir vistas previas completas o desplazarse rápidamente por líneas de tiempo densas, pero las pantallas de metadatos simples siguen respondiendo, la ruta de renderizado de imágenes es una explicación más sólida que una limitación general de capacidad del servidor.
El estado de la caché activa cambia la velocidad de las visitas repetidas
Un cliente que ya ha explorado un álbum puede reutilizar miniaturas, scripts, metadatos o recursos decodificados que un cliente nuevo todavía necesita obtener y procesar. Esto hace que el segundo recorrido sea más corto, pero no significa que el servidor haya ganado capacidad de repente. Significa que parte de la ruta de la solicitud desapareció porque el cliente comenzó desde un estado más activo que durante el primer recorrido.
Los estudios reales sobre navegadores muestran que las tasas de aciertos de la caché varían según los navegadores, las versiones, los dispositivos y el momento. Los porcentajes concretos de Facebook no constituyen una referencia de rendimiento de Immich, pero el mecanismo es importante: dos clientes pueden llegar al mismo servidor con historiales de caché locales distintos. Por lo tanto, un navegador de escritorio con la caché activa puede parecer mucho más receptivo que una aplicación de teléfono recién instalada, sin demostrar que alguno de los dos clientes sea inherentemente más rápido.
La caché también puede generar pruebas engañosas de antes y después. Actualizar el mismo álbum varias veces puede eliminar el trabajo de descarga y procesamiento de las ejecuciones posteriores, por lo que la ejecución más rápida a menudo mide la reutilización y no una carga de trabajo familiar representativa. Si el objetivo es comparar clientes, registra tanto una ruta en frío o recién abierta como una ruta repetida; la diferencia entre ambas es por sí misma una evidencia útil sobre cuánto depende cada cliente de la reutilización local.
Cuándo las diferencias entre clientes dejan de explicar el retraso
Las diferencias entre clientes dejan de ser la explicación principal cuando varios clientes distintos se ralentizan al mismo tiempo con la misma carga de trabajo. Si un navegador de escritorio, un teléfono y una tableta esperan más tiempo para obtener datos de la línea de tiempo o respuestas de vistas previas mientras aumentan la CPU del servidor, la latencia del almacenamiento, la actividad de la base de datos o la utilización de la red, la infraestructura compartida se convierte en un límite más plausible de la capacidad de respuesta que cualquier implementación concreta del cliente.
El tiempo de extremo a extremo debe incluir más elementos que el componente que parece más fácil de medir. Un análisis de latencia de Datadog muestra que la latencia de ida y vuelta puede incluir la transferencia de red, los proxies, los grupos de conexiones y la decodificación de la aplicación fuera de la propia base de datos. El mismo principio se aplica a Immich: un valor saludable de la base de datos no puede descartar retrasos en otros puntos entre el inicio de la solicitud y el resultado renderizado.
Una prueba de límites útil es la simetría. Si solo un cliente es lento mientras otro, en la misma LAN y con el mismo álbum, sigue siendo rápido, la ejecución del cliente, la caché o la red local merecen más atención. Si todos los clientes superan el mismo umbral de latencia aproximadamente al mismo tiempo, especialmente durante importaciones, generación de miniaturas, copias de seguridad u otra actividad del equipo anfitrión, la explicación ha pasado de la variación entre clientes a una limitación compartida del servidor, el almacenamiento o la red.
Usa una prueba de cliente controlada para encontrar el límite
Elige un álbum representativo y mantén constantes la versión del servidor, la ubicación de red, la cuenta, el conjunto de imágenes y el estado de los trabajos en segundo plano. Prueba cada cliente por separado y registra tres tiempos observables: la carga inicial de la línea de tiempo, la apertura de la misma vista previa grande y un desplazamiento rápido por un intervalo fijo de fotos. Anota también si el servidor muestra un pico de recursos durante cada ejecución, porque una comparación entre clientes no es válida si la carga del backend cambia entre las muestras.
Ejecuta cada cliente una vez desde un estado deliberadamente frío y otra vez inmediatamente después. Las pruebas de rendimiento suelen separar los resultados de la primera vista y la vista repetida, porque las cachés pobladas eliminan trabajo de las solicitudes posteriores. En Immich, la diferencia entre frío y activo indica cuánto cambia la experiencia gracias a la reutilización, mientras que la diferencia entre clientes bajo la misma condición de caché revela diferencias que probablemente sean locales al dispositivo o la aplicación.
Considera que una diferencia pertenece al cliente solo cuando se repite durante al menos tres ejecuciones y el cliente más rápido sigue siéndolo mientras las condiciones del servidor y la red sean comparables. Si todos los clientes se degradan juntos, deja de ajustar el cliente y examina la ruta común. Si solo difieren las acciones con muchas imágenes, concéntrate en la decodificación y el renderizado. Si la diferencia aparece únicamente en la primera ejecución, el estado de la caché —no la capacidad sostenible del servidor— es la conclusión más defendible.
Productos recomendados
Centro de Tecnología e IA
Más para leer
Los modelos abiertos están alcanzando a la IA de vanguardia: ¿será 2026 el año en que la IA local alcance un nivel suficientemente bueno?
Los modelos abiertos están alcanzando un nivel suficiente para más cargas de trabajo de IA local, mientras que los modelos de vanguardia en la...
NVIDIA PAIR convierte tu red doméstica en un clúster local de IA—¿todavía necesitas un gran servidor con GPU?
NVIDIA PAIR distribuye las solicitudes de IA local entre varios PC, haciendo que la capacidad de cómputo sea más flexible, mientras un servidor doméstico...
¿Por qué Immich se siente más rápido en una red LAN que mediante conexiones remotas?
Las solicitudes en la LAN suelen seguir una ruta más corta y con menor latencia. El acceso remoto añade limitaciones de capacidad de la...
