Política de relación de píxeles del dispositivo con --bot-dpr

La política de relación de píxeles es una decisión de pantalla, no un ajuste de renderizado: un MacBook Retina informa 2 en window.devicePixelRatio, un portátil de oficina suele informar 1 o 1.25, y un perfil preparado para uno no debería heredar en silencio el valor del otro. BotBrowser expone --bot-dpr con los modos profile, real y advanced para que el origen de ese número quede escrito en la orden de lanzamiento, mientras el CSS responsivo de la página y el uso que el sitio haga del valor siguen siendo asunto del sitio.

Para la cuestión distinta del ciclo de vida, consulta emulación de ventana activa y estado de visibilidad.

TL;DR

• --bot-dpr=profile es el valor por defecto: usa la escala de pantalla del perfil, así que DPR, ventana y pantalla viajan juntos cuando además fijas --bot-window=profile y --bot-screen=profile.
• --bot-dpr=real sigue el monitor del host, útil para un operador de soporte o una revisión de diseño donde la pantalla del puesto de trabajo es la experiencia prevista.
• advanced conserva el DPR del perfil y aplica ajustes de diseño limitados; es experimental, no está habilitado por defecto y no es un modo de mayor precisión.
• Elige el modo antes de que un BrowserContext cree su primera página o worker, porque las páginas existentes mantienen el comportamiento establecido al iniciar su contexto.
• Registra cinco campos junto a cada ejecución: versión de BotBrowser, perfil, modo de DPR, viewport y destino de la captura.

Contenido

• Por qué la escala de pantalla importa a una página
• Tres modos: profile, real y advanced
• Mantener el DPR junto con la ventana y la pantalla
• Sesiones por contexto
• Validar y registrar una política
• Despliegue y mantenimiento de una política

Ver el vídeo

Este vídeo en inglés sigue un solo número, window.devicePixelRatio. Repasa los valores habituales del artículo y sus tres modos (profile, real y advanced) y después pregunta a un navegador real de dónde sale su propio número: una página de laboratorio local se lee en la consola de DevTools de Chrome estándar en un runner Ubuntu (DPR 1 en una pantalla de 1920 por 984; la consulta 2dppx no coincide) y un runner Windows muestra la interfaz de DevTools ampliada de 1,25 a 1,75, que es la escala de la propia herramienta, no la de la página. Termina con la regla por contexto y los cinco campos que conviene registrar junto a cada ejecución. En las grabaciones no se carga ningún perfil de BotBrowser, así que los modos de --bot-dpr se citan de este artículo, no se ejecutan. El audio es en inglés.

Por qué la escala de pantalla importa a una página

window.devicePixelRatio indica a una página cuántos píxeles físicos hay detrás de un píxel CSS. Un portátil de oficina suele informar 1 o 1.25, un MacBook Retina informa 2 y muchos teléfonos informan 3. El mismo valor alimenta las media queries de resolución CSS, la selección de imágenes responsivas y los cálculos de diseño, así que viaja junto con el resto de la configuración de pantalla: tamaño de pantalla, tamaño de ventana y profundidad de color.

Cuando un perfil describe una pantalla y el monitor del host es otro, la sesión lleva dos configuraciones de pantalla a la vez. La opción --bot-dpr hace explícita la elección en lugar de dejarla en manos de la máquina en la que se ejecute el navegador. BotBrowser puede fijar de forma explícita la relación de píxeles del dispositivo de un perfil en un contexto controlado; no puede cambiar cómo responde un sitio a ese valor.

En un navegador normal el valor no siempre es constante. MDN indica que cambia cuando el usuario amplía o reduce el zoom de la página, y en muchos equipos de escritorio también cambia cuando una ventana pasa a un monitor con otra escala. Una página puede vigilar esos cambios con una media query de resolución, y por eso una aplicación puede volver a dibujar imágenes o lienzos cuando el valor se actualiza. Para un flujo repetible esto importa en la práctica: una sesión con un único origen de escala documentado ofrece a la página un valor inicial estable, de modo que una diferencia posterior entre ejecuciones apunta a la página o al host y no a un ajuste de pantalla sin registrar.

