Playwright vs Puppeteer : quatre choix avant de migrer

Playwright vs Puppeteer demande de choisir un contrat d’automatisation. La question utile porte sur la bibliothèque, la connexion, le binaire du navigateur et les éléments de débogage nécessaires au travail. Les deux bibliothèques créent des contextes isolés ; aucune ne rend automatiquement compatible un exécutable personnalisé. BotBrowser fournit des chemins de lancement documentés et des contrôles du navigateur fondés sur des profils pour les deux bibliothèques, mais ne garantit pas l’équivalence des protocoles, ne réalise pas leurs exécuteurs de tests et ne garantit pas l’acceptation par un site.

TL;DR

• Choisissez d’abord le navigateur et l’opération nécessaires. Puppeteer prend en charge Chrome et Firefox par CDP et WebDriver BiDi ; il ne se limite pas à CDP sur Chrome.
• Distinguez la connexion propre à Playwright de connectOverCDP(). Le contrat officiel indique explicitement une fidélité moindre pour ce rattachement CDP.
• Les deux bibliothèques séparent le stockage des contextes ; un contexte ne crée pas une machine ou une sortie réseau distincte à lui seul.
• Une trace de contexte Playwright et une chronologie de navigateur Puppeteer sont des produits différents. Leurs noms et tailles ne désignent aucun vainqueur.
• Fixez ensemble paquet, binaire et connexion. Conservez une action échouée même si une sonde DOM plus réduite réussit.

Sommaire

• Choisir selon quatre exigences
• Adapter la connexion à l’opération requise
• Comparer l’état et la portée de l’isolation
• Choisir les éléments de débogage nécessaires
• Fixer le couple paquet et navigateur
• Décider dans les limites des observations locales
• Conclusion pratique

Choisir selon quatre exigences

Une équipe qui part de Selenium peut d'abord consulter les changements pratiques d'une migration vers une alternative avant de comparer ces deux bibliothèques.

Partez d’une opération nécessaire. Maintenir une sortie PDF exclusivement Chromium ne présente pas les mêmes conditions d’acceptation qu’exécuter des assertions applicatives sur Chromium, Firefox et WebKit. Une connexion distante ajoute un contrat. La documentation des navigateurs Playwright et la liste de compatibilité Puppeteer définissent les combinaisons prises en charge ; le mot navigateur dans une offre de service ne suffit pas à identifier celle disponible.

Exigence	Décision Playwright	Décision Puppeteer	Preuve requise avant le choix
Connexion et opération	Choisir lancement/connexion habituels ou rattachement Chromium CDP	Choisir Chrome ou Firefox et le chemin CDP/BiDi adapté	La méthode nécessaire fonctionne par la connexion réelle
État du contexte	Attribuer création, réutilisation et fermeture de chaque BrowserContext	Attribuer createBrowserContext() et distinguer le contexte par défaut	Partage interne et séparation entre contextes correspondent au travail
Débogage	Déterminer si opérations ou assertions Playwright Test doivent être conservées	Déterminer si une chronologie Chrome explique l’échec	Le fichier contient l’événement nécessaire au diagnostic
Versions du navigateur	Consigner les exigences du paquet ou valider un exécutable personnalisé	Consigner le navigateur téléchargé ou assumer le couple personnalisé	Paquet, binaire, protocole et hôte restent reproductibles

Une case inconnue reste une décision en attente. Ouvrir une page distante ne suffit pas lorsque l’opération requise est une trace de contexte ou une commande CDP particulière. Un page.goto() réussi établit seulement la navigation de cette exécution ; il ne valide pas toute l’API. De même, une capture d’écran ne prouve pas qu’une assertion ou une opération serveur a été enregistrée.

La sélection et l’intégration répondent à deux questions. Le diagnostic du lancement Puppeteer traite les erreurs d’exécutable personnalisé et de session du navigateur après ce choix. L’analyse de l’ordre des scripts initiaux Playwright traite les écritures concurrentes précédant le document. Ces sujets ne remplacent pas la vérification du travail et du contrat de connexion avant de choisir.

Écrivez une condition capable de rejeter le candidat : méthode requise absente du protocole, binaire non pris en charge ou fichier omettant l’assertion décisive. Une préférence pour un écosystème plus vaste peut influencer la maintenance, mais ne constitue pas une acceptation exécutable. Associez cette préférence à l’opération et aux éléments que l’équipe doit maintenir.

Adapter la connexion à l’opération requise

