Technologie6 Min. Lesezeit

Vision-first vs. CSS-Selektoren: warum Koordinaten-Klicks robuster sind

Selektoren brechen bei jeder Layoutänderung. Vision-Analyse hält Automatisierung stabil, weil Elemente per Screenshot statt über fragile DOM-Pfade gefunden werden.

8. Apr. 2026

Das Selector-Problem in Antidetect-Workflows

CSS-Selektoren sind die Standardmethode, mit der Automatisierungstools Elemente auf einer Seite finden. Sie schreiben einen Pfad wie `button.submit-btn` oder `#login-form input[name="email"]`, und das Skript klickt oder füllt ihn aus. Das funktioniert, bis sich das Markup ändert — und in Antidetect-Workflows ändert sich das Markup ständig.

Verschiedene Browser-Profile können verschiedene Seitenversionen sehen. A/B-Tests, geografisch ausgerichtete Layouts, Zustimmungsbanner, Bot-Erkennungs-Herausforderungen und dynamische Klassennamen verschieben das DOM zwischen Sitzungen. Ein Selektor, der in Profil #1 funktioniert, existiert möglicherweise nicht in Profil #12.

Warum Selektoren häufiger brechen als Sie denken

Dynamische Klassennamen — Frameworks wie React, Next.js und Tailwind generieren gehashte oder Utility-Klassen, die sich zwischen Builds ändern. Ein Selektor, der auf `.css-1a2b3c` abzielt, funktioniert nach der nächsten Bereitstellung nicht mehr.
A/B-Tests — Dieselbe URL kann völlig unterschiedliche DOM-Strukturen an verschiedene Besucher liefern. Ihr Selektor geht von einer Variante aus; die Seite zeigt eine andere.
Zustimmungs- und Cookie-Banner — Diese Overlays injizieren neue Elemente, verschieben z-Indizes und umhüllen manchmal die gesamte Seite in einen Container, der nicht existierte, als Sie den Selektor schrieben.
Bot-Erkennungs-Overlays — Cloudflare-Herausforderungen, DataDome-Interstitials und ähnliche Systeme ersetzen den Seiteninhalt durch ihr eigenes Markup. Keine Selektor-Anpassung hilft, wenn die Seite selbst weg ist.
Gebiets- und Geolokalisierungsunterschiede — RTL-Layouts, übersetzte Schaltflächentexte und regionsspezifische UI-Komponenten ändern alle den DOM-Baum.

In einem Single-Browser-Skript bemerken und beheben Sie diese Probleme nacheinander. In einem Batch von 50 Profilen schlägt ein defekter Selektor stillschweigend in Dutzenden von Sitzungen fehl, bevor jemand es bemerkt.

Wie Vision-First-Interaktion funktioniert

Vision-First bedeutet, dass die KI einen Screenshot der Seite macht und ihn visuell analysiert — genauso wie ein Mensch auf einen Bildschirm schauen würde. Anstatt das DOM nach einem bestimmten Selektor zu durchsuchen, identifiziert sie Elemente nach ihrem Aussehen: "die blaue Sign-Up-Schaltfläche in der Mitte der Seite".

Der Ablauf ist unkompliziert:

Einen Screenshot des aktuellen Seitenzustands machen
Ihn an ein Vision-Modell senden, das interaktive Elemente und ihre Positionen identifiziert
Normalisierte Begrenzungsrahmen (Koordinaten) für jedes erkannte Element zurückgeben
Mit diesen Koordinaten klicken, hovern oder interagieren — keine DOM-Suche erforderlich

// Vision-first click flow
await browser_parallel_navigate({ url: "https://target.example/signup" });
const grouped = await browser_parallel_vision_analyze_grouped();
// AI identifies elements visually across all active browsers
// Returns normalized bounding boxes for each element
await browser_parallel_click_normalized_box({ box: signUpButton.box });

Koordinaten-Klicks vs Selektor-Klicks

Ein Selektor-Klick sagt "finde das Element in diesem DOM-Pfad und klicke es". Ein Koordinaten-Klick sagt "klicke an diese Position auf dem Bildschirm". Der Unterschied ist wichtig, wenn Seiten auseinandergehen.

Selektor-basierter Ansatz

// Breaks if class name changes, element moves, or overlay appears
await page.click("button.btn-primary.submit-action");
// Breaks if form structure changes
await page.fill("#signup-form input[type=email]", "user@mail.com");

Vision-basierter Ansatz

// Works regardless of class names, IDs, or DOM structure
await browser_parallel_screenshot();
const analysis = await browser_parallel_vision_analyze_grouped();
// AI finds "Sign Up" button visually — same as a human would
await browser_parallel_click_normalized_box({ box: analysis.signUp.box });

Der Vision-Ansatz kümmert sich nicht um Klassennamen, IDs oder Verschachtelungstiefe. Wenn die Schaltfläche auf dem Bildschirm sichtbar ist, wird sie gefunden. Dies ist besonders mächtig in Antidetect-Szenarien, in denen jedes Profil möglicherweise eine leicht unterschiedliche Seite rendert.

Gruppierte Analyse für Batch-Operationen

Bei der Ausführung von 20+ Browser-Profilen parallel muss die Vision-Analyse effizient sein. Ornold verwendet gruppierte Analyse — es nimmt Screenshots aus allen aktiven Sitzungen, sendet sie als Batch an das Vision-Modell und gibt Ergebnisse für jede Sitzung in einem Aufruf zurück.

Dies ist aus zwei Gründen wichtig:

