Performance regression i Immich WEB UI in 2.5.2 when using Firefox browsers desktop and mobile

[elversoee]

I have searched the existing issues, both open and closed, to make sure this is not a duplicate report.

• Yes

The bug

After upgrading to Immich 2.5.2 login in using my primary browser Firefox 147.0.1 on windows
jumping to my albums section is very slow to load 7 seconds (i have many albums) normally not that slow then after wanting to go back to the timeline it takes 10 seconds to load the timeline this only happens on firefox browsers both mobile and desktop.
Testing the same scenario on brave browser v1.86.146 it takes 2 seconds for album load and loading the timeline takes under a sec.
i have tested through my normally used reverse proxy and directly on the immich ip/port,
Deleted cache but nothing is helping.

The OS that Immich Server is running on

Debian 13 Vm on proxmox

Version of Immich Server

2.5.2

Version of Immich Mobile App

2.5.2 build 5033

Platform with the issue

• Server
• Web
• Mobile

Device make and model

Asus Zenfone 9 Android 14

Your docker-compose.yml content

#
# WARNING: To install Immich, follow our guide: https://docs.immich.app/install/docker-compose
#
# Make sure to use the docker-compose.yml of the current release:
#
# https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
#
# The compose file on main may not be compatible with the latest release.

name: immich

services:
  immich-server:
    container_name: immich_server
    image: ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}
    # extends:
    #   file: hwaccel.transcoding.yml
    #   service: cpu # set to one of [nvenc, quicksync, rkmpp, vaapi, vaapi-wsl] for accelerated transcoding
    volumes:
      # Do not edit the next line. If you want to change the media storage location on your system, edit the value of UPLOAD_LOCATION in the .env file
      - ${UPLOAD_LOCATION}:/data
      - /etc/localtime:/etc/localtime:ro
    env_file:
      - .env
    ports:
      - '2283:2283'
    depends_on:
      - redis
      - database
    restart: always
    healthcheck:
      disable: false

  immich-machine-learning:
    container_name: immich_machine_learning
    # For hardware acceleration, add one of -[armnn, cuda, rocm, openvino, rknn] to the image tag.
    # Example tag: ${IMMICH_VERSION:-release}-cuda
    image: ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}
    # extends: # uncomment this section for hardware acceleration - see https://docs.immich.app/features/ml-hardware-acceleration
    #   file: hwaccel.ml.yml
    #   service: cpu # set to one of [armnn, cuda, rocm, openvino, openvino-wsl, rknn] for accelerated inference - use the `-wsl` version for WSL2 where applicable
    volumes:
      - model-cache:/cache
    env_file:
      - .env
    restart: always
    healthcheck:
      disable: false

  redis:
    container_name: immich_redis
    image: docker.io/valkey/valkey:9@sha256:546304417feac0874c3dd576e0952c6bb8f06bb4093ea0c9ca303c73cf458f63
    healthcheck:
      test: redis-cli ping || exit 1
    restart: always

  database:
    container_name: immich_postgres
    image: ghcr.io/immich-app/postgres:14-vectorchord0.4.3-pgvectors0.2.0@sha256:bcf63357191b76a916ae5eb93464d65c07511da41e3bf7a8416db519b40b1c23
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
      POSTGRES_USER: ${DB_USERNAME}
      POSTGRES_DB: ${DB_DATABASE_NAME}
      POSTGRES_INITDB_ARGS: '--data-checksums'
      # Uncomment the DB_STORAGE_TYPE: 'HDD' var if your database isn't stored on SSDs
      # DB_STORAGE_TYPE: 'HDD'
    volumes:
      # Do not edit the next line. If you want to change the database storage location on your system, edit the value of DB_DATA_LOCATION in the .env file
      - ${DB_DATA_LOCATION}:/var/lib/postgresql/data
    shm_size: 128mb
    restart: always
    healthcheck:
      disable: false

volumes:
  model-cache:

Your .env content

# You can find documentation for all the supported env variables at https://immich.app/docs/install/environment-variables

# The location where your uploaded files are stored
UPLOAD_LOCATION=/mnt/immich
# The location where your database files are stored
DB_DATA_LOCATION=/immichDATA/immichDB/

# To set a timezone, uncomment the next line and change Etc/UTC to a TZ identifier from this list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones#List
TZ=DK

# The Immich version to use. You can pin this to a specific version like "v1.71.0"
IMMICH_VERSION=v2

# Connection secret for postgres. You should change it to a random password
# Please use only the characters `A-Za-z0-9`, without special characters or spaces
DB_PASSWORD=redacted

# The values below this line do not need to be changed
###################################################################################
DB_USERNAME=postgres
DB_DATABASE_NAME=immich
MACHINE_LEARNING_PRELOAD__CLIP__TEXTUAL=nllb-clip-large-siglip__v1

Reproduction steps

