1 pontos por GN⁺ 2023-11-01 | 1 comentários | Compartilhar no WhatsApp
  • Após os trabalhos de otimização em 2023, o Firefox melhorou não só em benchmarks, mas também na telemetria de usuários reais em carregamento de páginas, responsividade de entrada e tempo de execução de JavaScript
  • A Mozilla está trabalhando no Speedometer 3 junto com outros navegadores para criar um teste que reflita melhor o desempenho percebido pelos usuários em páginas reais da web
  • O tempo desde o recebimento do primeiro byte até o First Contentful Paint caiu de cerca de 250 ms no início do ano para 215 ms em outubro, tornando o feedback de carregamento quase 15% mais rápido
  • O percentil 95 do tempo de execução de JavaScript durante o carregamento da página caiu cerca de 300 ms, de aproximadamente 1560 ms para cerca de 1260 ms, e as otimizações do SpiderMonkey estão ligadas a essa melhora
  • Após os lançamentos do Firefox 116 e 117, a latência lenta de entrada no teclado também caiu de cerca de 65 ms para menos de 59 ms, mostrando uma melhora de 10% na redução de travamentos durante a digitação

Por que é difícil medir o desempenho no mundo real

  • O Firefox é um software cliente complexo que executa código de terceiros, então é difícil avaliar mudanças na experiência real do usuário apenas com métricas controladas de laboratório
  • Para observar o desempenho do navegador, são necessárias métricas de tempo anonimizadas como carregamento de página, responsividade e tempo de inicialização
  • Como os dados precisam ser tratados mantendo padrões de privacidade, a análise tem limitações
    • Como depende de métricas agregadas, não há um recurso para apontar com precisão dados de um site específico
    • Também não é fácil extrair conclusões acionáveis a partir dos dados coletados
  • O Speedometer 3 é um esforço para criar um teste de desempenho que simule a experiência real do usuário, ajudando os navegadores a direcionar melhorias com base em usuários reais e páginas reais da web

Melhorias no carregamento de páginas e no tempo de execução de JavaScript

  • Para o desempenho percebido no carregamento de páginas, First Contentful Paint é uma métrica mais adequada do que o evento onload
  • O critério de medição é o tempo desde o recebimento do primeiro byte da rede até o FCP
    • Esse valor mostra quão rapidamente o usuário recebe um feedback de que a página está carregando com sucesso
    • Embora a própria página influencie bastante, esse número pode cair quando o desempenho geral do navegador melhora
  • O tempo relacionado ao FCP caiu de cerca de 250 ms no início do ano para 215 ms em outubro
    • A velocidade com que o usuário recebe feedback de carregamento da página ficou quase 15% mais rápida do que no começo do ano
    • Essa melhora veio de trabalhos de otimização que não tinham como alvo direto o carregamento de páginas
  • O tempo de execução de código JavaScript durante o carregamento da página é comparado com base no percentil 95
    • Essa métrica mostra quanto espaço existe para reduzir atrito para o usuário em páginas com muito JavaScript
    • Caiu de cerca de 1560 ms no início do ano para aproximadamente 1260 ms em outubro
    • A redução de 300 ms, quase 20% de melhora, pode estar relacionada a boa parte da queda no tempo de FCP
  • O motor JavaScript SpiderMonkey recebeu otimizações significativas por meio do trabalho no Speedometer 3, levando à melhora no tempo de execução de JavaScript

Mudanças observadas na responsividade de entrada

  • A responsividade após o carregamento da página é medida por “keypress present latency”
    • É o tempo entre pressionar uma tecla no teclado e o momento em que o resultado aparece na tela
    • A página da web pode executar JavaScript na thread principal para responder ao evento de keypress, então há mais trabalho envolvido do que apenas renderização simples de texto
  • A maior parte da digitação já é rápida e limitada principalmente por hardware como a taxa de atualização do monitor, mas os casos de entrada lenta atrapalham bastante a experiência de uso
  • Como é importante aliviar os piores casos, essa métrica também é analisada com base no percentil 95
  • O percentil 95 de keypress present latency ficou em torno de 65 ms durante a maior parte do ano e, após os lançamentos do Firefox 116 e 117 em agosto, caiu para menos de 59 ms
    • Houve cerca de 10% de melhora nos casos mais lentos de entrada no teclado
    • Os usuários passam a perceber feedback mais imediato e menos interrupções durante a digitação
  • As melhorias vistas na telemetria mostram que o trabalho de desempenho de 2023 realmente teve efeito positivo para os usuários do Firefox, embora ainda exista espaço para otimizações adicionais

