Why Does Immich Feel Less Responsive Across Different Clients?
Immich can feel slower on one client because client-side rendering, image decoding, cache state, and network path add work after the server responds.
A family may browse the same library from a desktop browser, an older phone, and a tablet while the Immich server, storage, and database remain unchanged. One device can still open timelines or previews later because the end-to-end request includes work outside the server. The useful comparison is therefore server response time versus the extra time each client spends receiving, decoding, caching, and drawing the result.
The Client Changes the Work After Immich Responds
An Immich request does not end when the server has prepared JSON, a thumbnail URL, or an image response. The client still has to process that response, update its interface, schedule rendering, and react to user input. A fast server can therefore coexist with a sluggish-feeling client when the device or browser spends extra time turning returned data into a visible, interactive screen.
That distinction is especially important in browsers, where JavaScript, event handling, style calculation, layout, and much of painting compete for main-thread work. If an older phone or busy browser holds that thread longer, taps and scrolling can lag even though the Immich API completed at roughly the same time as it did on a faster desktop.
This is why comparing only server CPU or database latency misses part of the experience. ZimaSpace's discussion of native and browser clients shows the same systems principle: one backend can feed different client execution paths. For Immich, the first diagnostic question is whether the delay occurs before the response arrives or after the client begins processing it.
Image Rendering Can Make Fast Responses Feel Slow
Photo browsing makes the client gap more visible because a gallery is not just text and API metadata. A client may request many thumbnails or a larger preview, keep some in memory, decode compressed image data, scale it for the viewport, and compose several images while the user continues scrolling. The amount and timing of that local work can differ sharply between devices even when they request the same Immich asset.
Compressed formats such as JPEG and WebP must go through image decoding before pixels can be displayed. Faster CPUs, better optimized decoders, more available memory, and different browser engines can shorten that stage. On a weaker client, the network may finish first while decoding and painting become the part the user actually waits for.
The practical consequence is that a larger or sharper preview is not free merely because the server can generate it quickly. Higher-resolution images require more decoded pixel memory and more work to scale and draw. If one client becomes slow mainly while opening full previews or rapidly scrolling dense timelines, but simple metadata screens remain responsive, the image-rendering path is a stronger explanation than a server-wide capacity limit.
Warm Cache State Changes Repeat-Visit Speed
A client that has already browsed an album may reuse thumbnails, scripts, metadata, or decoded resources that a fresh client still needs to obtain and process. That makes the second pass shorter, but it does not mean the server suddenly gained capacity. It means part of the request path disappeared because the client started from a warmer state than it did on the first pass.
Real browser studies show that cache hit rates vary across browsers, versions, devices, and time. The exact Facebook percentages are not an Immich benchmark, but the mechanism matters: two clients can reach the same server with different local cache histories. A warmed desktop browser can therefore appear much more responsive than a newly installed phone app without proving that either client is inherently faster.
Cache also creates misleading before-and-after tests. Refreshing the same album several times can remove download and processing work from later runs, so the fastest run often measures reuse rather than a representative family workload. If the goal is to compare clients, record both a cold or newly opened path and a repeat path; the gap between them is itself useful evidence about how much each client depends on local reuse.
When Client Differences Stop Explaining the Delay
Client differences stop being the leading explanation when several otherwise different clients slow down at the same time under the same workload. If a desktop browser, phone, and tablet all wait longer for timeline data or preview responses while server CPU, storage latency, database activity, or network utilization rises, the shared infrastructure has become a more plausible floor on responsiveness than any one client implementation.
End-to-end timing should include more than the component that appears easiest to measure. A latency analysis from Datadog illustrates that round-trip latency can include network transfer, proxies, connection pools, and application decoding outside the database itself. The same principle applies to Immich: a healthy database number cannot rule out delay elsewhere between request start and a rendered result.
A useful boundary test is symmetry. If only one client is slow while another on the same LAN and album stays fast, client execution, caching, or local networking deserves more weight. If every client crosses the same latency threshold at roughly the same time, especially during imports, thumbnail generation, backups, or other host activity, the explanation has shifted from client variance toward a shared server, storage, or network constraint.
Use a Controlled Client Test to Find the Boundary
Pick one representative album and hold the server version, network location, account, image set, and background-job state constant. Test each client one at a time and record three observable timings: initial timeline load, opening the same large preview, and a rapid scroll through a fixed photo range. Also note whether the server shows a resource spike during each run, because a client comparison is invalid if the backend workload changes between samples.
Run each client once from a deliberately cold state and again immediately afterward. Performance testing commonly separates first-view and repeat-view results because populated caches remove work from later requests. For Immich, the cold-to-warm delta tells you how much reuse changes the experience, while the client-to-client delta under the same cache condition exposes differences that are more likely local to the device or application.
Treat a difference as client-bound only when it repeats across at least three runs and the faster client remains faster while server and network conditions stay comparable. If all clients degrade together, stop tuning the client and examine the common path. If only image-heavy actions diverge, focus on decode and rendering. If the difference appears only on the first run, cache stateโnot sustainable server capacityโis the more defensible conclusion.
Recommended products
Tech & AI HUB
More to Read
Open Models Are Catching Frontier AIโIs 2026 the Year Local AI Becomes Good Enough?
Open models are getting good enough for more local AI workloads, while frontier cloud models remain useful for the hardest reasoning and agent tasks.
NVIDIA PAIR Turns Your Home Network Into a Local AI ClusterโDo You Still Need One Big GPU Server?
NVIDIA PAIR spreads local AI requests across multiple PCs, making compute more elastic while one home server can keep data and state persistent.
Why Does Immich Feel Faster on LAN Than on Remote Connections?
LAN requests usually take a shorter, lower-latency path. Remote access adds WAN capacity limits and may add DNS, TLS, proxy, VPN, or relay hops.
