Abra GA4, divida las sesiones del último trimestre por navegador y el patrón suele estar ahí: Safari móvil rebota más que Chrome de escritorio, y su tasa de conversión queda por debajo de la media del sitio con un margen que nadie ha explicado. En los móviles de EE. UU. esa brecha sale cara, porque Safari concentró el 52,84% de la navegación móvil en agosto de 2026, según StatCounter. La mayoría de los equipos lo archiva como “los usuarios de iPhone simplemente navegan más” y sigue adelante.
En nuestra experiencia, una brecha de ese tamaño suele ser un error con una etiqueta de precio. Las pruebas de compatibilidad web son la práctica de confirmar que las páginas se muestran, responden y convierten igual en cada navegador y dispositivo que usan sus compradores, y la forma más rápida de delimitarlas es partir de la analítica que ya tiene. Esta guía cubre cuatro pasos: un diagnóstico de tasa de conversión por navegador, un mapa de los pares navegador-elemento que más fallan, un protocolo de pruebas ligado a la etapa del embudo y un mapa de prioridades que puede llevar directamente a su próximo sprint.
El argumento de ingresos para las pruebas de compatibilidad web
La matriz clásica de navegadores trata cada navegador como una línea equivalente: elija los diez principales, ejecute los mismos casos de prueba en cada uno, registre los errores. Ese modelo gasta la mayor parte del presupuesto donde el sitio ya funciona, porque el navegador principal del equipo recibe la mayor atención durante el desarrollo. Los ingresos se fugan en otra parte, normalmente en un navegador con poca cuota de tráfico y una gran brecha de conversión.
El patrón que buscamos es sencillo. Un navegador cuya tasa de conversión se sitúa entre un 25% y un 40% por debajo de la media del sitio es una señal de alarma de compatibilidad antes de que nadie escriba un caso de prueba. Una fricción así está extendida: el Contentsquare 2026 Digital Experience Benchmark, construido sobre 99.000 millones de sesiones, halló fricción en el 35,2% de todas las sesiones, con los errores de API creciendo un 16% interanual como la causa que más rápido aumenta. Cuando uno de esos fallos está ligado a un único navegador, un informe segmentado es donde aparece primero.
Por eso las pruebas de compatibilidad web pertenecen al presupuesto de crecimiento tanto como al de QA. Nuestros servicios de pruebas de compatibilidad parten de los datos de embudo del propio cliente, de modo que la lista de navegadores refleja dónde se pierde dinero este trimestre.
El diagnóstico de tasa de conversión por navegador
Un plan de pruebas de navegadores vale lo que vale su lista de navegadores, y la lista más precisa viene de datos de conversión segmentados. El diagnóstico siguiente lleva alrededor de una hora a alguien cómodo con GA4 y termina con una lista corta de problemas de compatibilidad de navegadores ordenada por lo que cuestan.
Segmentos de GA4 que conviene extraer
Use una ventana de 90 días de tráfico estable y evite semanas de lanzamiento y grandes rebajas, para que las medias reflejen el comportamiento normal. Después construya un informe y expórtelo:
- En Google Analytics 4, abra Explorar e inicie una exploración de formato libre.
- Añada Navegador y Categoría de dispositivo como dimensiones, con Navegador en filas y Categoría de dispositivo anidada debajo.
- Añada Sesiones, Tasa de eventos clave por sesión, Tasa de rebote y Tiempo medio de interacción por sesión como métricas.
- Para datos de carga, añada sus eventos de Web Vitals si los envía a GA4, o extraiga el Largest Contentful Paint por navegador desde su herramienta de monitorización de usuarios reales.
- Exporte a Google Sheets y añada una columna con la media del sitio para cada métrica.
El tiempo de carga merece su propia columna porque la base móvil ya es débil de partida. El Web Almanac 2025 de HTTP Archive, publicado en enero de 2026, halló que solo el 62% de los orígenes móviles alcanza un buen Largest Contentful Paint, frente al 74% en escritorio. Un navegador que carga más lento que esa base arrastra consigo todas las demás métricas.
Umbrales de valor atípico que delatan un error
Tres reglas separan los errores reales del ruido. Un navegador, o un par de navegador y dispositivo, califica como atípico cuando su tasa de conversión está más de un 25% por debajo de la media del sitio, su tasa de rebote más de un 20% por encima de la media, y registró más de 500 sesiones en la ventana. El mínimo de sesiones le mantiene lejos de navegadores de cola larga donde un puñado de visitas mueve la tasa en cualquier dirección.
Después ordene los atípicos por ingresos en riesgo: las sesiones del navegador (su cuota de tráfico sobre el total de sesiones), multiplicadas por la brecha de conversión y por el valor medio del pedido. La cuota de tráfico por sí sola le señala el navegador equivocado. Tome cifras ilustrativas: 200.000 sesiones en 90 días, una tasa de conversión del sitio del 2,0% y un pedido medio de 80 dólares. Un navegador con el 4% del tráfico que convierte un 45% por debajo de la media pierde unos 72 pedidos, o 5.760 dólares. Un navegador con el 30% del tráfico que convierte un 5% por debajo pierde unos 60 pedidos, o 4.800 dólares, y de todos modos no alcanzaría el umbral del 25%.
Para sitios de generación de leads, cambie el valor medio del pedido por el valor de un lead cualificado. Cuando la lista es larga o la causa raíz abarca front end y back end, una pasada más amplia de pruebas de aplicaciones web suele ser la vía más rápida a una respuesta.
El mapa de fallos navegador-elemento
Una vez existe la lista de atípicos, la mayor parte se corresponde con un conjunto corto de fallos recurrentes. La tabla empareja cada navegador con el elemento en el que más a menudo falla en sitios de marketing y e-commerce, empezando por el síntoma que verá en la analítica.
Safari
Autocompletado del formulario de pago
Caen las finalizaciones de compra; el botón de envío sigue desactivado tras el autocompletado
Escuche los eventos input, change y blur; vuelva a validar al enviar; pruebe con tarjetas y direcciones guardadas
Android WebView
Reproducción automática del vídeo principal
Bajo tiempo de interacción desde tráfico social y de apps; el CTA principal queda bajo un fotograma congelado
Imagen de póster más un control de reproducción visible; mantenga el CTA independiente del estado del vídeo; pruebe dentro de navegadores integrados en apps sociales
Firefox
Registro e inicio de sesión de terceros
Los registros empiezan y nunca se completan; la autenticación vuelve al formulario
Storage Access API o un dominio de autenticación propio; pruebe con la Protección de Rastreo Mejorada en Estándar y Estricta
Samsung Internet
Caché del service worker
Precios y contenidos del carrito obsoletos; más devoluciones y contactos con soporte
Nombres de caché versionados; estrategia network-first para precio, stock y endpoints del carrito; verifique las actualizaciones en una instalación real
Safari merece la mayor atención en el tráfico de EE. UU. por su cuota. El autocompletado de WebKit puede rellenar un campo sin disparar los eventos que escucha un script de pago, o dispararlos en un orden que la lógica de validación nunca previó. El resultado es un formulario que parece completo y un botón de envío que sigue gris, lo que en GA4 se lee como una caída en el paso de pago sin ningún error registrado.
Los otros tres siguen la misma lógica de una regla de plataforma que se topa con una página no preparada. Android WebView retiene la reproducción multimedia hasta que el usuario toca, salvo que la app anfitriona desactive ese ajuste, así que los vídeos principales en navegadores integrados de redes sociales suelen quedarse congelados. La Protección Total contra Cookies de Firefox particiona el almacenamiento por sitio, lo que rompe los flujos de registro que ceden el paso a un proveedor de autenticación en otro dominio. Cuando Samsung Internet destaca por altas tasas de devolución, un service worker sirviendo la caché de ayer es el primer sospechoso, y el daño aparece tanto en devoluciones y quejas como en conversiones perdidas.
Un protocolo de pruebas ligado al embudo
Conectar el Safari Web Inspector, la depuración remota de Chrome DevTools o una granja de dispositivos en la nube es trabajo estándar de pruebas de navegadores móviles, y la configuración es la misma sea lo que sea que pruebe. Lo que cambia según el tipo de página es qué elementos importan y qué navegadores los reciben. Trabajar en orden de embudo sitúa los primeros errores que encuentre más cerca de los ingresos, que es la manera más eficiente de comprobar la compatibilidad de navegadores con un equipo pequeño.
Páginas de destino: héroe y CTA
Las páginas de destino convierten en la primera pantalla, así que la pasada se queda ahí. Pruebe la reproducción automática del vídeo principal y su alternativa, el renderizado y el área táctil del CTA principal, la navegación fija en alturas de ventana reducidas como un móvil en horizontal, y la carga de fuentes web, donde un cambio tardío de fuente puede empujar el CTA por debajo del pliegue. Ejecútelo en Safari iOS, Chrome para Android y Samsung Internet, además de cualquier navegador integrado que aparezca como atípico. El entregable por navegador es una pasada manual de 15 minutos con capturas de la primera pantalla y una lectura de Core Web Vitals, para que marketing pueda comparar el resultado con las cifras de GA4 que dispararon la prueba.
Pago: formulario y medio de pago
El pago es la única página donde cada navegador atípico recibe una pasada completa, sin muestreo. Una pasada parcial en una página de pago demuestra muy poco, porque el error suele estar en el último paso. En cada navegador atípico, complete una compra real en staging o con una tarjeta de prueba, cubriendo:
- Autocompletado de dirección y tarjeta desde los datos guardados del navegador, seguido de la edición manual de un campo
- Formato del número de tarjeta y mensajes de validación
- Introducción, eliminación y reintroducción de códigos de descuento
- El iframe o redirección de pago de terceros, ya sea Stripe, PayPal o Adyen
- El renderizado del error tras una tarjeta rechazada, y la recuperación hasta un pedido correcto
El entregable es una confirmación de pedido por navegador, o un error reproducible con el paso en el que falló. Las comprobaciones de seguridad y carga del mismo flujo pertenecen al plan más amplio sobre cómo probar un sitio web de comercio electrónico, y ambas pueden ejecutarse en el mismo sprint.
Páginas de contenido: vídeo, compartir y recursos cerrados
Las páginas de contenido cargan con las conversiones de mitad de embudo: una visualización de vídeo que lleva a una solicitud de demo, un compartir que suma a un colega, un informe cerrado que se convierte en un lead. Pruebe la reproducción de vídeo incrustado, la hoja nativa de compartir y el formulario del recurso cerrado desde el primer campo hasta la página de agradecimiento. Céntrese en Safari iOS, Samsung Internet y Firefox Android, donde el comportamiento al compartir y los formularios incrustados de terceros varían más respecto a Chrome de escritorio. El entregable por atípico es una reproducción de vídeo, un toque en compartir y un envío de formulario que llegue al CRM. Para navegadores de los que nadie del equipo tiene un dispositivo, las herramientas de pruebas cross-browser que ejecutan hardware real son la vía práctica.
Su mapa de prioridades navegador-página
El mapa de prioridades convierte el diagnóstico y el protocolo en un único artefacto de sprint. Rellene la columna de Ingresos en riesgo con su propia exportación de GA4, y el orden de trabajo se define solo.
Pago
Safari iOS
Autocompletado, iframe de pago, recuperación de tarjeta rechazada
Cada versión que toque el pago
Sesiones × brecha de CVR de pago × valor medio del pedido
Registro e inicio de sesión
Firefox (escritorio y Android)
Autenticación de terceros, compra como invitado
Cada versión que toque la autenticación
Registros iniciados × tasa de abandono × valor por cuenta
Página de destino
Android WebView (integrado)
Alternativa del vídeo principal, toque en el CTA
Cada nueva campaña
Sesiones de pago en app × brecha de CVR × valor de lead o pedido
Página de destino
Samsung Internet
Navegación fija, carga de fuentes, renderizado del CTA
Mensual
Sesiones × brecha de CVR × valor medio del pedido
Producto y precios
Samsung Internet
Frescura de la caché del service worker
Tras cada cambio de precio o stock
Pedidos a precio obsoleto × diferencia de precio, más devoluciones
Página de contenido
Safari iOS, Firefox Android
Reproducción de vídeo, compartir, formulario cerrado
Trimestral
Envíos de formulario perdidos × valor de lead a negocio
Un mapa estático se queda obsoleto rápido, así que repita el diagnóstico cada trimestre y deje que las filas se reordenen. Ese ciclo mantiene las pruebas de compatibilidad ligadas a los ingresos a medida que los navegadores se actualizan y las campañas desplazan el tráfico entre ellos. Los ingenieros de QAwerk ejecutan el mismo ciclo dentro de nuestro proceso de pruebas en diversos navegadores, y pueden incorporarse a un proyecto en cualquier etapa, desde un rediseño en staging hasta un sitio que lleva años publicado.
El plan de pruebas que su analítica ya escribió
La mayoría de los equipos ya posee los datos que señalan sus errores de navegador más costosos. Una exportación de GA4 segmentada por navegador nombra los atípicos, el mapa de fallos sugiere la causa probable, y una pasada en orden de embudo lo confirma en las páginas que deciden los ingresos. Probar donde el sitio ya funciona se siente productivo, pero el dinero está en los navegadores con la brecha más amplia.
Empiece por el pago en el único navegador con mayores ingresos en riesgo, y luego baje por el mapa. Cada corrección confirmada debería aparecer en el siguiente segmento de 30 días como una brecha más estrecha, lo que da a marketing e ingeniería la misma cifra que seguir. Cuando la lista de atípicos es más larga de lo que su equipo puede cubrir, un equipo senior de QA puede ejecutar la matriz mientras sus ingenieros corrigen lo que encuentra. Contáctenos para obtener un mapa de prioridades navegador-página construido a partir de su propia analítica.
Preguntas frecuentes
¿Por qué mi tasa de conversión es más baja en Safari que en Chrome?
La causa más común es un elemento de pago o de formulario que se comporta de forma distinta en WebKit, el motor de Safari. El autocompletado puede rellenar campos sin disparar los eventos que esperan los scripts de validación, lo que deja el botón de envío desactivado. Los iframes de pago y las restricciones de cookies añaden más puntos de fallo. Compare la tasa de conversión por navegador en GA4 y luego complete una compra real en Safari iOS para confirmarlo.
¿Cómo pruebo la compatibilidad de un sitio web entre navegadores?
Empiece en GA4: segmente las sesiones por navegador y dispositivo, y marque los navegadores con tasas de conversión más de un 25% por debajo de la media y al menos 500 sesiones. Ordénelos por ingresos en riesgo. Pruebe las páginas que deciden los ingresos en cada atípico, el pago primero, en dispositivos reales, y registre cada fallo con el paso exacto y la versión del navegador.
¿Qué navegadores perjudican más las conversiones de e-commerce?
Depende de su audiencia, por eso debe decidirlo la analítica. En el tráfico de EE. UU., Safari iOS concentra el mayor riesgo de ingresos porque supera la mitad de la navegación móvil. Samsung Internet, Firefox y los WebView integrados de Android son atípicos frecuentes, ya que los scripts de pago y las estrategias de caché rara vez se prueban en ellos antes de publicar.
¿Cómo encuentro errores específicos de un navegador a partir de la analítica?
Cree una exploración en GA4 con Navegador y Categoría de dispositivo como dimensiones y tasa de conversión, tasa de rebote y tiempo de interacción como métricas durante 90 días. Los navegadores muy por debajo de la media del sitio en conversión y por encima en rebote apuntan a un error. Multiplique sesiones por la brecha de conversión y el valor del pedido para decidir cuál probar primero.
Descubre cómo QAwerk estabilizó las integraciones del proceso de pago y de pagos y mejoró la cobertura de regresión de Kazidomi antes de su expansión por Europa.