La référence WebDriver BiDi de Puppeteer décrit l’automatisation de Chrome et Firefox. Firefox utilise BiDi par défaut ; Chrome utilise CDP, dont toutes les fonctions ne sont pas encore couvertes par BiDi. La référence énumère aussi des opérations non prises en charge. La prise en charge de Firefox ne prouve donc pas qu’une méthode spécifique à Chrome y fonctionne. Un projet utilisant une opération Chromium de bas niveau doit vérifier sa frontière de protocole réelle.

Playwright présente une autre distinction. La référence BrowserType décrit connect() vers un serveur Playwright et connectOverCDP() vers un Chromium existant. La seconde connexion est explicitement moins fidèle. Une adresse WebSocket générique ne devient pas automatiquement une adresse Playwright ; identifiez le protocole du serveur avant d’y rattacher un client.

La même référence exige que les versions majeures et mineures de Playwright correspondent entre le client et le serveur qui lance le navigateur. Cette condition ne doit pas être attribuée au rattachement CDP, dont le contrat diffère. Consignez si le navigateur vient de launch(), d’un serveur Playwright ou d’un Chromium lancé séparément. Cette provenance compte davantage qu’un schéma d’URL identique.

Le nom importé ne prouve pas la complétude du protocole. Puppeteer avec BiDi, Puppeteer avec Chrome CDP et Playwright rattaché à Chromium CDP peuvent proposer des opérations différentes. Si un fournisseur distant contrôle les arguments et les mises à jour, son contrat client constitue une dépendance supplémentaire. Demandez les connexions et versions compatibles documentées, sans présumer que toutes les bibliothèques utilisent indifféremment le même serveur.

Gardez des exigences concrètes. Si le travail nécessite interaction, trace, commande de navigateur et nettoyage des contextes, validez ces quatre opérations par la connexion prévue. Une navigation minimale reste utile comme préparation, mais doit figurer à côté des opérations non testées. Elle ne transforme pas une intégration partielle en prise en charge complète. Chaque opération non disponible doit conserver son protocole et sa version exacte du paquet.

Comparer l’état et la portée de l’isolation

La documentation des contextes Playwright décrit des sessions indépendantes avec stockage isolé. La référence BrowserContext de Puppeteer décrit également cookies et stockage local séparés, ainsi que le contexte par défaut. Les deux offrent une frontière d’état pour des scénarios applicatifs indépendants. Elle ne crée ni hôte, ni système d’exploitation, ni quota distinct.

La comparaison utile porte sur la gestion de cette frontière. Une page créée dans A partage l’état applicatif pertinent de A ; B possède un autre périmètre de stockage. Ouvrir un onglet ne revient pas à créer un contexte. Fermer A ne signifie pas fermer le navigateur entier, et conserver le contexte par défaut peut produire une durée différente de celle des contextes explicitement créés.

Ces vérifications côté page conviennent à un fixture localhost dont vous êtes propriétaire. Exécutez-les avec page.evaluate() après navigation vers la même origine pour chaque bibliothèque. Elles examinent un état synthétique, sans copier de session de compte ni mesurer tous les mécanismes de stockage.

await pageA.evaluate(() => {
  localStorage.setItem('fixtureMarker', 'context-A');
  document.cookie = 'fixtureMarker=context-A; Path=/; SameSite=Lax';
});

const readState = () => ({
  cookie: document.cookie,
  local: localStorage.getItem('fixtureMarker'),
});

const a = await pageA.evaluate(readState);
const sibling = await siblingInA.evaluate(readState);
const b = await pageB.evaluate(readState);

Le fixture observé a créé les deux contextes, ouvert une page sœur de A et fermé A avant de recharger B. Les résultats de partage et de séparation figurent plus bas. Ils ne décrivent ni IndexedDB, ni persistance des permissions, ni service workers, ni profils sur disque, ni modèle de processus sans tests spécifiques. Un résultat localStorage ne certifie pas tout le stockage ; une chaîne de cookies vide ne prouve pas des sorties réseau différentes.

Incluez le nettoyage dans le choix. La bibliothèque peut exposer les bonnes API alors que le programme de test réutilise accidentellement une page globale ou ferme le navigateur nécessaire à une autre tâche. Attribuez chaque contexte et donnez au navigateur une durée couvrant toutes ses tâches partagées. L’analyse du cycle de vie des contextes Playwright développe ce point ; la comparaison établit seulement que les deux candidats offrent un modèle à valider.

Choisir les éléments de débogage nécessaires

La référence Tracing de Playwright distingue traces de contexte et traces Playwright Test. L’API de contexte capture les opérations du navigateur et l’activité réseau, mais pas les assertions telles que expect(). Lorsque ces assertions doivent être conservées, Playwright recommande la trace de son exécuteur de tests. Appeler context.tracing.start() n’ajoute pas cet exécuteur à un script autonome.

