Cheerio vs. Puppenspieler: Wie man das richtige Tool auswählt

Beide sind Node.js-Bibliotheken auf unterschiedlichen Ebenen. Cheerio nimmt vorhandenes HTML und stellt dir Selektoren zur Datenextraktion bereit. Puppeteer startet einen echten Chromium-Browser, führt das JavaScript der Seite aus und lässt dich das Ergebnis lesen oder anklicken.

Der schnellste Filter zur Unterscheidung von Cheerio und Puppeteer ist der View-Source-Test: Durchsuche den Rohquellcode nach den gewünschten Daten. Wenn sie dort vorhanden sind, reichen Cheerio und ein HTTP-Client aus. Wenn der Quellcode eine leere Hülle mit JS-Bundles ist, benötigst du einen Browser.

Cheerio ist eine reine Parsing-Bibliothek. Du übergibst ihr eine HTML-Zeichenkette mit cheerio.load(html) und sie gibt ein $ Objekt zurück, das jQuery nachahmt: $('h1').text(), $('a.product').each(...), Attribut-Lookups, Traversal. Es gibt kein DOM, keine Layout-Engine, keine JavaScript-Laufzeitumgebung.

Cheerio ruft HTML auch nicht selbst ab, daher kombinierst du es mit axios, node-fetch oder undici. Diese Trennung ist ein Vorteil: Du kontrollierst die Anforderungsschicht und Cheerio konzentriert sich auf das Parsen.

Puppeteer ist eine Node.js-API, die Chrome oder Chromium über das Chrome DevTools-Protokoll steuert. Wenn du npm install puppeteer, wird ein passender Chromium-Build mitgeliefert, sodass du keine separate Browser-Binärdatei verwalten musst.

Ein typisches Skript durchläuft denselben Lebenszyklus: puppeteer.launch(), browser.newPage(), page.goto(url), page.waitForSelector(...) für asynchrone Inhalte, dann page.content() oder page.evaluate(...) um das gerenderte DOM auszulesen.

Cheerio und Puppeteer nebeneinander zu stellen, ist weniger eine Entscheidung als vielmehr eine Bestätigung dafür, welche Aufgabe du hast. Geschwindigkeit und Speicherbedarf sprechen für Cheerio. JavaScript-Rendering, Netzwerküberwachung und Benutzersimulation sind die Stärken von Puppeteer.

Cheerio parst HTML in Millisekunden und benötigt pro Worker nur wenige Megabyte, sodass Tausende von Parses in einen einzigen Node.js-Prozess oder eine kleine serverlose Funktion passen. Jede Puppeteer-Browserinstanz benötigt in der Regel zwischen 150 und 300 MB RAM (Benchmark-Werte der Community zum Zeitpunkt der Erstellung dieses Artikels; bitte anhand Ihrer Arbeitslast überprüfen). Auf einem 1-GB-Lambda-Server ist die Parallelität damit schnell ausgeschöpft.

Wenn Sie $('div.card .price').text(), können Sie auch Cheerio schreiben. Die meisten Aufgaben umfassen 10 bis 20 Zeilen. Puppeteer stellt höhere Anforderungen: Sie sollten sich mit async/await, dem Seitenlebenszyklus und dem Debuggen von Timing-Fehlern, bei denen ein Selektor ausgelöst wird, bevor die Daten eintreffen.

Greife zu Cheerio, wenn der Antworttext bereits die Daten enthält. Das deckt einen großen Teil des öffentlichen Webs ab: Blogs, Nachrichten, Marketing-Seiten, RSS, Sitemaps, serverseitig gerenderte Suchergebnisse, Dokumentation.

Im Vergleich zwischen Cheerio und Puppeteer für diese Ziele ist Puppeteer überdimensioniert. Eine Cheerio-plus-Axios-Pipeline scrapt mehr Seiten pro Sekunde und passt in kostengünstige serverlose Worker. Wenn curl URL | grep Ihre Daten findet, wird Cheerio das auch.

Puppeteer spielt seine Stärken aus, wenn die Seite eher eine Anwendung als ein Dokument ist. SPAs, die auf React, Vue oder Angular basieren, liefern oft eine leere Hülle aus und fügen Inhalte nach dem Laden per XHR ein. Außerdem benötigen Sie einen echten Browser für Infinite Scroll, Dashboards mit Login-Zugang, Cookie- oder Session-Verwaltung sowie mehrstufige Formulare.

