Browserless vaut-il le coup ? Test de la montée en charge, de la fiabilité et de l’utilisation réelle

Browserless, c’est Chrome sans interface graphique proposé comme service que vous hébergez vous-même. Son conteneur Docker reste en permanence actif, accepte les tâches via HTTP ou WebSocket, et applique des limites d’admission partagées au lieu d’être embarqué dans chaque application appelante. Dans les tests REST menés ici, le service affichait zéro processus Chrome au repos, lançait des processus Chrome pendant une requête active, puis revenait à zéro ensuite. Ce qui est mutualisé, c’est la capacité du service et la mise en file d’attente, pas un ensemble vérifié de navigateurs déjà préchauffés.

J’ai testé la version v2.55.0 sur un environnement local contrôlé — démarrage décomposé en étapes, contrôle d’admission avec trois configurations, fidélité des réponses comparée à une vérité terrain connue, un test de charge de 30 sessions et la limite de timeout. Le résultat le plus utile n’était pas un gain de vitesse, mais un comportement opérationnel : les limites d’admission correspondaient aux réponses visibles côté client, et les principales limites observées venaient surtout de la manière de le déployer.

Le point le plus intéressant n’était pas un chiffre de latence. Browserless ne fait pas démarrer Chrome plus vite : il met une politique d’accès devant Chrome, avec un nombre fixe de sessions autorisées, une file derrière, puis un HTTP 429 pour tous les autres. Ce plafond est passé de 4 à 8 puis à 10 lorsque j’ai modifié deux variables d’environnement, et le suivi interne du conteneur s’est aligné sur les codes d’état de mon client à chaque requête.

Ce qu’est réellement Browserless

C’est souvent là que les gens se trompent de catégorie. Browserless n’est pas une bibliothèque que vous importez et appelez. C’est une image Docker — ghcr.io/browserless/chromium — que vous exécutez comme un service durable. Elle orchestre le travail du navigateur et l’expose de deux façons : des endpoints REST (/content, /scrape, /screenshot, /pdf, ainsi que /function et /unblock) et une interface CDP/WebSocket vers laquelle Puppeteer et Playwright peuvent se connect().

J’ai testé la surface REST. Le chemin WebSocket existe bel et bien et il est largement utilisé, mais je ne l’ai pas mesuré.

La version testée était v2.55.0, vérifiée le 27 juillet 2026.

Le nombre d’étoiles évolue ; considérez-le comme une lecture à un instant T.

Le verrou de licence : SSPL-1.0 ou licence commerciale

Le dépôt propose Browserless sous SSPL-1.0 ou licence commerciale Browserless. Lisez la licence du dépôt actuelle et exacte ainsi que le guide officiel de déploiement open source de Browserless avant de choisir une voie. Cet article n’a pas effectué d’analyse juridique sur les produits commerciaux, les applications closed source, les systèmes CI, les services hébergés ou les déploiements internes ; il ne classe donc pas ces cas dans une licence donnée. Faites évaluer le modèle de déploiement et de distribution par un juriste ou par la personne en charge des licences logicielles.

Browserless vend aussi des offres hébergées. Les tarifs et la définition des unités d’usage changent souvent et ne faisaient pas partie de ce test auto-hébergé ; vérifiez-les donc sur le site officiel plutôt que de prendre un tableau daté ici pour une preuve d’achat.

Comment fonctionne réellement le modèle de session

Le chemin REST mesuré se comportait comme un travail de navigateur par requête, mais ce banc de test n’a pas suffisamment exploré les entrailles de Browserless pour distinguer un nouveau processus browser de toutes les stratégies possibles de réutilisation de contexte. Ce qu’il a établi est plus simple : zéro processus Chrome au repos, 11 processus de la famille Chrome pendant une requête active, puis zéro à la fin de l’exécution séquentielle. Rien n’indiquait ici l’existence d’un pool de navigateurs préchauffés.

