Compatibilidad de navegadores con Baseline: auditoría para sistemas web con IA

Baseline ofrece un lenguaje común para describir el grado de soporte de una función de la plataforma web dentro de un conjunto definido de navegadores principales. La documentación de web.dev organiza esa información en disponibilidad limitada, Newly available —disponible recientemente— y Widely available —ampliamente disponible—. Newly available se aplica cuando todo el conjunto admite la función. Widely available añade el intervalo de madurez documentado de 30 meses desde ese punto.

Para una empresa, la utilidad aparece al vincular esos estados con decisiones concretas. Una landing que recibe tráfico de adquisición puede exigir funciones Widely available o una alternativa funcional. Una aplicación autenticada podría admitir una capacidad más reciente cuando sus datos de audiencia y sus pruebas lo justifiquen. Este criterio es metodología operativa de CreatikLab, no una garantía de Baseline. El estado no certifica accesibilidad, velocidad, seguridad, medición ni conversiones.

Chrome impulsó inicialmente Baseline y el WebDX Community Group se ocupa ahora de definirlo. El conjunto principal incluye Chrome para escritorio y Android, Edge, Firefox para escritorio y Android, y Safari para macOS e iOS. Una función permanece con disponibilidad limitada antes de funcionar en todo el conjunto. Newly available señala esa interoperabilidad; Widely available incorpora además el periodo documentado de 30 meses.

web.dev también identifica herramientas aplicables al flujo técnico. Lighthouse dispone de una auditoría Baseline Features; Browserslist admite consultas Baseline; Visual Studio Code y Chrome DevTools muestran información de Baseline; y ESLint puede controlar el uso de CSS según esos estados. Baseline Checker puede emplear datos de Google Analytics para ayudar a elegir un objetivo. Google no establece en esa guía qué objetivo debe adoptar cada negocio ni garantiza el funcionamiento de una experiencia específica.

Una web con IA puede reunir contenido público, respuestas generadas, streaming, formularios, autenticación, pagos, analítica y servicios externos. El fallo relevante rara vez consiste en que toda la web desaparezca. Puede afectar únicamente a una acción decisiva para parte de la audiencia: un botón que no responde, un estado de formulario que se pierde, una respuesta que no puede copiarse o un evento que no llega al sistema de medición. Son escenarios de diagnóstico, no comportamientos atribuidos a Baseline.

Por eso la política necesita responsables. Producto define los recorridos que no pueden fallar. Marketing identifica las páginas que reciben demanda pagada u orgánica. Ingeniería documenta las funciones web de las que depende cada componente. Analítica valida la calidad de los datos sobre navegadores. Baseline aporta el vocabulario compartido para dejar atrás expresiones imprecisas como “compatible con navegadores modernos”.

El marco de decisión de CreatikLab cruza cuatro dimensiones: importancia del recorrido, evidencia real de audiencia, calidad de la alternativa y coste del fallo. El estado oficial de Baseline se conserva separado de la decisión empresarial.

• Página pública de captación — evidencia: navegadores de entrada y recorrido hasta lead o venta; acción: priorizar Widely available o una alternativa equivalente; responsables: marketing e ingeniería frontend.
• Aplicación con acceso — evidencia: política de dispositivos y entorno real de usuarios; acción: valorar Newly available solo con pruebas y soporte documentado; responsables: producto e ingeniería.
• Herramienta interna — evidencia: inventario de navegadores gestionados; acción: aceptar una política más acotada cuando pueda imponerse y comunicarse; responsables: sistemas y producto.
• Interacción experimental con IA — evidencia: feature flag, telemetría de fallos y salida alternativa; acción: aislar las funciones con disponibilidad limitada de cualquier tarea esencial; responsables: producto e ingeniería.
• Sistema de diseño compartido — evidencia: catálogo de componentes y dependencias; acción: impedir que una función incompatible se propague a múltiples recorridos; responsables: diseño e ingeniería.

La matriz no sustituye una prueba de navegador. Sirve para que cada excepción tenga justificación, propietario y condición de revisión.

El trabajo comienza escribiendo la política en el repositorio y en la documentación del producto. Debe indicar el objetivo Baseline seleccionado, cómo se aprueban excepciones y qué recorridos se consideran esenciales. Después se configura el control durante el desarrollo mediante herramientas compatibles, como consultas de Browserslist o reglas de CSS, en lugar de dejar toda la responsabilidad para la revisión final.

1. Inventariar las funciones de plataforma utilizadas por formularios, navegación, multimedia, autenticación e interfaces de respuesta con IA.
2. Ejecutar la auditoría Baseline Features de Lighthouse sobre plantillas representativas y conservar el resultado como evidencia.
3. Relacionar cada hallazgo con su componente, página de entrada y consecuencia para el usuario.
4. Decidir entre sustituir la función, mejorar progresivamente, construir una alternativa o aprobar una limitación explícita.
5. Probar la compilación de producción en los navegadores incluidos en la política; una etiqueta de disponibilidad no reemplaza la prueba funcional.
6. Registrar decisión, evidencia, responsable y condición que obligará a repetir la evaluación.

