Tecnología6 min de lectura

Vision-first vs selectores CSS: por qué los clics por coordenadas resisten mejor

Los selectores se rompen cuando cambia el marcado. El análisis visual mantiene la automatización estable al encontrar elementos desde capturas en lugar de rutas DOM frágiles.

8 abr 2026

El problema de los selectores en flujos de trabajo antidetección

Los selectores CSS son la forma predeterminada en que las herramientas de automatización encuentran elementos en una página. Escribes una ruta como `button.submit-btn` o `#login-form input[name="email"]`, y el script hace clic o la rellena. Esto funciona hasta que el marcado cambia — y en flujos de trabajo antidetección, el marcado cambia constantemente.

Diferentes perfiles de navegador pueden ver diferentes versiones de página. Las pruebas A/B, los diseños dirigidos por geolocalización, los banners de consentimiento, los desafíos de detección de bots y los nombres de clase dinámicos cambian el DOM entre sesiones. Un selector que funciona en el perfil #1 puede no existir en el perfil #12.

Por qué los selectores se rompen más a menudo de lo que crees

Nombres de clase dinámicos — Marcos como React, Next.js y Tailwind generan clases con hash o utilidades que cambian entre compilaciones. Un selector dirigido a `.css-1a2b3c` deja de funcionar después del siguiente despliegue.
Pruebas A/B — La misma URL puede servir estructuras DOM completamente diferentes a diferentes visitantes. Tu selector asume una variante; la página muestra otra.
Banners de consentimiento y cookies — Estas superposiciones inyectan nuevos elementos, cambian z-indexes y a veces envuelven toda la página en un contenedor que no existía cuando escribiste el selector.
Superposiciones de detección de bots — Los desafíos de Cloudflare, los intersticiales de DataDome y sistemas similares reemplazan el contenido de la página con su propio marcado. Ningún ajuste de selector ayuda cuando la página en sí ha desaparecido.
Diferencias de localidad y geografía — Los diseños RTL, el texto de botón traducido y los componentes de UI específicos de la región cambian el árbol DOM.

En un script de navegador único, notas y corriges estos problemas uno a la vez. En un lote de 50 perfiles, un selector roto falla silenciosamente en docenas de sesiones antes de que alguien lo note.

Cómo funciona la interacción orientada a la visión

Orientado a la visión significa que la IA toma una captura de pantalla de la página y la analiza visualmente — de la misma manera que un humano miraría una pantalla. En lugar de buscar en el DOM un selector específico, identifica elementos por su apariencia: "el botón azul Sign Up en el centro de la página".

El flujo es directo:

Tomar una captura de pantalla del estado actual de la página
Enviarla a un modelo de visión que identifique elementos interactivos y sus posiciones
Devolver cuadros delimitadores normalizados (coordenadas) para cada elemento detectado
Hacer clic, pasar el ratón o interactuar usando esas coordenadas — no se necesita búsqueda en DOM

// 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 });

Clics de coordenadas vs clics de selector

Un clic de selector dice "encuentra el elemento en esta ruta DOM y haz clic en él". Un clic de coordenadas dice "haz clic en esta posición en la pantalla". La diferencia importa cuando las páginas divergen.

Enfoque basado en selectores

// 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");

Enfoque basado en visión

// 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 });

El enfoque de visión no le importan los nombres de clase, los ID o la profundidad de anidamiento. Si el botón es visible en la pantalla, se encuentra. Esto es especialmente poderoso en escenarios antidetección donde cada perfil puede renderizar una página ligeramente diferente.

Análisis agrupado para operaciones por lotes

Al ejecutar 20+ perfiles de navegador en paralelo, el análisis de visión debe ser eficiente. Ornold utiliza análisis agrupado — toma capturas de pantalla de todas las sesiones activas, las envía como lote al modelo de visión y devuelve resultados para cada sesión en una llamada.

Esto importa por dos razones:

