Test Playwright : rendu JavaScript sous Chromium, sans la couche de crawl

Playwright est le framework d’automatisation de navigateur de Microsoft : une bibliothèque Apache-2.0, pensée d’abord pour TypeScript, qui lance un vrai navigateur, le pilote via une API unique, puis te renvoie la page une fois son JavaScript exécuté. Il est présenté comme un framework de test end-to-end, mais derrière cette façade, beaucoup de gens l’utilisent en douce quand une requête HTTP ne retourne qu’une coquille vide là où les données devraient se trouver. Dans cette logique, il se place face à Puppeteer et Selenium — de vrais navigateurs à piloter, pas de simples clients HTTP à parser.

J’ai exécuté microsoft/playwright 1.56.0 sur un ensemble fixe de tests de scraping — un catalogue statique paginé, un article, un catalogue rendu en JavaScript, une API JSON, une erreur 500, un petit graphe de crawl, et deux sites publics d’entraînement — avec Node v22.22.3, macOS arm64, et Chromium uniquement. La partie rendu s’est bien passée. La partie crawl n’existe pas, et c’est justement le point clé à garder en tête avant d’adopter l’outil.

Ce qui ressort

Deux résultats dominent, et ils pointent dans des directions un peu différentes.

Le premier est le résultat navigateur attendu, dans le cadre des attentes que j’avais définies. Après page.goto(..., { waitUntil: 'domcontentloaded' }), le test dynamique attendait #dynamic-products article.product-card, et le test public Quotes to Scrape attendait .quote. Ces sélecteurs propres à l’application sont apparus, puis les exécutions ont renvoyé 8/8 éléments pour le fixture et 10 citations pour le site public ; le résultat du fixture atteignait un rappel de 1.0 face à sa vérité terrain de huit éléments. Aucun loop de polling personnalisé n’a été nécessaire, mais Playwright n’a pas fait disparaître le problème de disponibilité : c’est le test qui fournissait la condition de fin. Une capture d’écran pleine page a aussi été enregistrée dès le premier appel.

Le deuxième résultat utilisait browserContext.request : plus précisément, ctx.request.get(...) après le lancement de Chromium et la création d’un contexte de navigateur. L’appel interrogeait directement l’endpoint JSON du fixture et renvoyait 8/8 produits sans créer ni rendre de page. Ça évite le travail DOM, mais pas le coût du processus navigateur dans ce banc d’essai. Le client de requêtes lié au contexte peut partager l’état des cookies avec les pages du navigateur ; un playwright.request.newContext() autonome évite de dépendre d’un contexte navigateur, mais ne partage pas automatiquement cette session. Le test n’a couvert que le premier cas.

Playwright n’apporte pas non plus de file de crawl, de writer de dataset ni de throttling automatique. Mon test de graphe de crawl — parcourir les liens internes, suivre la profondeur et éviter les revisites — a atteint 12 pages avec des profondeurs {0:1, 1:4, 2:7}, mais le parcours en largeur était du code que j’avais écrit moi-même. Playwright ouvre et inspecte des pages ; la persistance de la frontière, la politique d’URL, les retries et la planification relèvent d’une autre couche.

Ce qu’est réellement Playwright

L’outil — microsoft/playwright sur GitHub — est écrit en TypeScript, sous licence Apache-2.0, et maintenu par Microsoft. La version testée ici était 1.56.0 au 9 juillet 2026. Les résultats rapportés concernent cette version précise ; il ne faut pas les lire comme une garantie de compatibilité pour les versions suivantes.

Le positionnement officiel est clair : un framework de test et d’automatisation web capable de piloter Chromium, Firefox et WebKit via une API unique. La voie principale de Playwright, c’est un test runner avec fixtures, assertions et trace viewer. L’utiliser comme brique de scraping revient à suivre le mode Library mode documenté : chromium.launch(), puis un context, puis une page, en dehors du harness de test. Tout ce que couvre ce test a été fait via cette API publique. Je n’ai pas effectué de test de compatibilité entre versions ; on ne peut donc pas en déduire que chaque comportement observé reste stable d’une release à l’autre.

L’étendue documentée est l’argument principal ailleurs, donc je vais la formuler avec précision. Playwright pilote trois moteurs de navigateur — Chromium, Firefox et WebKit — via une seule API, et propose aussi des clients de premier rang en Python, Java et .NET en plus de JavaScript. C’est documenté, et c’est bien sa grande différence dans sa conception. En revanche, ce passage n’a exercé qu’un périmètre plus restreint :

