How Does Network Latency Affect Immich During Large Mobile-Library Imports?

Network latency affects large Immich mobile imports most when the workflow requires many round trips, retries, or remote service hops rather than one uninterrupted bulk transfer.

A high-bandwidth link can still feel slow if each request waits on a long round trip, while a low-latency LAN can finish control operations quickly even with less headline bandwidth. After an asset is accepted, however, thumbnail generation, metadata work, and local indexing can continue without the phone being on the critical path, so upload delay and processing delay must be measured separately.

Latency and Throughput Limit Different Parts of an Import

Throughput determines how quickly large photo and video payloads can cross the link when the transfer is continuously busy. Latency determines how quickly a request-response exchange, authentication step, connection setup, or retry can complete. The import experience depends on the mixture of those operations rather than on either metric alone.

Tailscale’s explanation of path selection and relays shows why a network path can add delay without changing the Immich server itself. A direct path and a relayed path can reach the same endpoint but have different round-trip and throughput characteristics.

This means an upload that consists of many smaller files can be more sensitive to round-trip overhead than one large video of the same total size. Do not use a single speed-test number to predict completion unless the test resembles the request pattern and direction of the actual mobile import.

Retries Multiply the Cost of a Long Round Trip

Wireless loss, mobile handoffs, VPN path changes, or overloaded upstream links can force requests or segments to be retried. On a low-latency path, recovery may be barely noticeable; on a high-latency path, each retry adds another waiting interval and can make progress appear bursty.

A real-world account of slow remote Immich access is useful as a diagnostic example because commenters separated relay-path suspicion from an endpoint configuration issue. The lesson is to verify both transport path and application request behavior before blaming raw bandwidth.

The network explanation weakens when the server receives assets at a stable rate but background queues remain slow after the transfer stops. At that point, CPU, storage, database, or machine-learning work is controlling readiness rather than phone-to-server latency.

Remote Machine Learning Adds a Different Network Edge

If machine-learning inference runs on another host, indexing gains a server-to-ML network hop that the mobile upload path may not share. A household can therefore have fast phone uploads but slow semantic-search completion when the inference service is remote or intermittently reachable.

The example of remote machine learning demonstrates that Immich ML can be placed on another machine across a private network. That architecture can trade local CPU pressure for dependency on network reachability and round-trip time between services.

Keep this case separate from ordinary remote viewing. If the ML host is on the same LAN as the Immich server, internet latency from the phone is irrelevant to that inference step. If it is across a tunnel or WAN, measure that service path independently.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Import Traffic Can Compete With Interactive Remote Use

A large upload consumes upstream or downstream capacity depending on where the phone is located relative to the home server. When the same constrained WAN link also carries timeline images, API responses, backups, or other household traffic, queueing at the router or ISP edge can increase latency for small interactive requests.

ZimaSpace’s analysis of storage latency in Immich provides a parallel causal test: shared-resource contention matters only when the resource’s longer waits line up with the delayed user action. Apply the same discipline to the network instead of assuming every import saturates it.

This mechanism stops explaining a slowdown when WAN utilization is modest, round-trip time remains stable, and the server itself shows rising request or storage latency. Network and server contention can coexist, so identify which delay changes first under the controlled workload.

Test the Import as Four Separate Timelines

Use a fixed batch containing many small photos and several large videos. Record four timelines: client-to-server transfer, server acceptance, background processing, and final search readiness. Alongside them record round-trip latency, effective transfer rate, retransmission or retry symptoms, and the relevant server resource metrics.

Compare the same batch on local Wi-Fi or wired LAN and on the intended remote route without changing server settings. Use Tailscale’s direct-versus-relayed paths as a transport reference when interpreting a tunnel. If transfer time expands but server-side processing remains similar, the network is the controlling variable.

Accept the network diagnosis only when a controlled path change improves the predicted stage while the other stages remain comparable. That evidence is stronger than a speed test, a single high ping, or a general statement that remote uploads are always slower.