1. Login in to Immich web UI (On server 2.5.2 from 2.4.1) from firefox browser
2. Timeline loads fine on first login from login screen
3. Go to Albums using the "albums button" nothing happens until about 7 sec after (Not normal)
4. The the albums load after albums is loaded go to timeline with the "images button"
5. then nothing happens until after about 10 sec then the timeline loads
6. going between albums and timeline after these initial load times nothing changes it still take a very long loading time
7. testing the same scenarios on brave browser, everything works as expected like before 2.5.2
   ...

Relevant log output

Additional information

i have tested on mobile and the problem is the same on mobile Firefox vs mobile Brave

[mmomjian]

Unable to replicate with firefox 147.0.2 on windows 10

[bo0tzz]

Can you reproduce this on https://demo.immich.app ?

[elversoee]

Can you reproduce this on https://demo.immich.app ?

@bo0tzz
No i can not the demo server works as my 2.4.1 instance. meaning great.

i have tried to revert my compose file from version 2.4.1 because there was a change in the redis container but that did not change anything either still same result.

i have then tested jumping to random places in the timeline and the back to the top i works as i would expect (Fast)
i have 43.668 assets and 1132 albums in my profile.
but i had one of my other users on this instance log in on there account from my pc in Firefox this user has 8.042 assets and 156 albums and this user do not have problems on my machine. so this seems that is it my specific account that have problems.

Would it be possible to roll back the server to 2.4.1 just from the compose change or have there been changes in the database that it would not be advisable ??

[alextran1502]

I'd advise not going back to v2.4.1. Do you mind opening the Browser's network (F12), performing the navigation between pages, and capturing the screenshot of the request that takes an extremely long time?

[Nerdiyde]

Hey Guys,
just want to add that I experience the same on Firefox 147.0.2 (64-Bit) (Windows). Additionally for me the App also shows the same "slow" behaviour on iOs and Android.
Accessing it via Chrome is fine and works as usual.
Let me know when you need any logs. :)

[alextran1502]

@Nerdiyde, can you help describe what you are observing?

[Nerdiyde]

More or less exactly the same what OP described.
When I open the album view loading the page takes ~30seconds.
This seems to happen only on the album view. If I open the normal "Photos" view the load speed is as usual.

I used the Firefox profiler to record the "load time" and (I think many other details). In that case accessing the page took >1min.
You can see it here: https://profiler.firefox.com/public/0axv950ep51qacawd58r2a725n841rjtqxmj7kg/calltree/?globalTrackOrder=0w4&thread=5&v=13

Hope this helps. If you need anything else let me know.

Thanks for your help. :)

Edit: https://demo.immich.app/albums is working normal for me.
My immich instance is running on an N100/16GB RAM via docker compose. Overall system load is low so I would not expect an issue here...

[elversoee]

@alextran1502

From loaded timeline pushing the albums button

From loaded albums pushing pictures button. but the weird thing is when looking in the console network tab, when pushing the "pictures" button Nothing no request no lines in the console is changing absolutely nothing is happening until after about 6-7 seconds then alot happens and it is done in about a 1 sec.... it is like i do not push the button until after 7 sec

But when i change the album page from loading between "covers and list" there is again this long "pause" of about 7 sec and in the console no network request is made "nothing" is happening but after about 7 sec the album page changes between list and cover.

and for what ever reason many times now when jumping between timeline and albums the albums page is just black background and not loading at all, having to reload the page with F5.

but it seems that when going from loaded albums page with "list type" to the timeline the weird delay is not present but then going from from timeline to albums with "list type" it triggers the black background and never loads without manual refresh.

and it is all very non consistent and not always reproducible sometimes it works other it is not and i haven't found the specific course yet..
Pleas let me know if you need more info i will try deliver to the best of my abilities

[jrasm91]

The issue seems to be that the /assets/:id/thumbnail?edited=true request is taking around 500ms for each thumbnail. On the albums page, when it is a cover grid (not the list) it will try to make a lot of requests for the album covers. It's probably getting stuck with so many requests all being made at the same time and the requests themselves being very slow. We probably need to figure out where the bottleneck is coming from. There's network latency to the immich-server itself, and then the time it takes to do the necessary database queries, and finally the part that reads the file from disk and sends it back.

Can you answer a few questions?

• If you open one of these thumbnail requests in a separate tab does it load immediately or continue to take about 500ms?
• Do thumbnails on the timeline load immediately or do they also take 500ms?
• Are you the owner of the assets for which the thumbnails are taking a long time to load?
• Does you see any server logs? If you enable verbose logging, you should see a log saying how long the API endpoint took to respond

[elversoee]

It might be worth clicking for performance tab and recording and sharing a trace of the page. It definitely seems like a client/browser issue. Almost like it's getting bottleneck/stuck in some part of the code.

@jrasm91
Here you go https://share.firefox.dev/4tDVqtx

[elversoee]

It would be interesting to see if this issue was limited to Firefox, or if you can produce it on Chrome or other browsers. Also, is it a problem on a browser on your mobile device?

