Performance navigateur : optimisation à grande échelle

Mesurer d'abord la charge

La capacité dépend des pages, du mode du navigateur, de la durée des sessions, de la route réseau et de la concurrence de l'application. Mesurez ces facteurs ensemble avant de modifier la mémoire, le processeur, le réseau ou le cycle de vie. L'objectif est une exécution stable avec une protection cohérente de la confidentialité, pas le plus grand nombre possible de workers.

Une navigation textuelle courte ne coûte pas autant qu'une longue session avec vidéo, captures ou téléchargements. Planifiez la capacité avec le mélange réel de tâches et gardez une marge pour les démarrages simultanés, les nouvelles tentatives et la reprise.

Pourquoi l'optimisation des performances est importante

Un manque de mémoire peut interrompre BotBrowser en pleine opération, produire des résultats incomplets et altérer l’état de la session. Des processeurs surchargés ralentissent chaque instance, augmentent les temps de chargement et provoquent des dépassements de délai. L’accumulation de processus BotBrowser orphelins finit par épuiser les ressources du système.

À grande échelle, les petites inefficacités s'accumulent. La mémoire, la latence et les fermetures incomplètes influencent directement le coût de l'infrastructure et la capacité opérationnelle. Mesurez chaque charge avec ses pages, ses profils et ses routes réseau réels.

Établir une référence de capacité

Classes de charge

Classez les tâches selon leur activité et la durée pendant laquelle elles conservent des ressources :

• Navigation courte : une page simple et peu d'interactions.
• Application complexe : session longue, cadres et état actif.
• Travail visuel : vidéo, Canvas, captures et documents.
• Transfert de données : téléchargements, envois et routes plus lentes.

Mesurez chaque classe sur l'hôte, le mode, le profil et la route prévus. N'extrapolez pas un résultat obtenu avec une page vide.

Consommation mémoire

Composant	Principale source de variation
Session	Durée, pages ouvertes et état conservé
Travail visuel	Complexité, vidéo et captures
Application	DOM, JavaScript et opérations actives
Transfert	Téléchargements, envois et latence réseau
Observabilité	Journaux et artefacts autorisés

Les grandes applications, les images, les médias et les DOM complexes augmentent la consommation. Le dimensionnement doit partir de mesures effectuées sur la charge cible.

Surcharge du chargement de profil

Incluez la validation du profil, la préparation de la route et la première navigation dans la mesure du démarrage. Gardez la même version pendant chaque comparaison.

Choix opérationnels

Surdimensionnement

Une capacité supplémentaire fournit une marge utile, mais ne corrige pas une file sans limite, une fermeture incomplète ou un moteur graphique inadapté. Mesurez la charge avant d’ajouter des hôtes.

Blocage des ressources

Le blocage des médias inutiles peut réduire le travail réseau et graphique. Conservez les ressources nécessaires à la mise en page, aux interactions, à l'authentification et à la validation de confidentialité. Testez les changements sur des pages représentatives.

Configuration de la version

Conservez la configuration documentée de la version. Modifier les options de sécurité ou de rendu pour économiser des ressources peut changer le comportement des pages et compliquer la comparaison.

Réutilisation

Réutilisez une page uniquement tant qu'elle représente la même session et le même plan d'identité. Créez un nouveau contexte quand le stockage ou le profil doit être séparé, puis fermez complètement l'ancien contexte.

L'approche de BotBrowser

Le coût dépend de la page, du mode graphique, de la concurrence, de la route et de la durée de session. Utilisez une référence stable et mesurez la charge complète.

Pour les déploiements qui évaluent des parcours par contexte, Per-Context Fingerprint de BotBrowser (ENT Tier3) offre une autre option prise en charge. Comparez-la à la topologie actuelle avec la même charge autorisée et les mêmes exigences de confidentialité. Le résultat constitue une mesure propre à cette charge, pas un engagement général de capacité.

Contrôles opérationnels

Gestion de la mémoire

Mesurez la tendance mémoire avec des pages représentatives. Fermez chaque page et chaque contexte après utilisation, limitez la file de travail et recyclez le processus lorsque la politique opérationnelle l'exige. La limite adaptée au tas dépend de l'application et doit être validée avant la production.

