n8n lent ? Diagnostiquer et optimiser les performances de vos workflows

Un workflow qui mettait dix secondes en test en prend vingt minutes en production, l'éditeur rame, les exécutions s'empilent : « n8n est lent » est l'un des diagnostics les plus fréquents — et les plus vagues. Dans la quasi-totalité des cas, la lenteur n'est ni un bug de n8n ni un serveur sous-dimensionné, mais un pattern de workflow qui multiplie inutilement les opérations, ou un réglage d'instance resté sur sa valeur par défaut. Méthode dans l'ordre : mesurer d'abord, corriger les causes classiques ensuite, régler l'instance en dernier.

Mesurer avant d'optimiser : la durée par node

Le réflexe fondamental : ne jamais optimiser à l'intuition. Ouvrez une exécution terminée depuis la liste des exécutions — n8n affiche, pour chaque node, le temps qu'il a pris et le nombre d'items traités. Ce détail d'exécution est le même outil que celui utilisé pour déboguer un workflow, lu ici sous l'angle du temps plutôt que des données.

Ce que vous y trouverez presque toujours : un ou deux nodes concentrent 80 à 95 % de la durée totale. Optimiser les autres est une perte de temps. Et l'enjeu n'est pas cosmétique dès qu'un humain attend le résultat — webhook derrière un formulaire, chatbot, approbation Slack. L'étude de Jake Brutlag chez Google, « Speed Matters for Google Web Search » (2009, voir sur Google Scholar), a montré par expérimentation contrôlée qu'un délai artificiel de seulement 400 millisecondes réduisait le nombre de recherches par utilisateur de 0,6 % — et que l'effet persistait après la suppression du délai. Quelques centaines de millisecondes changent déjà le comportement ; plusieurs secondes font abandonner.

Le plan de diagnostic en cinq étapes

1. Reproduisez sur un volume réaliste : un workflow rapide sur 10 items de test peut être lent sur les 5 000 items de production, et la cause est précisément dans ce rapport.
2. Ouvrez le détail d'exécution et notez, node par node, la durée et le nombre d'items.
3. Identifiez le node dominant — celui qui concentre l'essentiel du temps.
4. Regardez si sa durée croît avec le nombre d'items. Une durée proportionnelle au volume signale un traitement item par item ; une durée fixe mais élevée signale plutôt un appel unique trop lourd (requête sans filtre, fichier volumineux).
5. Appliquez le remède correspondant (sections suivantes), puis re-mesurez sur le même volume — sans avant/après, impossible de savoir si vous avez gagné quelque chose.

Cause n°1 : traiter item par item ce qui pourrait l'être en lot

Le pattern le plus coûteux : une boucle qui exécute une opération réseau par item. Cent items = cent requêtes SQL, cent appels API, cent allers-retours dont chacun paie la latence réseau complète.

L'exemple canonique est la boucle de requêtes SQL. Au lieu d'interroger la base une fois par client :

-- Dans la boucle, exécuté 500 fois :
SELECT * FROM orders WHERE customer_id = '{{ $json.customer_id }}';

remontez la logique dans une seule requête avec jointure ou clause IN, exécutée une fois :

SELECT c.email, o.total, o.created_at
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.created_at > NOW() - INTERVAL '1 day';

Le node Postgres exécute cette requête en un aller-retour, et le workflow passe de minutes à secondes. Même raisonnement pour les nodes applicatifs : beaucoup proposent des opérations qui acceptent plusieurs items en une passe (création en lot, upsert multiple) — vérifiez-les avant d'enrouler le node dans une boucle. La boucle Loop Over Items reste le bon outil quand l'API n'offre aucune opération par lot, ou pour borner la mémoire — mais c'est un choix par défaut trop fréquent.

Cause n°2 : appels API séquentiels et pagination inefficace

Le node HTTP Request traite ses items les uns après les autres : 300 items à 500 ms de latence chacun, c'est 2 minutes 30 incompressibles. Trois remèdes, par ordre de préférence : chercher un endpoint de lot côté API (beaucoup acceptent un tableau d'objets en un POST) ; filtrer en amont pour réduire le nombre d'items ; ou paralléliser par petits groupes dans un node Code avec Promise.all — en gardant à l'esprit qu'une parallélisation agressive échange la lenteur contre des erreurs 429.

