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

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:

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 <head>
  • JS no fim do </body>
  • 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:

<script src="js/home.js" async></script>

O suporte nos navegadores hoje é excelente e poderíamos até colocar as chamadas no <head> 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 <head> e bloqueia a renderização. Chegam até a recomendar não usar um arquivo .css e embutir o código CSS inicial numa tag <style> inline. Tudo pra destravar o critical path.

Na home da Alura a gente tem 2 arquivos CSS. Requisitá-los é algo que atrasa a renderização. O browser baixa o HTML, descobre os <link>, faz os requests do CSS e só então pode exibir a página. Dá pra ver isso num gráfico:

Screenshot 2016-03-02 16.43.11

Repare o tempão entre o HTML (1ª linha) e os CSS (2ª e 3ª linha).

Uma das coisas mais legais do HTTP/2 é o Server Push. Com ele, conseguimos enviar várias Respostas HTTP com base em apenas uma Requisição. Na prática, significa que quando o browser requisita o HTML eu já posso mandar os CSS junto antes mesmo dele requisitar. Isso é melhor que deixar o CSS inline pois continua sendo um recurso separado, com cache independente e o browser pode cancelar o push se já tiver o recurso.

Observe a diferença brutal:

Screenshot 2016-03-02 16.47.10

@font-face é lento

O elefante na sala por aqui eram as fontes customizadas. O Thiago, nosso designer, fez uma criação linda usando Open Sans, do Google Fonts. Usar é fácil: só colocar um CSS na página com <link> e pronto.

Mas, Deus, isso é lento. Muito lento. Tipo intoleravelmente lento. É o que mais atrasava nossa renderização. É um CSS no <head> que conecta em outro domínio e faz mais um monte de requests. Isso demora demais. Ainda mais quando já otimizamos todo o resto, aí fica gritante o impacto de um mero @font-face externo.

A solução seria tirar a fonte e tacar Arial em tudo. Performance FTW! Mas o Thiago iria me matar. E os usuários não teriam esse design lindo que temos hoje. Então a estratégia foi tentar aliviar um pouco a pancada.

Primeiro passo é colocar tudo no servidor da Alura. Usar as fontes localmente ao invés do servidor do Google deixa tudo mais rápido. Perde-se o hipotético cache entre sites, mas me parece um preço razoável. Só isso já melhora mas podemos dar o passo seguinte: Server Push nas fontes!

Sabemos que o browser vai precisar das fontes pra renderizar a página e isso atrasa toda a renderização. Então assim como fizemos com os CSSs, podemos enviar as fontes via Server Push também. Elegante e rápido.

Screenshot 2016-03-02 17.57.09

Mais otimizações

O principal é o que vimos até agora, mas várias outras coisas melhoram a performance.

Colocamos um cache agressivo em todas as coisas do site. A maioria dos assets tá com cache de 1 ano como de praxe. Mas fomos além e cacheamos até o HTML. Sim, Expires na resposta HTML do servidor. Usamos meia hora. Isso faz o browser guardar a página localmente e a navegação voa. Além disso, até o GAE cacheia as respostas num proxy deles lá. Claro, isso não é pra todos os projetos. Só fizemos no site porque as respostas são quase estáticas e não variam por usuário.

Outro ponto foi pensar bem as animações do site e colocar o máximo de trabalho possível na GPU. Fazemos as animações com CSS3 priorizando propriedades aceleradas – como transform e opacity. Animar o SVG da home deu um certo trabalho também para ficar otimizada (que merece outro post).

O resultado é a grande diferença do site novo com relação ao antigo. E usuários mais felizes. O que você achou da performance do novo site? E que técnicas você já tem aplicado aí nos seus projetos?

