Firefox se volvió realmente más rápido para los usuarios en 2023

 (hacks.mozilla.org)
1 puntos por GN⁺ 2023-11-01 | 1 comentarios | Compartir por WhatsApp
  • Firefox mejoró la carga de páginas, la capacidad de respuesta a la entrada y el tiempo de ejecución de JavaScript no solo en benchmarks, sino también en la telemetría de usuarios reales, después de los trabajos de optimización de 2023
  • Mozilla está impulsando Speedometer 3 junto con otros navegadores para crear una prueba que refleje mejor el rendimiento que perciben los usuarios en páginas web reales
  • El tiempo desde la recepción del primer byte hasta First Contentful Paint se redujo de unos 250 ms a inicios de año a 215 ms en octubre, haciendo que la retroalimentación de carga fuera casi un 15% más rápida
  • El percentil 95 del tiempo de ejecución de JavaScript durante la carga de páginas bajó unos 300 ms, de aproximadamente 1560 ms a unos 1260 ms, y esta mejora está vinculada a optimizaciones en SpiderMonkey
  • Después de los lanzamientos de Firefox 116 y 117, la latencia lenta en la entrada de teclas también bajó de unos 65 ms a menos de 59 ms, mostrando una mejora del 10% que reduce las interrupciones al escribir

Por qué es difícil medir el rendimiento con usuarios reales

  • Firefox es un software cliente complejo que ejecuta código de terceros, por lo que es difícil juzgar los cambios en la experiencia real de los usuarios solo con métricas de laboratorio controladas
  • Para evaluar el rendimiento del navegador se necesitan métricas de tiempo anonimizadas como carga de páginas, capacidad de respuesta y tiempo de arranque
  • Como los datos deben manejarse manteniendo estándares de privacidad, el análisis tiene limitaciones
    • Al depender de métricas agregadas, no existe una función para señalar con precisión los datos de un sitio web específico
    • Tampoco es fácil extraer conclusiones accionables a partir de los datos recopilados
  • Speedometer 3 es un trabajo para crear una prueba de rendimiento que simule la experiencia real del usuario, ayudando a que los navegadores impulsen mejoras tomando como referencia a usuarios reales y páginas web reales

Mejoras en la carga de páginas y en el tiempo de ejecución de JavaScript

  • Para la percepción de rendimiento en la carga de páginas, First Contentful Paint se usa como una métrica más adecuada que el evento onload
  • El criterio de medición es el tiempo transcurrido desde que se recibe el primer byte desde la red hasta FCP
    • Este valor muestra qué tan rápido recibe el usuario la señal de que la página se está cargando correctamente
    • La propia página web influye mucho, pero si mejora el rendimiento general del navegador, esta cifra puede bajar
  • El tiempo relacionado con FCP cayó de unos 250 ms a inicios de año a 215 ms en octubre
    • La velocidad con la que el usuario recibe retroalimentación de carga de la página se volvió casi 15% más rápida que a inicios de año
    • Esta mejora provino de trabajos de optimización que no apuntaban directamente a la carga de páginas
  • El tiempo de ejecución de código JavaScript durante la carga de páginas se compara con base en el percentil 95
    • Esta métrica muestra cuánto margen hay para reducir la fricción del usuario en páginas con mucho JavaScript
    • Bajó de unos 1560 ms a inicios de año a unos 1260 ms en octubre
    • Son 300 ms menos, casi una mejora del 20%, y es posible que esté relacionada con una parte importante de la reducción del tiempo de FCP
  • El motor de JavaScript SpiderMonkey recibió optimizaciones considerables a través del trabajo en Speedometer 3, lo que llevó a mejoras en el tiempo de ejecución de JavaScript