Puppeteer eignet sich auch, wenn das Scraping ein Nebeneffekt einer umfassenderen Automatisierung ist: Screenshots, PDFs, Formularübermittlungen, Überprüfungen der Anzeigenplatzierung.

Die sauberste Antwort auf die Frage „Cheerio oder Puppeteer?“ für die meisten nicht trivialen Websites lautet: beides. Behandle Rendering und Parsing als getrennte Aufgaben: Puppeteer erstellt das endgültige DOM und übergibt den HTML-Code dann an Cheerio.

Warum trennen? Das Ausführen von querySelectorAll innerhalb page.evaluate löst bei jedem Selektor-Durchlauf einen Callback im Browser aus, und jeder Hin- und Rückweg durchläuft das DevTools-Protokoll. Bei zehn Feldern auf tausend Seiten summieren sich die Kosten.

Das einmalige Abrufen des gerenderten HTMLs mit page.content() und es lokal mit Cheerio zu parsen, ist schneller, und deine Selektorlogik bleibt auch ohne Browser debuggbar.

Nach npm init -y && npm install puppeteer cheerio, sieht ein Hybrid-Scraper für quotes.toscrape.com sieht so aus:

const puppeteer = require('puppeteer');
const cheerio = require('cheerio');

(async () => {
  const browser = await puppeteer.launch({ headless: 'new' });
  const page = await browser.newPage();
  await page.goto('https://quotes.toscrape.com/', { waitUntil: 'networkidle2' });

  const html = await page.content();
  await browser.close();

  const $ = cheerio.load(html);
  const quotes = [];
  $('div.quote').each((_, el) => {
    quotes.push({
      quote: $(el).find('span.text').text().trim(),
      author: $(el).find('.author').text().trim(),
    });
  });
  console.log(quotes);
})();

page.content() gibt den serialisierten HTML-Code des aktuellen Dokuments zurück, das übersichtlichere, moderne Äquivalent zu älteren page.evaluate(() => document.documentElement.innerHTML) Muster. Der Cheerio-Block entspricht genau dem, was du schreiben würdest, wenn axios den HTML-Code abgerufen hätte.

Auf localhost funktioniert jeder Scraper. In der Produktion zeigen sich Fehlerzustände als 403er, 429er, Fingerprinting-Herausforderungen und CAPTCHAs, sobald man eine Raten-Schwelle überschreitet. Puppeteer allein zu betreiben ist keine unauffällige Lösung: Vanille-Headless-Chromium sendet erkennbare Signale aus.

Realistische Skalierung bedeutet, private oder mobile Proxys zu rotieren, User-Agents zu randomisieren, Wiederholungsversuche mit Backoff durchzuführen und anspruchsvollere Anfragen über eine verwaltete Scraping-API zu leiten, die gerenderten HTML-Code für Cheerio zurückgibt.

Keine der beiden Bibliotheken ist die einzige Option. Playwright ähnelt Puppeteer, unterstützt jedoch Chromium, Firefox und WebKit und verfügt über eine automatische Wartefunktion, die viele zeitliche Probleme beseitigt. Selenium ist das ältere, vielseitige Arbeitstier und die richtige Wahl, wenn Ihr Team bereits ein Grid betreibt. Was das Parsing angeht, bietet jsdom ein echtes DOM und führt Skripte aus, während htmlparser2 der Streaming-Parser ist, auf dem Cheerio basiert.

• Rendering und Parsing sind unterschiedliche Aufgaben. Cheerio parst HTML; Puppeteer rendert Seiten. Wählen Sie das Werkzeug passend zur Aufgabe, nicht nach Ihrer Gewohnheit.
• Nutzen Sie den „View-Source“-Test. Befinden sich die Daten in der rohen Antwort, ist Cheerio in Kombination mit einem HTTP-Client schneller, kostengünstiger und einfacher zu warten.
• Greifen Sie zu Puppeteer, wenn JavaScript das DOM aufbaut, wenn Sie Klicks, Scrollvorgänge oder Anmeldungen benötigen oder wenn die Seite eine SPA-Shell ist.
• Das Hybrid-Muster ist auf JS-lastigen Seiten mit vielen Feldern die beste Wahl. Rendern Sie einmal mit page.content(), dann parse den HTML-Code in Node mit Cheerio.
• Planen Sie frühzeitig Maßnahmen gegen Bots ein. Proxys, Fingerprint-Hardening, Wiederholungsversuche und CAPTCHAs entscheiden darüber, ob Ihr Scraper den Produktivbetrieb übersteht.

