Présentation
Turbo‑Browser‑MCP est un serveur Playwright dédié aux tests d’interfaces web à grande vitesse. Le dépôt GitHub indique qu’il supporte le batching multi‑onglet, la génération de snapshots DOM delta compacts, le remplissage de formulaires dans React, Shadow DOM et iframe, ainsi que les uploads de fichiers depuis le disque et des guardes de soumission. Ces fonctionnalités visent à réduire le nombre d’appels réseau entre le client de test et le navigateur, tout en conservant la précision du rendu DOM.
Fonctionnement du batching multi‑onglet
Le serveur crée un pool d’instances Playwright, chaque instance pouvant ouvrir plusieurs onglets. Au lieu d’envoyer une requête HTTP par action utilisateur, Turbo‑Browser‑MCP agrège les interactions (clics, saisies, navigation) de tous les onglets actifs dans un batch. Ce lot est ensuite transmis en une seule opération au moteur Playwright, qui exécute les actions séquentiellement. Le gain de latence provient de la suppression des aller‑retours TCP pour chaque événement, ce qui est crucial lorsqu’on exécute des suites de tests contenant des milliers d’étapes.
Gestion des deltas DOM et remplissage de formulaires
Plutôt que d’envoyer le DOM complet après chaque modification, le serveur calcule des deltas – les différences entre l’état précédent et l’état actuel. Ces deltas sont encodés de façon compacte, limitant la bande passante consommée. En parallèle, Turbo‑Browser‑MCP intègre des modules capables de détecter les champs de formulaire dans des environnements React, Shadow DOM ou iframe, puis de les remplir automatiquement à partir de données fournies. Cette capacité repose sur l’inspection du shadowRoot et sur l’injection de scripts d’interaction qui respectent les cycles de vie du framework utilisé.
Sécurité, guardes de soumission et limites
Les "submit guards" implémentés interceptent chaque tentative d’envoi de formulaire. Le serveur vérifie la présence de tokens anti‑CSRF, la conformité des types MIME pour les fichiers uploadés, et bloque les soumissions qui ne respectent pas les contraintes définies. Cette couche de protection évite que des tests mal configurés déclenchent des actions indésirables sur des environnements de production. Cependant, la documentation du projet reste succincte : aucune métrique de performance (temps moyen de batch, taille moyenne des deltas) n’est fournie, et le comportement en cas de conflit de ressources entre onglets n’est pas détaillé. De plus, l’utilisation de fichiers locaux implique que le serveur doit disposer de permissions d’accès disque, ce qui peut poser des problèmes de sandboxing dans des pipelines CI stricts.