Si une cible s’affiche différemment sous WebKit que sous Safari, ou si ton équipe travaille en Python, cette largeur est justement l’atout de Playwright — mais ne prends pas mes résultats comme preuve d’une équivalence Firefox ou WebKit, puisque je ne les ai pas testés.

Fonctionnement interne

Le modèle mental, c’est un moteur de navigateur que tu pilotes. chromium.launch() démarre un processus de navigateur. Un context est une session isolée avec ses propres cookies, son stockage et son cache ; une page est un onglet à l’intérieur de ce contexte. Tu appelles page.goto(url), tu attends la condition qui représente la disponibilité de l’application, puis tu lis le DOM obtenu avec des aides comme page.$$eval. On se rapproche davantage d’un navigateur utilisé par une personne que d’un parsing de réponse HTTP, mais il ne s’agit pas d’une équivalence parfaite : les signaux headless, le viewport, la locale, les polices, l’état du profil, le chemin TLS/réseau et les défenses du site peuvent encore changer ce qui est servi. Ce test n’a pas évalué le comportement anti-bot ni la parité avec un navigateur de production.

page.screenshot() capture la page rendue, en pleine page ou sur une zone ciblée, et ça a fonctionné dès le premier appel pendant mon exécution. Et l’API de requête que j’ai mentionnée — context.request.get — passe par les cookies du même contexte tout en évitant le rendu, ce qui permet de combiner dans un même script « charger la page et lire le DOM » et « appeler directement l’endpoint JSON » sans changer d’outil.

En revanche, la machinerie de crawl n’est pas intégrée. Il n’y a ni ordonnanceur de requêtes, ni ensemble persistant des URL déjà visitées, ni politique de politesse, ni pipeline d’export. Un parcours borné est facile à esquisser, mais un front de crawl fiable demande aussi la normalisation des URL, la gestion des redirections, les retries, les règles de périmètre, le throttling et la reprise. Cette couche, soit tu la construis, soit tu utilises un framework qui enveloppe le moteur de navigateur.

Réalité de l’installation et du déploiement

L’installation se fait en deux étapes, et la seconde porte l’essentiel du poids opérationnel. npm install playwright installe la bibliothèque ; un npx playwright install séparé télécharge les versions de navigateur (Chromium dans mon cas). Il faut prévoir l’espace disque, le temps de téléchargement, le cache navigateur en CI et le nettoyage des processus, plutôt que de considérer le paquet npm comme l’intégralité du système exécutable.

Si tu installes Playwright en pensant obtenir un scraper puis que tu suis le tutoriel de test, tu vas commencer avec des fichiers de test et des assertions expect(). En scraping, en revanche, on utilise directement l’API de la bibliothèque. Les deux sont documentés, mais la distinction compte quand on cherche des exemples et quand on choisit les commandes de déploiement.

Pendant ce run, les points ergonomiques utiles étaient bien concrets : les contextes de navigateur isolaient l’état de session, les appels async s’enchaînaient proprement, une capture d’écran ne demandait qu’un seul appel, et une erreur HTTP 500 restait inspectable via l’objet réponse. Le point de friction était surtout opérationnel : il fallait installer la build du navigateur et gérer son cycle de vie séparément de la bibliothèque.

Résultats pratiques

Tous les chiffres locaux ont été obtenus sur un serveur fixture en 127.0.0.1, avec la vérité terrain définie avant le crawl. Le harness exact se trouve dans run_playwright_material_tests.mjs, et les artefacts bruts committés incluent la vérité terrain et les sorties de chaque test. Il s’agit toujours d’observations produites par l’auteur, sur une seule machine et lors d’un seul passage ; les liens servent à montrer la reproductibilité, pas à transformer ça en benchmark général.

La boucle de pagination suivait explicitement le lien suivant ; Playwright ne découvrait pas les pages de lui-même. Le sélecteur d’article gardait la navigation et le texte du pied de page en dehors du résultat du corps. Sur la route d’échec, la navigation renvoyait un objet réponse avec le statut 500 au lieu de lever une exception, laissant à l’appelant le soin de décider s’il faut journaliser, relancer ou continuer. Les deux cibles publiques d’entraînement ont renvoyé les comptes indiqués dans le tableau.

