[DRAFT] Performance Web no mundo real: porque o site da Alura voa

Performance Web no mundo real: porque o site da Alura voa
slopes
slopes

Compartilhe

Quando lançamos o novo site da Alura esse mês uma das coisas que mais chamou a atenção de todos foi a altíssima performance do site. Postei um vídeo de Antes de Depois no Facebook e no Twitter que bombou:

[video width="904" height="400" mp4="http://blog.alura.com.br/wp-content/uploads/2016/03/video-1.mp4"\]\[/video]

Repare como o novo site já está todo renderizado em apenas 1.5s. Enquanto o antigo começava a aparecer em 5.5s.

Muita gente perguntou como fizemos, então este um post focado na nossa estratégia de performance no novo site da Alura. Temos também um post com foco em explicar nossa arquitetura por trás dos panos.

O básico de performance Web

Há anos que falo de Performance na Web com foco em Front-end. No site da Alura, antes das otimizações agressivas, fizemos todo o feijão com arroz que todo mundo já sabe.

  • GZIP
  • Minificar CSS e JS
  • Comprimir HTML
  • CSS no
  • JS no fim do
  • Otimizamos as imagens (com svgo em 99% dos casos)
  • Cache-Control e Expires agressivo (até pro HTML!)

Mas só isso não fez a gente chegar . Tínhamos alguns gargalos importantes.

Progressive Enhancement

O maior erro do mundo front-end atual é depender demais de JavaScript #prontofalei. Single Page Applications, Angular, React e cia são inimigos da performance (e da acessibilidade, do SEO e de mais coisas). Frameworks pesados são desnecessários em muitos casos. Como no novo site da Alura.

HTML simples consegue te levar muito longe hoje em dia. E com um CSS bacana você faz muito sem precisar de JS. Para todo resto, um JavaScriptzinho aqui e ali resolve (sem jQuery). Resultado? Seu site é mais rápido, mais acessível e o Google te ama.

O bom e velho Progressive Enhancement é o coração da performance do novo site da Alura.

Carregamento assíncrono e não-blocante

Claro que várias coisas no site exigem JavaScript. E aí só colocar o JavaScript no fim da página não resolve. Tudo ainda é carregado de forma blocante e sequencial. A resposta é abusar do carregamento assíncrono.

Todos os nossos JavaScripts são carregados com async. Por exemplo:

O suporte nos navegadores hoje é excelente e poderíamos até colocar as chamadas no sem perda de performance.

Além disso, na nossa página, há um iframe do Vimeo com um vídeo de apresentação da Alura. Ele é totalmente secundário na página, mas era carregado na hora pelo browser. A solução foi adiar o carregamento dele também, criando o iframe num JS assíncrono.

Deveria ser crime não usar HTTP/2 hoje em dia

Uma das grandes vantagens de rodar no Google App Engine é ter HTTP/2 (e QUIC) automaticamente. Basta subir o site em HTTPS e já ganhamos as magias do HTTP/2. E, com elas, muitas otimizações de performance de antigamente mudam.

Em particular, não é preciso mais bitolar em concatenar arquivos CSS e JS agressivamente e nem criar sprites pra tudo. Isso não quer dizer que, no lugar do seu 1 arquivão de CSS concantenado você vai carregar 5467 arquivinhos. Isso pode estressar a rede e o browser.

No site da Alura, quebramos o CSS em 10 arquivos diferentes que são carregados individualmente e conforme a necessidade de cada página. Ainda há uma concatenação mas bem menos agressiva, o que facilita as coisas (no fonte temos por volta de 40 arquivos separados).

Outro ponto é que não nos preocupamos tanto com as imagens fora de sprites. Os ícones dos cursos por exemplo, são arquivos svg individuais. Mas mesmo carregando a lista com os 200 cursos da Alura você repara que a conexão multiplexada do HTTP/2 dá conta.

Server Push ❤

O consenso do povo de performance Web hoje em dia é que o foco deve ser remover todo e qualquer recurso blocante do carregamento inicial da página. É o que o pessoal chama de otimizar o Critical Path. E o maior inimigo aqui é o CSS. Ele fica no e bloqueia a renderização. Chegam até a recomendar não usar um arquivo .css e embutir o código CSS inicial numa tag