immich-app/immich
1
0
Fork 0
mirror of https://github.com/immich-app/immich.git synced 2026-07-25 14:00:45 +03:00
Code Issues 783 Packages Projects Releases 22 Wiki Activity

Uploading large amounts of files via the web causes browser lag. #7191

New Issue
Closed
opened 2026-02-05 12:51:32 +03:00 by OVERLORD · 1 comment
OVERLORD commented 2026-02-05 12:51:32 +03:00
Owner
Copy Link

Originally created by @baramofme on GitHub (Sep 14, 2025).

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

  • Yes

The bug

When uploading a large number of images via the web, if the upload window is open, it causes severe lag not only in the browser but also on the desktop.

maybe too many reflow occurs makes browser laggy. when during processing too many box inside upload popup.

The OS that Immich Server is running on

windows 11 pro

Version of Immich Server

v1.142.0

Version of Immich Mobile App

none

Platform with the issue

  • Server
  • Web
  • Mobile

Device make and model

x86 intel based desktop

Your docker-compose.yml content

official docker compose. not modified.
https://immich.app/docs/install/docker-compose/

Your .env content

official .env . not modified.
https://immich.app/docs/install/docker-compose/

Reproduction steps

  1. connect web immich
  2. drag and drop folder contains more than 20000 images
  3. upload window popup
  4. browser legs
  5. desktop legs
  6. collapse upload popup
  7. browser and deskop legs gone
  8. ...

Relevant log output

Additional information

  1. At first, the browser slows down. Then the entire desktop slows down and lags.

But strangely, the CPU, memory, and disk status are not bad.
Image

However, the browser keeps flickering, and the upload process repeatedly starts and stops. Even the Proxmox status stops communicating with the server in real time.

Monitoring the resources of the Proxmox LXC server shows that CPU and memory usage are low.
Image

  1. Minimizing the upload window eliminates browser and desktop lag.

https://github.com/user-attachments/assets/a8824961-c617-4d0c-abd0-e4993b9a9097

  1. I recorded browser performance when lag occurs. Force reflow happens.
    Event listener leaks are suspected to cause screen lag, as multiple clicks remain in memory.
Image

Speculation

I believe this is lag caused by reflow (screen recalculation) while processing numerous upload item boxes inside upload popup.

https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing?utm_source=devtools&utm_campaign=stable&hl=ko#avoid-forced-synchronous-layouts

Eliminated canidates

  1. It is not an issue with immich containers or Proxmox LXC.
    Server and desktop CPU, memory, and HDD usage are normal, but the browser flickers and abnormal situations recur.
  2. It is not a Windows issue.
    Desktop CPU, memory, and HDD usage are normal. The browser flickers and abnormal situations repeat.
  3. It is not a browser memory leak.
    During screen lag, the heap remains low in browser performance metrics.
  4. This is not an issue of the main thread being occupied due to JavaScript processing.
    Minimizing the upload window so the upload process is not visible on screen eliminates lag. JavaScript processing continues regardless of whether the upload window is minimized.

Proposal