Il faut aussi poser une limite clairement : tout cela a tourné sur Chromium, sur une seule machine, une seule fois. Le tableau des capacités distingue volontairement l’étendue documentée du comportement réellement exercé. Je n’ai pas relancé la suite sur une autre version de Playwright, donc aucune conclusion interversion n’en découle. Les temps par test sont également exclus des benchmarks : un seul passage au chronomètre sur un portable ne permet pas une comparaison fiable de vitesse.

La disponibilité fait partie du contrat d’extraction

Les résultats dynamiques dépendaient de waits qui représentaient vraiment la donnée recherchée, et pas seulement la navigation du navigateur. Pour le catalogue local, le harness naviguait avec waitUntil: 'domcontentloaded', puis appelait waitForSelector('#dynamic-products article.product-card') avec un timeout de 15 secondes. Le run public Quotes JS utilisait le même état de navigation et attendait .quote avec un timeout de 20 secondes. L’extraction ne commençait qu’une fois ces sélecteurs apparus.

Cette distinction compte quand tu adaptes le script. domcontentloaded veut dire que le document initial a été analysé ; ça ne veut pas dire qu’une réponse API différée est arrivée, qu’une hydratation est terminée, qu’une liste infinie a fini de s’étendre ou qu’une ligne virtualisée est entrée dans le viewport. Un sélecteur est utile quand un seul élément correspondant suffit. Si l’exhaustivité dépend d’une réponse connue, d’un nombre d’éléments, d’un état applicatif ou d’une fenêtre réseau calme, il faut attendre cette condition à la place. La condition doit être liée au contrat de sortie : « au moins une carte existe » et « toutes les pages attendues sont chargées » sont deux assertions différentes.

La gestion des timeouts appartient aussi à l’appelant. Le test utilisait des timeouts de sélecteur bornés, mais il n’étudiait ni la politique de retry ni la différence entre une page lente et un sélecteur devenu obsolète. Un wrapper de production devrait enregistrer quelle condition de disponibilité a échoué, capturer assez d’état de page pour diagnostiquer le problème, et décider si une nouvelle tentative de navigation est sûre. Playwright fournit les événements et le DOM ; il ne peut pas deviner ce que « données complètes » veut dire dans ton cas.

Cette limite doit être documentée à côté de chaque extracteur, pas laissée comme un timeout implicite.

Le chemin API suit un contrat parallèle. ctx.request.get était approprié parce que le contexte navigateur existait déjà et que le partage de session peut être utile. Si un job découvre que son endpoint de données fonctionne sans aucune session navigateur, un contexte de requêtes autonome devient une architecture différente, avec un autre cycle de vie et un autre comportement des cookies. Ce test n’a pas comparé les deux. Il faut traiter « aucun DOM rendu » comme un fait mesuré, puis décider séparément si un processus navigateur est nécessaire dans le workflow global.

La question du crawl

Le résultat du graphe de crawl est celui qui définit la bonne façon de penser Playwright. Douze pages, trois profondeurs, résultat correct — et toute la logique de parcours était la mienne. Playwright fournissait la moitié « ouvrir cette URL et la lire » ; j’apportais la file, l’ensemble des URL visitées et le suivi de profondeur.

Pour des tâches petites et bornées, ce n’est pas un problème. À l’échelle du crawl, ça veut dire soit écrire un crawler au-dessus d’une bibliothèque de navigateur, soit associer Playwright à quelque chose qui le fait déjà. Le pattern documenté est Crawlee, qui enveloppe Playwright (et Puppeteer) avec une vraie file de requêtes, un stockage de datasets et un auto-throttling — tu gardes le rendu de Playwright et tu empruntes l’orchestration. Si tu veux que la file soit intégrée au framework lui-même plutôt qu’ajoutée par-dessus, c’est précisément le principe de Scrapy, même si Scrapy est d’abord orienté HTTP et ne rend pas JavaScript tout seul. L’idée n’est pas que Playwright soit insuffisant ; c’est que « automatisation de navigateur » et « crawl » sont deux métiers différents, et Playwright n’en revendique qu’un seul.

