Turbo Frames lazy loading request count for low-traffic Rails pages

Request Consolidation in Turbo Frames

There is currently no native configuration in Turbo (Rails 7.1+) to batch or consolidate multiple loading='lazy' Turbo Frame fetches into a single HTTP request. By design, each frame with a src attribute operates as an independent unit; when the Intersection Observer triggers, Turbo issues a separate GET request for that specific frame's source.

Likely Explanations and Workarounds

The current behavior is a result of Turbo's decoupled architecture, where each frame manages its own lifecycle. If request volume is a bottleneck for your low-traffic workload, consider these architectural alternatives:

• Component Grouping: Instead of five lazy frames, use one lazy frame that wraps a larger partial containing all five components. This reduces five requests to one.
• Client-Side State: If the data is small, consider loading it as a single JSON payload via a separate request and rendering it client-side, though this moves away from the "Rails-way" of server-side rendering.

Loading Strategies: Eager vs. Lazy

You should use eager loading (the default) for all above-the-fold content. Deferring initial viewport content leads to Cumulative Layout Shift (CLS) and a poor perceived user experience.

Factor	Eager (Above-the-Fold)	Lazy (Below-the-Fold)
SEO	Indexed normally as part of initial HTML.	Generally ignored by crawlers as they rarely trigger JS intersection events.
Auth	Validated during initial page load.	Each request triggers the full Rails middleware stack and session check.
UX	Immediate visibility.	Reduced initial bandwidth; potential "pop-in" on scroll.

Verification Steps

To confirm the request behavior in your specific environment:

1. Open Browser Developer Tools > Network Tab.
2. Filter by Fetch/XHR.
3. Scroll down the page and observe if each turbo-frame triggers a unique request to its src URL.
4. Check tail -f log/development.log to see the independent controller actions being invoked.

Diagnostic Question: Are these lazy frames targeting the same controller action with different parameters, or entirely different endpoints? (If they share an action, a custom batching endpoint may be easier to implement).