Why do you need the EAGER_COUNT at all? Doesn't the browser load the ones marked with 'auto' immediately for the ones that are above the fold? If you do need this EAGER_COUNT trick then you're going to have do do some math that depends on viewport size, grid layout, and image dimensions.
The browser’s auto for content-visibility is not about loading priority, it just skips rendering work for off-screen elements. For img loading, auto doesn’t exist, you get eager or lazy. So if you set everything to lazy, even the first few images need to wait until the JS runs and the browser decides they’re near the viewport, which can cause a visible flash on the first fold. I usually set EAGER\_COUNT to around 4 or 6 for a grid that shows two or three per row on desktop, it’s enough to cover what you see without scrolling before the lazy ones kick in.
Thanks for the technical insight! You're absolutely right regarding standard native behavior. However, in this specific setup, EAGER\_COUNT acts as a deterministic control layer. Since the UI grid and DOM updates are integrated into a custom lightweight pipeline outside the main framework, relying solely on native viewport heuristics introduced edge-case rendering delays on fast pagination state changes across certain devices. Using a fixed count guarantees immediate fetch for the initial slice before the IntersectionObserver takes over, keeping the DOM operations predictably smooth. Appreciate the feedback though!