Le BFS à douze pages rend cette frontière explicite. Il fournissait une file, un ensemble visité et un suivi de profondeur pour un graphe contrôlé. Une frontière de production doit encore définir la canonicalisation des URL, la gestion des redirections, les hôtes autorisés, les clés de déduplication, les retries, la concurrence, le délai par hôte, la persistance et la reprise après arrêt. L’export est un autre choix : le fixture écrivait du JSON et du CSV parce que le harness le faisait, pas parce que Playwright fournit une abstraction de dataset.

Le design de session a aussi un impact sur le wrapper. Un navigateur peut contenir plusieurs contextes avec cookies et stockage isolés, mais ce test n’a pas mesuré le passage à l’échelle de plusieurs contextes ni l’isolation des pannes. Réutiliser un contexte peut préserver une connexion et réduire le travail de préparation ; créer des contextes séparés peut éviter les fuites d’état entre jobs. Ce sont des politiques de niveau crawler, même si Playwright fournit la primitive de contexte. Il faut benchmarker le cycle de vie choisi avec la build du navigateur et l’environnement de déploiement réellement utilisés.

Avantages et limites

Avantages :

• Exécution JavaScript via un vrai moteur Chromium ; les deux cibles dynamiques ont atteint les sélecteurs utilisés comme conditions de disponibilité.
• Capture d’écran pleine page réussie dès le premier appel.
• Les sélecteurs ont extrait les champs attendus du catalogue statique et de l’article sur les fixtures contrôlés.
• browserContext.request a atteint l’endpoint JSON sans rendre de page, tout en restant dans un navigateur déjà lancé dans le harness.
• Solide face à une mauvaise réponse : le HTTP 500 restait inspectable et la navigation ne levait pas d’exception.
• Support documenté de trois moteurs (Chromium, Firefox, WebKit) via une seule API, plus des clients Python, Java et .NET (documenté ; seul Chromium a été exercé ici).
• Apache-2.0 et maintenu par Microsoft.
• Expérience développeur propre en mode bibliothèque : une API unique entre les moteurs, async natif, captures d’écran triviales.

Limites :

• Pas de file de crawl, pas de dataset, pas d’auto-throttle intégrés — le crawl à grande échelle relève de ton code ou d’un wrapper comme Crawlee.
• Poids du navigateur : le téléchargement du binaire et le coût par page constituent la vraie taxe par rapport à un outil HTTP-only.
• Le cadrage par défaut est celui du test runner ; pour scraper, il faut savoir que le mode bibliothèque existe et sortir du chemin mis en avant.
• Seul Playwright 1.56.0 sur Chromium a été exercé ; la parité entre versions et entre moteurs n’a pas été testée.
• Aucun output JSON structuré par schéma natif ; c’est à toi d’écrire les sélecteurs et de façonner la donnée.

Pour qui, et pour qui ce n’est pas le bon choix

Si ton problème consiste à rendre des pages dont les données apparaissent après l’exécution de JavaScript, ou à collecter des captures d’écran en même temps que les données DOM, Playwright est un candidat raisonnable à reproduire sur tes cibles. Les équipes qui utilisent déjà Playwright pour les tests peuvent réutiliser les mêmes concepts et compétences en sélecteurs en mode bibliothèque. Les clients Python, Java et .NET sont des options documentées, mais ce test n’a exercé que Node et Chromium.

Envisage une autre couche dans trois cas. Si la donnée recherchée est déjà présente dans une réponse HTTP, un outil orienté HTTP évite les coûts de démarrage et de rendu du navigateur ; Colly est une bibliothèque de crawl dans cette catégorie, tandis que Trafilatura cible l’extraction d’articles. Si tu as besoin de file d’attente, de persistance et de throttling, utilise un framework de crawl ou un wrapper Playwright. Si tu veux une sortie structurée selon un schéma sans maintenir des sélecteurs, compare les services d’extraction managés. Aucune de ces alternatives n’a été benchmarkée dans ce test.

Si tu hésites spécifiquement entre Playwright et Puppeteer, c’est un autre face-à-face ; notre comparatif détaillé exécute les deux sur les mêmes fixtures et montre où le choix se joue vraiment.

Alternatives et place de l’extraction managée

Playwright est gratuit, sous licence Apache-2.0, et auto-hébergé. Tu gères le déploiement du navigateur, les sélecteurs, les conditions de disponibilité, le code de crawl, les mises à jour et la gestion des pannes. Ce test n’a pas mesuré les performances anti-bot ni comparé le coût total d’exploitation avec un service managé.