Así se crea una trazabilidad entre la función técnica y el riesgo del recorrido, sin delegar en una herramienta automática el juicio sobre usabilidad.

La medición debe realizarse por recorrido. Siempre dentro de las reglas de privacidad y consentimiento de la organización, conviene comparar cargas de página, interacción, validación, envío de formularios, autenticación y errores del cliente entre entornos compatibles. En generación de leads, el envío técnico debe conectarse con el resultado del CRM para distinguir una solicitud válida de una oportunidad aceptada por ventas.

Una especificación útil documenta evento, dimensión diagnóstica, interpretación comercial y responsable. Un envío de formulario puede ser el evento; navegador y versión del componente, las dimensiones; oportunidad aceptada, la interpretación; y analítica junto con operaciones comerciales, los responsables. Una diferencia correlacionada con un navegador justifica investigación, pero no demuestra por sí sola causalidad.

El estado Baseline debe figurar como contexto de ingeniería. Los indicadores comerciales siguen siendo recorridos completados, leads cualificados, compras válidas u otro resultado acordado. La documentación oficial no promete mejoras en esos indicadores.

• Evidencia: política escrita de navegadores. Acción: definir objetivo Baseline y excepciones. Propietario: producto.
• Evidencia: distribución de navegadores obtenida con controles de consentimiento. Acción: contrastar política y audiencia. Propietario: analítica.
• Evidencia: inventario de componentes. Acción: vincular funciones web con recorridos críticos. Propietario: frontend.
• Evidencia: informe Baseline Features de Lighthouse. Acción: priorizar por impacto, no por cantidad bruta. Propietario: QA.
• Evidencia: configuración de Browserslist, editor o linting. Acción: detectar desviaciones durante el desarrollo. Propietario: ingeniería.
• Evidencia: demostración de alternativas. Acción: comprobar que la tarea esencial sigue disponible. Propietarios: diseño y QA.
• Evidencia: telemetría de errores y finalización. Acción: investigar abandono por entorno sin presuponer su causa. Propietarios: analítica e ingeniería.
• Evidencia: registro de lanzamiento. Acción: documentar aceptación, corrección y disparador de nueva prueba. Propietario: operaciones de producto.

Al comparar proveedores, el comprador debería solicitar estas pruebas. Una promesa genérica de compatibilidad vale menos que una política clara, cobertura documentada, tratamiento de excepciones, medición y entrega técnica mantenible.

Widely available no significa ausencia de errores, accesibilidad automática, velocidad ni representación idéntica. Newly available tampoco significa que una función sea inadecuada. Una capacidad con disponibilidad limitada puede utilizarse de forma controlada si no bloquea tareas esenciales y existe una alternativa verificada. Tampoco debe suponerse soporte para navegadores integrados, dispositivos atípicos o scripts externos sin probarlos. web.dev no especifica precios, elegibilidad comercial ni resultados de negocio para Baseline.

Para un proyecto de automatización o sistemas personalizados con IA, un entregable experto concreto que puede definirse en el alcance es un paquete de decisión de compatibilidad: política de navegadores, inventario de funciones, hallazgos Baseline, registro de pruebas de recorridos críticos, decisiones sobre alternativas, especificación de telemetría y plan de corrección con evidencia, acción y responsable. Consulta automatización y sistemas personalizados con IA y confirma el alcance y la disponibilidad antes de contratar el trabajo. Para preparar una solicitud accionable, abre Lia en MarketingPro e indica los recorridos críticos, los navegadores conocidos de la audiencia, las pruebas existentes y los puntos de fallo o incertidumbre. No incluyas credenciales ni datos personales.

¿Qué es Baseline en desarrollo web?

Es un modelo para describir la disponibilidad de funciones de la plataforma web mediante los estados de disponibilidad limitada, Newly available y Widely available.

¿Qué navegadores forman el conjunto principal?

Incluye Chrome en escritorio y Android, Edge, Firefox en escritorio y Android, y Safari en macOS e iOS.

¿Widely available garantiza que no habrá errores?

No. Describe disponibilidad y madurez en el conjunto principal, pero no certifica accesibilidad, rendimiento, seguridad ni ausencia de defectos.

¿Puede una empresa usar funciones Newly available?

Puede valorarlo cuando los datos de audiencia, la importancia del recorrido, las alternativas y las pruebas funcionales respaldan la decisión.

¿Qué herramientas ayudan a aplicar la política?

La documentación oficial menciona Lighthouse, Browserslist, Visual Studio Code, Chrome DevTools, ESLint y Baseline Checker.

¿Cómo se relaciona la compatibilidad con la calidad del lead?

Hay que medir la finalización por entorno y conectar los envíos válidos con la cualificación del CRM. Una correlación debe investigarse antes de considerarla causal.