Optimisation du processeur

Conservez le modèle multiprocessus et les capacités graphiques normales de Chromium. Régulez la concurrence avec une file bornée et augmentez la charge par étapes. Une page utilisant du JavaScript prolongé, des médias ou Canvas exige davantage de capacité qu’une navigation simple.

Optimisation réseau

Bloquez les types de ressources inutiles pour réduire la bande passante :

// Playwright
await context.route('**/*.{png,jpg,gif,svg,ico}', route => route.abort());
await context.route('**/*.{mp4,webm,ogg}', route => route.abort());

Conservez la préparation du proxy dans la configuration réseau approuvée. Ne réutilisez une route validée que si ses identifiants, sa région et sa sortie restent inchangés, puis recommencez la validation après toute modification.

Gestion parallèle des instances

Placez une file bornée entre les tâches entrantes et la capacité du navigateur. N'admettez de nouvelles tâches que tant que le processeur, la mémoire, l'attente en file et le taux d'erreur mesurés restent dans la plage opérationnelle approuvée. Lorsque la pression augmente, suspendez l'admission ou ralentissez la distribution au lieu de créer davantage de sessions.

Définissez clairement la propriété de chaque tâche. L'ordonnanceur doit distinguer les états en attente, actif, terminé, annulé et incertain afin que la reprise ne duplique pas silencieusement un travail. Appliquez les limites et délais de nouvelle tentative au niveau de la file, puis rendez la capacité uniquement après la fermeture propre de la session précédente.

Évaluez la régulation avec des classes de charge représentatives. Un parcours multimédia, une navigation courte et un long flux authentifié peuvent nécessiter des groupes de planification distincts. Maintenez chaque groupe dans son budget mesuré et augmentez-le progressivement lorsque le candidat de version reste stable.

Cycle de vie sous forte charge

BotBrowser 150.0.7871.46 améliore la stabilité des charges sans interface graphique et fortement concurrentes qui créent souvent des pages, des processus de travail, des captures et des BrowserContexts. Cette évolution doit rester associée à une régulation applicative, des files bornées et une fermeture complète.

Préchauffez chaque processus avant la mesure. Fixez une limite de concurrence, placez le travail supplémentaire en file et fermez entièrement les contextes devenus inutiles. Conservez le statut de sortie du navigateur et stderr pour distinguer un problème de profil d’une pression sur les ressources. Sous Linux, gardez le même moteur graphique entre processus comparables.

Pour l'identité par contexte, appliquez le profil avant la première page ou le premier processus de travail. Les contrôles opérationnels compatibles peuvent évoluer ensuite, mais un contexte actif doit garder la même identité de famille de navigateur.

Validation

Validez une seule optimisation à la fois avec une charge de préproduction contrôlée. Comparez la réussite des tâches, le statut de sortie du navigateur, la tendance mémoire, la latence de création des pages, les captures et la fermeture des contextes avec la configuration de version inchangée. Conservez le même profil, la même route proxy, le même moteur graphique et les mêmes pages.

Utilisez le guide Linux GPU Backend pour un déploiement sans écran physique. Gardez le support graphique actif, sauf indication contraire du moteur documenté. Une modification qui retire une capacité requise du navigateur n’est pas une optimisation valide.

Journal de décision

Conservez pour chaque essai la version du navigateur, la famille de profil, la classe d'hôte, le moteur graphique, la route réseau et la limite de concurrence. Ajoutez la durée de l'échantillon, le nombre de tâches terminées et la raison d'un éventuel arrêt. Cette fiche permet à l'équipe d'exploitation de reproduire le résultat et d'annuler un réglage sans dépendre de la mémoire de son auteur.

Avant un déploiement progressif, définissez aussi le propriétaire du changement et le signal de retour arrière. Une hausse de débit ne suffit pas si elle s'accompagne de sorties du navigateur, de files plus longues ou d'un rendu incomplet. Étendez la nouvelle configuration par groupe de processus et comparez chaque groupe au témoin inchangé.

Diagnostic des écarts

