Warum fühlt sich Immich auf verschiedenen Clients weniger reaktionsschnell an?

Immich kann sich auf einem Client langsamer anfühlen, weil clientseitiges Rendering, Bilddekodierung, Cache-Zustand und Netzwerkpfad nach der Antwort des Servers zusätzliche Arbeit verursachen.

Eine Familie kann dieselbe Bibliothek über einen Desktop-Browser, ein älteres Smartphone und ein Tablet durchsuchen, während Immich-Server, Speicher und Datenbank unverändert bleiben. Ein Gerät kann Zeitleisten oder Vorschauen trotzdem später öffnen, weil die Anfrage von Ende zu Ende auch Arbeit außerhalb des Servers umfasst. Der sinnvolle Vergleich ist daher die Antwortzeit des Servers gegenüber der zusätzlichen Zeit, die jeder Client für das Empfangen, Dekodieren, Zwischenspeichern und Zeichnen des Ergebnisses benötigt.

Der Client verändert die Arbeit nach der Antwort von Immich

Eine Immich-Anfrage endet nicht, wenn der Server JSON, eine Thumbnail-URL oder eine Bildantwort vorbereitet hat. Der Client muss diese Antwort weiterhin verarbeiten, seine Oberfläche aktualisieren, das Rendering einplanen und auf Benutzereingaben reagieren. Ein schneller Server kann daher mit einem träge wirkenden Client einhergehen, wenn das Gerät oder der Browser zusätzliche Zeit benötigt, um die zurückgegebenen Daten in einen sichtbaren, interaktiven Bildschirm umzuwandeln.

Dieser Unterschied ist besonders in Browsern wichtig, wo JavaScript, Ereignisverarbeitung, Stilberechnung, Layout und ein großer Teil des Zeichnens um Arbeit auf dem Hauptthread konkurrieren. Wenn ein älteres Smartphone oder ein ausgelasteter Browser diesen Thread länger blockiert, können Tippen und Scrollen verzögert reagieren, obwohl die Immich-API ungefähr zur gleichen Zeit abgeschlossen war wie auf einem schnelleren Desktop.

Deshalb greift es zu kurz, nur die CPU-Auslastung des Servers oder die Datenbanklatenz zu vergleichen. Die Diskussion von ZimaSpace über nativen und Browser-Clients zeigt dasselbe Systemprinzip: Ein Backend kann unterschiedliche Client-Ausführungspfade versorgen. Bei Immich lautet die erste Diagnosefrage, ob die Verzögerung vor dem Eintreffen der Antwort oder erst nach Beginn der Verarbeitung durch den Client auftritt.

Die Bilddarstellung kann schnelle Antworten langsam wirken lassen

Beim Durchsuchen von Fotos wird der Unterschied zwischen Clients deutlicher, weil eine Galerie nicht nur aus Text und API-Metadaten besteht. Ein Client kann viele Thumbnails oder eine größere Vorschau anfordern, einige davon im Speicher behalten, komprimierte Bilddaten dekodieren, sie an den Darstellungsbereich anpassen und mehrere Bilder zusammensetzen, während der Benutzer weiter scrollt. Umfang und Zeitpunkt dieser lokalen Arbeit können sich zwischen Geräten stark unterscheiden, selbst wenn sie dasselbe Immich-Asset anfordern.

Komprimierte Formate wie JPEG und WebP müssen zunächst dekodiert werden, bevor Pixel angezeigt werden können. Schnellere CPUs, besser optimierte Decoder, mehr verfügbarer Speicher und unterschiedliche Browser-Engines können diese Phase verkürzen. Auf einem schwächeren Client kann das Netzwerk zuerst fertig sein, während Dekodierung und Zeichnen zu dem Teil werden, auf den der Benutzer tatsächlich wartet.

Die praktische Folge ist, dass eine größere oder schärfere Vorschau nicht allein deshalb kostenlos ist, weil der Server sie schnell erzeugen kann. Bilder mit höherer Auflösung benötigen mehr Speicher für dekodierte Pixel sowie mehr Arbeit zum Skalieren und Zeichnen. Wenn ein Client hauptsächlich beim Öffnen vollständiger Vorschauen oder beim schnellen Scrollen durch dichte Zeitleisten langsam wird, einfache Metadatenansichten aber reaktionsfähig bleiben, spricht das eher für den Bilddarstellungspfad als für eine allgemeine Kapazitätsgrenze des Servers.

Ein warmer Cache verändert die Geschwindigkeit wiederholter Aufrufe

Ein Client, der ein Album bereits durchsucht hat, kann Thumbnails, Skripte, Metadaten oder dekodierte Ressourcen wiederverwenden, die ein neuer Client erst abrufen und verarbeiten muss. Dadurch ist der zweite Durchlauf kürzer, aber der Server hat nicht plötzlich mehr Kapazität. Vielmehr ist ein Teil des Anfragepfads entfallen, weil der Client mit einem wärmeren Zustand gestartet ist als beim ersten Durchlauf.

