[bug] Filter panel takes 10–14 seconds to load on iPad with Chrome since v5.3.1, not reproducible on desktop

[photoserver-pro]

Description

Describe the bug

Since updating to v5.3.1, opening the Filter panel on an iPad using Chrome is extremely slow, taking roughly 10 to 14 seconds to load. This did not happen before this update, the same iPad has been used with Noodle for weeks/months without this issue. The same account and library on a Windows 11 desktop, also using Chrome, does not show this slowness at all.

To reproduce

1. Update to v5.3.1
2. Open Noodle on an iPad Pro 13" (M4) using Chrome
3. Open the Filter panel
4. Measure the time until the filter categories (Zeitleiste, Personen, Standort, Kamera, Tags, etc.) finish loading

Expected behavior

The Filter panel should load in a comparable time to before the v5.3.1 update, and comparable to the desktop experience, well under a second or two, not 10+ seconds.

Actual behavior

The Filter panel takes 10 to 14 seconds to fully load on the iPad. During this time, several categories briefly show as empty ("Keine Personen gefunden", "Keine Standorte gefunden", "Keine Kameras gefunden", "Keine Tags verfügbar") before presumably populating, see screenshot. On the same account/library via Chrome on a Windows 11 desktop, this delay does not occur at all.

Troubleshooting already done

• Fully restarted the iPad to rule out any client side caching issues, the problem persists
• Confirmed this is specific to this device/browser combination, since the same account works normally, without delay, on a Windows 11 desktop with Chrome
• The iPad is a modern, high performance device (iPad Pro 13" M4), so this is unlikely to be a hardware limitation

Impact

This makes the Filter panel, a core navigation tool, frustrating to use on iPad, one of the primary devices for browsing a photo library day to day. Given this started right after the v5.3.1 update and was not present before, on the exact same device and browser, this strongly points to a regression introduced in that release, rather than a pre-existing device limitation.

Environment

• Device: iPad Pro 13" (M4)
• Browser: Chrome
• Version: 5.3.1 (regression, not present in the version used previously)
• Comparison: not reproducible on Windows 11 desktop, Chrome, same account

Screenshots

1. Filter panel on iPad mid load: several categories showing "Keine ... gefunden/verfügbar" while still loading.

Gallery version

5.3.1

Platform

Web

Logs or screenshots

Additional context

No response

[Deeds67]

Thanks for the detailed report — the screenshot and the "works on desktop, same account" comparison were both genuinely useful.

I tried to reproduce this and haven't managed to yet, so I'd like to narrow it down with your help rather than guess.

What I tested

I ran a real WebKit browser (the engine Chrome uses on iPadOS — on iOS every browser is WebKit under the hood) against a v5.3.1 instance with a ~69,000-asset library, at the iPad Pro 13" viewport (1032×1376 @2x), and measured the time from page load to the filter categories being populated:

Engine	Viewport	Time to categories populated
WebKit	1032×1376 (iPad portrait)	2.3 s
WebKit	1032×1376 (repeat)	3.3 s
WebKit	1920×1080 (desktop)	3.2 s
Chromium	1032×1376 (iPad portrait)	2.9 s
Chromium	1920×1080 (desktop)	2.9 s

The filter panel issues exactly one request (GET /api/search/suggestions/filters); it returned in 471 ms with a 5 KB response. No difference between engines, and none between the iPad and desktop viewports.

So whatever is happening on your iPad isn't something I can see from the code path alone — which means it's likely specific to your device, network, or library, and I need a few data points to find it.

What would help most (in order — the first one takes five seconds and needs no iPad):

1. On your Windows desktop, narrow the Chrome window to about 1030px wide and reload. Does the slowness appear? This switches Gallery to the same compact-sidebar layout your iPad gets, so it tests the layout theory without involving the iPad at all.
2. Does Safari on the same iPad behave the same as Chrome? This separates "iPadOS in general" from "Chrome on iOS specifically."
3. The timing and size of one request. In DevTools → Network on the desktop, and (if you can) Safari Web Inspector on the iPad, find GET /api/search/suggestions/filters and tell me its size and whether the 10–14 s shows up as waiting for the server or as queued/stalled. That single number separates a server problem from a client/network one.
4. Is it only the filter panel, or the whole page? Does the photo grid itself also take 10–14 s to fill in on the iPad, or does it appear normally while only the filter panel lags?
5. Roughly how many named people and tags do you have? The filter suggestions response is unbounded, so a very large number of either makes it bigger. Mine was small (5 KB), so I couldn't test that end.

Also worth trying, since it's one setting: Settings → App Settings → Sidebar mode → Expanded on the iPad. That restores the pre-5.3.1 layout. If the delay persists with it set to Expanded, that rules out the sidebar change we made in 5.3.1.

Happy to dig further once I have any of the above.

[photoserver-pro]

I'll take some time in the next few days to look into the problem more closely and provide a comprehensive bug report.