Effizienz — Ein API-Aufruf verarbeitet alle Sitzungen statt N separater Aufrufe. Die Latenz bleibt unabhängig von der Batch-Größe ungefähr konstant.
Divergenz-Handling — Die KI sieht den tatsächlichen Zustand jeder Sitzung. Wenn Profil #7 ein CAPTCHA-Overlay hat, während die anderen das Formular zeigen, spiegelt das gruppierte Ergebnis das wider. Sie können die Logik pro Sitzung verzweigen, anstatt anzunehmen, dass alle Seiten gleich aussehen.

// Grouped vision analysis across all active browsers
const results = await browser_parallel_vision_analyze_grouped();
// results.groups shows which browsers are in which state
// e.g., 15 browsers on the form, 3 on CAPTCHA, 2 on error page

Wenn DOM-Modus immer noch gewinnt

Vision-Analyse ist nicht immer die richtige Wahl. DOM-basierte Interaktion (Ornolds Standardmodus) ist schneller, kostenlos und völlig zuverlässig für strukturierte Seiten mit stabilem Markup.

Verwenden Sie DOM-Modus, wenn:

Die Zielseite stabiles, vorhersehbares HTML hat (z.B. Ihre eigene App, bekannte Plattformen)
Sie Formulare mit klaren Eingabefeldern und Beschriftungen ausfüllen
Geschwindigkeit wichtiger ist als Widerstandsfähigkeit — DOM-Snapshots sind sofort, Vision-Analyse dauert 1-3 Sekunden
Sie Vision-Kreditkosten vermeiden möchten

Verwenden Sie Vision-Modus, wenn:

Seiten zwischen Profilen variieren (A/B-Tests, Geotargeting, dynamische Layouts)
Sie mit Canvas-basierten UIs, bildreichen Seiten oder benutzerdefinierten Web-Komponenten arbeiten
Selektoren ständig brechen und die Wartungskosten hoch sind
Sie überprüfen müssen, wie die Seite tatsächlich aussieht (visuelles QA)

Sie können beide Modi gleichzeitig aktivieren. Der KI-Agent wählt automatisch den besten Ansatz für jede Aktion — DOM für einfache Formularausfüllungen, Vision für komplexe oder unvorhersehbare Seiten.

Vergleich in der Praxis

Hier ist, was in der Praxis passiert, wenn Sie einen Registrierungsfluss über 30 Linken Sphere-Sitzungen ausführen:

Selektor-basierte Automatisierung

25 von 30 Sitzungen werden erfolgreich abgeschlossen
3 schlagen fehl, weil ein Zustimmungsbanner das Formular-Layout verschoben hat
1 schlägt fehl, weil Cloudflare eine Interstitial-Seite bereitgestellt hat
1 schlägt fehl, weil die Website während der Ausführung eine neue Version mit anderen Klassennamen bereitgestellt hat
Gesamt: 83% Erfolgsquote. Manuelle Intervention für 5 Sitzungen erforderlich.

Vision-basierte Automatisierung

29 von 30 Sitzungen werden erfolgreich abgeschlossen
1 schlägt fehl, weil die Seite nicht geladen wurde (Netzwerk-Timeout — kein Selektor-Problem)
Zustimmungsbanner, Layout-Verschiebungen und Klassennamen-Änderungen hatten keine Auswirkung
Gesamt: 97% Erfolgsquote. Ein Wiederholungsversuch für das Timeout erforderlich.

Die Lücke vergrößert sich mit zunehmender Batch-Größe. Bei 50+ Profilen erfordert selektor-basierte Automatisierung typischerweise ständige Wartung. Vision-basierte Automatisierung bleibt stabil, weil sie sich an das anpasst, was tatsächlich auf dem Bildschirm ist.

Vision-Modus in Ornold einrichten

Aktivieren Sie den Vision-Modus beim Verbinden Ihres KI-Agenten mit Ornold MCP. Wählen Sie im Dashboard-Assistent in Schritt 2 "Beide Modi", um DOM + Vision-Tools zu erhalten. Oder fügen Sie das Flag manuell hinzu:

# Claude Code — enable both DOM and Vision modes
claude mcp add --transport stdio ornold-browser -- npx ornold-mcp --token YOUR_TOKEN --mode both --linken-port 40080

# Codex — in config.toml
[mcp_servers.ornold-browser]
command = "npx"
args = ["ornold-mcp", "--token", "YOUR_TOKEN", "--mode", "both", "--linken-port", "40080"]

Jede Vision-Analyse kostet 1 Guthaben. DOM-Snapshots sind kostenlos. Mit aktiviertem "Beide Modi"-Modus verwendet der KI-Agent standardmäßig DOM und wechselt nur bei Bedarf zu Vision.

Wichtigste Erkenntnisse

CSS-Selektoren gehen von einem stabilen DOM aus. In Antidetect-Workflows ist das DOM alles andere als stabil.
Vision-First-Interaktion findet Elemente nach Aussehen, nicht nach Pfad. Sie passt sich automatisch an Layout-Änderungen, Overlays und A/B-Tests an.
Gruppierte Vision-Analyse verarbeitet Batch-Divergenz — jede Sitzung wird basierend auf ihrem tatsächlichen Zustand analysiert.
DOM-Modus ist immer noch die beste Standardwahl für Geschwindigkeit und Kosten. Verwenden Sie Vision, wenn Seiten unvorhersehbar sind oder Selektoren ständig brechen.
Beide Modi können koexistieren. Lassen Sie den KI-Agent das richtige Werkzeug für jede Aktion wählen.