Replace gzip with Gzip and brotli with Brotli (#1745)

* Replace gzip with Gzip

* Fix typo

src/content/en/2019/http2.md

@@ -34,7 +34,7 @@ The protocol seemed simple, but it also came with limitations. Because HTTP was
 
 That in itself brings its own issues as TCP connections take time and resources to set up and get to full efficiency, especially when using HTTPS, which requires additional steps to set up the encryption. HTTP/1.1 improved this somewhat, allowing reuse of TCP connections for subsequent requests, but still did not solve the parallelization issue.
 
-Despite HTTP being text-based, the reality is that it was rarely used to transport text, at least in its raw format. While it was true that HTTP headers were still text, the payloads themselves often were not. Text files like [HTML](./markup), [JS](./javascript), and [CSS](./css) are usually [compressed](./compression) for transport into a binary format using gzip, brotli, or similar. Non-text files like [images and videos](./media) are served in their own formats. The whole HTTP message is then often wrapped in HTTPS to encrypt the messages for [security](./security) reasons.
+Despite HTTP being text-based, the reality is that it was rarely used to transport text, at least in its raw format. While it was true that HTTP headers were still text, the payloads themselves often were not. Text files like [HTML](./markup), [JS](./javascript), and [CSS](./css) are usually [compressed](./compression) for transport into a binary format using Gzip, Brotli, or similar. Non-text files like [images and videos](./media) are served in their own formats. The whole HTTP message is then often wrapped in HTTPS to encrypt the messages for [security](./security) reasons.
 
 So, the web had basically moved on from text-based transport a long time ago, but HTTP had not. One reason for this stagnation was because it was so difficult to introduce any breaking changes to such a ubiquitous protocol like HTTP (previous efforts had tried and failed). Many routers, firewalls, and other middleboxes understood HTTP and would react badly to major changes to it. Upgrading them all to support a new version was simply not possible.
 

src/content/en/2019/javascript.md

@@ -146,17 +146,17 @@ In the context of browser-server interactions, resource compression refers to co
 
 There are multiple text-compression algorithms, but only two are mostly used for the compression (and decompression) of HTTP network requests:
 
-- [Gzip](https://www.gzip.org/) (gzip): The most widely used compression format for server and client interactions
-- [Brotli](https://github.com/google/brotli) (br): A newer compression algorithm aiming to further improve compression ratios. [90% of browsers](https://caniuse.com/#feat=brotli) support Brotli encoding.
+- [Gzip](https://www.gzip.org/) (`gzip`): The most widely used compression format for server and client interactions
+- [Brotli](https://github.com/google/brotli) (`br`): A newer compression algorithm aiming to further improve compression ratios. [90% of browsers](https://caniuse.com/#feat=brotli) support Brotli encoding.
 
 Compressed scripts will always need to be uncompressed by the browser once transferred. This means its content remains the same and execution times are not optimized whatsoever. Resource compression, however, will always improve download times which also is one of the most expensive stages of JavaScript processing. Ensuring JavaScript files are compressed correctly can be one of the most significant factors in improving site performance.
 
 How many sites are compressing their JavaScript resources?
 
 {{ figure_markup(
   image="fig10.png",
-  caption="Percentage of sites compressing JavaScript resources with gzip or brotli.",
-  description="Bar chart showing 67%/65% of JavaScript resources are compressed with gzip on desktop and mobile respectively, and 15%/14% are compressed using Brotli.",
+  caption="Percentage of sites compressing JavaScript resources with Gzip or Brotli.",
+  description="Bar chart showing 67%/65% of JavaScript resources are compressed with Gzip on desktop and mobile respectively, and 15%/14% are compressed using Brotli.",
   chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTpzDb9HGbdVvin6YPTOmw11qBVGGysltxmH545fUfnqIThAq878F_b-KxUo65IuXaeFVSnlmJ5K1Dm/pubchart?oid=241928028&format=interactive"
   )
 }}

src/content/en/2020/caching.md

@@ -503,7 +503,7 @@ One large source of invalid `Expires` headers is from assets served from a popul
 
 ## The `Vary` header
 
-We have discussed how a caching entity can determine whether a response object is cacheable, and for how long it can be cached. However, one of the most important steps the caching entity must take is determining if the resource being requested is already in its cache. While this may seem simple, many times the URL alone is not enough to determine this. For example, requests with the same URL could vary in what compression they used (gzip, brotli, etc.) or could be returned in different encodings (XML, JSON etc.).
+We have discussed how a caching entity can determine whether a response object is cacheable, and for how long it can be cached. However, one of the most important steps the caching entity must take is determining if the resource being requested is already in its cache. While this may seem simple, many times the URL alone is not enough to determine this. For example, requests with the same URL could vary in what compression they used (Gzip, Brotli, etc.) or could be returned in different encodings (XML, JSON etc.).
 
 To solve this problem, when a caching entity caches an object, it gives the object a unique identifier (a cache key). When it needs to determine whether the object is in its cache, it checks for the existence of the object using the cache key as a lookup. By default, this cache key is simply the URL used to retrieve the object, but servers can tell the caching entity to include other 'attributes' of the response (such as compression method) in the cache key, by including the Vary response header, to ensure that the correct object is subsequently retrieved from cache - the `Vary` header identifies 'variants' of the object, based on factors other than the URL.
 

src/content/es/2019/javascript.md

@@ -146,17 +146,17 @@ En el contexto de las interacciones navegador-servidor, la compresión de recurs
 
 Existen varios algoritmos de compresión de texto, pero solo dos se utilizan principalmente para la compresión (y descompresión) de solicitudes de red HTTP:
 
-- [Gzip](https://www.gzip.org/) (gzip): El formato de compresión más utilizado para las interacciones de servidor y cliente.
-- [Brotli](https://github.com/google/brotli) (br): Un algoritmo de compresión más nuevo que apunta a mejorar aún más las relaciones de compresión. [90% de los navegadores](https://caniuse.com/#feat=brotli) soportan la codificación Brotli.
+- [Gzip](https://www.gzip.org/) (`gzip`): El formato de compresión más utilizado para las interacciones de servidor y cliente.
+- [Brotli](https://github.com/google/brotli) (`br`): Un algoritmo de compresión más nuevo que apunta a mejorar aún más las relaciones de compresión. [90% de los navegadores](https://caniuse.com/#feat=brotli) soportan la codificación Brotli.
 
 Los scripts comprimidos siempre deberán ser descomprimidos por el navegador una vez transferidos. Esto significa que su contenido sigue siendo el mismo y los tiempos de ejecución no están optimizados en absoluto. Sin embargo, la compresión de recursos siempre mejorará los tiempos de descarga, que también es una de las etapas más caras del procesamiento de JavaScript. Asegurarse de que los archivos JavaScript se comprimen correctamente puede ser uno de los factores más importantes para mejorar el rendimiento del sitio.
 
 **¿Cuántos sitios están comprimiendo sus recursos de JavaScript?**
 
 {{ figure_markup(
   image="fig10.png",
-  caption="Porcentaje de sitios que comprimen recursos de JavaScript con gzip o brotli.",
-  description="Gráfico de barras que muestra el 67% / 65% de los recursos de JavaScript se comprime con gzip en computadoras de escritorio y dispositivos móviles respectivamente, y el 15% / 14% se comprime con Brotli.",
+  caption="Porcentaje de sitios que comprimen recursos de JavaScript con Gzip o Brotli.",
+  description="Gráfico de barras que muestra el 67% / 65% de los recursos de JavaScript se comprime con Gzip en computadoras de escritorio y dispositivos móviles respectivamente, y el 15% / 14% se comprime con Brotli.",
   chart_url="https://docs.google.com/spreadsheets/d/e/2PACX-1vTpzDb9HGbdVvin6YPTOmw11qBVGGysltxmH545fUfnqIThAq878F_b-KxUo65IuXaeFVSnlmJ5K1Dm/pubchart?oid=241928028&format=interactive"
   )
 }}

src/content/fr/2019/caching.md

@@ -542,7 +542,7 @@ La plus grande source d'en-têtes `Expires` invalides provient de ressources ser
 
 ## En-tête `Vary`
 
-L'une des étapes les plus importantes de la mise en cache est de déterminer si la ressource demandée est mise en cache ou non. Bien que cela puisse paraître simple, il arrive souvent que l'URL seule ne suffise pas à le déterminer. Par exemple, les requêtes ayant la même URL peuvent varier en fonction de la [compression](./compression) utilisée (gzip, brotli, etc.) ou être modifiées et adaptées aux visiteurs mobiles.
+L'une des étapes les plus importantes de la mise en cache est de déterminer si la ressource demandée est mise en cache ou non. Bien que cela puisse paraître simple, il arrive souvent que l'URL seule ne suffise pas à le déterminer. Par exemple, les requêtes ayant la même URL peuvent varier en fonction de la [compression](./compression) utilisée (Gzip, Brotli, etc.) ou être modifiées et adaptées aux visiteurs mobiles.
 
 Pour résoudre ce problème, les clients donnent à chaque ressource mise en cache un identifiant unique (une clé de cache). Par défaut, cette clé de cache est simplement l'URL de la ressource, mais les développeurs et développeuses peuvent ajouter d'autres éléments (comme la méthode de compression) en utilisant l'en-tête `Vary`.