Lazy-Loading Ads

Idea

Loading ads immediately on page load can drain resources, delay core content rendering, and hurt user experience—especially on mobile or slow networks. Lazy-loading ad units means they only fetch and render when likely to be seen by the user.

By deferring ad requests until the ad container is near the viewport (or visible at a threshold), you:

1. Increase overall CPM revenue.
2. Reduce unused ad loads (ads that never appear on screen).
3. Improve page load speed and Core Web Vitals.
4. Offer a better UX by avoiding delays and invisible network requests.

Visibility threshold: the key trigger

A central question: when should you trigger the ad load? Many implementations wait until the ad container is fully visible; but waiting too long may risk missing the ad impression window or causing layout shifts. Buffering a bit earlier helps.

Recommended pattern: trigger when the ad unit element is around 10 % visible in the viewport. This gives you a head-start—enough time to send the request, receive the bid, set targeting, and render the creative before the user scrolls past.

However — every site is different. You may need to adjust the threshold (e.g., 20 %, 30 %, or even pre-load just above the fold) depending on ad latency, viewport height, and scroll speed.

Tuning & best practices

1. Pre-load above the fold: If your ad slot is visible on page load, trigger it earlier (e.g., threshold 0 or immediate load) to avoid delay.
2. Monitor bid latency: Use console logs or performance traces to see how long bids take — if bids frequently arrive late, increase threshold or start loading earlier.
3. Idle vs busy users: On slower devices or heavy pages, preload ads with a larger buffer (e.g., 20–30% visibility) so the ad request finishes in time.
4. Cleanup observers: Always disconnect the IntersectionObserver once done to avoid memory overhead.
5. Fallback logic: If the slot never becomes visible (e.g., user doesn’t scroll), either skip loading or load after a timeout to increase fill opportunity.