Ja, Cheerio ist deutlich schneller, da es niemals einen Browser startet. Ein Cheerio-Parse läuft in Millisekunden gegen eine In-Memory-Zeichenkette, während das Laden einer Seite mit Puppeteer von der Netzwerk-, Render- und JavaScript-Ausführungszeit abhängt, was in der Regel einige Sekunden dauert. Auf gleicher Hardware können Sie in der Regel 10- bis 100-mal mehr Cheerio-Worker parallel ausführen als Puppeteer-Worker.

Nein. Cheerio sieht nur den HTML-Code, den man ihm übergibt. Wenn eine Seite ihren Inhalt also über clientseitiges JavaScript aufbaut, gibt Cheerio eine leere Hülle zurück. Man benötigt entweder einen Headless-Browser wie Puppeteer oder Playwright davor, oder man kann manchmal direkt auf die zugrunde liegende JSON-API zugreifen, die die SPA aufruft, und das Rendern komplett überspringen.

Du benötigst einen HTTP-Client, aber es muss nicht unbedingt axios sein. Cheerio erwartet eine HTML-Zeichenkette, daher funktioniert alles, was eine solche abruft: axios, node-fetch, undici, der integrierte fetch in modernem Node.js oder sogar das Einlesen einer gespeicherten .html Datei. Wählen Sie den Client, der Ihnen die für Ihr Projekt erforderlichen Funktionen für Wiederholungsversuche, Proxy und Header-Steuerung bietet.

Technisch gesehen ja, da Puppeteer das DOM mit page.$$eval und ähnliche Helper abfragen. In der Praxis ist das jedoch verschwenderisch: Jeder Selektor-Durchlauf durchläuft das DevTools-Protokoll, und du zahlst die Speicher-Kosten des Browsers für Aufgaben, die gar kein JavaScript benötigen. Die meisten Teams behalten Puppeteer für das Rendering und lassen Cheerio die Extraktion übernehmen.

Playwright ist heute in der Regel die sicherere Standardwahl. Es unterstützt Chromium, Firefox und WebKit über eine einzige API, bietet eine bessere automatische Wartezeit und verfügt von Haus aus über leistungsfähigere Debugging-Tools. Entscheiden Sie sich für Puppeteer, wenn Ihr Team bereits über Puppeteer-Erfahrung verfügt, wenn Sie nur Chromium nutzen oder wenn Sie eine bestehende Puppeteer-Codebasis erweitern.

Bei der Entscheidung zwischen Cheerio und Puppeteer geht es im Grunde darum, ob Ihre Zielseite einen Browser benötigt. Wenn die HTML-Antwort die Daten bereits enthält, ist Cheerio in Kombination mit einem HTTP-Client die schlanke, schnelle und kostengünstige Lösung. Wenn ein JavaScript-Framework das DOM zur Laufzeit aufbaut, benötigen Sie Puppeteer oder Playwright, um es zunächst zu rendern. Und wenn eine Seite JS-lastig ist, Sie aber bei jedem Besuch viel extrahieren müssen, rendern Sie einmal mit Puppeteer und parsen Sie mit Cheerio.

Was keine Bibliothek allein lösen kann, ist die Realität in der Produktion: Blockierungen, rotierende IPs, Fingerprinting und CAPTCHAs. Wenn du lieber deinen Cheerio-Code behalten und den Kampf gegen die Request-Ebene beenden möchtest, liefert WebScrapingAPI gerenderten, entsperrten HTML-Code über einen einzigen Endpunkt, sodass sich dein Parser auf Selektoren statt auf Tarnung konzentrieren kann. Wählen Sie das Tool, das zu Ihrer Seite passt, planen Sie frühzeitig Maßnahmen gegen Bots ein, und Sie werden viel weniger Zeit mit dem Debuggen von Scrapern und mehr Zeit mit der Nutzung der Daten verbringen.