Merge pull request zenorocha#296 from zenorocha/http2

Considering HTTP/2 changes in some rules

src/documents/css/en/combine-css.html.md

@@ -27,4 +27,6 @@ So combine your CSS. Having a smaller number of files will result in a smaller n
 
 Want to have the best of both worlds? Automate this process through a build tool.
 
+It's good to have in mind that the cost of new requests is much cheaper with HTTP/2. Maybe you shouldn't concatenate all your CSS files in a sigle one. It doesn't mean that we should use hundreds of different files. Requests still have a cost. But it's worth measuring the impact of having a few separated files instead of a single one. We get better modularity, cache independency and a simpler build process.
+
 *> [Useful tools](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-combining-multiple-css-files) / [References](https://github.com/zenorocha/browser-diet/wiki/References#combining-multiple-css-files)*

src/documents/css/en/prefer-link-over-import.html.md

@@ -17,4 +17,6 @@ Or through the `@import` directive (inside an external stylesheet or in an inlin
 
 When you use the second option through an external stylesheet, the browser is incapable of downloading the asset in parallel, which can block the download of other assets.
 
+When using HTTP/2, this delay on the second file download can bem mitigated using *server push*. It's possible to push the file referenced in `@import` right after the original response, avoiding the blocking behavior. Still, if you can, avoid `@import` for simplicity.
+
 *> [References](https://github.com/zenorocha/browser-diet/wiki/References#prefer--over-import)*

src/documents/css/pt/combine-css.html.md

@@ -27,4 +27,6 @@ Logo, combine seu CSS. Quanto menor for o número de arquivos, menor será o nú
 
 Quer ter o melhor dos dois mundos? Automatize esse processo através de uma ferramenta de build.
 
+É bom ter em mente também que o custo dos requests cai bastante no novo HTTP/2. Talvez não seja necessário concatenar tanto os arquivos CSS. Não quer dizer que usar centenas de arquivos seja uma boa ideia, afinal os requests ainda têm um custo. Mas vale a pena medir se ter alguns poucos arquivos separados já não é suficiente, ao invés de concatenar tudo em um só. As vantagens são melhor modularidade, independência de cache e simplificar o build.
+
 *> [Ferramentas úteis](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-combining-multiple-css-files) / [Referências](https://github.com/zenorocha/browser-diet/wiki/References#combining-multiple-css-files)*

src/documents/css/pt/prefer-link-over-import.html.md

@@ -17,4 +17,6 @@ Ou da propriedade `@import` dentro de uma folha de estilo externa ou inline em u
 
 Quando você utiliza a segunda opção a partir de uma folha de estilo externa, o navegador é incapaz de realizar o download em paralelo, o que causa atraso na cascata de carregamento dos arquivos.
 
+Se já estiver usando HTTP/2, esse atraso no segundo download pode ser mitigado com uso do *server push*. É possível enviar esse arquivo referenciado no `@import` junto com a resposta do request original, evitando o carregamento cascata. Ainda assim, se puder, evite o `@import` por simplicidade.
+
 *> [Referências](https://github.com/zenorocha/browser-diet/wiki/References#prefer--over-import)*

src/documents/html/en/avoid-inline.html.md

@@ -13,6 +13,8 @@ There are three basic ways for you to include CSS or JavaScript on your page:
 
 The first two options, despite reducing the number of HTTP requests, actually increase the size of your HTML document. But this can be useful when you have small assets and the cost of making a request is greater. In this case, run tests to evaluate if there's any actual gains in speed. Also be sure to evaluate the purpose of your page and its audience: if you expect people to only visit it once, for example for some temporary campaign where you never expect return visitors, inlining/embedded code will help in reducing the number of HTTP requests.
 
+In HTTP/2, it's possible to use a new feature called *server push* to force specific files to be pushed directly to the client right after the initial HTML response without inlining. It has the same advantage as embedding a resource without its problems. If you already uses HTTP/2 consider using *server push*.
+
 *> Avoid manually authoring CSS/JS in the middle of your HTML (automating this process with tools is preferred).*
 
 The third option not only improves the organization of your code, but also makes it possible for the browser to cache it. This option should be preferred for the majority of cases, especially when working with large files and lots of pages.

src/documents/html/pt/avoid-inline.html.md

@@ -13,6 +13,8 @@ Existem três formas básicas de você lidar com CSS e Javascript:
 
 As duas primeiras opções, apesar de reduzirem o número de requisições, aumentam o tamanho do documento HTML. Elas podem ser interessante quando você tem arquivos pequenos e o custo de uma requisição é maior. Nesse caso, faça testes para avaliar se há realmente ganho. Avalie também o objetivo da página e sua audiência, se o esperado é que usuários visitem essa página somente uma única vez, como por exemplo uma campanha temporária onde não se espera futuras visitas à mesma, utilizar inline/incorporado ajudará na redução do número de requisições.
 
+Com HTTP/2, é possível usar o recurso *server push* para forçar o envio de determinado arquivo junto com o HTML inicial sem precisar de inline. Na prática tem a mesma vantagem do inline sem suas desvantagens. Se já estiver usando HTTP/2 avalie essa opção.
+
 *> Evite escrever manualmente o CSS/JS no meio do HTML (use uma ferramenta que automatize esse processo).*
 
 Já a terceira opção, não só melhora a organização do seu código, como também possibilita que eles sejam armazenados no cache do navegador. Prefira essa opção para a maior parte dos casos, quando lidamos com arquivos grandes e muitas páginas.

src/documents/images/en/data-uri.html.md

@@ -27,4 +27,6 @@ Both this method and the CSS spriting method require build time tools to be main
 
 However has the disadvantage of growing the size of your HTML/CSS considerably if you have large images. It is not recommended to use this method if you aren't gzipping your HTML/CSS during HTTP requests as the size overhead might negate the speed gains you get from minimizing the number of HTTP requests.
 
+In HTTP/2, it's possible to use a new feature called *server push* to force specific files to be pushed directly to the client right after the initial response without inlining the data URI value. It has the same advantage as embedding a resource without its problems. If you already uses HTTP/2 consider using *server push*.
+
 *> [Useful tools](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-data-uri) / [References](https://github.com/zenorocha/browser-diet/wiki/References#data-uri)*

src/documents/images/en/sprites.html.md

@@ -27,4 +27,6 @@ When using your *sprite*, avoid leaving too much white space between images. Thi
 
 And despite nearly everyone knowing about sprites, this technique isn't widely used—perhaps due to developers not using automated tools to generate sprites. We've highlighted a few that can help you out with this.
 
+It's good to have in mind that the cost of new requests is much cheaper with HTTP/2. Maybe you shouldn't group all your images in a single sprite. It doesn't mean that we should use hundreds of different files. Requests still have a cost. But it's worth measuring the impact of having a few separated files instead of a single one. We get better modularity, cache independency and a simpler build process.
+
 *> [Useful tools](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-use-css-sprites) / [References](https://github.com/zenorocha/browser-diet/wiki/References#use-css-sprites)*

src/documents/images/pt/data-uri.html.md

@@ -27,4 +27,6 @@ Ambos esse método e CSS sprites precisam de ferramentas de build para serem de
 
 Entretanto tem a desvantagem de aumentar consideravelmente o tamanho do seu HTML/CSS se você possuir imagens grandes. Não é recomendado utilizar esse método se você não está utilizando a técnica de gzip no seu HTML/CSS durante as requisições HTTP já que a sobrecarga de tamanho pode anular os ganhos de velocidade sobre minimizar o número de requisições HTTP.
 
+Com HTTP/2, é possível usar o recurso *server push* para forçar o envio de determinado arquivo junto com o request inicial sem precisar de embuti-lo com data URIs inline. Na prática tem a mesma vantagem do inline sem suas desvantagens. Se já estiver usando HTTP/2 avalie essa opção.
+
 *> [Ferramentas úteis](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-data-uri) / [Referências](https://github.com/zenorocha/browser-diet/wiki/References#data-uri)*

src/documents/images/pt/sprites.html.md

@@ -27,4 +27,6 @@ Ao montar seu *sprite*, evite deixar muito espaço em branco entre as imagens, i
 
 Apesar de extremamente difundida, essa técnica é pouco usada já que os desenvolvedores não utilizam ferramentas que automatizam o processo de geração dessa imagem. Por isso, separamos algumas que podem te ajudar nisso.
 
+É bom ter em mente também que o custo dos requests cai bastante no novo HTTP/2. Talvez não seja necessário se preocupar tanto com sprites. Não quer dizer que usar centenas de arquivos seja uma boa ideia, afinal os requests ainda têm um custo. Mas vale a pena medir se ter alguns poucos arquivos separados já não é suficiente. As vantagens são melhor modularidade, independência de cache e simplificar o build.
+
 *> [Ferramentas úteis](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-use-css-sprites) / [Referências](https://github.com/zenorocha/browser-diet/wiki/References#use-css-sprites)*

src/documents/js/en/combine-js.html.md

@@ -27,4 +27,6 @@ So combine your JS. Having a smaller number of files will result in a smaller nu
 
 Want to have the best of both worlds? Automate this process through a build tool.
 
+It's good to have in mind that the cost of new requests is much cheaper with HTTP/2. Maybe you shouldn't concatenate all your JS files in a sigle one. It doesn't mean that we should use hundreds of different files. Requests still have a cost. But it's worth measuring the impact of having a few separated files instead of a single one. We get better modularity, cache independency and a simpler build process. And if you load them all asynchronously the code is executed faster, as soon as the responses arrive.
+
 *> [Useful tools](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-combine-multiple-js-files-into-one) / [References](https://github.com/zenorocha/browser-diet/wiki/References#combine-multiple-js-files-into-one)*

src/documents/js/pt/combine-js.html.md

@@ -27,4 +27,6 @@ Logo, combine seu JS. Quanto menor for o número de arquivos, menor será o núm
 
 Quer ter o melhor dos dois mundos? Automatize esse processo através de uma ferramenta de build.
 
+É bom ter em mente também que o custo dos requests cai bastante no novo HTTP/2. Talvez não seja necessário concatenar tanto os arquivos JS. Não quer dizer que usar centenas de arquivos seja uma boa ideia, afinal os requests ainda têm um custo. Mas vale a pena medir se ter alguns poucos arquivos separados já não é suficiente, ao invés de concatenar tudo em um só. As vantagens são melhor modularidade, independência de cache e simplificar o build. E se você carregá-los assincronamente, o código é executado mais rapidamente, conforme as respostas forem chegando.
+
 *> [Ferramentas úteis](https://github.com/zenorocha/browser-diet/wiki/Tools#wiki-combine-multiple-js-files-into-one) / [Referências](https://github.com/zenorocha/browser-diet/wiki/References#combine-multiple-js-files-into-one)*