Import On Visibility

Load non-critical code when content approaches the viewport

Many pages ship JavaScript for offscreen sections that a user may never reach. Import-on-visibility keeps the initial route lighter while still loading content early enough to feel ready when users scroll to it.

Quick Reference

• Use Intersection Observer to start loading code before an offscreen section becomes visible
• Reserve space with placeholders or skeletons so deferred sections do not cause layout shift
• Tune rootMargin so heavy content loads early enough without competing with above-the-fold work
• Use this for charts, reviews, related products, embeds, and offscreen dashboards

Check

Identify components, widgets, or modules that load on first render even though they only appear after the user scrolls. Flag which ones can switch to visibility-based loading.

Fix

Use Intersection Observer or an equivalent framework primitive to load the offscreen component or dependency when it approaches the viewport, while preserving layout stability and a clear placeholder.

Explain

Explain import-on-visibility, how it differs from import-on-interaction, and how viewport-based loading helps large pages stay fast.

Code Review

Inspect scroll-triggered sections, embeds, charts, recommendation modules, and long landing pages. Flag code that is bundled eagerly even though the corresponding UI stays offscreen until later, and verify the deferred version still loads before the user reaches it.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/performance/import-on-visibility

Load non-critical code when content approaches the viewport

Use viewport-aware loading to fetch components, embeds, and feature code shortly before they become visible instead of shipping them on first load.

Priority: high · Difficulty: intermediate · Time: 20 min

--- Import-on-visibility starts loading code when an offscreen section is close enough to matter. Patterns.dev's import-on-visibility pattern and Intersection Observer make it a practical way to keep the initial page lean without making later sections feel unfinished.

Code Examples

#

Plain JavaScript with Intersection Observer

const mountPoint = document.querySelector('#reviews')
let loaded = false

const observer = new IntersectionObserver(
  async ([entry]) => {
    if (!entry.isIntersecting || loaded) return

    loaded = true
    observer.disconnect()

    const { mountReviews } = await import('./reviews.js')
    mountReviews(mountPoint)
  },
  { rootMargin: '400px 0px' }
)

observer.observe(mountPoint)

React Example

  const containerRef = useRef {
        if (!entry.isIntersecting) return

        observer.disconnect()
        const mod = await import('./sales-chart')
        setChart(() => mod.SalesChart)
      },
      { rootMargin: '500px 0px' }
    )

    observer.observe(node)
    return () => observer.disconnect()
  }, [])

  return (
    <div ref={containerRef} style={{ minHeight: 320 }}>
      {Chart ?  : }
    </div>
  )
}

Why It Matters

• Reduced first-load cost: Offscreen components do not compete with critical content during the initial route load.
• Better scroll journeys: Heavy sections can load just before the user reaches them instead of blocking first paint.
• Controlled timing: rootMargin lets you decide how early to fetch based on the weight of the deferred component, which is why this pattern complements lazy loading instead of replacing it.
• Better fit for long pages: Marketing pages, dashboards, feeds, and article templates often contain expensive sections well below the fold.

Implementation Guidance

• Use a placeholder or skeleton with reserved height so the section does not shift layout when it loads.
• Start with a rootMargin between 300px and 1000px for heavier modules, then tune it based on asset weight and scroll speed.
• Disconnect the observer after loading so the import runs once.
• Keep accessibility intact: headings, landmarks, and focus order should still make sense before the module hydrates, and PageSpeed Insights is a good way to verify the route-level impact afterward.

Verification

Use the Chrome DevTools Performance panel or a throttled waterfall trace to confirm the deferred code leaves the initial path and then arrives early enough during scroll.

1. Confirm the deferred section's code is not part of the initial route bundle or first-load request set. 2. Scroll through the page on a throttled mobile profile and verify the module request starts before the section enters the viewport. 3. Check that the placeholder reserves space so the section loads without causing CLS. 4. Tune rootMargin until the section appears ready when reached, typically somewhere between 300px and 1000px before visibility for heavier modules. 5. Re-measure the route and confirm initial JS cost, main-thread work, or page weight improves without introducing visible loading jank later in the scroll.