Las próximas versiones de Firefox y Chromium podrían hacer cambios importantes.

En primer lugar, en Firefox 66 para equipos de escritorio, la reproducción automática de video y sonido en todas las páginas está bloqueada de forma predeterminada. El blog Mozilla Hacks advierte a los desarrolladores de antemano . La reproducción de video y sonido solo se permite a través de la API HTMLMediaElement y solo después de que el usuario interactúa con la página (clic del mouse, clic del botón o toque en la pantalla táctil).

En Chromium, pueden ocurrir cambios aún más interesantes.

Al mismo tiempo, se permite la reproducción automática de video con sonido amortiguado. Para dicho contenido, debe establecer el atributo "silenciado" en verdadero para HTMLMediaElement . La captura de pantalla muestra que los usuarios pueden desactivar manualmente el bloqueo de sonido para sitios individuales.

En Firefox para Android, la nueva implementación reemplazará el mecanismo de bloqueo automático de reproducción existente.

Técnicamente, Firefox bloquea la llamada play() de HTMLMediaElement.play() , devolviendo un error NotAllowedError . Todos los navegadores con una funcionalidad similar hacen lo mismo. En consecuencia, los desarrolladores web no deben suponer que la llamada a play() siempre tendrá éxito. Para evitar el bloqueo, se recomiendan dos opciones. Primero: comience a reproducir contenido junto con un controlador de eventos, por ejemplo, KeyboardEvent en el escritorio o touchend para Android. Segundo: inicie la reproducción automática sin sonido (está habilitada de manera predeterminada) y muestre al usuario un botón para activar el sonido.

El lanzamiento de la versión final de Firefox 66 está programado para el 19 de marzo de 2019 , por lo que los desarrolladores tienen tiempo para prepararse.

Actualmente, Mozilla está trabajando en el bloqueo automático de contenido de Web Audio : se promete hasta finales de 2019.

Presupuesto de página web

Los cambios al cromo todavía están en discusión. No es el hecho de que la confirmación correspondiente se incluirá en la rama principal. Pero la idea es muy interesante.

El 4 de febrero de 2019, uno de los desarrolladores, Alex Russell, presentó el commit 1265506 ("Modo nunca lento") . Sugiere introducir en el navegador un modo adicional --enable-features=NeverSlowMode , que limitará el presupuesto de cada página web , garantizando así una carga rápida.

Alex Russell es uno de los principales desarrolladores de Chrome, Blink y la plataforma web de Google, el autor del artículo "¿Se lo puede permitir? El presupuesto de la productividad web en el mundo real ", cuya traducción se publicó en Habré.


Ilustración de un artículo de Alex Russell

Presupuesto sugerido:

• Volumen de una imagen: 1 MB
  
• El volumen de todas las imágenes: 2 MB
  
• Una hoja de estilo CSS: 100 KB
  
• Todas las hojas de estilo CSS: 200 KB
  
• Tamaño máximo de script: 50 KB

Naturalmente, el usuario incluirá esta función a voluntad. Por ejemplo, si trabaja a través de una conexión a Internet lenta, en un dispositivo débil (computadora desactualizada), etc. El límite de presupuesto asegura una carga rápida y sin frenos, pero al mismo tiempo aumenta la probabilidad de que la página no se cargue hasta el final.

Obviamente, el presupuesto debe revisarse periódicamente, centrándose en el tiempo de carga de la página.

Sitios de obesidad

El presupuesto de páginas es una buena idea. Muchos usuarios y especialistas señalan que a lo largo de los años, los programas y las aplicaciones web no se vuelven más rápidos, a pesar de un aumento significativo en el rendimiento de la computadora.

Por alguna razón, las solicitudes de aplicaciones están creciendo más rápido que el rendimiento del hardware. Como resultado, el software se vuelve más lento cada año, y los sitios web están engordando .

La tendencia es que el software no se vuelve más rápido y más funcional en absoluto. Obtenemos equipos más rápidos en los que el software con las mismas funciones se alterna más lentamente que antes. Todo funciona mucho más lento que la velocidad máxima. ¿Alguna vez se preguntó por qué su teléfono arranca de 30 a 60 segundos? ¿Por qué no puede arrancar, digamos, en un segundo? No hay limitaciones físicas. Personalmente, me gustaría eso. Quiero que los desarrolladores lleguen al límite, utilizando cada bit para el rendimiento. - Del artículo "Mi decepción en el software"

Quizás un presupuesto de página web ayudará a resolver el problema si otros desarrolladores de Chromium aceptan el compromiso de Russell.

---