Si le résultat se dégrade, vérifiez d'abord ce qui a changé entre les deux exécutions : page, profil, proxy, backend graphique, image de conteneur ou concurrence. Une comparaison avec plusieurs variables ne permet pas d'attribuer l'écart. Revenez à la configuration témoin, puis réintroduisez les changements un par un.

Acceptation des versions et preuves de reprise

Comparer des phases opérationnelles représentatives

Un candidat doit être comparé à la référence approuvée avec les mêmes classes de charge et la même image hôte. Séparez le démarrage à froid, le travail stabilisé et l'arrêt contrôlé. Le démarrage à froid indique si de nouveaux workers peuvent rejoindre le service de manière prévisible. La phase stable montre si l'attente en file et l'utilisation des ressources restent maîtrisées une fois les caches et connexions établis. L'arrêt confirme que la capacité revient après les tâches terminées, annulées ou en échec.

Maintenez chaque phase assez longtemps pour observer la variation normale des pages et de la route réseau. Comparez les distributions de durée et d'attente, ainsi que la pression mémoire durable, la contention CPU, l'activité de stockage et l'utilisation réseau. Une exécution courte réussie vérifie la compatibilité de base, mais ne suffit pas pour approuver un budget de production.

Documentez le mélange de tâches qui fonde la décision. Incluez les tâches ordinaires, la session prise en charge la plus longue et un cas d'échec autorisé. Le dossier restera ainsi utile lorsque l'application, la route, l'image hôte ou la version du navigateur changera.

Appliquer des critères d'acceptation explicites

L'acceptation doit confirmer que le service accomplit le travail requis tout en préservant une marge opérationnelle. Examinez ensemble la réussite des tâches, le traitement attendu des erreurs, la croissance de la file, la fin du nettoyage et le temps de reprise. Une version ne doit pas être approuvée uniquement parce que les tâches rapides progressent si les tâches plus lourdes deviennent moins fiables.

Utilisez l'objectif de service existant comme base de décision. S'il n'existe pas encore d'objectif formel, établissez-en un à partir de la version approuvée avant de comparer le candidat. Consignez tout compromis volontaire, par exemple une légère hausse de latence contre une pression mémoire durable plus faible, et faites-le approuver par le responsable de l'application.

Intégrez les contrôles fonctionnels et de confidentialité au même plan. Une économie obtenue en supprimant un comportement nécessaire de rendu, de stockage, de média ou de réseau constitue une régression. Les mesures de performance ne soutiennent une version que si le parcours représentatif conserve son résultat autorisé.

Exercer la régulation et la reprise

Le test d'acceptation doit comprendre une période où les arrivées dépassent la capacité disponible. Confirmez que la file bornée applique la politique d'admission prévue, protège le travail en cours et retrouve sa plage normale lorsque la demande baisse. Vérifiez que les nouvelles tentatives sont différées conformément à la politique au lieu d'ajouter immédiatement de la pression.

Testez aussi une interruption contrôlée d'un worker. Le superviseur doit identifier son indisponibilité, conserver un résultat clair pour la tâche et n'admettre un remplacement que lorsque la capacité est disponible. Le travail terminé ne doit pas être répété silencieusement, et le travail incertain doit suivre la procédure de rapprochement de l'application.

Après l'interruption, vérifiez que la mémoire, l'activité de stockage, l'attente en file et la durée des tâches reviennent dans la plage approuvée. Un service qui accepte de nouveau des tâches alors que le nettoyage reste incomplet n'a pas entièrement repris. Maintenez une admission réduite jusqu'à ce que le flux et la marge de l'hôte soient stables.

Conserver les preuves de retour arrière

Chaque changement de performance doit avoir une condition de retour arrière et un responsable. Cette condition peut être une croissance persistante de la file, une baisse de fiabilité, un nettoyage incomplet ou une perte de marge de reprise. Définissez-la avant le déploiement afin d'éviter une interprétation improvisée pendant un incident.

Conservez l'identifiant de version, l'image hôte, le manifeste de charge, la classe de route, la configuration, la fenêtre d'observation et les résultats résumés du candidat comme de la référence. Stockez les journaux selon la politique de conservation et d'accès, sans identifiants, contenu de page ni données personnelles.

