Ontem às 20 horas da noite recebi uma mensagem de um amigo que dizia: "vamos fazer um site novo para as escolas do Paraná [...] O problema não é nem o site ser feio, a questão é que ele não funciona".
Esse meu amigo já estava há vários minutos tentando imprimir seu comprovante de matrícula no site do governo do Paraná. A cada clique para navegar pelo menu principal do site era debitado de sua paciência longos 10 segundos de espera para finalmente receber uma tela de erro do Brave dizendo "out of memory".
Essa última parte é que me deixou especialmente intrigado. Como é possível uma página tão simples quanto a de um site tradicional dos anos 2000 estar crasheando com um erro aparentemente de cliente de memória esgotada?
Esse tipo de coisa me deixa sinceramente triste, é um ultraje à todos desenvolvedores web que se esforçam tanto para entregar um serviço de qualidade. Qual o sentido de suar tanto para entender as entranhas de um sistema web, para estar páreo às constantes mudanças no cenário de tecnologia web, de tratar o sistema com cuidado e seriedade se tem gente ganhando (e não é pouco) para fazer uma narquia dessas? Não existe uma alma sequer no time de dev que perceba o problema e tome iniciativa para resolvê-lo?
Um exercício muito interessante que todos deveriam fazer numa situação dessas é imaginar se fosse uma empresa privada no lugar do governo. Eu duvido que seu blog ou seu ecommerce duraria mísero um ano de existência se demorasse 15 segundos para carregar uma página simples.
Não me entenda mal
Sim, eu ainda sou júnior e eu não faço ideia da complexidade do sistema por baixo dos panos e eu sei que, na prática, as coisas não são tão bonitas quanto na teoria. Mesmo assim não existem condições tão escassas em 2021 para que um servidor web demore tanto para retornar uma página com as notas do aluno. O governo tem recursos quase infinitos para uma infraestrutura web e suponho que não há nada de tão complexo em uma query de notas de alunos que retornarão menos de 100 registros e mesmo assim o site pena para carregar.
Eu não sou de só reclamar e não resolver o problema porque não é da minha conta, mas, nesse caso, não tenho muita escolha. O sistema roda em um JavaServer Faces que renderiza as páginas server side então, provavelmente, o problema é lá na ponta deles e fica muito difícil de debugar sem ter acesso ao código.
Uma coisa que é fácil de notar é a falta de otimização dos assets e péssima prática de só sair jogando <script> e <link> no <head> e torcer para que dê tudo certo.
Olhe para essa página. O que de tão especial está acontecendo para o browser acusar 2.2 Mb de assets baixados durante o carregamento? Essa página contém 1.2 Mb só de Javascript não minificado e 530 Kb de CSS não minificado, além de imagens e fontes não otimizadas. É claro, dentre os scripts não poderia faltar um jquery e bootstrap de quase 800 Kb.
Só essa tela demora cerca de 20 segundos para carregar usando uma conexão 3G rápida. Em comparação, a tela de posts relevantes aqui do dev.to demorou 17 segundos para carregar transferindo cerca de 3 Mb durante o carregamento. É um completo descaso.
O que dá para fazer?
Todos esses problemas são remanescentes de um sistema legado e o pouco caso dos concursados com salário garantido, mas há uma via relativamente simples de modernização sem precisar reconstruir parte grande do código.
Especificamente nessa página de login é notável que a estratégia de server side rendering é descartável e poderia ser substituída por uma página estática pré renderizada. Só isso, provavelmente, já pouparia cerca 50% do tempo de carregamento.
Seguindo nessa mesma linha a ideia é desatrelar o frontend do backend e fazer a comunicação por uma API REST. Hoje em dia temos frameworks frontend que fazem um belíssimo trabalho de entregar código performático e compatível. O NextJS, por exemplo, oferece de graça algumas estratégias de renderização em que o programador tem a liberdade de escolher qual funciona melhor página à página. Isto é, você pode servir uma página renderizada no servidor e também outras pré renderizadas ou renderizadas no cliente. É maravilhoso.
O mundo enterprise adora um MVC e frameworks baseados em React não impõem nenhuma arquitetura rígida de código, mas, se esse for o caso, há opções como o Angular que simplesmente fazem as desculpas se tornarem tão obsoletas quanto seus sistemas.
Conclusão
Por fim, gostaria de adicionar que a impossibilidade de colocar minhas mãos no código e resolvê-lo é uma tortura interna e o primeiro post sendo um rant indica um início um pouco duvidoso 😂.
Top comments (0)