Hoeveel dedicated vCPU heeft een VPS voor webscraping met headless Chrome nodig?

Hoeveel headless browsers kan elk plan draaien?

Eén headless Chrome-browser heeft tussen 1,5 en 2 vCPU nodig: twee gepubliceerde regels vallen in dat bereik. Playwright Test start standaard half zoveel workers als er logische CPU-cores zijn. BrowserStack, dat echte browsers als bedrijf draait, vraagt self-hosted klanten om 1,5 CPU per browser op Linux voor standaardwebsites, en minstens 2 voor intensieve sites of gebruik rond de klok. Toegepast op elk plan:

Waarom gebruikt headless Chrome zoveel CPU?

Een headless browser doet alles wat een zichtbare doet, behalve naar een scherm tekenen. Hij downloadt de pagina, parseert HTML en CSS, voert elk script uit, legt de pagina uit en houdt timers actief. Chromium verdeelt dat werk over meerdere processen: een browserproces dat de rest beheert, en rendererprocessen voor webinhoud, waarbij elk nieuw tabblad of venster in de regel in een eigen proces opent. Tien tabbladen kosten bijna tien renderers aan CPU.

Drie aanpassingen verlagen de rekening zonder het resultaat te veranderen:

• Blokkeer wat nooit wordt gelezen. Afbeeldingen, fonts en media kosten bandbreedte en decodeertijd; request interception in Puppeteer of routing in Playwright weigert ze.
• Hergebruik één browser, open verse contexts. Chrome starten is de dure stap; een nieuwe context of pagina binnen een draaiende browser is veel goedkoper.
• Sla de browser over wanneer de data het toelaat. Data die in de HTML staat of in een JSON API die de pagina aanroept, komt terug van een gewone HTTP-client, die helemaal geen script draait.

Sinds Chrome 132 wordt de oude headless-modus alleen nog als aparte binary geleverd, chrome-headless-shell; --headless op gewone Chrome draait de nieuwe modus.

Maken dedicated vCPU's uit voor scraping-workers?

Een browser die CPU tekortkomt, faalt in plaats van langzamer te worden. Navigatie- en selectortimeouts staan in seconden. Wanneer een buur CPU-tijd opslokt, worden pagina's te laat gerenderd, verlopen wachttijden en wordt een job die zou zijn gelukt opnieuw geprobeerd, wat meer CPU kost. Browserless, dat gehoste Chrome verkoopt, schrijft het in zijn documentatie: lagere concurrency geeft elke browser meer CPU en geheugen, vermindert timeouts en verbetert de stabiliteit. Verloren CPU-tijd verschijnt als steal, uitgelegd in wat CPU-stealtime is en hoe je het op een VPS controleert.

Bij Cobaltfell is de CPU-kant van die afweging vastgelegd. Een vCPU is één hardwarethread van de hostprocessor. Die van jou zijn één op één vastgezet aan je VPS en worden nooit aan een andere klant uitgeleend, en de twee threads van een fysieke core blijven bij elkaar, dus elke 2 vCPU vormen één hele core die geen buur deelt. Volledige belasting is toegestaan zolang je werk het nodig heeft: geen CPU-credits, geen burst-venster en geen throttling na een paar minuten op 100%.

Concurrency bepaal je op elke host op dezelfde manier: begin met één browser per twee vCPU, verhoog zolang de foutmarge stabiel blijft, en stop bij de eerste stijging van timeouts.

Hosts die dedicated vCPU's verkopen, gerangschikt volgens dezelfde schriftelijke criteria, staan in welke de beste dedicated-CPU-VPS-provider is in 2026.

Hoe draai ik Chrome-workers veilig op een VPS?

Houd de Chrome-sandbox aan, draai als normale gebruiker en geef de container een init-proces. Gescrapete pagina's zijn per definitie niet-vertrouwde code, en de officiële gidsen zijn het op elk punt eens:

• Sandbox. De troubleshootinggids van Puppeteer noemt draaien zonder sandbox ten zeerste afgeraden. De Docker-gids van Playwright merkt op dat draaien als root de Chromium-sandbox uitschakelt, en raadt een aparte gebruiker plus het bijbehorende seccomp-profiel aan voor scraping en crawlen.
• Init-proces. Beide gidsen raden de --init-flag van Docker aan, zodat afgeronde Chrome-childprocessen worden opgeruimd in plaats van op te stapelen als zombies.
• Gedeeld geheugen. Playwright raadt --ipc=host aan voor Chromium, omdat Chromium zonder dat geheugen kan uitputten en crashen.

Twee cijfers vertellen hoe een pool ervoor staat: het geheugen dat alle Chrome-processen vasthouden, en de steal-kolom van 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

Hoe zit het met de regels van de websites, en met proxies?

Scrapen blijft binnen de voorwaarden van elke site en de wet die geldt voor de operator en voor de site. Deze pagina bepaalt de grootte van de machine, niet de legaliteit van een project. Aanvallen op systemen die niet van jou zijn, waaronder brute-forcing en denial of service, zijn verboden volgens wat het acceptabel-gebruikbeleid van Cobaltfell toestaat, dus het aantal requests blijft netjes.

Proxies en IP-rotatie zijn een apart onderwerp, en Cobaltfell verkoopt geen van beide. Elke VPS krijgt één IPv4-adres en een IPv6 /64 op een poort van 1 Gbit/s. Het maandelijkse verkeer van je plan telt alleen uitgaande data, en erboven gaan levert op zichzelf nooit een extra kostenpost op. De prijzen van de plannen staan onder hoeveel een VPS met dedicated cores kost.