Le service Node durable accepte un nombre borné de tâches navigateur, en met d’autres en file d’attente dans une limite également bornée, puis rejette le reste. Considérez ce modèle d’admission comme le contrat architectural mesuré ci-dessous. N’en déduisez pas une réutilisation de processus ou de contextes à partir du mot « pool » ; le banc de mesure ne peut pas le prouver.

Le contrôle d’admission repose sur deux paramètres :

• CONCURRENT — le nombre de sessions pouvant s’exécuter en même temps.
• QUEUED — le nombre de requêtes supplémentaires autorisées à attendre un créneau.

Le endpoint /config du conteneur renvoyait par défaut CONCURRENT=10, QUEUED=10, TIMEOUT=30000. Tout ce qui dépasse CONCURRENT + QUEUED est refusé immédiatement.

L’authentification n’est pas facultative. Browserless v2 exige toujours un token — si vous ne définissez pas TOKEN, il en génère un aléatoire et l’affiche sur stdout au démarrage. Chaque appel REST doit inclure ?token=.

Pour l’observabilité, vous disposez de /pressure (sessions en cours, en file, CPU, mémoire, rejets récents), /sessions et /config. Il existe aussi une exportation JSON /metrics, mais elle nécessite de définir METRICS_JSON_PATH et je ne l’ai pas utilisée. L’image lance aussi dumb-init comme PID 1, ce qui correspond à la réponse documentée aux plaintes sur les processus zombies qui accompagnent Chrome en conteneur depuis des années.

Réalité du setup : une commande, et quatre choses que personne ne met dans la commande

La ligne d’installation la plus citée tient bien en un seul docker run. Tout ce qu’il y a autour, en revanche, mérite d’être anticipé.

L’image pèse 4,34 Go. C’est ce chiffre qui doit guider vos attentes, pas la latence de démarrage. Le manifeste contient à la fois linux/arm64 et linux/amd64 ; sur mon hôte arm64, Docker a téléchargé la version arm64 native. (L’user-agent de Chrome dans le conteneur affiche quand même X11; Linux x86_64 — c’est la signature cosmétique de Chrome sur Linux, pas de l’émulation. uname -m renvoie aarch64. Les gens ouvrent des tickets là-dessus.)

J’ai utilisé --shm-size=2g pour chaque mesure. Le banc de test n’incluait pas d’exécution témoin avec le /dev/shm par défaut de Docker, donc cet article ne peut pas affirmer que 2 Go sont universellement obligatoires ni quantifier le point de rupture. Dimensionnez-le selon votre volume de navigateurs et votre charge.

Le token est un sujet de déploiement, pas une formalité. Sans lui, toute personne pouvant atteindre le port 3000 peut utiliser un navigateur sur votre réseau.

Le réseau du conteneur est votre problème. Mon fixture tournait sur l’hôte, donc le conteneur y accédait via host.docker.internal (colima le mappe avec --add-host host.docker.internal:host-gateway). J’ai vérifié avec un simple curl brut que le conteneur atteignait bien le fixture avant de faire confiance à la moindre mesure.

Mon environnement : colima 0.10.3 (6 CPU / 11,6 Gio) avec Docker 29.2.1 sur macOS 26.5.2 arm64. Le banc de test utilisait uniquement la bibliothèque standard Python 3. Pour PNG et PDF, il vérifiait les signatures de fichier, pas la validité de décodage, les dimensions, le nombre de pages, l’exhaustivité ou la fidélité visuelle.

Un lancement minimal équivalent utilise l’image figée, un token explicite et l’allocation mémoire partagée utilisée ici :

docker run --rm -p 3000:3000 --shm-size=2g \
  -e TOKEN=replace-with-a-secret \
  ghcr.io/browserless/chromium:v2.55.0

Une fois que /pressure?token=... répond, un POST /content?token=... authentifié avec un corps JSON contenant l’URL cible teste le chemin REST. En production, les appels doivent aussi prévoir une stratégie de retry bornée avec jitter pour les réponses 429 ; relancer immédiatement ne fait que se battre à nouveau contre la même file pleine.

La taxe de démarrage, décomposée

Trois démarrages docker run neufs, médianes avec min–max :

