iagogois.com.br
Contexto e problema
Um portfólio de dev precisa mostrar o que você entrega e o seu nível técnico. O próprio site é a prova do segundo ponto: 4 temas completos, efeitos com critério e um debugger público, onde qualquer pessoa liga, desliga e ajusta cada efeito. A história completa está no post Como este site foi feito.
Decisões técnicas
Por que um debugger público
Em vez de esconder o processo, o site mostra como funciona por dentro. Aperte ⇧D: cada efeito, cor e layout pode ser ajustado e voltado ao padrão.
Por que medir antes de otimizar
Num site com animação, o que importa também é a fluidez durante o uso. Um teste abre o site no Chrome, rola até o fim e mede cada frame. O modo leve foi refeito com base nesses números, não em palpite.
Por que só 2 ou 3 efeitos por tema
Não é só para não parecer júnior: efeito demais prejudica a experiência de quem visita, e UX é um dos fatores mais importantes de um site. Cada feature precisa fazer sentido; coisa demais vira slop. Por isso cada tema escolhe poucos efeitos-assinatura e executa bem, e todo efeito pode ser desligado.
Desafios
- 01O preloader segurava o maior elemento da tela e o LCP passava de 3 segundos no celular. Ele caiu de 1,6 s para 0,4 s.
- 02Um erro de hidratação só aparecia em produção: as datas eram formatadas em fusos diferentes no servidor e no navegador.
Resultado
- 35→63
- fps no celular, tema Aurora, modo leve
- 100
- de SEO no PageSpeed
- 4
- temas completos, em pt e en
Próximo case
react-ui →