Repository navigation
Closed
Labels
area:UIRelated to UI/UX. For Frontend Developers.Related to UI/UX. For Frontend Developers.area:performancekind:bugThis is a clearly a bugThis is a clearly a bug
Description
Under which category would you file this issue?
Airflow Core
Apache Airflow version
3.2.2
What happened and how to reproduce it?
- Open Airflow Home in the browser
- 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.
- Click on Home again
- 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
Reacted by Nils Badtke
Metadata
Metadata
Assignees
Labels
area:UIRelated to UI/UX. For Frontend Developers.Related to UI/UX. For Frontend Developers.area:performancekind:bugThis is a clearly a bugThis is a clearly a bug
Activity
pierrejeambrun commentedon Jul 8, 2026
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.
Screen.Recording.2026-07-08.at.16.17.15.mov
hterik commentedon Jul 8, 2026
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 commentedon Jul 8, 2026
Ok I see the problem, re-opening, thanks for the details
[-]Rendering dag overview page very slow[/-][+]Rendering dags list page very slow[/+]