Progressively load interactive elements of Dag Card

[shivaam]

Follow-up to #69681.

The DAG Card view can render up to 50 cards with 14 recent runs per card. On cached navigation, rebuilding hundreds of run bars and repeated interactive controls can delay the page even though most cards are below the viewport.

This change renders every card shell and its static DAG information immediately, while deferring the expensive interactive content until the card approaches the viewport:

• pause, trigger, favorite, delete, and review controls
• full schedule and asset-expression UI
• recent-run bars
• run-state badges

The cards share one IntersectionObserver per scroll root. Hydration is one-way, so scrolling away does not unmount controls or disturb focus or open menus. The observer finds the actual scrolling ancestor and applies a 600 px rootMargin, avoiding a dependency on the newer scrollMargin option. Keyboard focus entering a deferred card hydrates its controls, and browsers without IntersectionObserver fall back to eager rendering.

This is intentionally not list virtualization. All card shells, DAG names, DAG identity links, sorting behavior, and browser find are available immediately. Interactive controls and recent-run links for fully offscreen cards appear when their card approaches the viewport or receives focus. All cards eventually hydrate, so the final page state is unchanged.

Screen.Recording.2026-07-21.at.7.18.52.PM.mov

Closes: #69609

Testing

• 31 focused Vitest tests covering shared-observer behavior, scroll-root selection, one-way hydration, keyboard focus, fallback behavior, cleanup, stable geometry, and card interactions
• targeted ESLint and Prettier checks
• full UI TypeScript check with pnpm tsc --noEmit
• production Vite build and Airflow prek UI hooks
• git diff --check
• live Breeze sort, scroll, hover, keyboard, and exact run-link smoke tests

---

Was generative AI tooling used to co-author this PR?

• Yes (OpenAI Codex)

Generated-by: OpenAI Codex following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[shivaam]

@pierrejeambrun I have been experimenting with some ideas to make the UI snappier for displaying multiple rows of data. Could you take a look and share your thoughts?
I made some improvements to the UI speed earlier as well - #69681

[bbovenzi]

Please keep as a draft PR if you dont want it merged yet.

[shivaam]

Please keep as a draft PR if you dont want it merged yet.

So this PR is ready for review but not ready for merge. I thought a draft PR means that it is not ready for review but in this case I am looking for feedback from the community while doing some more testing on my end. Wondering what is the best way to say it is ready for feedback?

[bbovenzi]

I think a better safeguard is to keep it as a draft but then you can tag specific contributors in a comment to ask them to take a look.

[shivaam]

I think a better safeguard is to keep it as a draft but then you can tag specific contributors in a comment to ask them to take a look.

Sounds good.

Since we are already here, if you get a chance can you also look at the PR and let me know if you have any thoughts. The improvement is marginal thought it makes the UI feel more snappier.

[bbovenzi]

I feel like we should progressively load the interactive elements of a card instead of the cards themselves. Those are the slow to load elements. Batches of 5 cards would probably create some odd start-stop jitter during scrolling.

If a card is not in view, don't try to fetch or render any of the asset_expression, pause/unpause, delete button, favorite button, needs review tag. We can apply the same logic to the content of the table list too. So that the new dag run stats mad task instance stats also don't slow down rendering

[shivaam]

I feel like we should progressively load the interactive elements of a card instead of the cards themselves. Those are the slow to load elements. Batches of 5 cards would probably create some odd start-stop jitter during scrolling.

If a card is not in view, don't try to fetch or render any of the asset_expression, pause/unpause, delete button, favorite button, needs review tag. We can apply the same logic to the content of the table list too. So that the new dag run stats mad task instance stats also don't slow down rendering

Great point. I like this idea and updated the PR to render the slower components only when the card is in the view. It took a few iterations. Let me know your thoughts.

[bbovenzi]

Looking good!

[github-actions]

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-3-test

You can attempt to backport this manually by running:

cherry_picker 4db892e v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.