La référence Tracing de Puppeteer décrit un fichier ouvert dans Chrome DevTools ou un lecteur de chronologies. Une seule trace peut être active par navigateur. Le produit et sa portée concurrente diffèrent donc d’une chronologie applicative indépendante par contexte. Des workers partageant le navigateur doivent attribuer la gestion de la trace ; des noms de fichier uniques ne suffisent pas.

Choisissez selon la question à résoudre. Pour une assertion applicative échouée, l’action, l’instantané du document et l’état attendu peuvent être décisifs ; pour les performances, ce seront peut-être les événements temporels. Un JSON volumineux n’est pas automatiquement un dossier d’échec plus complet qu’un petit ZIP. Un ZIP ne garantit pas davantage un diagnostic de performances pertinent.

La sonde a vérifié des entrées de trace dans le ZIP Playwright et des événements dans les JSON temporels Puppeteer. Ces assertions prouvent uniquement la structure. Elles ne prouvent pas qu’un opérateur a ouvert les lecteurs, trouvé un échec précis ou reconstitué une transaction distribuée. Le flux de travail des traces Playwright traite capture et examen ; comparer des extensions ne remplace pas ce travail.

Les limites de protocole restent importantes. La documentation actuelle de Puppeteer énumère Tracing parmi les lacunes BiDi génériques. Pourtant, le paquet installé plus ancien, connecté à Chrome par BiDi, a produit une chronologie Chrome dans cette sonde. Ce chemin Chromium ne permet aucune généralisation à Firefox ou à toutes les connexions BiDi. Inversement, une liste générique ne doit pas effacer un fichier effectivement produit. Conservez paquet, navigateur et connexion pour étudier l’écart.

Fixer le couple paquet et navigateur

Le contrat d’installation Playwright associe ses versions à des binaires précis et décrit les canaux de navigateurs de marque. La référence de configuration Puppeteer indique que le paquet complet télécharge un Chrome spécifique ; sa table de compatibilité relie les versions du paquet et du navigateur. Verrouillage des dépendances et chemin exécutable sont complémentaires.

La distinction entre puppeteer et puppeteer-core a des conséquences opérationnelles. La référence précise que core ignore les fichiers de configuration et variables d’environnement qu’elle décrit. Un projet core doit sélectionner son navigateur par l’API applicable. Copier la configuration du paquet complet ne prouve pas que le binaire sélectionné a changé.

Un exécutable personnalisé déplace la responsabilité. Les intégrations Playwright et Puppeteer de BotBrowser documentent le lancement, mais l’existence du chemin ne constitue pas un résultat de compatibilité. Consignez version et hash du binaire, version du paquet, connexion, arguments et hôte. Conservez l’échec d’une action requise même si une autre opération de la page réussit.

L’exécution locale utilisait Playwright 1.58.0, puppeteer-core 24.29.1 et Chrome standard 157.0.8103.79 sur macOS arm64. Cette combinaison choisie explicitement n’était pas le couple par défaut documenté pour l’ancien paquet Puppeteer. Les pages publiques actuelles ont été récupérées séparément et portaient la version 25.17.0. Elles décrivent le contrat présent, sans prouver que le paquet ancien possède tous les comportements décrits.

Définissez les événements imposant une nouvelle acceptation. Mise à jour automatique du navigateur, changement de paquet, d’adresse distante ou de mode de lancement peuvent invalider le couple accepté. Réutilisez le fixture, examinez l’opération exacte et conservez le résultat antérieur. Une navigation réussie après mise à jour ne valide pas l’entrée, la capture des traces et le nettoyage. Chaque exigence demande une observation à sa propre frontière.

Décider dans les limites des observations locales

Trois tâches ont fonctionné simultanément sur la même machine : lancement Playwright, Puppeteer Chrome CDP et Puppeteer Chrome BiDi. Le pool demandé était 20, le pool effectif 3 puisqu’il y avait trois tâches. La vérification a enregistré 16 CPU et environ 19.8 GB disponibles, en additionnant les pages macOS libres, inactives et spéculatives sans compter deux fois les pages purgeables. Aucun débit ou service distant n’a été évalué.