When a relatively large number of upload items are added during an upload (100 items? I'm not entirely sure.), try applying the technique below.

  1. Virtualization - recommend, but need som dev resources
    For very large lists (like your 20,000 boxes), virtualization is the most effective solution. This technique only renders the elements that are currently visible within the user's viewport. As the user scrolls, new elements are dynamically added to the visible area, and elements that move out of view are removed. This keeps the number of DOM elements low, preventing performance issues caused by a massive DOM tree. Libraries like react-virtualized or react-window are excellent for this purpose.

  2. Use display: none - easy, not much dev resources
    If you just want to hide elements from view without completely deleting them from the DOM, you can set their CSS property to display: none. While this still triggers a reflow, it can be less resource-intensive than repeatedly deleting and creating DOM nodes, especially if you need to show them again later.

  3. Batch Updates - looks laggy for users
    Instead of removing elements one by one at short intervals, group multiple DOM operations together and execute them at once. For instance, instead of deleting a box every 0.3 seconds, delete a batch of 10 boxes every 3 seconds. This reduces the number of times the browser has to perform a reflow, significantly improving performance.

  4. Use document.createDocumentFragment() -- looks broken for users
    When adding or removing a large number of elements, use document.createDocumentFragment(). This is an in-memory DOM node that acts as a temporary container. You can add or remove multiple elements from this fragment without triggering a reflow. Once all the operations are complete, append the entire fragment to the real DOM in a single step. This causes only one reflow instead of many.

Originally created by @baramofme on GitHub (Sep 14, 2025). ### I have searched the existing issues, both open and closed, to make sure this is not a duplicate report. - [x] Yes ### The bug When uploading a large number of images via the web, if the upload window is open, it causes severe lag not only in the browser but also on the desktop. maybe too many reflow occurs makes browser laggy. when during processing too many box inside upload popup. ### The OS that Immich Server is running on windows 11 pro ### Version of Immich Server v1.142.0 ### Version of Immich Mobile App none ### Platform with the issue - [ ] Server - [x] Web - [ ] Mobile ### Device make and model x86 intel based desktop ### Your docker-compose.yml content ```YAML official docker compose. not modified. https://immich.app/docs/install/docker-compose/ ``` ### Your .env content ```Shell official .env . not modified. https://immich.app/docs/install/docker-compose/ ``` ### Reproduction steps 1. connect web immich 2. drag and drop folder contains more than 20000 images 3. upload window popup 4. browser legs 5. desktop legs 6. collapse upload popup 7. browser and deskop legs gone 8. ... ### Relevant log output ```shell ``` ### Additional information 1. At first, the browser slows down. Then the entire desktop slows down and lags. But strangely, the CPU, memory, and disk status are not bad. <img width="419" height="346" alt="Image" src="https://github.com/user-attachments/assets/38fa703b-67c9-4a62-8aea-2f5e2bff07ff" /> However, the browser keeps flickering, and the upload process repeatedly starts and stops. Even the Proxmox status stops communicating with the server in real time. Monitoring the resources of the Proxmox LXC server shows that CPU and memory usage are low. <img width="1106" height="996" alt="Image" src="https://github.com/user-attachments/assets/2d3e9fba-5fcc-4aa9-8a4d-bf7db05c4b7e" /> 2. Minimizing the upload window eliminates browser and desktop lag. https://github.com/user-attachments/assets/a8824961-c617-4d0c-abd0-e4993b9a9097 3. I recorded browser performance when lag occurs. Force reflow happens. Event listener leaks are suspected to cause screen lag, as multiple clicks remain in memory. <img width="1492" height="889" alt="Image" src="https://github.com/user-attachments/assets/62852d65-e08c-4613-acc0-5ea62055c511" /> ### Speculation I believe this is lag caused by reflow (screen recalculation) while processing numerous upload item boxes inside upload popup. https://web.dev/articles/avoid-large-complex-layouts-and-layout-thrashing?utm_source=devtools&utm_campaign=stable&hl=ko#avoid-forced-synchronous-layouts Eliminated canidates 1. It is not an issue with immich containers or Proxmox LXC. Server and desktop CPU, memory, and HDD usage are normal, but the browser flickers and abnormal situations recur. 2. It is not a Windows issue. Desktop CPU, memory, and HDD usage are normal. The browser flickers and abnormal situations repeat. 3. It is not a browser memory leak. During screen lag, the heap remains low in browser performance metrics. 4. This is not an issue of the main thread being occupied due to JavaScript processing. Minimizing the upload window so the upload process is not visible on screen eliminates lag. JavaScript processing continues regardless of whether the upload window is minimized. ### Proposal When a relatively large number of upload items are added during an upload (100 items? I'm not entirely sure.), try applying the technique below. 4. Virtualization - recommend, but need som dev resources For very large lists (like your 20,000 boxes), virtualization is the most effective solution. This technique only renders the elements that are currently visible within the user's viewport. As the user scrolls, new elements are dynamically added to the visible area, and elements that move out of view are removed. This keeps the number of DOM elements low, preventing performance issues caused by a massive DOM tree. Libraries like react-virtualized or react-window are excellent for this purpose. 3. Use display: none - easy, not much dev resources If you just want to hide elements from view without completely deleting them from the DOM, you can set their CSS property to display: none. While this still triggers a reflow, it can be less resource-intensive than repeatedly deleting and creating DOM nodes, especially if you need to show them again later. 1. Batch Updates - looks laggy for users Instead of removing elements one by one at short intervals, group multiple DOM operations together and execute them at once. For instance, instead of deleting a box every 0.3 seconds, delete a batch of 10 boxes every 3 seconds. This reduces the number of times the browser has to perform a reflow, significantly improving performance. 2. Use document.createDocumentFragment() -- looks broken for users When adding or removing a large number of elements, use document.createDocumentFragment(). This is an in-memory DOM node that acts as a temporary container. You can add or remove multiple elements from this fragment without triggering a reflow. Once all the operations are complete, append the entire fragment to the real DOM in a single step. This causes only one reflow instead of many.
OVERLORD commented 2026-02-05 12:51:35 +03:00
Author
Owner
Copy Link

@bo0tzz commented on GitHub (Sep 14, 2025):

If you're uploading a large amount of assets, please use the cli https://immich.app/docs/features/command-line-interface/

@bo0tzz commented on GitHub (Sep 14, 2025): If you're uploading a large amount of assets, please use the cli https://immich.app/docs/features/command-line-interface/
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
accessibility
changelog:enhancement
changelog:security
changelog:skip
changelog:translation
cli
date-time
dependencies
documentation
external-library
format
good first issue
mobile-beta
mobile-beta
mobile-beta
needs-answer
nice to have
pull-request
Mirrored from GitHub Pull Request
 sharing
tech-debt
📱mobile
🖥️web
🗄️server
🧠machine-learning
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: immich-app/immich#7191
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?