Rendering dag overview page very slow

[hterik]

Under which category would you file this issue?

Airflow Core

Apache Airflow version

3.2.2

What happened and how to reproduce it?

1. Open Airflow Home in the browser
2. Click on the Dags tab in the navbar to the left.
   • Page loads and displays first 50 dags found. Ignore how long this takes for now. This is just to cache the response for step 5.
3. Click on Home again
4. Click on Dags again -
   • Confirm in the browser developer console that no network request is being sent.
   • The list of first 50 dags are shown. But it takes around 2 seconds for the page to load, despite no network delay being involved.

Using Firefox 152.0.4 on pretty snappy laptop that generally doesn't have performance issue elsewhere.

What you think should happen instead?

If the list of dags is cached in the browser, it should render with no noticeable delay.

Operating System

Ubuntu

Deployment

Other Docker-based deployment

Apache Airflow Provider(s)

No response

Versions of Apache Airflow Providers

apache-airflow==3.2.2
apache-airflow-client==3.2.2
apache-airflow-core==3.2.2
apache-airflow-mypy==0.1.0
apache-airflow-providers-celery==3.20.0
apache-airflow-providers-cncf-kubernetes==10.17.1
apache-airflow-providers-common-compat==1.15.0
apache-airflow-providers-common-io==1.7.2
apache-airflow-providers-common-sql==2.0.0
apache-airflow-providers-docker==4.5.6
apache-airflow-providers-fab==3.6.4
apache-airflow-providers-postgres==6.7.0
apache-airflow-providers-smtp==3.0.1
apache-airflow-providers-standard==1.13.1
apache-airflow-task-sdk==1.2.2

Official Helm Chart version

Not Applicable

Kubernetes Version

No response

Helm Chart configuration

No response

Docker Image customizations

No response

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[pierrejeambrun]

Cannot reproduce on latest main closing. Feel free to re-open when you have a added more evidence for reproduction. (screen recording, or specific instruction)

What you describe is purely 'front-end' (table is already loaded), and it's very unlikely that displaying a table of 50 rows is taking forever. But feel free to re-open once you have added additional evidences.

This sounds like a local problem because you also reported something similar for the Grid and none of was surfaced (can't reproduced or heard from others). But I might be wrong of course.

Screen.Recording.2026-07-08.at.16.17.15.mov

[hterik]

That video is showing exactly the same kind of delay i describe, between t=9 to t=10.5 is almost 2 seconds.

I can understand network latencies adding up to that, but rendering 50 items only on the client shouldn't take that long. When you add the network latency on top of that, which is how one would typically experience it, the overall perception is even slower.

The issue get worse when you use Card view, your video is using List view. Toggling between card and list view btw seems to be a good probe for how fast the page renders. It's not quite as slow as a full page navigation, but it should exercise most of the rendering-path if that's where the bottlenecks are.

[pierrejeambrun]

Ok I see the problem, re-opening, thanks for the details