Pourquoi Immich semble-t-il moins réactif sur différents clients ?

Immich peut sembler plus lent sur un client parce que le rendu côté client, le décodage des images, l’état du cache et le chemin réseau ajoutent du travail après la réponse du serveur.

Une famille peut parcourir la même bibliothèque depuis un navigateur de bureau, un téléphone ancien et une tablette, tandis que le serveur Immich, le stockage et la base de données restent inchangés. Un appareil peut malgré tout ouvrir les chronologies ou les aperçus plus tard, car la requête de bout en bout inclut des opérations effectuées en dehors du serveur. La comparaison utile oppose donc le temps de réponse du serveur au temps supplémentaire que chaque client consacre à recevoir, décoder, mettre en cache et afficher le résultat.

Le client modifie le travail effectué après la réponse d’Immich

Une requête Immich ne se termine pas lorsque le serveur a préparé le JSON, une URL de miniature ou une réponse contenant une image. Le client doit encore traiter cette réponse, mettre à jour son interface, planifier le rendu et réagir aux entrées de l’utilisateur. Un serveur rapide peut donc coexister avec un client qui semble lent lorsque l’appareil ou le navigateur passe davantage de temps à transformer les données reçues en écran visible et interactif.

Cette distinction est particulièrement importante dans les navigateurs, où JavaScript, la gestion des événements, le calcul des styles, la mise en page et une grande partie de l’affichage se disputent le travail du thread principal. Si un téléphone ancien ou un navigateur très sollicité monopolise ce thread plus longtemps, les appuis et le défilement peuvent subir des ralentissements, même si l’API Immich a terminé à peu près au même moment que sur un ordinateur de bureau plus rapide.

C’est pourquoi comparer uniquement le processeur du serveur ou la latence de la base de données ne rend pas compte de toute l’expérience. L’analyse de ZimaSpace sur les clients natifs et les navigateurs montre le même principe systémique : un même backend peut alimenter des chemins d’exécution différents côté client. Pour Immich, la première question de diagnostic consiste à déterminer si le délai se produit avant l’arrivée de la réponse ou après le début de son traitement par le client.

Le rendu des images peut donner l’impression que les réponses rapides sont lentes

La navigation dans les photos rend l’écart entre clients plus visible, car une galerie ne se limite pas à du texte et à des métadonnées d’API. Un client peut demander de nombreuses miniatures ou un aperçu plus grand, en conserver certaines en mémoire, décoder les données d’image compressées, les redimensionner pour la fenêtre d’affichage et composer plusieurs images pendant que l’utilisateur continue de faire défiler la page. La quantité et le moment de ce travail local peuvent varier fortement d’un appareil à l’autre, même lorsqu’ils demandent le même élément Immich.

Les formats compressés tels que JPEG et WebP doivent passer par le décodage des images avant que les pixels puissent être affichés. Des processeurs plus rapides, des décodeurs mieux optimisés, davantage de mémoire disponible et des moteurs de navigateur différents peuvent raccourcir cette étape. Sur un client moins puissant, le réseau peut avoir terminé en premier, tandis que le décodage et l’affichage deviennent l’étape que l’utilisateur attend réellement.

En pratique, un aperçu plus grand ou plus net n’est pas gratuit simplement parce que le serveur peut le générer rapidement. Les images en haute résolution nécessitent davantage de mémoire pour les pixels décodés ainsi que plus de travail pour les redimensionner et les afficher. Si un client ralentit principalement lors de l’ouverture des aperçus complets ou du défilement rapide de chronologies denses, tandis que les écrans contenant de simples métadonnées restent réactifs, le chemin de rendu des images constitue une explication plus probable qu’une limite générale de capacité du serveur.

L’état du cache à chaud modifie la vitesse des visites répétées

Un client qui a déjà parcouru un album peut réutiliser des miniatures, des scripts, des métadonnées ou des ressources décodées qu’un client fraîchement ouvert doit encore obtenir et traiter. Le deuxième parcours est ainsi plus court, mais cela ne signifie pas que le serveur a soudainement gagné en capacité. Cela signifie qu’une partie du chemin de la requête a disparu, car le client a commencé dans un état plus favorable que lors du premier parcours.

