loading="lazy" applied unconditionally to all listing images

Bug: loading="lazy" applied unconditionally to all listing images, including the LCP candidate — hurts Core Web Vitals

Theme: Epsilon (Osclass), lazy load setting = "Lazy load based on browser support"

Location: loop-single.php line 16 (and equivalent lines for the user-image avatar), the image tag:


<img ... <?php echo (eps_is_lazy_browser() ? 'loading="lazy"' : ''); ?> src="..." data-src="..." />


Problem: The native loading="lazy" attribute is applied to every listing card image regardless of its position in the grid, including the first (above-the-fold) item — which is typically the page's Largest Contentful Paint (LCP) element. Per Google's own guidance (web.dev/articles/lcp-lazy-loading), lazy-loading the LCP image delays its discovery and directly increases LCP, since the browser deprioritizes it instead of fetching it immediately. Confirmed via Lighthouse: on a category/listing page, "Load Delay" accounted for 48% of total LCP time specifically because the LCP <img> carried loading="lazy".

Suggested fix: eps_draw_item() already receives a position counter ($c, 1-based, passed from every calling loop in main.php/search.php/etc.). Pass this into loop-single.php/loop-single-premium.php (already in scope via PHP's include) and skip loading="lazy" for the first 2-4 items per grid (e.g. $c > 4), matching the standard "don't lazy-load above-the-fold images" pattern most modern themes/frameworks use.

Secondary inconsistency: loop-single-premium.php never applies loading="lazy" at all (no eps_is_lazy_browser() check present), unlike the regular loop-single.php — likely an oversight, worth reviewing for consistency.

well you cannot identify in dynamically generated content which cards will be above/below fold.
what if even first 4 are below fold, what if first 8 is above fold? it's not going to clean your warning and not going to help anything.

well you cannot identify in dynamically generated content which cards will be above/below fold.
what if even first 4 are below fold, what if first 8 is above fold? it's not going to clean your warning and not going to help anything.

That's a fair point — you're right that the exact fold position can't be known server-side, and that's true for any dynamically generated grid, not just this one. But that uncertainty doesn't make the fix pointless; it just means the goal isn't a perfect guess, it's a favorable trade-off.

Google's own LCP guidance (web.dev/articles/lcp-lazy-loading) is explicit about this: lazy-loading a resource that turns out to be the LCP element measurably delays LCP, because the browser has to complete a layout pass before it will even consider fetching a lazy-marked image — while a non-lazy image is picked up immediately by the preload scanner during HTML parsing. The guidance's recommendation is to avoid lazy-loading likely-above-the-fold content, precisely because the cost of being wrong is asymmetric: occasionally eager-loading a handful of images that turn out to be below the fold on an unusual breakpoint costs a few extra KB — genuinely negligible. Lazy-loading the actual LCP image costs real, measured page-load time; in our Lighthouse test it was 48% of total LCP.

Given eps_draw_item() already receives a position counter ($c) from every calling loop, the lowest-risk version of this fix would be to only exempt the very first card ($c === 1) from loading="lazy". Regardless of column count — 1 column on mobile, 4-6 on desktop — the first item in the grid always renders at the top of the loop, so it's effectively always at or very near the fold on every breakpoint. That alone would address the majority of the LCP cases we're seeing, with essentially no downside.