50 Comentários

  1. Caio Ribeiro Pereira 07/03/2016 at 10:29 #

    Nossa parabéns pelo trabalho! Ficou sensacional o novo site do Alura.
    Uma pergunta, sobre o Server Push, não conheço ainda essa nova feature do HTTP2, e não me ficou claro sobre o que especificamente foi feito para incluir os CSS e fonts dentro do Server Push, para eles serem carregados em paralelo. Esse setup é feito no GAE ou em algum arquivo do projeto?

  2. Sérgio Lopes 07/03/2016 at 10:38 #

    Então, cada Server faz de um jeito, por isso não coloquei o código específico. No GAE você manda um header Link com uma lista de coisas pra fazer preload (no nginx é assim também). Aí ele parseia esse header e manda as coisas com Server Push pra você automaticamente.

    PS. Se abrir o DevTools na aba Network e inspecionar o request da home / dá pra ver o Link lá

  3. Lucas 07/03/2016 at 10:39 #

    Gostei mas quando sairá a atualização total p/ curso de Android?

  4. Diego Candido 07/03/2016 at 10:58 #

    Muito rápido, vou analisar, mas ele está rodando encima de qual plataforma de programação? PHP, Node.js, etc.

  5. Diego Ramos 07/03/2016 at 11:18 #

    Show de bola, sempre mandando bem!

    Grande abraço!

  6. Rafael Ponte 07/03/2016 at 11:21 #

    Excelente, Sergio!

    Sem dúvida você é a maior referência que conheço no assunto, não só pela teoria mas pela aplicabilidade nos sites do Alura, Caelum, blog etc. Parabéns mesmo!

    Se você fosse nomear a principal melhoria qual delas seria?

  7. Talita Pagani 07/03/2016 at 11:22 #

    Um excelente case de sucesso e que mostra que fazer um site otimizado não é um bicho de sete cabeças, parabéns Sérgio e toda a equipe da Alura/Caelum!
    Você falou vários aspectos que concordo e costumo ensinar aos meus alunos: tomar cuidado com a dependência gritante de JavaScript, frameworks e recursos externos. Para nós que somos “velhos” de web, é mais natural a gente usar com cautela estes recursos pois começamos em uma época em que não os tínhamos disponíveis. Como disse um aluno meu, somos “old school”, rsrs. A gente fazia progressive enhancement sem nem saber que era isso (a.k.a. “fazer funcionar no IE 6”). É interessante ver como essa experiência faz a diferença hoje até mesmo para passarmos este conhecimento aos demais colegas.

  8. Lucas N. Munhoz 07/03/2016 at 11:38 #

    Como é feita a reutilização de html nesse caso? Já que não está sendo utilizado nenhum framework JS, como vocês reaproveitam o header em todas as páginas, por exemplo? Ainda existe um template engine por trás?

  9. Sérgio Lopes 07/03/2016 at 11:45 #

    @Diego: PHP!

    Dá uma olhada na nossa arquitetura: http://blog.alura.com.br/a-arquitetura-do-novo-site-do-alura/

  10. Sérgio Lopes 07/03/2016 at 11:47 #

    Valeu, Rafael! 🙂

    O prêmio de prática que causa mais impacto vai para “quase nada de JS e o pouco que tiver deixar 100% assíncrono”.

    Mas o prêmio de “melhoria mais cool e da hora” vai pro Server Push com certeza 😛

  11. Sérgio Lopes 07/03/2016 at 11:48 #

    @Talita: Disse tudo!

    A gente já apanhou tanto de JS no passado que só de ver essas “WebApps modernas” / SPAs / etc de hoje em dia me dá frio na espinha

  12. Sérgio Lopes 07/03/2016 at 11:49 #

    @Lucas: Back-end! E viva a arquitetura tradicional da Web.
    Um bom e velho ‘include’ no cabeçalho em todos os requests.

  13. Marcelo Kanzaki 07/03/2016 at 13:45 #

    Excelente.

    Absurdamente rápido, fácil de navegar e atraente.

    Eu comecei a navegar apenas para conhecer os aspectos técnicos do projeto, mas o conteúdo estava tão atraente e claro que comecei a ler e resolvi assinar.

    Parabéns pelo projeto.

  14. João Mello 07/03/2016 at 15:20 #

    Simplesmente sensacional, nunca li nenhuma explicação tão bem detalhada e mostrando as ferramentas para o sucesso, meus parabéns a equipe.
    Gostei do Server Push, vou estudar mais.

  15. Felipe 07/03/2016 at 15:47 #

    Com o uso do HTTP2, tendo uma conexão TCP entre o cliente o servidor, em teoria vocês não precisariam concatenar é nada, não é? Digo, se quiser mandar os 5000 arquivinhos JS e CSS, deveria funcionar tão bem quanto – ou existe algum limite, tipo a partir de X arquivos a conexão multiplex do HTTP2 já não dá conta?

  16. Victor 07/03/2016 at 20:12 #

    Muito bom.

    Adorei a parte do “arquitetura tradicional”. Gosto muito das novas tecnologias, mas sair usando sem análise do projeto não traz benefício algum.

    Parabéns.

  17. Mário Areias 07/03/2016 at 21:24 #

    Sérgio, tu é o cara pra performance Web. Toda vez que preciso melhorar a performance de algum site, eu procuro teus blog posts. Muito bom 🙂

  18. Augusto Rodrigues 07/03/2016 at 22:46 #

    Show de bola o post Sérgio!
    Parabéns a toda equipe de desenvolvimento, alto nível o site! 🙂

  19. Anderson 08/03/2016 at 00:56 #

    Ficou muito bom!

    Conhece alguma ferramenta para análise de performance, que mantenha histórico e que possa fazer comparações entre os testes?

    E parabéns pelo trabalho!

  20. Sérgio Lopes 08/03/2016 at 10:25 #

    @anderson eu gosto bastante do webpagetest

  21. Rodrigo Rosenfeld Rosas 08/03/2016 at 10:28 #

    O artigo é bom e ficou bem escrito e eu só gostaria de mencionar um detalhe em relação a usar os scripts no header vs no final do body.

    Eu escrevi recentemente uma série de artigos sobre desempenho de aplicações web e muitas das coisas que comento lá aplicam-se basicamente a SPA para os vários casos em que JavaScript não é tão opcional assim…

    Mas, especificamente sobre a questão de carregar no header ou no final do body eu recomendo que ocorra no header justamente porque o download inicia-se antes. Isso é especialmente importante se o tamanho do documento for grande e a banda de conexão for lenta (3G por exemplo). Digamos que em uma conexão lenta leve 2s para terminar de carregar o documento inicial. Isso significa que seu script só vai começar a baixar depois de 2s. Alguns navegadores que ainda não suportam HTTP2 Server Push vão se beneficiar de poder começar a baixar o script o quanto antes e mesmo os mais antigos que não suportam async ainda poderiam beneficiar-se do atributo defer.

    Eu comento sobre várias coisas relacionadas ao desempenho nesses artigos, mas algumas coisas são bem específicas de SPA, onde a aplicação não funciona sem JavaScript:

    http://rosenfeld.herokuapp.com/en/articles/2016-02-29-scripts-loading-trade-offs-a-performance-analysis
    http://rosenfeld.herokuapp.com/en/articles/2016-02-29-getting-an-spa-to-load-the-fastest-possible-way-and-how-webpack-can-help-you
    http://rosenfeld.herokuapp.com/en/articles/2016-02-26-improving-spa-loading-time-with-webpack-and-why-sprockets-is-in-your-way

  22. Rodrigo Rosenfeld Rosas 08/03/2016 at 10:38 #

    Só pra complementar, eu mantenho uma aplicação que precisa de 864KB de JavaScript minificado (286KB gzipped) e ela renderiza a primeira tela informando que está carregando em 680ms e termina de carregar em menos de 2s, acessando do Brasil um servidor em NY e desativando o cache completamente. O usuário que acessou a aplicação mais rapidamente essa semana sem cache levou 1.39s para concluir o carregamento completo da aplicação enquanto que com cache o acesso mais rápido dessa semana foi de 726ms, e esses dados são para o sistema de produção, que ainda não está completamente otimizado quanto a versão do ramo master, que adotou o code splitting que discuto no artigo e reduziu o tamanho do script inicial, além de outras melhorias para cortar algumas bibliotecas por códigos menores…

    Meu ponto é que SPA não deveria ser justificativa para sites lentos.

  23. Sérgio Lopes 08/03/2016 at 12:21 #

    @Rodrigo Excelentes contribuições! Ótimos números seus, e realmente, dá pra otimizar bastante SPAs.

    Sobre o script blocante no head pra iniciar o download logo, duas alternativas seriam: 1) carregar tudo com async; ou 2) deixar o script embaixo mas colocar um preload/prefetch no head (ou num header http).

    De qualquer forma, como o assunto é SPA, geralmente voce quer o comportamento blocante porque não faz sentido renderizar o HTML sem o JS.

  24. Marco Antonio Fassa da Silva 08/03/2016 at 14:50 #

    Top demais galera, estão de parabéns! Parabéns pelo excelente post e conteúdo.

    Uma dúvida, no Google PageSpeed Insights ele da uma msg “Considere corrigir: Eliminar JavaScript e CSS de bloqueio de renderização no conteúdo acima da borda
    “… o quanto isso influencia? É possível resolver? É viável resolver? Na opinião de vcs claro.

    Eng. Marco Antonio Fassa da Silva
    Contele GE – Gestor de Equipes externas
    http://contelege.com.br

  25. Rodrigo Rosenfeld Rosas 08/03/2016 at 15:09 #

    Eu não sugeri usar script bloqueante no head, apenas sugeri mover seu script async para o head pelo motivo que apontei. Na aplicação que eu mantenho é o que faço, todos os scripts são async e nos artigos eu explico como eu faço para aguardar o script vendors ser carregado antes de rodar o código da aplicação, caso seu download seja concluído primeiro…

    Em relação ao truque do preload/prefetch tem o problema que comentei em relação a suporte a navegadores mais antigos se sua aplicação precisar suportar… Além disso, preload é muito recente e há um problema relacionado à prioridade dessas requisições. Veja esse artigo excelente pra você entender melhor porque o http2 server push e o prefetch não são ideais, caso já não tenha lido:

    https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/

    Atualmente eu ainda acho que incluir scripts async no head é o mais indicado…

  26. Sérgio Lopes 08/03/2016 at 15:30 #

    @Marco Ele quer que a gente faça online do CSS no head. É praticamente o mesmo efeito do Server Push. Mas o PageSpeed nao leva em conta ServerPush ainda entao ele que tá ruim quando na verdade ta feito ja.

  27. Sérgio Lopes 08/03/2016 at 15:57 #

    @Rodrigo Perfeito! Script async mata elegantemente. Menos complexo que preload etc.

  28. Wallace Espindola 09/03/2016 at 00:34 #

    Excelente mais uma vez Sérgio! Top performance como sempre! Continue o bom trabalho! Abraço.

  29. Bruno 09/03/2016 at 09:21 #

    Da para construir um WebApp SPA completo com pouquíssimo Js(usando bibliotecas como React.Js problemas de SEO vão embora), não vejo o problema em relação ao uso javascript, desde que seja bem feito.

    Se o usuário precisa realizar três ações para chegar em um determinado ponto de escolha então seu tempo de carregamento(caso o WebApp não seja um SPA) é a soma do tempo de carga de cada um, então nesse ponto o SPA leva uma grande vantagem.

    Em relação a posição do CSS e do Js(no meu caso para SPA) eu coloco o CSS fora da head e espero os arquivos de renderização de Js serem carregados primeiro, essa escolha me fornece tempos de carregamento inferiores a 1 segundo

  30. Diogo Franco 09/03/2016 at 09:31 #

    Parabéns pelo post. Ficou sensacional.

    Utilizo grande parte das soluções apresentadas e elas funcionam muito bem, mesmo. Gostaria de saber se vocês aplicaram alguma otimização para banco de dados. Consulta de informação em tempo real.
    Abraço.

  31. Sérgio Lopes 09/03/2016 at 11:57 #

    @Bruno com certeza da pra fazer SPA performatica. Legais suas dicas.

    E vc tem toda razão quanto ao tempo ser a soma das páginas que ele visita. Por isso colocar cache é essencial. E tbm deixar o código simples pro tempo de execução não ser o gargalo.

    De todos os spas de hj tenho simpatiza do mais com React tbm. Em especial com server side rendering

  32. Sérgio Lopes 09/03/2016 at 11:59 #

    @Diogo Otimizamos o backend sim, o que nos rendeu alguns milissegundos aí na conta. Mas 90% do gargalo da Web hj tá no front e na rede. Focamos aí

  33. Vanderson Assis 09/03/2016 at 14:59 #

    Cara, muito louco e um ótimo aprendizado! Obrigado!

    Offtopic: Coloquem mais conteúdo de desenvolvimento de jogos com Unity no Alura! rs…

  34. Vilmar 10/03/2016 at 12:00 #

    Show de bola, eu odeio JS, mais ainda o JQuery, rsrsrsr 🙂

    Pergunta quer não quer calar, por que o WordPress, ferramenta, a qual tem maioria dos sites construídos, pretende migrar de PHP para Node.js ???

  35. Sérgio Lopes 10/03/2016 at 12:11 #

    @Vilmar To por fora das ultimas fofocas, mas o que tinha visto era só o Admin do WordPress.com, nao?

  36. Vilmar 10/03/2016 at 14:04 #

    Veja:

    WordPress anuncia Migração para Node.js
    http://vilmarbro.com.br/wordpress-anuncia-migracao-para-node-js/

  37. Erick 10/03/2016 at 14:19 #

    Parabéns Sérgio, manja muito de performance!

    Uma dúvida em relação aos svgs, gostaria de saber sua opinião entre utilizar svg inline ou externo. Sei que cada um tem suas vantagens e desvantagens, mas em questão de performance, qual dos dois é melhor? O que você coloca na balança para tomar a decisão de utilizar um ou outro?

    Abs!

  38. Thiago 10/03/2016 at 14:56 #

    Muito bom mesmo, esta bem veloz. Eu só não entendi ainda como faz o Server Push. Meu site já esta com ssl e http2, mas ainda falta melhorar 😀

  39. Sérgio Lopes 10/03/2016 at 15:02 #

    @Erick A grande vantagem do svg inline é poder usar css sem restricoes. Então coisas como mudar cor do icone, fazer animações, hover etc. Ruim é perder cache.

    Boa parte dessas vantagens vc consegue tbm com svg externo mas usando “symbol” e invocando com “use” (com “img” normal nao rola). Foi assim que fizemos no Alura. Tenho um rascunho de post aqui explicando melhor como fazer. Mas por enquanto segue uma referencia bacana: http://nucleoapp.com/how-to-create-an-icon-system-using-svg-symbols/?utm_content=kuku.io&utm_medium=social&utm_source=twitter.com&utm_campaign=kuku.io

  40. Sérgio Lopes 10/03/2016 at 15:17 #

    @Thiago Depende do server. Mas a maioria (GAE, nginx, apache) convencionou que é através de um header Link na resposta. Dá uma olhada no DevTools na aba Network ao abrir o Alura. Procura lá nos headers o Link pra vc ver a ideia.

  41. Thiago 10/03/2016 at 17:59 #

    legal @Sergio, o meu server já é o nginx na versão 1.9.12. Eu até vi esse header link, não achei que fosse algo tão simples de se fazer rs… Vou procurar \o/ Valeu 😀

  42. Thiago 10/03/2016 at 18:36 #

    legal @Sergio… consegui fazer o server push, só não vi ainda como fazer para mais de um css, neste caso!

    Só para confirmar: atualmente tenho o css em um subdominio, com ssl e tudo mais. No html, tenho css no header e alguns no footer. Neste caso do server push, esses que eu coloco no header, não preciso mais coloca-lo neste subdominio né, nem precisaria mais concatená-los, certo?

  43. Sérgio Lopes 10/03/2016 at 18:39 #

    @Thiago Pro server-push funcionar precisa estar no mesmo dominio sim. Pode colocar varios separado por virgula. Sobre concatenar ou não, a ideia é que vc pode ser menos agressivo na concatenacao. Mas mesmo com HTTP/2 nao recomendo importar, sei la, 100 arquivos CSS diferentes. O overhead no browser seria grande. Mas tbm nao precisa ir pra tudo junto num unico arquivo. No Alura a gente quebrou em 10 arquivos diferentes. E as pgs carregam 2 ou 3 por vez apenas.

  44. Gil Marinho 15/03/2016 at 12:20 #

    Sergio, parabéns pelo trabalho!
    Muito interessante a otimização do site da Alura que inclusive, nós aqui da Tipo Publicidade seremos clientes.
    Vamos implementar estas técnicas de front end em nossos site em HTML, CSS e JavaScript focados em SEO aqui da empresa. Entendemos, com sua contribuição é claro, o quão importante é a performance para o usuário e a importância que os buscadores como o Google dá para sites mais ágeis no carregamento e usabilidade. Excelente trabalho com o Alura, faremos igual aqui em nossos próximos cases. Obrigado por compartilhar as técnicas Sergio.

  45. Lázaro Melo 16/03/2016 at 10:26 #

    Tenho também um problema enorme com fontes google, mas tenho que usar, poderia explicar de forma mais ampla como conseguir diminuir esse tempo de resposta das fontes. Muito obrigado e parabéns…

  46. Rafael Menezes 20/03/2016 at 15:31 #

    Um curso de otimização no Alura, forte e com açúcar por favor!

  47. Álvaro Fernando 23/03/2016 at 18:23 #

    Ótimo artigo! Obrigado por compartilhar. Baita aprendizado.

  48. Tiago Celestino 28/03/2016 at 09:35 #

    Tinha salvo há algum tempo esse link: http://www.thedotpost.com/2015/12/rebecca-murphey-http2-is-here-now-lets-make-it-easy – uma apresentação bem interessante sobre o http/2

  49. Thiago 10/11/2016 at 17:01 #

    Sabem quando que o NGINX vai começar a dar suporte ao http2? Porque andei lendo que o nginx-1.10, nginx-1.11 ainda não suportam 🙁

Deixe uma resposta