1 comentários

 
GN⁺ 2023-11-01
Comentários do Hacker News
  • Dá para perceber subjetivamente que o Firefox parece ter ficado mais rápido recentemente, e as melhorias são realmente bem-vindas e satisfatórias
    Ainda assim, fico um pouco desconfortável com a metodologia de medição com anonimização forte. Pode ser também efeito de a própria web ter ficado mais rápida ou de as pessoas estarem usando hardware melhor
    Se sites com muitos visitantes forem mais otimizados e distribuírem versões mais leves, a telemetria pode fazer parecer que, em média, tudo ficou um pouco mais rápido. O mesmo pode valer para troca de hardware e atualizações de sistema operacional e drivers

    • Eu usava um Firefox antigo de 2020 e só atualizei por causa de um problema de segurança com WebP; a versão nova pareceu imediatamente mais rápida
    • Como versões antigas do Firefox ainda são usadas, dá para comparar se a melhora veio da própria atualização do Firefox ou se é porque a web em geral ficou mais rápida
    • O caminho mais fácil para aumentar a velocidade parece ser deixar o software como está e permitir que o poder de processamento e a rede continuem melhorando
      Historicamente, software se comporta como um gás, preenchendo o espaço e consumindo recursos, e esses recursos em geral não pertencem ao autor do software
      O software não está devorando o mundo, está devorando recursos computacionais e largura de banda pagos todo mês
    • Nos últimos 6 meses, o Firefox vinha parecendo cada vez mais um programa pesado, e eu estava pensando em mudar para o Chrome por causa de travamentos aleatórios e engasgos
      Eu não tinha percebido isso antes de ler este texto, mas ultimamente essa sensação parece ter sumido, e eu já até deixei de pensar em trocar
    • A web de fato está ficando mais rápida. Isso aparece em métricas globais agregadas como uma queda lenta, mas constante, e acho que muito disso vem do Google ter empurrado isso ao ligar métricas de desempenho e ranking de busca
      Mas os dados deste texto mostram mudanças de desempenho em degraus bem nítidos, alinhadas com a distribuição de versões do navegador. Não seria honesto deixar de reconhecer o esforço da equipe do Firefox em melhorar o desempenho
  • É bom ver a Mozilla realmente melhorando o Firefox em vez de apenas ficar mudando componentes da interface de lugar
    Como usuário de longa data, quero torcer pelo lado mais fraco para manter pelo menos um pouco do equilíbrio de poder na web. É bom ver a Mozilla focando mais em tecnologia do que em política e, de qualquer forma, o Firefox é um bom software, então não tenho grandes reclamações

    • Também acho normal a Mozilla continuar mudando a interface. Se isso aumentar o número de usuários, ótimo, e para a Mozilla não ficar sempre um passo atrás ela precisa ter liberdade para correr riscos
      Por exemplo, o FirefoxOS parece ter sido um fracasso, mas a maioria dos grandes desafios fracassa mesmo. Se você economiza nesses desafios de longo prazo, acaba percebendo tarde demais, como a Microsoft, que hoje em dia muitas crianças nem têm laptop e obviamente não rodam Windows no celular. Eu acharia normal haver mais projetos como o FirefoxOS
    • Não é importante só focar em tecnologia, mas também no produto, ou seja, no Firefox
      Dá para dizer que está focando em tecnologia e ainda assim despejar todos os recursos no Firefox OS
    • Concordo com apoiar o lado mais fraco pelo equilíbrio de poder na web e, desde que troquei há alguns anos, estou realmente satisfeito com a mudança
  • Depois de atualizar para a 118, o Firefox trava aleatoriamente a cada poucos dias. Não parece ser problema de CPU nem de swap, mas todas as janelas congelam e é preciso dar killall firefox; ainda assim, o Firefox encerra de forma limpa
    Também é difícil encontrar informações por causa de spam em mecanismos de busca, e antes da 118 ele funcionava bem há anos. Acontece com tão pouca frequência que é difícil fazer testes de reprodução, como desativar extensões ou criar um perfil novo, então acho que só vou ter de conviver com isso

    • Sou desenvolvedor do Firefox. Dependendo do ambiente, há algumas formas de diagnosticar isso. Se tudo congelou no Linux, é bem possível que o problema esteja no processo pai, o processo de nível mais alto que gerencia as abas
      Se o crash reporter estiver ativado, você pode enviar SIGABRT ao processo pai e, depois de reiniciar, aparecerá uma entrada em about:crashes que pode ser enviada
      Se estiver usando o Firefox da distribuição e tiver gdb e debuginfod, dá para anexar o gdb ao processo pai do Firefox, obter os símbolos e executar thread all apply bt para despejar a pilha de todas as threads do processo pai
      Se estiver usando a build da Mozilla, pode usar https://firefox-source-docs.mozilla.org/toolkit/crashreporte... para integrar com o servidor de símbolos da própria Mozilla. Dependendo da distribuição, isso pode ou não funcionar também no Firefox empacotado pela distribuição
      Quando tiver informações do travamento, você pode anexar a pilha, a versão do Firefox, o relatório de falha, about:support e outros dados relevantes no rastreador de bugs da distribuição ou em https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
      No Linux, esses travamentos muitas vezes são bugs entre o Firefox e o ambiente gráfico, ou problemas no driver gráfico, e ter a pilha ajuda bastante a reduzir as possibilidades. Às vezes, um update de pacote ou uma configuração resolve
    • Tive sintomas parecidos no Brave em dois computadores e resolveu ao desligar a aceleração de hardware. Ambos usavam gráficos Intel
    • Fico curioso se você está usando uma distribuição Linux que não seja a versão estável ou de suporte de longo prazo
      As reclamações sobre instabilidade do Firefox que aparecem no HN normalmente parecem vir de usuários de Windows ou de usuários de Linux que instalam a versão mais nova fora do empacotamento da distribuição. Já eu uso o Firefox da versão estável do Debian há anos e nunca encontrei os bugs descritos em tópicos como este
    • Se isso acontece enquanto você está digitando, pode ser https://bugzilla.mozilla.org/show_bug.cgi?id=1844505. Eu também sou afetado por esse bug e, até agora, nem tinha pensado em procurar o ticket
      Para reproduzir, talvez seja preciso usar os binários puros da Mozilla
  • É uma boa notícia, e me dá vontade de testar de novo
    Usei por quase 20 anos, desde a época do Phoenix/Firebird e daquele esquema de instalação de “descompactar em algum lugar”, mas migrei para navegadores baseados em Chromium por causa da diferença de velocidade percebida
    Não cheguei a rodar benchmarks nem medir quais ações eram alguns milissegundos mais lentas no Firefox para confirmar a suspeita, mas quando a ferramenta é usada o dia inteiro, todos os dias, inclusive no trabalho, fica fácil perceber essas diferenças
    Ao ver vários relatos recentes de melhora de desempenho e métricas de uso real, fiquei com vontade de usar por alguns dias de novo. Se eu não perceber diferença, ou se ele de fato parecer mais rápido, pretendo voltar
    Quero voltar porque é essencial existir um mecanismo de navegador alternativo. Não quero que os comitês de padrões virem algo como “neste ano o Google decidiu que tem que ser assim”

    • Com bom desempenho somado a ótimos complementos como Multi Account Containers e Tree Style Tabs, vira um excelente navegador
  • O recurso matador do Firefox continua sendo permitir flexibilidade no gerenciamento de abas. Continuo no ecossistema do Firefox por causa do Sidebery e do TreeStyleTab
    Para quem acumula muitas abas ou usa abas como lista de tarefas, a experiência é incomparavelmente melhor, então é difícil imaginar usando outra coisa
    No Android também uso Firefox por causa dos complementos uBlock Origin e Dark Reader. A navegação móvel fica muito melhor. Não é que eu tenha grande lealdade ao Firefox; só não encontrei um navegador baseado em Chromium que combine tão bem comigo

    • As abas verticais nativas do Edge também são bem boas. Não são cheias de recursos, são basicamente abas verticais com descarregamento automático e grupos de abas, mas em compensação são muito estáveis e quase não têm bugs
    • Para quem acumula muitas abas, Auto Tab Discard é necessário. Ele coloca abas de fundo não usadas para dormir para que não consumam recursos
      E também gosto do fato de ser possível, com CSS, transformar a barra de abas em, por exemplo, três linhas roláveis
    • Fico curioso para saber se, ao usar TreeStyleTab, você removeu as abas de cima ou se deixa as duas visíveis
      Em telas pequenas, parecia que eu perdia bastante espaço deixando ambas
    • Já usei os dois, mas no fim gostei mais dos grupos de abas do Safari, que se integram à experiência do navegador de forma mais fluida
  • Usei o Firefox como navegador principal por anos e ele foi muito bom. Talvez por eu rodá-lo principalmente em máquinas potentes, mas não tive grandes reclamações no Linux, Windows ou Mac

    • Tenho a mesma experiência mesmo sem usar máquinas potentes. Todos os dispositivos que uso diariamente já têm mais de 5 anos, mas estou totalmente satisfeito com a combinação Firefox + uBlock Origin
    • Uso há alguns anos e concordo quase totalmente, mas o único lugar em que tive problemas foi nas ferramentas de desenvolvedor
      Ao abrir arquivos JS grandes, o depurador fica bem lento, e os source maps agravam ainda mais essa lentidão. Também há casos em que nem sempre consigo inspecionar valores de variáveis ao usar source maps, embora isso possa ser um problema de configuração das ferramentas de build
  • No Speedometer 2, o Firefox é muito mais lento que o Chrome, e o Chrome é um pouco mais lento que o Edge. Ainda assim, acho que na vida real não há grande diferença
    Respeito e confio na privacidade da Mozilla. Containers e a possibilidade de rodar Ublock e Tampermonkey no celular são coisas cujo valor é difícil de medir

    • Para quem usa computadores fracos, isso ainda importa. Durante uma viagem, a tela do meu MacBook quebrou e eu tive que comprar às pressas um notebook com Celeron 6305 e 4 GB de RAM; instalei o Firefox como sempre faço, mas ele ficou tão lento e travando tanto que era impossível usar
      Ao mudar para o Edge, ficou muito mais rápido e usou menos dos 4 GB de RAM. Eu não imaginava que a diferença seria tão grande, mas era inegável, e em PCs de baixo desempenho o Edge roda muito melhor que outros navegadores
    • Os principais navegadores parecem todos rápidos o suficiente no momento. Agora eu gostaria que o foco fosse mais em reduzir o consumo de energia
    • Em relação a isso, também tem https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
    • Em uma conexão de 75 Mbps, o Firefox carrega instantaneamente tudo de que preciso
      Então fico pensando qual é o sentido de benchmark
  • Sei o que a equipe do Firefox está fazendo em relação a desempenho e acredito que chegaram às conclusões corretas
    Só fico um pouco decepcionado por não terem mostrado também a mudança de desempenho em relação ao mesmo período do ano passado, para controlar efeitos sazonais. A imagem 1 mostra mudanças em centésimos de segundo, então ao observar um sinal desse tamanho, controlar o ruído parece ainda mais importante
    Dito isso, sou um usuário satisfeito do Firefox

    • Não seria esse o arewefastyet?
      https://arewefastyet.com/
      Além disso, também existe https://wiki.mozilla.org/Areweyet
    • Fico curioso sobre que tipo de efeito sazonal está sendo assumido aqui. Não conheço bem a área de desempenho de navegadores, então não sei se a composição das tecnologias web que as pessoas consomem realmente muda conforme a estação
      Olhando de forma ingênua, a tendência aqui parece consistente e o sinal parece maior que a dispersão. Parece o resultado de engenheiros competentes otimizando essa métrica ao longo do período medido
      Ao mesmo tempo, concordo que seria bom ter um eixo temporal mais longo. A grande melhora de agosto pode não ter sido por causa do Firefox 116 ter saído em 1º de agosto, mas porque as pessoas do hemisfério norte, em época de férias, passaram a ver conteúdo mais leve para leitura
  • Se você continua em navegadores baseados em Chromium pela sensação de velocidade, vale pelo menos dar uma chance ao Firefox
    Hoje em dia uso numa boa a ponto de nem pensar em voltar atrás, e é realmente importante manter uma forte diversidade de navegadores para o futuro da web

    • Estou usando o Brave com recompensas, VPN e carteira desativadas, além de uns 20 flags alterados. Para mim ele é mais rápido, tem melhor suporte a extensões, menos bugs e também usa menos memória quando há poucas abas. Escolhi o Brave porque permite sincronização
      O Firefox também foi impressionante, e eu também testei um fork chamado Floorp. Ele tem alguns recursos extras úteis e, com suporte a sincronização, me pareceu melhor que o Firefox comum. Antes eu usava o ungoogled-chromium
      https://github.com/Floorp-Projects/Floorp/releases
      Infelizmente, na minha experiência, alguns sites ainda funcionam melhor em navegadores Chromium. É algo anedótico, mas também sinto uma espécie de tratamento desfavorável ao Firefox em sites do Google, e parece haver mais vazamentos de memória. Por causa do Manifest V3, acho que no fim vou acabar mudando para o Firefox, mas por enquanto vou continuar no Brave
  • Não sei dizer se realmente melhorou, mas ainda existem dois problemas que nunca foram resolvidos
    Primeiro, em vídeos VP9 a decodificação de vídeo com aceleração por hardware se comporta de forma estranha. Mesmo desativando isso ou forçando AV1, às vezes ainda há engasgos
    Segundo, em um ambiente com gráficos híbridos, se eu deixo um vídeo rodando em segundo plano enquanto jogo, o kWin trava, o vídeo que estava sendo reproduzido no navegador fica verde, e tudo que usa a iGPU ou a dGPU passa a travar pesadamente. No fim, preciso encerrar a sessão e entrar de novo para reiniciar manualmente a sessão
    O segundo problema pode ser por causa do Nvidia prime offload no Wayland. A culpa é minha por ter uma placa Nvidia, mas não consegui encontrar no Bugzilla um tópico relacionado já não resolvido e, sinceramente, fico meio receoso de abrir um relatório e começarem a me questionar. Eu queria depurar melhor, mas não tenho paciência
    Não é algo que me faria abandonar o Firefox, mas são duas dores de cabeça antigas. De qualquer forma, parabéns para a equipe. Hoje consegui converter 5 pessoas para o Firefox

    • No Linux, a decodificação por hardware infelizmente é uma bela bagunça. A maioria desses problemas provavelmente acontece porque o Firefox até se integra corretamente com várias APIs de codificação de vídeo, mas algum driver ou componente desse tipo acaba tendo bugs
      Se for desktop, talvez valha a pena desativar totalmente a decodificação de vídeo por hardware
    • Dica: existe uma extensão do Firefox para forçar o YouTube a usar H.264
      Meu dispositivo suporta aceleração por hardware para VP9, mas a confiabilidade era ruim; quando mudei para H.264, os vídeos do YouTube passaram a rodar de forma suave. Outros sites de vídeo geralmente usam H.264 por padrão, então na prática isso só é necessário para o YouTube
    • O segundo problema é realmente enlouquecedor. Durante anos deixei YouTube ou streams da Twitch abertos no segundo monitor, mas agora enfrento quedas de frames, travamentos no vídeo e congelamentos o tempo todo
      É uma regressão de desempenho realmente estranha