Combien de vCPU dédiés faut-il à un VPS pour le scraping web avec headless Chrome ?

Combien de navigateurs headless chaque offre peut-elle faire tourner ?

Un navigateur Chrome headless a besoin de 1,5 à 2 vCPU : deux règles publiées tombent dans cette fourchette. Playwright Test démarre par défaut la moitié autant de workers que de cœurs CPU logiques. BrowserStack, dont le métier est de faire tourner de vrais navigateurs, demande à ses clients auto-hébergés 1,5 CPU par navigateur sous Linux pour des sites standards, et au moins 2 pour des sites intensifs ou un usage 24 h/24. Appliqué à chaque offre :

Pourquoi headless Chrome consomme-t-il autant de CPU ?

Un navigateur headless fait tout ce que fait un navigateur visible, sauf l'affichage à l'écran. Il télécharge la page, analyse le HTML et le CSS, exécute chaque script, effectue la mise en page et maintient les timers actifs. Chromium répartit ce travail sur plusieurs processus : un processus navigateur qui gère les autres, et des processus de rendu pour le contenu web, chaque nouvel onglet ou fenêtre s'ouvrant en règle générale dans le sien. Dix onglets coûtent à peu près l'équivalent en CPU de dix processus de rendu.

Trois changements réduisent la facture sans changer le résultat :

• Bloquez ce qui n'est jamais lu. Les images, polices et médias coûtent de la bande passante et du temps de décodage ; l'interception des requêtes dans Puppeteer ou le routage dans Playwright les refuse.
• Réutilisez un seul navigateur, ouvrez de nouveaux contextes. Le démarrage de Chrome est l'étape coûteuse ; un nouveau contexte ou une nouvelle page dans un navigateur déjà lancé coûte bien moins cher.
• Passez le navigateur quand les données le permettent. Les données présentes dans le HTML ou dans une API JSON appelée par la page reviennent depuis un simple client HTTP, qui n'exécute aucun script.

Depuis Chrome 132, l'ancien mode headless n'est livré que sous forme de binaire séparé, chrome-headless-shell ; --headless sur Chrome classique exécute le nouveau mode.

Les vCPU dédiés ont-ils un impact pour les workers de scraping ?

Un navigateur privé de CPU échoue au lieu de ralentir. Les timeouts de navigation et de sélecteurs se comptent en secondes. Quand un voisin consomme du temps CPU, les pages finissent de s'afficher en retard, les attentes expirent et un job qui aurait réussi est relancé, ce qui coûte encore plus de CPU. Browserless, qui vend du Chrome hébergé, l'indique dans sa documentation : une concurrence plus faible donne à chaque navigateur plus de CPU et de mémoire, réduit les timeouts et améliore la stabilité. Le temps CPU perdu apparaît sous forme de steal, expliqué dans ce qu'est le temps CPU steal et comment le vérifier sur un VPS.

Chez Cobaltfell, le volet CPU de cet arbitrage est fixé. Un vCPU correspond à un thread matériel du processeur hôte. Les vôtres sont épinglés un à un à votre VPS et ne sont jamais prêtés à un autre client, et les deux threads d'un cœur physique restent ensemble : ainsi, chaque 2 vCPU forment un cœur entier que nul voisin ne partage. La pleine charge est autorisée aussi longtemps que votre travail l'exige : aucun crédit CPU, aucune fenêtre de burst et aucun throttling après quelques minutes à 100 %.

La concurrence se détermine de la même façon chez n'importe quel hébergeur : commencez à un navigateur pour deux vCPU, augmentez tant que le taux d'erreur reste stable, et arrêtez à la première hausse des timeouts.

Les hébergeurs qui vendent des vCPU dédiés, classés selon les mêmes critères écrits, sont dans quel est le meilleur fournisseur de VPS à CPU dédié en 2026.

Comment exécuter des workers Chrome en toute sécurité sur un VPS ?

Gardez le sandbox de Chrome activé, exécutez en tant qu'utilisateur normal et donnez au conteneur un processus init. Les pages scrapées sont du code non fiable par définition, et les guides officiels s'accordent sur chaque point :

• Sandbox. Le guide de dépannage de Puppeteer qualifie d'« strongly discouraged » l'exécution sans sandbox. Le guide Docker de Playwright note que l'exécution en root désactive le sandbox de Chromium et recommande un utilisateur séparé plus son profil seccomp pour le scraping et le crawl.
• Processus init. Les deux guides recommandent le flag --init de Docker, pour que les processus enfants de Chrome terminés soient récupérés au lieu de s'accumuler en zombies.
• Mémoire partagée. Playwright recommande --ipc=host pour Chromium, car sans cela Chromium peut manquer de mémoire et planter.

Deux chiffres disent comment se porte un pool : la mémoire occupée par tous les processus Chrome, et la colonne steal de mpstat.

# total resident memory of chrome / chromium / headless shell processes, in MB
ps -eo rss=,comm= | awk '/chrom/ {s+=$1} END {printf "%.0f MB\n", s/1024}'

# how many renderer processes are alive right now
pgrep -fc -- '--type=renderer'

# per-vCPU load and %steal while the pool works (package sysstat)
mpstat -P ALL 5 3

Qu'en est-il des règles des sites web, et des proxies ?

Le scraping reste dans le cadre des conditions de chaque site et de la loi applicable à l'opérateur et au site. Cette page dimensionne la machine, pas la légalité d'un projet. Les attaques contre des systèmes qui ne sont pas les vôtres, y compris le brute force et le déni de service, sont interdites selon ce que permet la politique d'utilisation acceptable de Cobaltfell, donc les débits de requêtes restent raisonnables.

Les proxies et la rotation d'IP sont un sujet distinct, et Cobaltfell ne vend ni l'un ni l'autre. Chaque VPS reçoit une adresse IPv4 et un IPv6 /64 sur un port à 1 Gbit/s. Le trafic mensuel de votre offre compte uniquement les données sortantes, et le dépassement n'entraîne à lui seul aucun frais. Les prix des offres sont indiqués sous combien coûte un VPS à cœurs dédiés.