La ligne du milieu est facile à surinterpréter. Elle ne mesure pas le démarrage du navigateur isolément et ne montre pas que Browserless lance Chrome plus vite qu’une bibliothèque intégrée au processus. C’est un aller-retour HTTP vers un conteneur, plus le travail du navigateur, la navigation et le transfert de la réponse. L’écart d’environ 0,17 seconde entre la première requête et les suivantes peut inclure des effets de système de fichiers, du système, de Chrome, de Node ou du cache du conteneur. Comme les processus Chrome étaient à zéro au repos et que le banc n’a capturé ni trace CDP ni chronologie des processus pour ces appels, il ne peut pas attribuer cet écart à une réutilisation du navigateur ou à un coût de lancement “amorti”.

Et ce sont des chiffres obtenus dans une VM colima sur macOS. Un Linux installé directement sur la machine donnera autre chose. Ne citez pas 0,78 s à votre SRE comme si c’était portable.

En pratique : trouver le plafond, des deux côtés

Le contrat CONCURRENT + QUEUED → 429 est répété partout, mais rarement démontré.

Le protocole : une route de fixture qui dort 5 secondes côté serveur, afin que chaque requête occupe de façon fiable une session pendant une durée connue. Ensuite, on lance simultanément CONCURRENT + QUEUED + 4 requêtes et on observe ce qui revient — pendant qu’un thread de sondage distinct interroge /pressure pour lire le suivi interne du conteneur.

Trois conclusions en ressortent.

Le plafond est exactement CONCURRENT + QUEUED, à chaque fois. Les réponses réussies étaient 4, 8 et 10 — la somme configurée dans chaque cas. Les rejets correspondaient au dépassement, soit 4 dans les trois exécutions.

Le plafond bouge. Ce n’est pas une constante gravée dans l’image ; c’est ce que vous configurez. Passer de 4 à 8 puis à 10 en modifiant les variables d’environnement est précisément ce qui rend l’outil utile plutôt qu’anecdotique.

Et les deux signaux sont indépendants. Les codes d’état de mon client provenaient de vraies réponses HTTP ; /pressure provenait du suivi interne du conteneur, sondé par un autre thread. Les deux se sont accordés sur ces trois courtes exécutions. Cela fait de /pressure un signal candidat pour la production, mais pas un contrat complet d’autoscaling : la fréquence de collecte, la sémantique de remise à zéro, l’agrégation multi-réplicas et le comportement sous charges mixtes plus longues doivent encore être validés.

Une nuance que les comptes réussite/échec masquent. Une requête en file ne échoue pas — elle attend, et elle peut attendre longtemps. En (2, 2) avec un travail de 5 secondes, les réponses réussies sont arrivées entre 5,7 s et 11,0 s, médiane 8,3 s. La latence de bout en bout a donc atteint environ deux durées de session. Le banc n’a pas enregistré des horodatages séparés pour l’admission et l’exécution, il ne peut donc pas attribuer l’intégralité du délai à l’attente en file.

À quoi cela ressemble sur une vraie tâche

Imaginez que vous rendiez 4 000 pages produit en PDF chaque nuit, et que chaque page prenne environ 5 secondes. Vous réglez CONCURRENT=5, QUEUED=5. Votre plafond de débit est de 5 pages toutes les 5 secondes — une page par seconde — donc la tâche prend environ 67 minutes si le pipeline reste exactement plein. C’est du calcul basé sur un comportement mesuré, pas un benchmark, mais c’est bien ce calcul qu’il faut faire avant de déployer.

Toute requête arrivée après saturation des slots de traitement et d’attente peut recevoir un 429 immédiatement ; le fait d’envoyer les requêtes en même temps ne garantit pas quel numéro perd la course. Un orchestrateur doit considérer cette réponse comme un signal de backpressure et appliquer un retry borné avec jitter. Sinon, il risque de perdre des pages pendant que la comptabilité globale du job continue — un risque opérationnel, pas un scénario d’échec démontré par ce banc.

En pratique : ce que voient vraiment les endpoints

