Por que você deve ficar sempre de olho na performance do seu site
A gente é bem bitolado em performance aqui na Alura e na Caelum há bastante tempo. Já seguimos muitas boas práticas na hora de desenvolver e até ensinamos várias delas nos cursos de performance front-end.
Mas a vida acontece
Mais especificamente, as coisas evoluem. Mudam organicamente. Uma funcionalidade nova aqui, outra ali. Muita gente mexe no código. Até os browsers mudam. E aí sem a gente nem perceber, a performance pode ir pro ralo.
Recentemente passamos por diversos pequenos casos na plataforma de aula da Alura onde a performance estava sofrendo por besteiras pequenas ou por débito técnico que estava acumulando. E isso me fez lembrar como precisamos sempre estar de olho na performance do site. Não é algo que se faz e se larga. É preciso monitorar.
O HTTP/2 que sumiu
Usamos HTTP/2 na Alura há bastante tempo. Somos mega fãs. Poucos meses atrás um update do Chrome passou a exigir um protocolo mais moderno de negociação do HTTP/2 (o ALPN). Mas ele só funciona se o servidor tiver OpenSSL mais moderno. E a gente usava o Ubuntu LTS aqui que tava com OpenSSL antigo.
Conclusão: ficamos algumas semanas sem HTTP/2 no site até migrar toda a infra para um Ubuntu + OpenSSL recente. Mas como ficar sabendo disso? Afinal usávamos HTTP/2 aqui sem problemas por muito tempo. Só ficando de olho mesmo, monitorando.
O GZIP que não era
Nessa migração, atualizamos nossas configurações no servidor, onde usamos o nginx. E, claro, beabá de performance, temos GZIP habilitado por lá. Mas comecei a reparar que nosso jQuery tava com mais de 90KB de transferência - e eu sabia que devia ser menos de 30KB. Um erro no arquivo do nginx e estávamos fazendo GZIP apenas de HTML e CSS. Tanto JS quando SVG, que se beneficiam bastante de GZIP, estavam de fora. Um fix de 1min que economizou uns 100KB pra todos os pageviews de alunos da Alura.
O JS que sobrou
E por falar em pequenas ações com grandes ganhos, outra que economizou mais uns 200KB pros usuários foi tirar um JS esquecido lá na página que era usado em uma funcionalidade que nem existia mais. Era um Google Charts que usamos uma época e nunca mais. Mas o JavaScript ainda estava lá. Pior: por descuido, era um script blocante no head. Ouch. 200KB inúteis de um request crossdomain travando a renderização. Pra envergonhar qualquer especialista em performance.
Todas essas melhorias (e mais algumas) já estão no ar para todos os alunos. Mas o ponto é perceber como é fácil escorregar em algo e perder a mão com a performance do site. Coisas mudam, projetos crescem e, se não ficamos de olho, podemos estar perdendo oportunidades como essas - pequenas correções no projeto com grandes impactos na performance final sentida pelo usuário.
Se você se interessa por performance de Front-end, não deixe de conferir os 2 cursos na Alura completíssimos e com notas altíssimas dos alunos que fizeram. Sem querer nos gabar mas já nos gabando, com certeza são material referência na área no Brasil hoje; não há nada nem parecido por aí.