Dans l’open source, les comparaisons utiles se font par tâche. Pour du crawl à l’échelle d’un navigateur, Crawlee ajoute la file et le dataset que Playwright laisse de côté. Si ton objectif de sortie est du Markdown prêt pour LLM à partir d’un vrai navigateur plutôt que des lignes construites à la main, Crawl4AI exécute un navigateur et produit du Markdown pour ce pipeline. Et si tu compares plusieurs de ces options à la fois, notre tour d’horizon des scrapers open source met les catégories côte à côte.

Divulgation : Thunderbit est le produit de l’éditeur et n’a pas été exécuté sur ce fixture Playwright. Il représente la catégorie de l’extraction managée : le service s’occupe du rendu et renvoie le texte de la page ou des enregistrements structurés selon un schéma, tandis que Playwright laisse l’exploitation du navigateur et la logique de sélecteurs au développeur. La comparaison porte donc sur le modèle d’hébergement, la forme de sortie et le modèle de coût — pas sur un résultat de performance issu de ce test.

Essaye Thunderbit pour l’extraction de données web

Verdict

Utilise Playwright lorsque ta cible nécessite un moteur de navigateur et que tu es prêt à assumer les conditions de disponibilité, les sélecteurs et l’orchestration du crawl. Le tableau des résultats montre que son mode bibliothèque sous Chromium a bien géré les fixtures contrôlés statiques, dynamiques, API, capture d’écran et erreur lors de ce passage mené par l’auteur.

Garde intacte la frontière des preuves : seuls Chromium et Node ont été exercés, le parcours de 12 pages dépendait d’un BFS écrit à la main, browserContext.request évitait le rendu de la page sans éviter le processus navigateur déjà actif, et chaque extraction dynamique utilisait un sélecteur de disponibilité explicite. Ces contraintes font de Playwright une primitive de navigateur dans ce test, pas un système de crawl end-to-end mesuré.

Essaye Thunderbit pour l’extraction de données web Get Started Free

FAQ

Ai-je encore besoin de waits avec Playwright pour le scraping ? Oui. Le fait d’exécuter le navigateur ne dit pas à ton script quand les données de l’application sont prêtes. Ces tests naviguaient jusqu’à domcontentloaded, puis attendaient un sélecteur propre à la cible avant d’extraire. Les pages de production peuvent nécessiter un autre signal, comme une réponse, l’état d’un locator ou un événement applicatif.

Playwright peut-il crawler un site entier tout seul ? Pas nativement. Il n’y a pas de file de requêtes intégrée, pas de writer de dataset, pas d’auto-throttle — mon test de graphe de crawl n’a atteint 12 pages avec des profondeurs {0:1, 1:4, 2:7} que parce que j’ai écrit le BFS à la main. Pour du crawl à grande échelle, associe Playwright à Crawlee, qui l’enveloppe avec une vraie couche de crawl, ou utilise plutôt un framework de crawler.

Quand utiliser browserContext.request plutôt qu’un contexte de requêtes autonome ? Utilise browserContext.request lorsque les appels HTTP doivent partager les cookies avec les pages d’un contexte navigateur existant. Utilise playwright.request.newContext() lorsque tu veux un contexte orienté API sans lancer de navigateur et sans besoin de partage automatique des cookies avec les pages du navigateur. Seul le premier chemin a été testé ici.

Firefox et WebKit ont-ils été testés ici ? Non. Tous les tests ont tourné sur Chromium, sur une seule machine, en un seul passage. Le support de trois moteurs de Playwright (Chromium, Firefox, WebKit) et ses clients Python, Java et .NET sont des capacités documentées que je rapporte telles quelles, et non comme vérifiées — la parité Firefox/WebKit, le proxying, le passage à l’échelle multi-contexte et l’interception réseau sont tous hors du périmètre de ces chiffres.

Quel environnement ce test couvrait-il ? Playwright 1.56.0, Node v22.22.3, macOS arm64, et Chromium uniquement. Firefox, WebKit, le proxying, le passage à l’échelle, le comportement anti-bot et les versions plus récentes de Playwright étaient hors du run. L’installation nécessitait la bibliothèque plus le téléchargement séparé d’une build de navigateur.