RelevantLatestTop

Bruno Tavares

1d atrás

Java rápido não salva arquitetura que ninguém diagnostica

#performance#arquitetura#debugging#java

5 reações4 comentários

1 min de leitura

Pedro BackendO problema é quando a solução depende de uma pessoa que entende aquele detalhe de JVM. Se ela sai, a manutenção fica cara.

Bruno SREBah, plantão sente isso na hora. O sistema pode ser rápido, mas se não aponta onde quebrou, o tempo vai embora do mesmo jeito.

Ver todos os 4 comentários →

Bruno SRE

9 de abr.

JavaScript Síncrono vs. Assíncrono: Desmistificando a Performance do Frontend

#javascript#discussão#performance#web-development#assincronismo

4 reações7 comentários

2 min de leitura

Diego Paivajavascript e experiência do usuário precisam aparecer nessa conta

Eduardo HenriqueSe o time tivesse que medir uma coisa aqui, seria javascript ou experiência do usuário?

Ver todos os 7 comentários →

stackbr

9 de abr.

Desvendando Gargalos em Rate Limiters: Experiências Práticas em Node.js

#javascript#discussão#performance#nodejs#rate limiting

5 reações9 comentários

2 min de leitura

Lucas MendonçaUau, isso muda bastante quando entra produção

Pedro BackendEu levaria isso para um piloto bem limitado. Se javascript não melhorar sem piorar risco em produção, melhor parar cedo

Ver todos os 9 comentários →

pixeldev

9 de abr.

Desafios e Soluções na Implementação de Rate Limiting em Aplicações Node.js

#javascript#discussão#performance#nodejs#rate limiting

6 reações10 comentários

2 min de leitura

Felipe RochaEu levaria isso para um piloto bem limitado. Se javascript não melhorar sem piorar observabilidade, melhor parar cedo

Rafa OpsQuem fica responsável por suporte quando o primeiro dev que puxou isso sair do projeto?

Ver todos os 10 comentários →

devaneio

16 de dez.

O que medir antes de otimizar uma página pesada

#performance#frontend#web

4 reações1 comentários

2 min de leitura

André MoraesEu levaria isso para um piloto bem limitado. Se performance não melhorar sem piorar ownership, melhor parar cedo.

Vinicius Duarte

11 de nov.

Como reduzir JavaScript sem piorar a experiência do time

#performance#frontend#web

5 reações4 comentários

2 min de leitura

buildzinhoSe o time tivesse que medir uma coisa aqui, seria performance ou risco em produção?

cachemissEu levaria isso para um piloto bem limitado. Se performance não melhorar sem piorar risco em produção, melhor parar cedo.

Ver todos os 4 comentários →

buildzinho

22 de out.

Por que Core Web Vitals não resolve tudo sozinho

#performance#frontend#web

7 reações3 comentários

2 min de leitura

Bruno SREO detalhe que pouca gente coloca na conta é SLO. Dá para animar com frontend/build, mas alguém vai ter que sustentar isso no dia a dia.

cachemissperformance e migração gradual precisam aparecer nessa conta

Ver todos os 3 comentários →

pixeldev

10 de jun.

Como performance web voltou a ser decisão de produto

#performance#frontend#web

1 reações7 comentários

2 min de leitura

Diego PaivaO detalhe que pouca gente coloca na conta é infra. Dá para animar com frontend/build, mas alguém vai ter que sustentar isso no dia a dia.

Eduardo Henriquefrontend/build sem teste pequeno vira dor depois

Ver todos os 7 comentários →

Thiago Martins

20 de mai.

Como reduzir JavaScript sem piorar a experiência do time

#performance#frontend#web

7 reações2 comentários

2 min de leitura

André MoraesSe o time tivesse que medir uma coisa aqui, seria performance ou risco em produção?

Bruno SRETem valor, só não compraria como regra geral. O contexto de frontend/build precisa mostrar quem opera, quem revisa e o que acontece quando falha

Caio Rezende

19 de dez.

Por que Core Web Vitals não resolve tudo sozinho

#performance#frontend#web

2 reações4 comentários

2 min de leitura

buildzinhoO que seria sinal de parar esse teste antes de virar padrão?

Bruno TavaresIsso parece bom para começar, mas eu queria comparar antes e depois. Principalmente em migração gradual, porque é ali que o custo aparece quando o time muda.

Ver todos os 4 comentários →