Las pruebas cross-browser consisten en comprobar que un sitio se ve y funciona bien en los navegadores que usan tus visitantes y en los dispositivos desde los que los usan. En la práctica son tres motores de renderizado (Blink de Chromium, WebKit de Safari y Gecko de Firefox) en escritorio y móvil. Puedes cubrir casi todo gratis con navegadores instalados, Playwright y una vista móvil, y pagar por dispositivos en la nube solo cuando necesites hardware real que no tienes.
Qué navegadores probar
Parte de tu propia analítica, no de un ranking mundial. Un panel B2B puede usarse sobre todo en Chrome y Edge de escritorio, mientras que una tienda para consumidores puede recibir sobre todo tráfico de Safari en iPhone. Revisa los informes de navegadores y dispositivos de los últimos tres meses y cubre todo lo que supere un pequeño porcentaje de las sesiones.
Si todavía no tienes datos, este conjunto cubre los motores y la mayor parte del tráfico real:
| Navegador | Motor | Por qué importa |
|---|---|---|
| Chrome (escritorio y Android) | Blink | Mayor cuota en escritorio y Android |
| Safari (iPhone, iPad, Mac) | WebKit | Todos los usuarios de iPhone y la mayoría de fallos que “solo pasan en móvil” |
| Edge | Blink | Navegador predeterminado en Windows; suele comportarse como Chrome |
| Firefox | Gecko | Motor propio; destapa suposiciones que en realidad son rarezas de Chromium |
| Samsung Internet | Blink | Preinstalado en móviles Samsung, con su propio ciclo de actualizaciones y modo oscuro |
Dos motores merecen más atención: WebKit, por el iPhone, y Gecko, porque es el único motor importante que no es de Apple ni de Google.
Qué revisar en cada navegador
Los fallos entre navegadores se concentran en sitios previsibles. Recorre esta lista en cada página clave:
- Layout. Los
gapde flexbox y grid,position: sticky,aspect-ratioy las container queries en versiones antiguas de los navegadores. - Fuentes. Las fuentes web cargan, las alternativas tienen métricas parecidas y no hay texto invisible mientras cargan.
- Formularios. Selectores de fecha y hora, estilos de
select, colores del autocompletado, mensajes de validación y el tipo de teclado móvil de cada campo. - Multimedia. Reglas de reproducción automática de vídeo (la mayoría de navegadores móviles solo la permiten sin sonido), formatos de imagen como AVIF y qué imagen elige
srcset. - Desplazamiento y unidades de viewport.
100vhfrente al100dvhdinámico en móvil, scroll snapping, desplazamiento suave y overscroll. - APIs de JavaScript. Cualquier cosa de hace menos de un par de años: comprueba el soporte antes de depender de ella.
- Interacción. Menús que solo se abren con hover en pantallas táctiles, el contorno de foco para quien usa teclado y las zonas táctiles.
- Modo oscuro y zoom. Páginas al 200 % de zoom y con el modo oscuro del sistema.
Herramientas gratis que hacen casi todo el trabajo
Instala los navegadores. Chrome, Edge y Firefox funcionan en todos los sistemas de escritorio. Safari solo funciona en macOS, y esa es la principal razón por la que quien no tiene Mac necesita herramientas extra.
Comprueba el soporte antes de escribir código. Baseline marca las funciones web como “newly available” o “widely available” en los principales navegadores, y Can I use ofrece tablas de soporte versión a versión. Consultarlos antes evita la mayoría de los fallos entre navegadores.
Automatiza con Playwright. Playwright ejecuta el mismo script de prueba en Chromium, Firefox y WebKit en Windows, macOS y Linux, y puede emular dispositivos móviles. Un script corto que abra tus diez páginas más importantes en los tres motores y guarde capturas detectará la mayoría de regresiones en cada pull request.
Usa vistas móviles para revisar el responsive. Los problemas de diseño móvil se confunden a menudo con problemas del navegador. Descártalos rápido con el modo dispositivo de DevTools o con una extensión como Mobile View Extension, y después busca causas propias del motor. La diferencia entre ambas herramientas se explica en simulador móvil en extensión o DevTools.
Usa emuladores para los motores móviles. El simulador de Xcode te da Safari real de iOS en un Mac (guía); el emulador de Android Studio te da Chrome real de Android (guía).
Cuándo tiene sentido pagar herramientas de pruebas cross-browser
Los servicios de pruebas en la nube alquilan dispositivos reales y muchas versiones de navegadores. Merece la pena pagarlos cuando:
- no tienes Mac y necesitas probar Safari en iPhone con frecuencia;
- tus clientes usan versiones antiguas de navegadores que no puedes instalar a la vez;
- un contrato te obliga a probar en modelos de teléfono concretos;
- tus pruebas automáticas tienen que ejecutarse en hardware móvil real.
Para un sitio pequeño suele bastar un plan mensual que se usa en la semana de lanzamiento; para revisiones puntuales, las pruebas gratuitas dan mucho de sí.
Una rutina cross-browser ligera
- Mientras desarrollas: consulta Baseline antes de usar una función nueva y revisa la vista móvil sobre la marcha.
- En cada pull request: genera capturas con Playwright en Chromium, Firefox y WebKit.
- Antes del lanzamiento: recorre los flujos clave en Safari (Mac o simulador), Firefox y Chrome en Android.
- Después del lanzamiento: vigila la monitorización de errores y la analítica, con los errores agrupados por navegador.
La parte móvil de la revisión previa al lanzamiento se detalla en el checklist de pruebas de una web móvil.
Preguntas frecuentes
¿Cómo puedo probar mi web en diferentes navegadores gratis?
Instala Chrome, Edge y Firefox, usa Playwright para ejecutar WebKit en cualquier sistema, y DevTools o una extensión de vista móvil para los tamaños de teléfono. En un Mac, el simulador de Xcode añade Safari real de iOS.
¿Hace falta probar en Edge si ya pruebo en Chrome?
Edge usa el mismo motor que Chrome, así que las diferencias son raras. Basta con una revisión rápida, salvo que tu público use funciones propias de Edge o directivas empresariales.
¿Cuál es hoy la causa más común de los fallos entre navegadores?
Usar una función de CSS o JavaScript antes de que esté soportada en todos los navegadores de tus usuarios. Consultar su estado en Baseline antes de adoptarla evita la mayoría de estos fallos.