It can be normal for “Execute step” (partial executions) to feel slower, especially on larger workflows or after idle periods.
Partial executions send extra data/metadata to the backend and can hit size limits or overhead that full runs don’t have. Use a Manual Trigger and run the whole workflow when possible, or temporarily limit data during testing to reduce payload size (Manual, partial, and production executions).
Large data in the editor are slower because the UI must stream and render execution data. For heavy runs, execute in the background (active workflow via webhook/schedule) rather than through the editor UI (UI lag on large loops).
First runs after idle (“cold”) can be slower; similar reports show initial latency that improves on subsequent runs (first-run slowness examples).
If you see timeouts or long node times, reduce items per run (Split in Batches), avoid heavy Code nodes where built-in nodes suffice, and ensure adequate resources; increase execution timeout if needed when self-hosting (heap/memory and batching advice).