Las páginas no leen el DPR de forma aislada. Las consultas de resolución CSS pueden elegir otra hoja de estilos cuando cambia la escala. Las imágenes responsivas pueden elegir otra fuente. Las dimensiones del lienzo, los cálculos del viewport visual y los controles de zoom de la aplicación también pueden depender de la relación entre píxeles CSS y píxeles físicos.

Los perfiles móviles suelen usar un DPR mayor que los de escritorio. Lo importante no es que un número más alto sea mejor. Lo importante es que el valor concuerde con la familia de dispositivos prevista y con las dimensiones de pantalla que aporta el mismo perfil. No copies el DPR de un móvil en un perfil de escritorio solo para que la página use una imagen de mayor resolución.

Tres modos: profile, real y advanced

Modo	Úsalo cuando	Resultado
profile	El perfil debe definir la configuración de pantalla	Usa la escala de pantalla del perfil. Valor por defecto.
real	La sesión debe seguir la pantalla del host	Usa la escala de pantalla del host.
advanced	Un flujo existente necesita ajustes de diseño limitados conservando el DPR del perfil	Modo de compatibilidad experimental. No está activado por defecto.

profile es el valor por defecto, así que los lanzamientos existentes mantienen su comportamiento actual. Establece otro modo solo cuando el despliegue lo necesite.

Empieza por el modelo de pantalla que el perfil debe representar. Un navegador basado en un perfil suele incluir un sistema operativo de destino, una familia de viewport, dimensiones de pantalla y capacidades de entrada. La escala de pantalla pertenece a ese mismo grupo. Si el perfil representa un portátil o un teléfono, profile mantiene la escala conectada con el resto de los datos del perfil.

Usa real en una estación de trabajo donde el monitor físico forma parte de la experiencia del usuario. Es habitual en un operador de soporte, una revisión de diseño o una sesión de navegador que debe seguir los ajustes de accesibilidad del host. En estos casos la pantalla del host es la fuente de verdad. real expone la escala de pantalla del host, que puede diferir de la del perfil seleccionado, así que elígelo solo cuando esa configuración respaldada por el host sea intencionada.

advanced es experimental y no está activado por defecto. Conserva el DPR del perfil y aplica ajustes de diseño limitados, pero no reescala toda la página ni garantiza medidas de diseño o capturas coincidentes. No es un modo de mayor precisión, y que los valores de DPR del host y del perfil sean distintos no basta por sí solo para activarlo. Comprueba el diseño de la página y las capturas afectadas en el host previsto antes de adoptarlo, y vuelve a profile si los ajustes introducen incoherencias.

Los sistemas de escritorio pueden funcionar con monitores que tienen distintos ajustes de escala. Un host puede informar un valor mientras que el perfil se preparó para otro. profile es útil cuando el perfil debe permanecer estable entre máquinas. real es útil cuando la estación de trabajo actual debe controlar la pantalla. Ambas son opciones válidas con fuentes de verdad distintas.

Mantener el DPR junto con la ventana y la pantalla

DPR, ventana y pantalla forman una única configuración de pantalla. Cámbialos juntos, no uno por uno entre ejecuciones.

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --bot-dpr=profile \
  --bot-window=profile \
  --bot-screen=profile

Las sesiones de escritorio con interfaz usan por defecto dimensiones de ventana y pantalla del host. Si una sesión con interfaz debe informar las dimensiones del perfil, establece --bot-window=profile y --bot-screen=profile junto a --bot-dpr=profile. La guía de pantalla y ventana cubre las opciones de tamaño, y la emulación de dispositivos cubre los perfiles móviles.

Una sesión de estación de trabajo que representa el monitor del propio operador puede usar en cambio la pantalla del host para los tres valores:

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --bot-dpr=real \
  --bot-window=real \
  --bot-screen=real

Los valores exactos de ventana y pantalla dependen del perfil y del despliegue. Los dos ejemplos muestran la relación entre las tres políticas. Elige valores admitidos por la compilación de BotBrowser instalada y conserva el mismo conjunto en las páginas que se comparan.