Cambios observados en la capacidad de respuesta a la entrada

  • La capacidad de respuesta después de la carga de la página se mide con “keypress present latency”
    • Es el tiempo desde que se presiona una tecla en el teclado hasta que el resultado aparece en pantalla
    • Como la página web puede ejecutar JavaScript del hilo principal para responder al evento de keypress, intervienen más tareas que en un simple renderizado de texto
  • La mayoría de la escritura es rápida y está limitada principalmente por el hardware, como la tasa de refresco del monitor, pero los casos de entrada lenta interfieren mucho con la experiencia de uso
  • Como es importante mitigar los peores casos, esta métrica también se analiza con base en el percentil 95
  • El percentil 95 de keypress present latency estuvo alrededor de 65 ms durante la mayor parte del año, y después de los lanzamientos de Firefox 116 y 117 en agosto bajó a menos de 59 ms
    • Hubo una mejora del 10% en los casos más lentos de entrada de teclas
    • Los usuarios experimentan retroalimentación más inmediata y menos interrupciones al escribir
  • La mejora observada en la telemetría muestra que el trabajo de rendimiento de 2023 realmente produjo efectos positivos para los usuarios de Firefox y que aún queda margen para más optimizaciones

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-11-01
Opiniones en Hacker News

  • Se puede confirmar subjetivamente que Firefox últimamente se siente más ágil, y las mejoras de verdad se agradecen y resultan satisfactorias.
    Aun así, me queda cierta incomodidad con la metodología de medición que incorpora una anonimización fuerte. ¿No podría ser que la web en sí se haya vuelto más rápida, o que la gente esté usando mejor hardware?
    Si los sitios con mucho tráfico se optimizan más y publican versiones más livianas, en la telemetría podría parecer que, en promedio, todo se volvió un poco más rápido. Lo mismo podría pasar por renovaciones de hardware y actualizaciones del sistema operativo o de drivers.

    • Estaba usando una versión vieja de Firefox de 2020 y recién actualicé después del problema de seguridad de WebP; la nueva versión se sintió más rápida de inmediato.
    • Como todavía se usan versiones antiguas de Firefox, se podría comparar si la mejora se debe a una actualización del propio Firefox o a que la web en general se volvió más rápida.
    • La forma más fácil de aumentar la velocidad parece ser dejar el software igual y permitir que la capacidad de procesamiento y la red sigan mejorando.
      Históricamente, el software se comportó como un gas: ocupa el espacio disponible y consume recursos, y esos recursos normalmente no pertenecen a quien escribe el software.
      El software no se está comiendo el mundo; se está comiendo los recursos de cómputo y el ancho de banda que pagamos todos los meses.
    • Durante los últimos 6 meses Firefox se fue sintiendo cada vez más como un programa pesado, y por los cierres aleatorios y los tirones pensé en pasarme a Chrome.
      No me había dado cuenta hasta leer este artículo, pero últimamente esa sensación parece haber desaparecido, y ya había dejado de pensar en cambiarme.
    • La web efectivamente se está volviendo más rápida. En las métricas agregadas globales se ve una tendencia lenta pero constante a la baja, y creo que en buena parte se debe a que Google impulsó la conexión entre métricas de rendimiento y posicionamiento en búsquedas.
      Pero los datos de este artículo muestran un cambio de rendimiento claro y escalonado, ligado al despliegue de versiones del navegador. No sería honesto no reconocer el trabajo del equipo de Firefox para mejorar el rendimiento.

  • Me alegra ver que Mozilla realmente está mejorando Firefox, en vez de limitarse a mover componentes de la UI de un lado a otro.
    Como usuario de muchos años, quiero apoyar al más débil para mantener aunque sea un poco el equilibrio de poder en la web. Que Mozilla se enfoque más en la tecnología que en la política es algo bueno y, en cualquier caso, Firefox es buen software, así que no tengo grandes quejas.

    • También me parece bien que Mozilla siga cambiando la UI. Si eso aumenta la cantidad de usuarios, es algo bueno, y Mozilla debe tener la libertad de asumir riesgos si no quiere quedarse siempre un paso atrás.
      Por ejemplo, FirefoxOS parece haber sido un fracaso, pero la mayoría de los grandes desafíos fracasan por naturaleza. Si uno se guarda ese tipo de apuestas a largo plazo, termina dándose cuenta tarde, como Microsoft, de que hoy muchos chicos ni siquiera tienen laptop y que, por supuesto, sus teléfonos no corren Windows. Me parece bien que existan más proyectos como FirefoxOS.
    • No solo importa enfocarse en la tecnología, sino también en el producto, es decir, Firefox.
      Uno podría decir que se enfoca solo en la tecnología y aun así volcar todos los recursos en Firefox OS.
    • Estoy de acuerdo con apoyar al más débil por el equilibrio de poder en la web, y después de cambiarme hace unos años, de verdad estoy satisfecho con la transición.

  • Después de actualizar a la 118, Firefox se congela aleatoriamente cada pocos días. No es un problema de CPU ni de swap, pero todas las ventanas quedan congeladas y hace falta killall firefox; aun así, Firefox se cierra de forma limpia.
    Por el spam de los motores de búsqueda es difícil encontrar información relacionada, y hasta antes de la 118 había funcionado bien durante años. Pasa tan poco que también es difícil hacer experimentos de reproducción, como desactivar extensiones o crear un perfil nuevo, así que supongo que tendré que aguantarlo.

    • Soy desarrollador de Firefox. Según el entorno, hay varias formas de diagnosticarlo. Si en Linux se congela todo, es probable que el problema esté en el proceso padre, el proceso de nivel superior que administra las pestañas.
      Si el reportador de fallos está activado, puedes enviar SIGABRT al proceso padre, y después del reinicio debería aparecer una entrada en about:crashes que puedes enviar.
      Si usas el Firefox de tu distribución y tienes gdb y debuginfod, puedes adjuntar gdb al proceso padre de Firefox, obtener los símbolos y luego ejecutar thread all apply bt para volcar las pilas de todos los hilos del proceso padre.
      Si usas una compilación de Mozilla, puedes usar https://firefox-source-docs.mozilla.org/toolkit/crashreporte... para integrarte con su propio servidor de símbolos. Según la distribución, puede funcionar o no también con el Firefox empaquetado por la distro.
      Cuando tengas información del fallo, puedes publicarla en el rastreador de bugs de la distribución o en https://bugzilla.mozilla.org/enter_bug.cgi?product=Core, adjuntando la pila, la versión de Firefox, el reporte de fallo, about:support y demás información relevante.
      En Linux, estos congelamientos muchas veces se deben a bugs entre Firefox y el entorno de escritorio o a problemas con el driver gráfico, y contar con la pila permite acotar mucho la causa. A veces se soluciona con una actualización de paquetes o con un solo ajuste.
    • En Brave tuve síntomas similares en dos computadoras, y se resolvió al desactivar la aceleración por hardware. Ambas tenían gráficos Intel.
    • Me pregunto si estás usando algo que no sea la versión estable o de soporte a largo plazo de una distribución de Linux.
      Las quejas sobre inestabilidad de Firefox que se ven en HN parecen venir en general de usuarios de Windows o de usuarios de Linux que instalan versiones más recientes por fuera del empaquetado de la distribución. En cambio, usando Firefox en Debian estable durante años, nunca me topé con los bugs que se describen en estos hilos.
    • Si ocurre mientras escribes, podría ser https://bugzilla.mozilla.org/show_bug.cgi?id=1844505. A mí también me afecta este bug, pero hasta ahora no se me había ocurrido buscar el ticket.
      Para reproducirlo, supongo que habría que probar con el binario original de Mozilla.

  • Es una buena noticia y me dan ganas de volver a probarlo.
    Lo usé durante casi 20 años, desde la época de Phoenix/Firebird y su método de instalación de “descomprimir en algún lado”, pero me cambié a un navegador basado en Chromium por la diferencia percibida de velocidad.
    No corrí benchmarks para confirmar mis sospechas ni medí qué acciones eran unos milisegundos más lentas en Firefox, pero cuando una herramienta se usa todo el día, todos los días, incluso para trabajar, es fácil notar esas sensaciones.
    Al ver varios informes de mejoras de rendimiento recientes y métricas de uso real, me dan ganas de volver a usarlo unos días. Si no noto la diferencia, o si de hecho se siente más rápido, voy a volver.
    Quiero volver porque es imprescindible que exista un motor de navegador alternativo. No quiero que los comités de estándares se conviertan en eventos del tipo “este año Google decidió que se hace así”.

    • Si a un buen rendimiento se le suman excelentes complementos como Multi Account Containers y Tree Style Tabs, queda un navegador excelente.

  • La función estrella de Firefox sigue siendo que permite flexibilidad en la gestión de pestañas. Gracias a Sidebery y TreeStyleTab sigo dentro del ecosistema de Firefox.
    Para quienes acumulan muchas pestañas o las usan como lista de pendientes, la experiencia es tan abrumadoramente mejor que cuesta imaginar usar otra cosa.
    También uso Firefox en Android porque tiene complementos como uBlock Origin y Dark Reader. La navegación web móvil mejora muchísimo. No es que tenga una gran lealtad a Firefox en sí; simplemente no he encontrado un navegador basado en Chromium que se adapte tan bien a mí.

    • Las pestañas verticales integradas de Edge también son bastante buenas. No tienen muchísimas funciones; básicamente son pestañas verticales con descarga automática y grupos de pestañas, pero a cambio son muy estables y casi no tienen bugs.
    • Como alguien que acumula muchas pestañas, necesito Auto Tab Discard. Pone en reposo las pestañas en segundo plano que no se usan para que no consuman recursos.
      Y también me gusta que con CSS se pueda convertir la barra de pestañas, por ejemplo, en tres filas desplazables.
    • Me da curiosidad si al usar TreeStyleTab eliminan las pestañas de arriba o si muestran ambas en pantalla.
      En pantallas pequeñas, tener ambas me daba la sensación de perder bastante espacio.
    • Probé ambas, pero al final preferí los grupos de pestañas de Safari, que están integrados de forma más fluida en la experiencia del navegador.

  • He usado Firefox como navegador principal durante años y me ha ido muy bien. Tal vez sea porque lo uso principalmente en equipos de gama alta, pero no tuve mayores quejas en Linux, Windows ni Mac.

    • Me pasa lo mismo aunque no uso equipos de gama alta. Todos mis dispositivos de uso diario tienen más de 5 años, pero estoy completamente satisfecho con la combinación Firefox + uBlock Origin.
    • Lo uso desde hace años y estoy casi de acuerdo, pero el único lugar donde tuve problemas fue con las herramientas para desarrolladores.
      Al abrir archivos JS grandes, el depurador se vuelve bastante lento, y los source maps empeoran aún más esa lentitud. También hay casos en los que no siempre puedo inspeccionar valores de variables al usar source maps, aunque tal vez sea un problema de configuración de la herramienta de build.

  • En Speedometer 2, Firefox es mucho más lento que Chrome, y Chrome es un poco más lento que Edge. Aun así, en la vida real no creo que haya una gran diferencia.
    Respeto y confío en la protección de privacidad de Mozilla. Es difícil ponerle precio a los contenedores y a la posibilidad de ejecutar Ublock y Tampermonkey en móvil.

    • Para quienes usan computadoras de bajos recursos, sigue siendo importante. Durante un viaje se rompió la pantalla de mi MacBook y compré de emergencia una laptop con Celeron 6305 y 4 GB de RAM; instalé Firefox como siempre, pero era tan lento y se trababa tanto que no se podía usar.
      Al cambiar a Edge, fue mucho más rápido y también usaba menos de los 4 GB de RAM. No esperaba que la diferencia fuera tan grande, pero era innegable; en una PC de bajos recursos, Edge corre mucho mejor que otros navegadores.
    • Los navegadores principales, por ahora, parecen ser todos lo suficientemente rápidos. Me gustaría que ahora se enfocaran más en reducir el consumo de energía.
    • Relacionado con esto, también está https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b....
    • Con una conexión de 75 Mbps, Firefox carga al instante todo lo que necesito.
      Me pregunto qué sentido tienen los benchmarks.

  • Creo que el equipo de Firefox sabe lo que está haciendo en materia de rendimiento y que sacó las conclusiones correctas.
    Pero un pequeño punto que me habría gustado ver es el cambio de rendimiento frente al mismo periodo del año pasado, para controlar los efectos estacionales. La imagen 1 muestra variaciones en centésimas de segundo, así que al observar una señal de ese tamaño parece más importante controlar el ruido.
    Dicho eso, soy un usuario satisfecho de Firefox.

    • ¿No es eso arewefastyet?
      https://arewefastyet.com/
      Además está https://wiki.mozilla.org/Areweyet.
    • Me pregunto qué efecto estacional se está suponiendo aquí. No conozco bien el área de rendimiento de navegadores, así que no sé si la composición de tecnologías web que consume la gente realmente cambia según la temporada.
      Viéndolo de forma ingenua, la tendencia aquí parece consistente y la señal parece mayor que la dispersión. Da la impresión de ser el resultado de ingenieros inteligentes optimizando esa métrica durante el periodo de medición.
      Al mismo tiempo, estoy de acuerdo en que sería bueno tener un eje temporal más largo. La gran mejora de agosto podría no deberse a que Firefox 116 salió el 1 de agosto, sino a que la gente del hemisferio norte ve lecturas más ligeras durante la temporada de vacaciones.

  • Si sigues pegado a navegadores basados en Chromium por la sensación de velocidad, creo que al menos valdría la pena probar Firefox una vez.
    Últimamente lo uso tan bien que ni pienso en volver, y es realmente importante que se mantenga con fuerza la diversidad de navegadores para el futuro de la web.

    • Uso Brave con las recompensas, la VPN y la billetera desactivadas, y con unas 20 flags cambiadas. Para mí es más rápido, tiene mejor soporte de extensiones, menos bugs y usa menos memoria cuando hay pocas pestañas. Elegí Brave porque permite sincronización.
      Firefox también me impresionó, y también probé un fork llamado Floorp. Tiene algunos agregados útiles y, aun con soporte de sincronización, me pareció mejor que Firefox común. Antes usaba ungoogled-chromium.
      https://github.com/Floorp-Projects/Floorp/releases
      Lamentablemente, según mi experiencia, algunos sitios web todavía funcionan mejor en navegadores Chromium. Es anecdótico, pero en sitios propiedad de Google siento algo como fingerprinting negativo contra Firefox, y también parece haber más fugas de memoria. Por Manifest V3 probablemente termine cambiándome a Firefox, pero por ahora me voy a quedar en Brave.

  • No estoy muy seguro de que haya mejorado, pero hay dos problemas que nunca terminan de resolverse.
    Primero, en videos VP9, la decodificación de video acelerada por hardware se comporta raro. Incluso si la desactivo o fuerzo AV1, a veces se entrecorta.
    Segundo, en un entorno de gráficos híbridos, si juego mientras veo un video en segundo plano, kWin se congela, el video que se estaba reproduciendo en el navegador se pone verde y todo lo que usa la iGPU o la dGPU empieza a trabarse muchísimo. Al final tengo que cerrar sesión y volver a iniciarla para reiniciar la sesión manualmente.
    Lo segundo quizá se deba a Nvidia prime offload en Wayland. Es culpa mía por tener una tarjeta Nvidia, pero no encontré en Bugzilla ningún tema relacionado que siga sin resolverse y, sinceramente, me da un poco de miedo reportarlo y que me hagan preguntas en tono de interrogatorio. Me gustaría depurarlo más, pero no tengo paciencia.
    No es suficiente para abandonar Firefox, pero son dos dolores de cabeza persistentes. De todos modos, felicidades al equipo. Hoy logré que 5 personas se cambiaran a Firefox.

    • La decodificación por hardware en Linux, lamentablemente, es bastante caótica. En la mayoría de estos problemas es probable que Firefox se esté integrando correctamente con varias APIs de codificación de video, pero que el bug esté en algún lado como el driver.
      Si estás en escritorio, también vale la pena probar desactivar por completo la decodificación de video por hardware.
    • Tip: hay una extensión de Firefox que fuerza a YouTube a usar H.264.
      Mi equipo soporta aceleración por hardware para VP9, pero era poco confiable; al cambiar a H.264, los videos de YouTube se reprodujeron con fluidez. Los otros sitios de video usan H.264 por defecto, así que en la práctica solo hace falta para YouTube.
    • El segundo problema es realmente desesperante. Durante años solía dejar abierto YouTube o un stream de Twitch en el segundo monitor, pero ahora sufro constantemente caídas de frames, cortes de video y congelamientos.
      Es una regresión de rendimiento realmente extraña.