Pour tester honnêtement la fidélité du rendu, la page de fixture masque son texte repère à toute personne qui n’exécute pas un vrai navigateur. La chaîne visible Runtime Injected Marker 88 est assemblée à partir de fragments JavaScript au chargement, donc aucune version littérale contiguë n’existe dans les octets envoyés par le serveur. Une simple récupération statique de cette page renvoie 702 octets qui ne contiennent aucun des deux marqueurs.

Le fait que /content renvoie 811 octets avec le marqueur injecté signifie qu’un vrai Chromium a rendu la page avant de renvoyer le HTML. /scrape a extrait une valeur d’un nœud qui n’existe qu’une fois JavaScript exécuté. Les deux ont fonctionné sans aucun code d’automatisation côté client — un simple POST authentifié.

C’est cela, la vraie promesse. Lors de la même série de tests, un crawler statique a complètement raté ce type de contenu, et les bibliothèques de navigateur intégrées au processus (chromedp, rod, Selenium) ne l’ont capté qu’après que j’ai ajouté un wait explicite. Browserless, lui, l’a capté avec une requête de forme curl. Vous échangez du code d’automatisation contre du poids à l’exécution.

Deux limites à cette affirmation. Les preuves couvrent les types de contenu de mon fixture, pas l’ensemble du web moderne. Et /unblock, le endpoint anti-détection, a volontairement été laissé de côté — aucun de ces résultats ne doit être lu comme une revendication de capacité anti-bot. /function, /download et /performance n’ont pas été testés non plus.

En pratique : contrôle bref des résidus

Chrome en conteneur a la réputation de laisser des cadavres derrière lui, alors j’ai exécuté 30 sessions séquentielles avec CONCURRENT=3 et compté les processus à l’intérieur du conteneur.

Avant de faire confiance au moindre résultat, j’ai calibré le détecteur. Pendant qu’une session était en cours, l’énumérateur /proc a vu 11 processus de la famille Chrome (browser, zygote, GPU, renderers, utilitaires). C’est important : cela prouve que l’instrument voit bien Chrome, donc son retour à zéro en fin de test est une mesure et non une cécité. Un test de fuite qui affiche « 0 processus » sans prouver qu’il sait les compter ne vaut rien.

Après 30 sessions : 0 processus Chrome, 0 zombie. Les seuls survivants étaient dumb-init, node, Xvfb, start.sh et sh. /sessions affichait 0 au repos.

Mémoire du conteneur, d’après docker stats (la mesure visible par l’opérateur, pas l’RSS d’un processus isolé) :

Croissance nette sur 30 sessions : environ 9,5 Mo, et la courbe échantillonnée se stabilisait après la session 10. Cela ne correspond pas à une fuite linéaire simple par session sur cette courte fenêtre. Le warmup de Node est une explication plausible, mais ce que ces compteurs de processus et cette série mémoire ne peuvent pas prouver.

Périmètre : 30 sessions séquentielles, c’est un petit test de charge, pas un test d’endurance ni de concurrence. Les avertissements de longue date sur les listeners EventEmitter dans le tracker de tickets sont exactement le genre de problème qui peut apparaître après des heures et des milliers de sessions, et je n’ai pas exécuté ce scénario. La conclusion permise ici est seulement qu’aucune accumulation de processus Chrome ni de zombies n’a été observée dans cette fenêtre sur v2.55.0.

La limite de timeout

TIMEOUT est documenté comme un paramètre. Je voulais voir s’il s’appliquait.

Avec TIMEOUT=5000, une session qui tentait de garder la page ouverte 15 secondes renvoyait un HTTP 408 au bout de 5,007 s au lieu de rester bloquée. Cette observation unique confirme l’application de la limite près du seuil configuré. Elle ne révèle pas l’implémentation du timer ni ne prouve le nettoyage du slot ; un test plus robuste répéterait l’essai, observerait le retour à l’état idle dans /sessions et /pressure, puis vérifierait qu’une requête suivante récupère bien le créneau libéré.

Le piège de migration : PREBOOT est inerte, et ne vous le dit pas

De toutes les mesures effectuées, c’est celle que j’aurais le plus aimé recevoir avant une mise à jour.