Eficiencia — Una llamada API maneja todas las sesiones en lugar de N llamadas separadas. La latencia se mantiene aproximadamente constante independientemente del tamaño del lote.
Manejo de divergencia — La IA ve el estado real de cada sesión. Si el perfil #7 tiene una superposición CAPTCHA mientras que los otros muestran el formulario, el resultado agrupado lo refleja. Puedes ramificar la lógica por sesión en lugar de asumir que todas las páginas se ven igual.

// 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

Cuándo el modo DOM aún gana

El análisis de visión no siempre es la opción correcta. La interacción basada en DOM (modo predeterminado de Ornold) es más rápida, gratuita y perfectamente confiable para páginas estructuradas con marcado estable.

Usa el modo DOM cuando:

La página de destino tiene HTML estable y predecible (por ejemplo, tu propia aplicación, plataformas conocidas)
Estás rellenando formularios con campos de entrada y etiquetas claros
La velocidad importa más que la resiliencia — las instantáneas DOM son instantáneas, el análisis de visión toma 1-3 segundos
Quieres evitar costos de créditos de visión

Usa el modo Vision cuando:

Las páginas varían entre perfiles (pruebas A/B, geolocalización, diseños dinámicos)
Estás tratando con interfaces basadas en canvas, páginas ricas en imágenes o componentes web personalizados
Los selectores se rompen constantemente y el costo de mantenimiento es alto
Necesitas verificar cómo se ve realmente la página (QA visual)

Puedes habilitar ambos modos a la vez. El agente IA elige automáticamente el mejor enfoque para cada acción — DOM para rellenos de formularios simples, visión para páginas complejas o impredecibles.

Comparación del mundo real

Esto es lo que sucede en la práctica al ejecutar un flujo de registro en 30 sesiones de Linken Sphere:

Automatización basada en selectores

25 de 30 sesiones se completan exitosamente
3 fallan porque un banner de consentimiento cambió el diseño del formulario
1 falla porque Cloudflare sirvió una página intersticial
1 falla porque el sitio implementó una nueva versión durante la ejecución con nombres de clase diferentes
Total: 83% de tasa de éxito. Se necesita intervención manual para 5 sesiones.

Automatización basada en visión

29 de 30 sesiones se completan exitosamente
1 falla porque la página no se cargó (timeout de red — no es un problema de selector)
Los banners de consentimiento, cambios de diseño y cambios de nombres de clase no tuvieron efecto
Total: 97% de tasa de éxito. Se necesita un reintento para el timeout.

La brecha se amplía a medida que crece el tamaño del lote. Con 50+ perfiles, la automatización basada en selectores típicamente necesita mantenimiento constante. La automatización basada en visión se mantiene estable porque se adapta a lo que realmente está en la pantalla.

Configurar el modo Vision en Ornold

Habilita el modo vision al conectar tu agente IA a Ornold MCP. En el asistente del panel de control, selecciona "Ambos modos" en el Paso 2 para obtener herramientas DOM + Vision. O agrega la bandera manualmente:

# 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"]

Cada análisis de visión cuesta 1 crédito. Las instantáneas DOM son gratuitas. Con el modo "ambos" habilitado, el agente IA usa DOM por defecto y cambia a visión solo cuando es necesario.

Conclusiones clave

Los selectores CSS asumen un DOM estable. En flujos de trabajo antidetección, el DOM es cualquier cosa menos estable.
La interacción orientada a la visión encuentra elementos por apariencia, no por ruta. Se adapta automáticamente a cambios de diseño, superposiciones y pruebas A/B.
El análisis de visión agrupado maneja la divergencia de lotes — cada sesión se analiza según su estado real.
El modo DOM sigue siendo la mejor opción predeterminada para velocidad y costo. Usa visión cuando las páginas son impredecibles o los selectores se rompen constantemente.
Ambos modos pueden coexistir. Deja que el agente IA elija la herramienta correcta para cada acción.