Los despliegues sin interfaz merecen la misma disciplina. Sin un monitor visible, el origen de la pantalla sigue siendo una decisión: decide si la sesión representa la pantalla del perfil o una pantalla del host, y escribe las opciones de forma explícita en lugar de heredar lo que ofrezca la máquina.

Cuando una sesión pasa de una estación de trabajo local a una máquina remota, decide si el navegador representa la pantalla del operador o la pantalla de destino del perfil. Haz que esa decisión forme parte de la configuración del despliegue. Evita elegir el modo a partir de una variable de entorno que cambia sin avisar entre máquinas. Un argumento de lanzamiento visible facilita auditar el comportamiento resultante. Una prueba local que usa real puede dar un resultado distinto en una máquina sin monitor físico, y una prueba que usa profile puede diferir de una prueba de estación de trabajo ligada a un monitor. Ninguno de los resultados es incorrecto, pero la diferencia debe ser intencionada.

Sesiones por contexto

Con huellas por contexto, establece --bot-dpr antes de que el BrowserContext cree su primera página o worker. La política elegida sigue asociada al comportamiento de pantalla y de diseño de ese contexto. Las páginas existentes conservan el comportamiento establecido cuando arrancó su contexto, así que cambiar un comando de lanzamiento más tarde no las actualiza. Cierra y vuelve a crear un contexto cuando la configuración de pantalla deba cambiar.

Usa el mismo modo para el navegador principal y para un perfil por contexto cuando representen el mismo dispositivo. Elige un modo distinto solo cuando el contexto represente deliberadamente otro entorno de pantalla. Escalar contextos de navegador cubre el ciclo de vida más amplio de los contextos.

Si varios contextos representan la misma familia de dispositivos, usa la misma política de DPR y ajustes de ventana y pantalla equivalentes. Si representan dispositivos distintos a propósito, guarda los ajustes de cada contexto juntos en su propio registro de configuración. No compartas un contexto entre una pantalla respaldada por el perfil y una respaldada por el host cuando la aplicación dependa de un diseño responsivo estable.

Los grupos de contextos también deben registrar qué modo se eligió. Esto ayuda a explicar por qué dos páginas con la misma URL pueden recibir marcado responsivo distinto, y evita que un worker herede un contexto creado para otra política de pantalla.

Un servicio que arranca muchos contextos debe fijar el modo en su configuración de lanzamiento compartida y copiarlo en las opciones de creación de cada contexto. Registra el modo elegido al arrancar sin registrar el contenido del perfil. Mantén un único responsable de los valores por defecto de línea de comandos que usan los scripts envoltorio y los servicios de lanzamiento. Si varios scripts eligen cada uno su propio valor por defecto, un cambio de mantenimiento puede dividir un grupo de contextos en políticas de pantalla distintas.

Cuando un script envoltorio construye líneas de comandos, pasa el modo elegido como un valor completo en lugar de concatenar texto sin validar. Acepta solo profile, real y advanced, y rechaza cualquier otro valor antes de iniciar el navegador. Un lanzamiento fallido es más fácil de diagnosticar que una sesión que usa en silencio otra política de pantalla.

Validar y registrar una política

1. Inicia una sesión con el perfil elegido y un modo de DPR.
2. Mantén sin cambios la ventana, la pantalla y el DPR durante toda la comprobación.
3. Inicia una segunda sesión con el mismo perfil y modo y confirma que el comportamiento de pantalla coincide.
4. Al comparar modos, cambia solo --bot-dpr y registra el comando de lanzamiento completo de cada ejecución.

Verifica tu huella de navegador enumera verificadores públicos que muestran los valores de pantalla informados.

Situación	Acción
Se espera el comportamiento de pantalla del perfil	--bot-dpr=profile
La sesión debe seguir la pantalla del host	--bot-dpr=real
Un flujo existente necesita ajustes de diseño	Evalúa el experimental --bot-dpr=advanced en el host previsto; si no, conserva profile
La pantalla difiere entre contextos	Establece el modo antes de que cada contexto cree páginas o workers
Las dimensiones con interfaz siguen al host	Añade --bot-window=profile y --bot-screen=profile