Lors d'un déploiement progressif, élargissez le périmètre seulement après que l'étape précédente a respecté les critères pendant une fenêtre d'observation adéquate. Si une condition de retour apparaît, arrêtez l'expansion, réduisez les admissions, terminez ou rapprochez le travail accepté et restaurez la dernière configuration approuvée. Rejouez ensuite la référence représentative pour confirmer que la reprise est complète.

Notes de production

Commencez par les défauts, optimisez les goulots d'étranglement. Profilez votre charge de travail réelle avant d'appliquer les optimisations.

Fermez les pages terminées. Appeler page.close() marque une limite claire du cycle de vie. Naviguer vers une autre URL ne termine pas la responsabilité de la page.

Utilisez domcontentloaded au lieu de networkidle0 pour la vitesse. La stratégie d'attente networkidle0 attend que toute activité réseau s'arrête, ce qui peut prendre des secondes sur les pages lourdes.

Définissez des délais d'attente réalistes. Choisissez la limite à partir du parcours et traitez son expiration comme un résultat contrôlé.

Surveillez la mémoire continuellement. Définissez les alertes selon la capacité mesurée de l'hôte et l'objectif de service.

Recyclez les instances selon la tendance. Redémarrez un processus lorsque la politique opérationnelle ou la tendance des ressources le demande, après la fermeture correcte de ses contextes.

Évaluez Per-Context Fingerprint comme option de déploiement. Si votre licence le permet, comparez le parcours par contexte pris en charge au déploiement actuel avec la même charge représentative. Planifiez la capacité à partir des résultats mesurés.

Questions fréquentes

Quelle quantité de mémoire prévoir par instance ?

Mesurez des pages représentatives sur l’hôte cible. Les médias, iframes, extensions et rendus peuvent modifier fortement la consommation. Conservez une marge pour le système et les lancements concurrents.

Le mode headless économise-t-il de la mémoire ?

Il peut réduire une partie du travail du système de fenêtres, mais la page utilise toujours le rendu, le réseau, JavaScript et les ressources graphiques. La différence dépend de la charge.

Faut-il désactiver le support graphique ?

Gardez le support graphique actif. Sa suppression peut modifier les capacités de rendu et empêcher les charges qui utilisent WebGL ou WebGPU de fonctionner normalement. Consultez le guide Linux GPU Backend pour les hôtes headless.

Comment gérer une fermeture incomplète du navigateur ?

Appelez browser.close() sur chaque chemin de sortie et utilisez le superviseur du déploiement pour identifier un worker sans réponse. Vérifiez que la capacité de l'hôte revient à sa plage normale après une annulation ou une erreur.

--bot-time-scale affecte-t-il le chargement des pages ?

Ce paramètre contrôle la présentation temporelle liée au profil. Mesurez séparément la fin des pages et gardez la valeur constante entre processus comparables.

Quand ajouter de la capacité ?

Ajoutez de la capacité lorsqu'une charge durable ne respecte plus l'objectif de service après vérification des files et de la fermeture. Utilisez les tendances CPU, mémoire, réussite des tâches et sorties du navigateur plutôt qu'un seuil fixe.

Quel est l'impact du proxy ?

Un proxy ajoute de la latence réseau. Gardez la route stable pendant la mesure comparative et rapprochez la sortie de la région requise lorsque le parcours le permet.

Décisions de capacité

L'optimisation des performances pour BotBrowser consiste à maximiser la densité d'instances tout en maintenant la stabilité et la cohérence des empreintes. Concentrez-vous sur la gestion mémoire via les limites de tas et le recyclage d'instances, l'efficacité CPU via les capacités nécessaires et les limites de concurrence, et l'optimisation réseau via le blocage de ressources et la configuration proxy.

Pour la configuration d'infrastructure, voir Headless Server Setup et Docker Deployment Guide. Pour la référence des paramètres CLI, voir CLI Recipes. Pour l'optimisation spécifique aux captures d'écran, voir Screenshot Best Practices.