La pagination mérite le même examen : récupérer 10 000 enregistrements par pages de 20 génère 500 requêtes là où des pages de 200 en demandent 50. Montez la taille de page au maximum accepté par l'API et arrêtez la boucle dès que la fenêtre utile est couverte — notre guide de la pagination avec HTTP Request détaille les trois mécanismes courants et leurs pièges.

Cause n°3 : node Code sur des milliers d'items et binaire en mémoire

Un node Code en mode « Run Once for All Items » qui transforme 10 000 items en une passe est rapide. Les vrais coûts se cachent ailleurs : le mode « Run Once for Each Item » sur de gros volumes, les boucles imbriquées qui recherchent dans un tableau pour chaque item (préférez un Map construit une fois), et la duplication de grosses structures à chaque itération.

Les données binaires sont l'autre poids mort : un workflow qui fait transiter des PDF ou des vidéos de node en node garde tout en RAM par défaut, ce qui ralentit l'exécution bien avant le crash mémoire. Extrayez tôt les métadonnées utiles, lâchez le binaire dès qu'il ne sert plus, et passez l'instance en mode filesystem — sujet complet dans notre guide des fichiers volumineux et binary data.

Cause n°4 : le workflow monolithique

Un workflow de 80 nodes qui charge tout, transforme tout et écrit tout dans une seule exécution cumule les données de chaque étape en mémoire et devient impossible à mesurer finement. Découper en sub-workflows — un parent qui orchestre, des enfants qui traitent chacun un lot borné — libère la mémoire entre les appels et donne des durées par sous-ensemble lisibles dans l'historique.

Les réglages d'instance qui changent la donne

Quand le workflow lui-même est propre mais que toute l'instance traîne, regardez la configuration :

# Ne pas sauvegarder les données des exécutions réussies (les erreurs restent)
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
EXECUTIONS_DATA_SAVE_ON_ERROR=all
# Purge automatique de l'historique (par défaut : 336 h, soit 14 jours)
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168

Par défaut, n8n enregistre les données complètes de chaque exécution réussie : sur un workflow qui tourne toutes les minutes avec des payloads conséquents, la base enfle et tout ralentit — liste des exécutions, sauvegarde des workflows, démarrage. Trois leviers complémentaires :

• SQLite vs PostgreSQL : SQLite (le défaut) convient pour tester, pas pour une production qui écrit constamment. Le passage à PostgreSQL (DB_TYPE=postgresdb) est le premier geste sur toute instance sérieuse ;
• Le mode queue quand la charge est structurelle : si le problème n'est pas un workflow lent mais un volume global qui sature l'instance, le mode queue avec Redis et des workers répartit les exécutions — sans accélérer, rappelons-le, une exécution individuelle mal conçue ;
• Une supervision de base (CPU, mémoire, taille de base, durée des exécutions) pour voir les dérives avant la panne.

Limiter la fenêtre de données : ne récupérer que le delta

Beaucoup de workflows lents refont chaque nuit un travail déjà fait : re-télécharger tout le CRM, re-traiter tous les fichiers. Stockez le timestamp du dernier passage (dans une Data Table, un fichier ou la base) et ne demandez que ce qui a changé depuis — filter[updated_at], paramètre since, requête SQL bornée par date. Un traitement incrémental transforme un batch d'une heure en exécution de trente secondes.

Timeouts et retry : la lenteur qui vient d'en face

Enfin, un workflow « lent » attend parfois simplement une API qui ne répond pas : sans timeout explicite, un node HTTP Request peut rester suspendu de longues minutes sur un serveur muet, et des retries mal réglés multiplient les attentes. Fixez un timeout adapté à chaque appel externe et un retry avec backoff qui échoue vite et proprement — réglages détaillés dans notre guide retry et timeout du node HTTP Request.

En résumé

Un workflow n8n lent se soigne dans l'ordre : mesurer la durée par node pour trouver le node dominant ; remplacer les traitements item par item par des opérations en lot (SQL avec jointure, endpoints batch, pagination large) ; alléger ce qui transite (binaire, fenêtres incrémentales) ; découper les monolithes en sub-workflows ; et seulement ensuite toucher à l'instance — sauvegarde des exécutions sur none, pruning, PostgreSQL, mode queue quand la charge globale le justifie. Mesurez avant, mesurez après : c'est la seule différence entre optimiser et bricoler.