La entrada completa de la opción está en la referencia de opciones de la CLI.

Conserva un registro breve de cada ejecución. Los campos que explican la mayoría de las diferencias de escala de pantalla son la versión de BotBrowser, el perfil, el modo de DPR, el viewport y el destino de captura, como una captura de pantalla, un PDF o una medición de página. Con esos cinco campos, quien revisa puede saber si dos capturas difieren por la política, por el perfil o por la forma de generar la salida, sin volver a abrir la página.

Para comparar modos en una página, ejecuta el mismo flujo tres veces con la misma versión del navegador, perfil, viewport, modo de ventana y modo de pantalla, cambiando solo --bot-dpr entre ejecuciones. Guarda el comando de lanzamiento junto a cada resultado. Si dos ejecuciones difieren, los comandos guardados muestran enseguida si el modo fue el único cambio, y si no difieren, la página no depende de la escala de pantalla en ese flujo.

Las dimensiones de una captura de pantalla se expresan en píxeles CSS, mientras que el mapa de bits de salida puede verse afectado por el factor de escala del dispositivo. Una prueba que compara imágenes debe mantener fijo el modo de DPR tanto en la captura de referencia como en la actual. Si no, un diseño puede permanecer igual mientras difieren las dimensiones del mapa de bits o la rasterización del texto.

Los flujos de PDF e impresión tienen sus propias reglas de tamaño de página, pero el diseño web que alimenta la impresión sigue dependiendo de los valores de viewport y de pantalla. Elige la política de DPR antes de cargar el documento y mantén los ajustes de impresión separados de los de pantalla. Así es más fácil distinguir un cambio de diseño CSS de un cambio de tamaño de papel.

Para la regresión visual, guarda la política junto al viewport y la versión del navegador en los metadatos de la prueba. Vuelve a generar una línea base solo cuando cambie la política de pantalla prevista. No actualices las capturas solo porque un ejecutor tenga otro monitor. Usa profile para líneas base portables o real para pruebas ligadas explícitamente a una estación de trabajo.

Antes de entregar una configuración, confirma lo siguiente en el registro de lanzamiento:

• la versión de BotBrowser está fijada;
• el destino del perfil y el papel del host están documentados;
• el modo de DPR es explícito;
• los modos de ventana y pantalla son explícitos;
• el modo se establece antes de crear la primera página;
• las pruebas de capturas o de diseño responsivo usan la misma política que su línea base;
• cada configuración por contexto registra su propia política de pantalla;
• el paso de profile a real o advanced se revisa como un cambio de comportamiento.

Estas comprobaciones no exigen que una página exponga datos privados del perfil. Dejan claro el origen del comportamiento de pantalla para el equipo que opera el navegador. Si un diseño difiere tras un despliegue, el registro de lanzamiento te da los primeros lugares donde comparar.

Despliegue y mantenimiento de una política

Empieza con un perfil representativo y un flujo de aplicación. Ejecuta el flujo con profile y repítelo con la misma versión del navegador, viewport y ajustes de ventana. Si la pantalla del host forma parte del requisito, repite la comparación con real. Guarda la salida de cada ejecución junto con el registro de lanzamiento. Así el equipo dispone de un pequeño conjunto de referencia antes de aplicar la política a un grupo mayor.

Despliega primero el modo elegido en un grupo de contextos. Revisa las páginas que usan navegación responsiva, selección de imágenes, tablas, gráficos y diseños de impresión, porque estas áreas suelen mostrar los cambios de pantalla antes que las páginas de texto ordinarias. Si el resultado es adecuado, aplica la misma configuración al resto de los contextos que representan la misma familia de dispositivos.

Trata el modo elegido como parte de la entrada de la prueba, no como un detalle del entorno. Cuando un informe de error dice que una página se veía distinta, la primera pregunta es qué origen de pantalla usó la sesión. Si el registro de lanzamiento responde a esa pregunta, la investigación puede pasar directamente a la página, al perfil o al host.