Browserless 2.0.0 a supprimé PREBOOT et KEEP_ALIVE — le changelog indique qu’ils ont été retirés parce qu’ils prêtaient à confusion, servaient peu et provoquaient des bugs. C’est compréhensible. Le vrai problème, c’est ce qui se passe quand on copie-colle une config v1 dans v2, ce qui est la façon la plus courante de migrer.

J’ai lancé le conteneur avec -e PREBOOT=true et je l’ai comparé au comportement par défaut :

Chaque timing tombe dans la propre plage min–max de l’option par défaut — c’est du bruit, pas un effet. Et rien n’était préchauffé : le conteneur PREBOOT=true reste au repos sans aucun navigateur, exactement comme celui sans le flag. Deux autres signaux, et aucun n’est un nombre :

• /config n’expose aucune clé preboot. Les clés sont concurrent, queued, timeout, token, maxCPU, maxMemory, retries, etc.
• Aucun message d’erreur. Aucun avertissement. Rien dans les logs du conteneur.

Donc une config v1 PREBOOT sur v2 est un no-op silencieux au démarrage normal et dans les vérifications de logs. L’absence de clé dans /config plus l’absence de changement de comportement constituent le signal détectable ; Browserless n’émet ni rejet explicite ni avertissement. Un contrôle de migration doit inspecter la configuration effectivement appliquée plutôt que de considérer qu’un démarrage vert prouve que chaque variable d’environnement a été prise en compte.

KEEP_ALIVE est le cas inverse, et il ne faut pas tout mélanger. Il a été supprimé dans la même version, mais il n’est pas silencieux — une vérification ponctuelle du conteneur montre qu’il consigne Environment variable of "KEEP_ALIVE" is deprecated and ignored. dans stdout. C’est un vrai avertissement pour l’opérateur. Je n’ai pas soumis KEEP_ALIVE au même banc de mesure que PREBOOT, donc je le rapporte ici comme une vérification et non comme une mesure. Mais la tendance est suffisamment claire pour compter : seul PREBOOT est le piège silencieux. Browserless est plus explicite à propos de KEEP_ALIVE qu’un résumé du type « v2 ignore vos flags v1 » ne le laisserait penser.

Avantages et inconvénients

Avantages

• Contrôle d’admission conforme à la documentation et variable avec la configuration — prouvé à trois plafonds différents, simultanément côté codes client et côté suivi interne du serveur.
• /pressure correspondait aux comptes running, queued et rejected visibles côté client dans trois courtes exécutions ; à considérer comme une entrée possible pour l’autoscaling et l’alerting.
• Rendu Chromium réel sans code d’automatisation côté client : un seul POST authentifié a révélé du DOM injecté en JavaScript qu’une récupération statique ne peut pas voir.
• Aucun processus Chrome cumulatif observé lors d’une séquence de 30 sessions ; le compteur final était de 0 processus Chrome et 0 zombie.
• Un essai TIMEOUT a renvoyé 408 à 5,007 s pour un budget de 5,000 s ; le nettoyage et la libération de slot n’ont pas été vérifiés séparément.
• Auth activée par défaut : les quatre endpoints REST renvoient 401 sans token.
• Un seul docker run pour un service prêt en environ 0,78 s, puis un premier rendu 0,32 s plus tard.

Inconvénients

• Image de 4,34 Go. C’est le vrai coût de départ, et il se voit dans votre registre, votre cache CI et votre temps de déploiement à froid.
• Licence SSPL-1.0 ou licence commerciale Browserless. Évaluez les conditions exactes actuelles selon votre modèle de déploiement et de distribution.
• PREBOOT issu de v1 est accepté puis ignoré silencieusement en v2 — ni erreur, ni avertissement, ni clé /config.
• Vous opérez un service, vous n’ajoutez pas juste une dépendance : un conteneur, un token, un chemin réseau, un plafond d’admission et la responsabilité des mises à jour.
• Les requêtes en file ont poussé la latence de bout en bout à environ deux durées de session lors de l’exécution (2, 2) ; l’attente en file n’a pas été mesurée séparément.
• Le timing REST mesuré inclut un aller-retour HTTP et n’isole pas le coût de lancement du navigateur ni ne prouve sa réutilisation.

