Render-Modi

renderMode steuert, wie Thunderbit die Seite vor der Verarbeitung abruft. Es ist der Hebel zwischen Latenz, Kosten und der Fähigkeit, dynamische Inhalte zu verarbeiten.

none (Standard)

Reiner HTTP-Fetch. Kein Browser, keine JavaScript-Ausführung.

• Geeignet für: server-gerenderte Seiten, RSS, JSON-Endpunkte, klassische Blogs
• Latenz: am niedrigsten
• Limit: liefert leeres / Shell-HTML bei SPAs und JS-hydratisierten Inhalten

basic

headless Browser mit JS-Ausführung, aber ohne vollständiges Warten auf Hydration.

• Geeignet für: Seiten, die JS zum Rendern brauchen, sich aber schnell stabilisieren
• Latenz: ~1–2× none
• Limit: spät eintreffende Inhalte (Lazy-Load, async Fetch) können verloren gehen

full

headless Browser mit vollständiger Hydration + konfigurierbarem waitFor.

• Geeignet für: SPAs, Infinite Scroll, Inhalte, die aus APIs hydratisieren
• Latenz: am höchsten
• Tipp: kombiniere mit waitFor (ms) nur, wenn du es brauchst — zusätzliches Warten kostet dich Latenz bei jeder Anfrage

Wie wählen

1. Starte mit none. Wenn du leeren Inhalt bekommst (SCRAPE_EMPTY_CONTENT), upgrade.
2. Probier als Nächstes basic.
3. Greif für bekannte SPAs auf full zurück.

Setz nicht „zur Sicherheit" auf full als Default — du zahlst die 5–10-fache Latenz ohne Gewinn auf den meisten Seiten.

Diese Seite wird mit Benchmarks pro Modus erweitert — schau bald wieder vorbei.