Vérification observée	Playwright	Puppeteer Chrome CDP	Puppeteer Chrome BiDi
A et sa page sœur lisent le marqueur	context-A	context-A	context-A
B commence sans marqueur	null, cookie vide	null, cookie vide	null, cookie vide
Retour de l’action DOM dans le monde principal	applied	applied	applied
Structure de trace observée	ZIP avec entrées .trace	JSON temporel, 7289 événements	JSON temporel, 7063 événements
B recharge après fermeture de A	Terminé, marqueur absent	Terminé, marqueur absent	Terminé, marqueur absent
Nettoyage du navigateur dans cette exécution	Fermé	Fermé	Fermé

L’action DOM appelait le bouton du fixture depuis page.evaluate() et lisait son résultat dans le même appel. Elle était volontairement plus réduite qu’un test d’entrée utilisateur : ni hit testing, ni entrée fiable, ni actionnabilité, ni attente automatique n’ont été validés. Présenter cette ligne comme une validation du clic sans la restriction exagérerait le résultat. L’observation porte sur une action de script contrôlée et son marqueur applicatif.

L’exécution initiale des actions sur éléments reste en échec. Après les assertions de stockage, CDP a signalé Runtime.callFunctionOn timed out et BiDi script.callFunction timed out, avec un délai de protocole de 15 secondes. Playwright a terminé cette exécution. La sonde ultérieure du monde principal a réussi sans réparer ni revalider ces chemins. Elle précise l’écart observé, sans établir sa cause, corriger le couple ou justifier une comparaison de fiabilité.

Une préparation initiale avait aussi dimensionné le pool avec la seule mémoire immédiatement libre, donnant un worker. Cette exécution interrompue reste conservée séparément ; elle ne constitue pas la comparaison concurrente. Le calcul ultérieur inclut les composantes pertinentes de mémoire disponible macOS et enregistre trois navigateurs au maximum, aucun résiduel. La correction concernait l’ordonnancement de l’expérience, pas les bibliothèques.

Utilisez le résultat pour définir la prochaine acceptation. Si le travail réel exige des actions sur éléments, validez ce chemin précis avec un couple officiellement pris en charge avant de migrer. S’il exige seulement une évaluation de page avec état séparé et une capture temporelle, la petite sonde est pertinente dans son environnement déclaré. Firefox, WebKit, PDF, serveurs Playwright distants et assertions Playwright Test n’ont pas été exercés.

Consignez le travail, la famille de navigateurs, la connexion, le couple paquet/binaire, le responsable du contexte et celui des fichiers. Joignez cas réussis, échoués et non testés. Choisissez le candidat répondant aux exigences dans un contrat maintenable, ou gardez le choix ouvert jusqu’au test manquant. Une décision conditionnelle appuyée sur un échec reproductible vaut davantage qu’une recommandation universelle fondée sur des preuves incompatibles.

Questions fréquentes

Puppeteer se limite-t-il à Chrome et CDP ?

Non. Sa documentation officielle décrit Chrome et Firefox avec CDP et WebDriver BiDi. La disponibilité d’une méthode dépend toujours du protocole, du navigateur et de la version du paquet.

Le rattachement CDP offre-t-il tout le contrat Playwright ?

Non. BrowserType décrit explicitement une fidélité moindre que la connexion par protocole Playwright. Vérifiez les opérations requises sans déduire l’équivalence d’une navigation réussie.

Des contextes séparés donnent-ils des identités séparées ?

Pas à eux seuls. Le stockage isolé ne prouve pas des machines, sorties réseau, quotas ou permissions différents. Les deux bibliothèques demandent un contrat explicite de travail et de durée.

Quelle bibliothèque est plus rapide pour le scraping ou le PDF ?

Ce fixture ne répond pas à cette question. Il ne contient ni charge représentative de scraping, ni comparaison PDF, ni mesure temporelle contrôlée. Choisissez d’abord opération et navigateur, puis mesurez ce travail séparément.

Sources

• Playwright : binaires et canaux
• Playwright : contrats de connexion BrowserType
• Playwright : isolation des contextes
• Playwright : tracing et limites des assertions
• Puppeteer : configuration et exécutables personnalisés
• Puppeteer : prise en charge WebDriver BiDi
• Puppeteer : correspondance paquet/navigateur
• Puppeteer : BrowserContext
• Puppeteer : traces temporelles
• BotBrowser : intégration Playwright
• BotBrowser : intégration Puppeteer

Conclusion pratique

Choisissez Playwright ou Puppeteer selon connexion, opération, état à gérer, éléments de débogage et couple navigateur/paquet maintenable. Conservez séparément les chemins d’entrée échoués et les sondes DOM réussies, ainsi que documentation actuelle et paquets anciens installés. BotBrowser fournit une intégration documentée ; le contrat d’automatisation exige encore sa propre preuve d’acceptation.