Qui devrait l’utiliser, et qui devrait s’en passer

Browserless prend tout son sens quand plus d’une chose a besoin d’un navigateur. Un service de rendu partagé entre plusieurs applications, une équipe qui veut des captures d’écran et des PDF via un endpoint HTTP plutôt que de dépendre de Chrome dans chaque service, une chaîne de traitement qui a réellement besoin d’un plafond de capacité avec backpressure mesurable — c’est exactement le profil adapté. Si vous avez déjà Docker et quelqu’un pour opérer le déploiement, l’histoire opérationnelle est claire : admission prévisible, backpressure observable, et aucun processus Chrome ni zombie accumulé dans la vérification séquentielle de 30 sessions.

C’est aussi un bon choix si l’alternative consiste à installer son propre Chromium dans chaque service de la stack. Centraliser cela dans un seul conteneur avec un token et un plafond est un vrai gain architectural.

Passez votre chemin si vous écrivez un seul script. Télécharger 4,3 Go et faire tourner un conteneur pour qu’un unique fichier Python récupère une page rendue, c’est beaucoup de cérémonie pour une petite tâche — une bibliothèque de navigateur dans votre processus le fait sans service séparé. Passez votre chemin si les conditions SSPL ne conviennent pas à votre produit commercial et que vous ne pouvez pas les résoudre. Passez votre chemin si ce que vous voulez vraiment est un navigateur déjà préchauffé sans coût à froid, parce que PREBOOT ne vous donnera pas ça en v2. Et passez votre chemin si votre vrai problème est la gestion anti-bot, puisque cela relève d’un endpoint que je n’ai volontairement pas testé et que je ne cautionne pas.

Alternatives, et où Thunderbit se situe

La comparaison utile n’est pas Browserless contre un autre conteneur. C’est l’endroit où vit le navigateur et qui est responsable de le maintenir en vie.

Lecture associée : test de Browsertrix Crawler.

Lecture associée : test de chromedp.

Si vous voulez un navigateur dans votre propre processus et que vous ne craignez pas d’écrire les waits, une bibliothèque est plus légère et n’impose pas de déploiement. J’ai détaillé ce côté dans la comparaison Playwright vs Puppeteer et dans la sélection de projets open source de scraping.

Si vous ne voulez pas opérer de navigateur du tout, notre Thunderbit est une alternative managée. Browserless renvoie du contenu rendu que votre code interprète ; Thunderbit peut renvoyer du Markdown ou des données alignées sur un schéma, tandis que le fournisseur gère l’infrastructure de rendu. Cet article n’a pas benchmarké la latence, la capacité, le comportement en cas d’échec, la qualité d’extraction ni le coût de Thunderbit ; le tableau décrit donc des frontières de responsabilité, pas une comparaison de performances.

Lectures liées issues de la même série de tests : le test de Crawl4AI couvre un pipeline Markdown adossé à un navigateur que vous opérez vous-même, et la vue d’ensemble des outils de scraping web cartographie la catégorie au sens large.

Essayez Thunderbit pour l'extraction de données web

Verdict

Faut-il faire tourner Browserless ? Oui, si plusieurs appelants ont besoin d’un navigateur, si quelqu’un peut opérer le conteneur, et si votre revue de licence valide le modèle de déploiement. Dans trois tests synthétiques d’admission, le nombre de requêtes acceptées correspondait à CONCURRENT + QUEUED, les dépassements recevaient un 429, et /pressure concordait avec les comptes visibles côté client. Dans un test séquentiel séparé de 30 sessions, aucun processus Chrome ni zombie ne s’est accumulé. Un essai de timeout a renvoyé 408 près de la limite configurée. Ce sont des observations utiles et bornées, pas des garanties universelles.