Updated to Immich 2.5.5 server and app
I have already tested that, please se previous posts.
But Firefox mobile (147.0.3) also have problems
Brave Mobile (1.86.148) and Brave desktop (1.86.148) windows 10 64 Bit do Not have problems

[jrasm91]

I haven't looked at it yet but I think it might be this issue, so it should get fixed once we bump the immich/ui dependency.

immich-app/ui#573

[elversoee]

Interesting..
Thanks

[elversoee]

@jrasm91
updated to 2.5.6 have improved the loading times on firefox
probably #26025 Thanks @michelheusschen
it is how ever still not on 2.4.x speeds i will try to test and time things and compare to brave browser next week

[nixon-do]

I have had the same issue since I updated as well (hello fellow Dane here), the Web UI isn't loading more than just the /photos/ url but with no pictures and 100% cpu.

All my other tabs in firefox can't reach any url while the webui uses 100%, the only solution is to kill the web content PID with btop or kill -9.

But I can see on my phone that photos sync fine.

Server is 2.2.1, docker on a raspberry pi 4. Browser is Firefox 147.0.3 on Arch linux.

[jrasm91]

I'm pretty sure there is a performance issue on 2.2.1 that is fixed upgrading to 2.4.0 or later, so you probably just need to update.

[jonathanjuursema]

Just wanted to chip in that I'm also running into this issue.

My main observation:

• The initial load of the main timeline takes a few seconds
• Clicking to the Album overview page instantly displays all albums with title and metadata, but almost all without thumbnail
• All thumbnails show up at the same time around 5 seconds after the page otherwise completed loading

I'm running Immich 2.5.6 behind an nginx proxy. This behavior shows up in Zen Browser (Firefox).

I've tried to troubleshoot the issue with an LLM (I first thought I'd just needed to tweak some settings either in Immich or nginx). That troubleshooting pointed towards Service Workers. In the last scenario (local access) where it does work in Zen no Service Workers are registered. Moreover, in my regular access path (the nginx proxied version in Zen browser) I can make the issue disappear by disabling service workers in Firefox globally.

The problem also does not show up in Zen when accessing Immich locally (not via the nginx proxy). In that case, no service worker seems to have registered according to the developer tools.

I don't observe the problem in Safari (Mobile) or Chrome (Desktop) (through my nginx proxy).

Note: I have a technical background but not in webdev, I don't know what these service workers are supposed to do.

I'm more than happy to provide additional information

[jonathanjuursema]

I just today upgraded to v2.6.1. As far as I can tell this fixed the issue in the web UI, and it also improved the performance of the iOS app. I found references to streamlining the HTTP implementation, so it would make sense to me.

For the original poster: do give v2.6.1 a try. As far as I'm concerned, I think this issue is solved. Thank you!

[elversoee]

@jrasm91
Some un scientific test of my Immich Instance
2.5.6 improved a lot from initial 2.5.x release
2.6.1 is also just so ever slightly faster. and feels more responsible

But Testing on the same Client PC Windows 10 64 bit with Firefox 64 bit 148.0 and Brave 64 bit version 1.88.134
Wired 2.5GbE connection to the same LAN that the Immich Instance is on
through my Reverse proxy "HA Proxy" on my Pfsense Box.
i have 1135 Albums i my profile

From Login screen to loaded timeline
Firefox = around 1 sec.
Brave = under 1 sec.

From loaded timeline to album page with thumbnails
Firefox = just under 3 sec == way better that initial 2.5.x version that was around 10-12 sec and 2.5.6/2.6.1 is absolutely okay
Brave = under 1,5 sec

From loaded Albums back to timeline
Firefox = 1,8 sec
Brave = under 0,5 sec

From loaded album to logout screen
Firefox = around 1 sec
Brave = Instant 0,3 sec

I have tested the "service worker" that @jonathanjuursema mentioned but that did not change anything for me.

But Firefox is my primary Browser and i would of course like that it works just as good as all the "google alternatives"
and that i know it worked in the 2.4.x release because it was the "log out" delay that initially "caught my attention"
that led to the rest off all the tests.

Thanks
/Martin

[jrasm91]

Yeah, sounds like the non-firefox browsers have some extra optimizations. I'm glad that it is usable again though. We will try to do some performance testing in the next few releases to make sure albums stays snappy.

[zivshek]

switching to chrome resolved the issue for me... but yeah, Immich on Firefox is very slow, it can take forever to open a video and many times I need to refresh a few times for a page to show.

[elversoee]

Yes... but the point of using Immich is to not bee dependent on google...
still using Android... not made the jump to grapheneOS yet

[zivshek]

I totally agree, so I switched to Brave, which is also fast and private, I also tested on Vivaldi, also fast, maybe it’s a chromium thing. I still use Firefox on my phone, because all chromium browsers don’t work well with Bitwarden.