← ← ← 5/2/2022, 6:54:43 PM | Posted by: Felippe Regazio
Tem gente que coloca pastas de imagens no backend e tasca uma rota pra servir estático de lá. Não faça isso, vc tá transformando asset estático em cross-request
Em tese todo asset (com exceção de base64 e afins) vira uma request, mas uma cross-request (o front pedir algo pra outro domínio ou sub-domínio) demora um pouco mais e tem outras políticas de segurança, cache e afins. Mantenha assets estáticos (imagens, fonts, etc) no front.
Pessoal costuma enviar códigos de erro do backend e ter json de tradução pra isso no front. Isso é desenecessário. Eis o que vc tem que fazer:
Vc precisa colocar uma lib de tradução na sua API. Vc vai receber uma header com o idioma que espera a resposta da API, mantendo a tradução no próprio backend. Para cada código de erro, vc envia um { message } com a mensagem já traduzida.
Dessa forma o front pode decidir fazer algo checando o código de erro, ou usar sua mensagem diretamente. Ex:
GET 401 { error_code: 'ACCESS_DENIED', message: 'Usuário ou senha inválidos' }
Maior parte dos apps que vejam não valorizam o client service worker. Isso é um erro enorme. Esse é um dos seus maiores aliados na performance. Em poucas palavras: podemos usar ele pra "salvar/instalar" o seu front inteiro no browser do usuário.
Assim, o service worker evita repetir requests, pq o front ta basicamente instalado na maquina da pessoa, é como se vc pedisse o front apenas uma vez pro server e nunca mais até que ele seja atualizado e a versão local invalidada. Esse é apenas um dos usos de um service worker
Service workers nasceram com o intuito de melhorar performance de aplicações, payloads, heavy process etc. Então se vc quer performance estude service workers. Configura-los e cria-los é bem chatinho, o cache invalidation deles é tenso de configurar, mas vale cada esforço.
Com um service worker configurado o usuario só requisita as paginas que ele nunca viu da sua aplicação uma única vez ao server, e depois apenas se vc atualizar. Isso alivia MUITO. Frameworks como Vue e React já trazem servicer workers out of the box, não tem motivo pra nao usar.
Um router numa SPA não serve somente pra mudar de página, se fosse assim vc poderia usar um a[href] somente e pronto. O router na SPA serve pra vc RECICLAR a rota atual.
Ou seja, vc vai mudar de pagina (ou de view, ou de parte da aplicação) re-aproveitando tudo o que puder da tela, a runtime do framework vai fazer isso pra vc, te fazendo ganhar performance.
Por ex: vc tem duas rotas de textos: about e terms. Ambas tem layout com header, footer, sidebar e um miolo de texto variável. Se vc usar o router pra transicionar, a runtime só vai trocar o miolo, sem trazer todo o layout novamenet: performance!
Polling é a tecnica de ficar fazendo requests de X em X segundos para algum lugar afim de atualizar uma informação no front end para parecer que ela está em tempo real. Às vezes é necessário, mas há alternativas mais leves.
Se vc precisa trocar informação com o server (geralmente não é o que ocorre), prefira configurar um socket, vai dar mais trabalho mas vai doer menos no bolso.
Se vc precisa receber informações do server, prefira utilizar SSE (Server Sent Events) que serve justamente pra isso.
Sabe quando vc vai trazer uma google font via e ela fica travando a pagina pra carregar? Isso é pq vc tá fazendo um cross-request via link na header. Vc pode evitar isso e outras coisas com dns pre-fetch/connect
Vc pode ler mais sobre DNS pre-fetch e pre-connect aqui: https://developer.mozilla.org/en-US/docs/Web/Performance/dns-prefetch
É mais um recurso criado com o inteuito de melhorar a performance. Ele basicamente cacheia os passos (e alguns payloads) de cross-requests pra vc, e faz alguns rodarem em background, liberando a pag.
Se vc fizer tudo isso que eu disse aí em cima, sua aplicação vai ter uma boa performance e aposto que um cloudfront ou um heroku bem basico com um cloudflare vai servir ela com velocidade e confiabilidade por muito tempo.