Load connection type metadata on-demand to improve Add Connection page load time

[yuseok89]

Apache Airflow version

main (development)

If "Other Airflow 3 version" selected, which one?

No response

What happened?

The Connection Add page takes ~10 seconds to load on first access.

• GET /ui/connections/hook_meta imports all Hook classes and their form definitions, which loads every provider and its dependencies.

With 100+ connection types, this causes significant delay before users can interact with the form.
I understand the slowdown is more noticeable because the main branch has all providers installed by default.
Nevertheless, in my opinion, it would be good if this could be improved.

Screen.Recording.2026-02-12.at.9.34.40.PM.mov

What you think should happen instead?

It's not a critical issue, but for better user experience, the Add Connection form should be usable within about 1 second. To achieve this, connection types should load first, then metadata only when the user selects a type.

Step	Current	Proposed
Add button click	Load all types + metadata	Load types only
Connection type dropdown	—	Populated from types API
User selects type	—	Load metadata for that type only
Form fields	—	Rendered from detail API

Proposed API changes:

1. GET /ui/connections/connection_types (new, lightweight)

   • Returns only connection type identifiers

2. GET /ui/connections/hook_meta/{connection_type} (new, on-demand)

   • Returns full metadata (standard_fields, extra_fields) for the selected type only

3. GET /ui/connections/hook_meta (existing)

   • Kept unchanged for backward compatibility

How to reproduce

1. Install Airflow with many providers
2. Go to Connections page.
3. Click Add button.
4. This reproduces when the cache is cold (first load or after restart): the page takes ~10 seconds before the connection type dropdown is usable.

Operating System

macOS

Versions of Apache Airflow Providers

No response

Deployment

Other Docker-based deployment

Deployment details

No response

Anything else?

If the committers agree with this approach, I would like to implement it.
If you approve, I would appreciate it if you could assign this issue to me.

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

[yuseok89]

If the committers agree with this approach, I would like to implement it.
If you approve, I would appreciate it if you could assign this issue to me.

[jroachgolf84]

@yuseok89, feel free to open up a PR for this issue!

[choo121600]

Thanks for raising this! I agree the initial load time is noticeable.

Just for context, #60410 recently introduced YAML-based discovery for connection form metadata
Since I think this change is closely related to this issue, it might be helpful to align with @amoghrajesh to ensure the approach is consistent.

cc @amoghrajesh

[jason810496]

Here is more context for the long-term goal: #60404

The idea is to read the metadata from provider.yaml instead of importing via get_ui_field_behaviour.

[yuseok89]

@choo121600 @jason810496
Thanks for the context and pointers.
I'll look into the code to see how the YAML-based approach works.

@amoghrajesh
Would splitting the API(connection_types + on-demand detail per type) align with the YAML-first direction?

[jason810496]

Sorry that I didn't look into the proposed "API(connection_types + on-demand detail per type)" approach carefully in my last reply.
From my perspective, the static yaml based approach might already be fast enough

Since we only need the provider.yaml for each provider instead of importing hooks for each provider, which should be less than 1 seconds for those file I/O operation. Maybe we can wait until the yaml base approach finishes and then see whether do we need the additional separate routes for the UX purpose.

[Arunodoy18]

Thanks for the detailed context and pointers!

From the discussion, it sounds like the YAML-based provider metadata direction (#60410 / #60404) is the primary long-term solution, and performance improvements might naturally come from that change.

I’m interested in contributing in this area. Would it be more helpful right now to:
• Help validate or test the YAML-based approach performance once it lands, or
• Help with follow-up optimizations if UI/API load time is still noticeable afterwards?

Happy to help wherever it’s most useful.