Studien zu realen Browsern zeigen, dass Cache-Trefferraten je nach Browser, Version, Gerät und Zeitpunkt variieren. Die konkreten Facebook-Prozentwerte sind kein Immich-Benchmark, aber der Mechanismus ist relevant: Zwei Clients können denselben Server mit unterschiedlicher lokaler Cache-Historie erreichen. Ein Desktop-Browser mit warmem Cache kann daher deutlich reaktionsschneller wirken als eine neu installierte Smartphone-App, ohne dass damit bewiesen wäre, dass einer der beiden Clients grundsätzlich schneller ist.

Der Cache kann außerdem Vorher-nachher-Tests irreführend machen. Wenn dasselbe Album mehrmals aktualisiert wird, können spätere Durchläufe Download- und Verarbeitungsarbeit einsparen, sodass der schnellste Durchlauf oft eher die Wiederverwendung als eine typische Familiennutzung misst. Wenn Clients verglichen werden sollen, sollten sowohl ein kalter oder neu geöffneter Pfad als auch ein wiederholter Pfad aufgezeichnet werden. Die Differenz zwischen beiden liefert selbst nützliche Hinweise darauf, wie stark jeder Client auf lokale Wiederverwendung angewiesen ist.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Wann Client-Unterschiede die Verzögerung nicht mehr erklären

Client-Unterschiede sind nicht mehr die wahrscheinlichste Erklärung, wenn mehrere ansonsten unterschiedliche Clients unter derselben Arbeitslast gleichzeitig langsamer werden. Wenn ein Desktop-Browser, ein Smartphone und ein Tablet gleichzeitig länger auf Zeitleistendaten oder Vorschauantworten warten, während CPU-Auslastung des Servers, Speicherlatenz, Datenbankaktivität oder Netzwerkauslastung steigen, ist die gemeinsame Infrastruktur als Ursache für die Grundverzögerung plausibler als die Implementierung eines einzelnen Clients.

Die Ende-zu-Ende-Zeitmessung sollte mehr umfassen als die Komponente, die am einfachsten zu messen scheint. Eine Latenzanalyse von Datadog zeigt, dass die Round-Trip-Latenz Netzwerkübertragung, Proxys, Verbindungspools und die Dekodierung durch die Anwendung außerhalb der Datenbank umfassen kann. Dasselbe Prinzip gilt für Immich: Ein unauffälliger Datenbankwert schließt keine Verzögerung an anderer Stelle zwischen dem Beginn der Anfrage und dem gerenderten Ergebnis aus.

Ein nützlicher Abgrenzungstest ist die Symmetrie. Wenn nur ein Client langsam ist, während ein anderer im selben LAN und mit demselben Album schnell bleibt, sollten Client-Ausführung, Caching oder lokale Netzwerkbedingungen stärker berücksichtigt werden. Wenn alle Clients ungefähr zur gleichen Zeit dieselbe Latenzschwelle überschreiten, insbesondere während Importen, der Thumbnail-Erzeugung, Backups oder anderer Host-Aktivitäten, hat sich die Erklärung von Client-Variationen hin zu einer gemeinsamen Einschränkung durch Server, Speicher oder Netzwerk verschoben.

Mit einem kontrollierten Client-Test die Grenze finden

Wähle ein repräsentatives Album und halte Serverversion, Netzwerkstandort, Konto, Bildbestand und Zustand der Hintergrundaufgaben konstant. Teste jeden Client einzeln und notiere drei beobachtbare Zeitwerte: das anfängliche Laden der Zeitleiste, das Öffnen derselben großen Vorschau und schnelles Scrollen durch einen festgelegten Fotobereich. Notiere außerdem, ob der Server während jedes Durchlaufs einen Ressourcenspitzenwert zeigt, da ein Client-Vergleich ungültig ist, wenn sich die Backend-Arbeitslast zwischen den Messungen verändert.

Führe jeden Client einmal aus einem bewusst kalten Zustand und anschließend sofort noch einmal aus. Bei Leistungstests werden häufig Erstaufruf- und Wiederholungsaufruf-Ergebnisse getrennt betrachtet, weil gefüllte Caches bei späteren Anfragen Arbeit einsparen. Bei Immich zeigt die Differenz zwischen kalt und warm, wie stark die Wiederverwendung das Nutzungserlebnis verändert. Die Differenz zwischen Clients unter derselben Cache-Bedingung macht dagegen Unterschiede sichtbar, die eher lokal auf das Gerät oder die Anwendung zurückzuführen sind.

Ordne einen Unterschied nur dann dem Client zu, wenn er sich in mindestens drei Durchläufen wiederholt und der schnellere Client bei vergleichbaren Server- und Netzwerkbedingungen schneller bleibt. Wenn alle Clients gleichzeitig schlechter werden, sollte die Optimierung des Clients beendet und der gemeinsame Pfad untersucht werden. Wenn nur bildintensive Aktionen auseinanderlaufen, sollte der Fokus auf Dekodierung und Rendering liegen. Wenn der Unterschied nur beim ersten Durchlauf auftritt, ist der Cache-Zustand die besser begründbare Schlussfolgerung – nicht eine dauerhaft verfügbare Serverkapazität.