No mezcles cambios de política con un cambio de versión del navegador, una migración de perfil o un rediseño del viewport. Cada uno de esos cambios puede alterar el comportamiento del diseño. Cuando hagan falta varios cambios, aplícalos en ejecuciones de prueba separadas y mantén los registros separados. Una secuencia clara permite identificar qué cambio afectó al resultado.

Tras pasar a una nueva versión de BotBrowser, revisa la política elegida aunque la línea de comandos no haya cambiado. El valor por defecto sigue siendo profile, pero una versión puede cambiar la documentación disponible o las opciones admitidas. Reutiliza el mismo perfil y los mismos ajustes de captura para comparar antes y después. Si el resultado cambia, comprueba por este orden la versión del navegador, el perfil, el modo de ventana, el modo de pantalla y el modo de DPR.

Guarda la versión del navegador, el perfil, el modo elegido, el viewport y el destino de captura junto a la configuración de la prueba o del servicio. Este registro es útil cuando una página cambia su diseño responsivo, cuando cambia una fuente de imagen o cuando una captura se genera con un tamaño inesperado. También da a quienes revisan una lista concreta de valores que aprobar antes de un despliegue.

Los ajustes de pantalla del host pueden afectar al tamaño del texto, al contraste y al comportamiento de entrada en una estación de trabajo con interfaz. Si un operador usa el navegador directamente, real puede coincidir con las expectativas de pantalla de esa persona. Si el navegador es una sesión portable respaldada por un perfil, profile mantiene estable el comportamiento de pantalla cuando cambia el host. Habla de esta elección con las personas que usan la sesión en lugar de elegir un modo solo por los valores por defecto del servidor, y haz las revisiones de accesibilidad con el mismo viewport y los mismos ajustes de ventana que se usan en producción.

Los errores más comunes son dejar el modo implícito mientras cambia la máquina host, cambiar el DPR cuando un contexto ya ha creado páginas y usar advanced como un ajuste general de calidad. Escribe de forma explícita las tres políticas de pantalla cuando un flujo dependa de ellas, crea un contexto nuevo para una nueva política de pantalla y limita advanced al flujo que lo necesite.

Una política de pantalla es más fácil de mantener cuando está visible junto al resto de la configuración de lanzamiento. Incluye el modo elegido en las notas de despliegue, las plantillas de prueba y los manuales operativos, de modo que un compañero pueda saber si una sesión sigue al perfil o al host sin abrir la página. Cuando una configuración pasa de desarrollo a producción, conserva el modo y los ajustes de ventana y pantalla relacionados, y registra el modo anterior y el nuevo junto con las líneas base visuales actualizadas siempre que un despliegue lo cambie.

BotBrowser proporciona la opción --bot-dpr para elegir la política de relación de píxeles del dispositivo (profile por defecto, real para la pantalla del host y el experimental advanced). Si se establece antes de que un contexto cree su primera página, permite que las sesiones de escritorio y por contexto mantengan un único origen de escala documentado, de modo que un equipo puede comparar ejecuciones cambiando solo esa opción. BotBrowser no puede hacer que advanced reescale toda la página ni garantiza medidas de diseño o capturas idénticas, y no controla el monitor del host, el CSS responsivo de la página ni el uso que un sitio haga del valor informado.

Para un cambio de relación que llega sin evento de resize, consulta la guía de eventos de viewport móvil.

Fuentes públicas

• MDN: Window.devicePixelRatio
• Documentación de BotBrowser: política de relación de píxeles
• Opciones de la CLI de BotBrowser: --bot-dpr

Conclusión práctica

Trata --bot-dpr como parte de la entrada de la prueba: usa profile para líneas base portables, real solo cuando el monitor del puesto de trabajo sea el requisito, y evalúa advanced en el host previsto en lugar de adoptarlo por defecto. Después guarda un registro de lanzamiento por ejecución con la versión de BotBrowser, el perfil, el modo, el viewport y el destino de la captura, de modo que una diferencia de captura o de diseño responsivo apunte a la página y no a un ajuste de pantalla sin registrar.