Des études réelles sur les navigateurs montrent que les taux d’accès au cache varient selon les navigateurs, les versions, les appareils et le moment. Les pourcentages exacts de Facebook ne constituent pas une référence pour Immich, mais le mécanisme est important : deux clients peuvent atteindre le même serveur avec des historiques de cache locaux différents. Un navigateur de bureau dont le cache est déjà rempli peut donc sembler bien plus réactif qu’une application installée récemment sur un téléphone, sans prouver que l’un ou l’autre client est intrinsèquement plus rapide.

Le cache peut également fausser les tests avant-après. Actualiser plusieurs fois le même album peut supprimer le téléchargement et le traitement des exécutions suivantes, de sorte que la mesure la plus rapide évalue souvent la réutilisation plutôt qu’une charge familiale représentative. Si l’objectif est de comparer des clients, enregistrez à la fois un parcours à froid ou nouvellement ouvert et un parcours répété ; l’écart entre les deux fournit en lui-même des indications utiles sur la dépendance de chaque client à la réutilisation locale.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Quand les différences entre clients n’expliquent plus le délai

Les différences entre clients cessent d’être l’explication principale lorsque plusieurs clients par ailleurs différents ralentissent en même temps sous la même charge. Si un navigateur de bureau, un téléphone et une tablette attendent tous plus longtemps les données de chronologie ou les réponses d’aperçu tandis que l’utilisation du processeur du serveur, la latence du stockage, l’activité de la base de données ou l’utilisation du réseau augmente, l’infrastructure partagée devient une limite de réactivité plus probable que l’implémentation d’un client particulier.

La mesure de bout en bout doit inclure davantage que le composant qui semble le plus facile à mesurer. Une analyse de la latence réalisée par Datadog montre que la latence aller-retour peut inclure le transfert réseau, les proxys, les pools de connexions et le décodage côté application, en dehors de la base de données elle-même. Le même principe s’applique à Immich : une mesure saine de la base de données ne permet pas d’exclure un délai ailleurs entre le début de la requête et l’affichage du résultat.

Un test utile consiste à vérifier la symétrie. Si un seul client est lent tandis qu’un autre, sur le même réseau local et avec le même album, reste rapide, l’exécution côté client, la mise en cache ou le réseau local méritent davantage d’attention. Si tous les clients franchissent le même seuil de latence à peu près au même moment, notamment pendant des importations, la génération de miniatures, des sauvegardes ou une autre activité de l’hôte, l’explication passe de la variation entre clients à une contrainte partagée du serveur, du stockage ou du réseau.

Utilisez un test contrôlé entre clients pour localiser la limite

Choisissez un album représentatif et gardez constants la version du serveur, l’emplacement réseau, le compte, le jeu d’images et l’état des tâches en arrière-plan. Testez chaque client séparément et notez trois temps observables : le chargement initial de la chronologie, l’ouverture du même grand aperçu et un défilement rapide sur une plage de photos fixe. Notez également si le serveur présente un pic de ressources pendant chaque test, car une comparaison entre clients n’est pas valable si la charge du backend change entre les mesures.

Exécutez chaque test une fois dans un état volontairement froid, puis immédiatement une seconde fois. Les tests de performance distinguent généralement les résultats de première vue et de vue répétée, car les caches remplis suppriment du travail lors des requêtes suivantes. Pour Immich, l’écart entre l’état froid et l’état chaud indique dans quelle mesure la réutilisation modifie l’expérience, tandis que l’écart entre clients dans les mêmes conditions de cache met en évidence des différences plus probablement liées à l’appareil ou à l’application.

Ne considérez une différence comme propre au client que si elle se répète sur au moins trois exécutions et que le client le plus rapide reste le plus rapide alors que les conditions du serveur et du réseau restent comparables. Si tous les clients se dégradent ensemble, cessez d’optimiser le client et examinez le chemin commun. Si seuls les usages fortement axés sur les images divergent, concentrez-vous sur le décodage et le rendu. Si la différence apparaît uniquement lors de la première exécution, l’état du cache — et non la capacité durable du serveur — constitue la conclusion la plus défendable.