Il faut toutefois être honnête sur l’investissement. C’est une image de 4,34 Go et un service que vous opérez, pas une simple dépendance que vous ajoutez ; ce test n’a pas établi de comparaison de vitesse avec une bibliothèque de navigateur intégrée au processus. Ce que vous gagnez, c’est un navigateur que vous pouvez rationner : un plafond connu et un backpressure mesurable. Dans le contrôle séquentiel de 30 sessions, aucun processus Chrome ni zombie accumulé n’a été observé. Les coûts sont le poids du déploiement et une licence qu’il faut lire. Si vous rendez seulement quelques pages depuis un script unique, l’échange ne vaut pas le coup. Si vous exploitez une couche de rendu dont plusieurs services dépendent, oui — mais vérifiez vos variables d’environnement v1 à l’entrée, parce que PREBOOT peut rester là à avoir l’air actif alors qu’il ne fait strictement rien.

Essayez Thunderbit pour l'extraction de données web Get Started Free

FAQ

Browserless rend-il Chrome sans interface plus rapide ?
Ce test ne permet pas de répondre à cela. L’endpoint HTTP est devenu réactif 0,78 s après docker run; le premier appel /content a ensuite pris 0,32 s et les appels suivants dans le même conteneur environ 0,15 s. Ces chiffres combinent un aller-retour HTTP, du travail navigateur, la navigation et le transfert de réponse. Le banc n’a pas isolé le temps de lancement, ni tracé la réutilisation des processus, ni publié de benchmark comparable intégré au processus. Utilisez Browserless pour la frontière de service partagée et le contrôle d’admission, puis mesurez votre propre chemin de latence.

Que se passe-t-il quand on dépasse la limite de concurrence de Browserless ?
Vous recevez immédiatement un HTTP 429. Le plafond est exactement CONCURRENT + QUEUED, et je l’ai confirmé sur trois configurations : (2,2) a accepté 4 requêtes et en a rejeté 4, (3,5) a accepté 8 et rejeté 4, (5,5) a accepté 10 et rejeté 4. Le endpoint /pressure du serveur a indiqué à chaque fois des comptes cohérents de running, queued et recentlyRejected. À noter : les requêtes en file ne échouent pas, elles attendent — en (2,2) avec un travail de 5 secondes, les réponses réussies ont pris entre 5,7 s et 11,0 s. Concevez votre client pour traiter le 429 comme un signal de backpressure avec retry et backoff.

PREBOOT fonctionne-t-il encore dans Browserless v2 ?
Non. PREBOOT a été supprimé en 2.0.0, et v2 accepte -e PREBOOT=true sans aucune erreur ni avertissement tout en n’en faisant rien. J’ai confirmé ce caractère inerte de trois façons : la latence était indiscernable du comportement par défaut, un conteneur PREBOOT=true au repos n’avait aucun processus chrome en attente, et /config n’expose aucune clé preboot. Si vous avez migré une config v1, vos instances ne sont pas préchauffées. À noter que KEEP_ALIVE, supprimé dans la même version, affiche bien un avertissement « deprecated and ignored » — le problème de silence concerne donc spécifiquement PREBOOT.

Browserless est-il gratuit pour un usage commercial ?
Le dépôt propose SSPL-1.0 ou une licence commerciale Browserless, mais cet article ne mappe pas des scénarios commerciaux ou closed source précis à l’une ou l’autre option. Consultez la licence actuelle et le guide officiel de déploiement, puis faites évaluer votre modèle de déploiement et de distribution par la personne responsable des licences logicielles.

Browserless laisse-t-il des processus Chrome zombies derrière lui ?
Aucun n’a été observé sur la fenêtre testée. Après 30 sessions séquentielles, le conteneur comptait 0 processus Chrome et 0 zombie, avec seulement dumb-init, node, Xvfb, start.sh et sh encore présents. Le détecteur a compté 11 processus de la famille Chrome pendant qu’une session était active, donc il n’était pas aveugle. La mémoire du conteneur est passée de 294 Mio à 303 Mio puis s’est stabilisée dans les échantillons. Ce n’est pas un résultat d’endurance sur plusieurs heures, ni en concurrence, ni sur des milliers de sessions.