path: root/files/pt-br/web/http/caching/index.html

---
title: Cacheamento HTTP
slug: Web/HTTP/Caching
tags:
  - Cache
  - Cacheamento
  - Guía
  - HTTP
  - Internet
  - Rede
  - Web
translation_of: Web/HTTP/Caching
original_slug: Web/HTTP/HTTP
---
<div>{{HTTPSidebar}}</div>

<p class="summary">A performance de websites e aplicações podem ser melhoradas significativamente ao reusar recursos previamente buscados. Caches em web reduzem latência e o tráfego de rede e assim diminuir o tempo necesário para exibir uma representação do recurso. Ao usar <em>caching </em>em HTTP, websites se tornam mais responsivos.</p>

<h2 id="Diferentes_tipos_de_caches">Diferentes tipos de <em>caches</em></h2>

<p><em>Caching</em> é uma técnica que guarda uma cópia de dado recurso e mostra de volta quando requisitado. Quando um web cache tem um recurso requerido em seu armazenamento, ele intercepta a solicitação e retorna sua cópia ao invés de fazer o download novamente do servidor original. Isto alcança vários objetivos: facilita o balanceamento do servidor que não precisa servir todos os <em>clients</em> sozinho, e melhora a performance por estar próximo do <em>client</em>,  por exemplo, ele leva menos tempo para transmitir o recurso de volta. Para um website, é um componente principal para alcançar alta performance. De outro lado, ele deve ser configurado devidamente pois não são todos os recursos que ficam idênticos para sempre: é importante colocar um recurso em cache somente até que ele mude, não mais que isso. </p>

<p>Há muitos tipos de caches: estes podem ser agrupados em duas categorias principais, caches privados ou compartilhados. Um <em>cache compartilhado</em> é um cache que armazena respostas para serem reusadas por mais de um usuário. Um <em>cache privado</em> é dedicado a um único usuário. Esta página irá falar principalmente sobre caches em navegadores e em <em>proxy</em>, mas há também caches de <em>gateway</em>, CDN, cache de proxy reverso e balanceadores de carga (<em>load balancers)</em> que são implantados em servers da web para melhor confiabilidade, desempenho e dimensionamento de sites e aplicativos da web.</p>

<p><img alt="What a cache provide, advantages/disadvantages of shared/private caches." src="/en-US/docs/Web/HTTP/Caching/http_cache_type.png" style="height: 573px; width: 910px;"></p>

<h3 id="Caches_privados_de_browser">Caches privados de browser</h3>

<p>Um cache privado é dedicado para um único usuário. Você já pode ter visto <em>"caching"</em> nas configurações de seu navegador. Um cache de browser guarda todos os documentos que foram baixados via <a href="/pt-BR/docs/Web/HTTP" title="en/HTTP">HTTP</a> pelo usuário. Este cache é usado para tornar disponíveis documentos visitados para navegação "para frente e para trás" (ou <em>back/forward</em>, em Inglês<em>)</em>, salvar, ver como fonte, etc. sem exigir uma viagem para o servidor. Também melhora a navegação offline de conteúdo em cache.</p>

<h3 id="Caches_de_proxy_compartilhada">Caches de proxy compartilhada</h3>

<p>Uma cache compartilhada é uma cache que armazena respostas para serem reusadas por mais de um usuário. Por exemplo, um fornecedor de acesso à internet ou sua empresa pode ter definido uma web proxy como parte de sua infraestrutura de rede local para servir muitos usuários para que recursos populares sejam reusados numerosas vezes, reduzindo o tráfego de rede e latência.</p>

<h2 id="Alvos_de_operações_de_cache">Alvos de operações de cache</h2>

<p>Fazer cache de HTTP é opcional, mas reusar um recurso em cache é usualmente desejável. No entanto, caches HTTP comuns são tipicamente limitados a respostas em cache para {{HTTPMethod("GET")}} e podem declinar outros métodos. As chaves primárias de cache consistem de um método de requisição e um alvo URI (como requisições são alvos de cache, muitas vezes somente o URI é usado). Formas comuns de entrada de cache são:</p>

<ul>
 <li>Resultados bem sucedidos de uma requisição: uma resposta {{HTTPStatus(200)}} (OK) para uma requisição {{HTTPMethod("GET")}} contendo recursos como documentos HTML, imagens ou arquivos.</li>
 <li>Redirecionamentos permanentes: uma resposta {{HTTPStatus(301)}} (Moved Permanently).</li>
 <li>Respostas de erro: um resultado {{HTTPStatus(404)}} (Not Found).</li>
 <li>Resultados incompletos: uma resposta {{HTTPStatus(206)}} (Partial Content).</li>
 <li>Outras respostas que não sejam {{HTTPMethod("GET")}} se algo mais adequado para uso como chave de cache é definido.</li>
</ul>

<p>Uma entrada de cache pode também consistir de múltiplas respostas armazenadas diferenciadas por uma chave secundária, se a requisição é alvo de negociação de conteúdo. Para mais detalhes veja a informação sobre o cabeçalho {{HTTPHeader("Vary")}} abaixo.</p>

<h2 id="Controlando_cache">Controlando cache</h2>

<h3 id="O_cabeçalho_Cache-control">O cabeçalho <code>Cache-control</code></h3>

<p>O cabeçalho-geral {{HTTPHeader("Cache-Control")}} HTTP/1.1 é usado para especificar diretivas para mecanismos de cache em ambas requisições e respostas. Use este cabeçalho para definir suas políticas de cache com a variedade de diretivas que fornece.</p>

<h4 id="Não_usar_armazenamento_de_cache">Não usar armazenamento de cache</h4>

<p>O cache não deve armazenar nada sobre a requisição do cliente ou a resposta do servidor. Uma requisição é enviada ao servidor e uma resposta completa é baixada por cada e toda vez.</p>

<pre>Cache-Control: no-store
Cache-Control: no-cache, no-store, must-revalidate
</pre>

<h4 id="Sem_fazer_cache">Sem fazer cache</h4>

<p>Um cache irá enviar a requisição ao servidor de origem para validação antes de liberar uma cópia em cache. </p>

<pre>Cache-Control: no-cache</pre>

<h4 id="Caches_privados_e_públicos">Caches privados e públicos</h4>

<p>A diretiva "public" indica que a resposta pode ser colocada em cache por qualquer cache. Isto pode ser útil, se páginas com autenticação HTTP ou códigos de status de resposta que não são normalmente colocadas em cache, devem agora ser colocadas. Por outro lado, "private" indica que a resposta é para um único usuário somente e não deve ser armazenada por um cache compartilhado. Um cache privado de navegador pode armazenar a resposta neste caso.</p>

<pre>Cache-Control: private
Cache-Control: public
</pre>

<h4 id="Data_de_validade">Data de validade</h4>

<p>A diretiva mais importante aqui é "<code>max-age=&lt;seconds&gt;</code>" que é a quantidade máxima de tempo que um recurso será considerado "fresco". Contrário ao {{HTTPHeader("Expires")}}, esta diretiva é relativa ao tempo da requisição. Para os arquivos na aplicação que não irão mudar, você pode normalmente adicionar cache agressivamente. Isto inclui arquivos estáticos como imagens, arquivos CSS e Javascript, por exemplo.</p>

<p>Para mais detalhes, veja também a seção <a href="#">Tempo de Vida </a>abaixo.</p>

<pre>Cache-Control: max-age=31536000</pre>

<h4 id="Validação">Validação</h4>

<p>Quando usamos a diretiva "<code>must-revalidate</code>", o cache deve verificar o status dos recursos obsoletos antes de os usar e os expirados não deverão ser usados. Para mais detalhes, veja a seção <a href="#Cache_validation">Validation</a> abaixo.</p>

<pre>Cache-Control: must-revalidate</pre>

<h3 id="O_header_Pragma">O header <code>Pragma</code></h3>

<p>{{HTTPHeader("Pragma")}} é um header HTTP/1.0, não é especificado para respostas HTTP e não é, assim, uma reposição confiável para o cabeçalho geral HTTP/1.1 <code>Cache-Control</code>, apesar de se comportar da mesma forma que <code>Cache-Control: no-cache</code>, se o campo do cabeçalho <code>Cache-Control</code> é omitido em uma requisição.Use <code>Pragma</code> somente para compatibilidade com clients HTTP/1.0 mais antigos</p>

<h2 id="Tempo_de_Vida">Tempo de Vida</h2>

<p>Quando um recurso é armazenado em um cache, ele poderia teoricamente ser servido para sempre. Caches possuem armazenamento finito então itens são periodicamente removidos do armazenamento. <span id="result_box" lang="pt"><span>Esse processo é chamado de <em>despejo de cache</em>.</span> <span>Por outro lado, alguns recursos podem mudar no servidor fazendo com que o cache fique desatualizado.</span> <span>Como o HTTP é um protocolo cliente-servidor, os servidores não podem contatar caches e clientes quando um recurso é alterado;</span> <span>eles precisam comunicar um tempo de expiração para o recurso.</span> <span>Antes deste período de expiração, o recurso é novo;</span> <span>após o tempo de expiração, o recurso é obsoleto.</span> <span>Os algoritmos de despejo geralmente privilegiam recursos novos em vez de recursos obsoletos.</span> <span>Observe que um recurso obsoleto não é despejado ou ignorado;</span> <span>quando o cache recebe uma solicitação para um recurso obsoleto, ele encaminha essa solicitação com um {{HTTPHeader ("If-None-Match")}} para verificar se, de fato, ainda está <em>fresco</em>.</span> <span>Em caso afirmativo, o servidor retorna um cabeçalho {{HTTPStatus ("304")}} (Não modificado) sem enviar o corpo do recurso solicitado, economizando alguma largura de banda.</span></span></p>

<p>Here is an example of this process with a shared cache proxy:</p>

<p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="https://mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="height: 910px; width: 822px;"></p>

<p>O tempo de Vida é calculado beaseado em vários headers. Se o "<code>Cache-control: max-age=N</code>" header é especificado, então o tempo de vida é igual a N. Se este header não está presente, o que ocorre com frequência, ele checa se um {{HTTPHeader("Expires")}} header está presente. Se um <code>Expires</code> header existe, então é o valor menos o valor do {{HTTPHeader("Date")}} header determina o tempo de vida. Finalmente, se nenhum header está presente, procure pelo {{HTTPHeader("Last-Modified")}} header. Se este header está presente, então o tempo de vidaé igual ao valor do  <code>Date</code> header menos o valor do <code>Last-modified</code> header dividido por 10.<br>
 O valor de expiração é computado por:</p>

<pre>expirationTime = responseTime + freshnessLifetime - currentAge
</pre>

<p>No qual <code>responseTime</code>é o tempo em que a resposta é recebida de acordo com o navegador.</p>

<h3 id="Revved_resources">Revved resources</h3>

<p>The more we use cached resources, the better the responsiveness and the performance of a Web site will be. To optimize this, good practices recommend to set expiration times as far in the future as possible. This is possible on resources that are regularly updated, or often, but is problematic for resources that are rarely and infrequently updated. They are the resources that would benefit the most from caching resources, yet this makes them very difficult to update. This is typical of the technical resources included and linked from each Web pages: JavaScript and CSS files change infrequently, but when they change you want them to be updated quickly.</p>

<p>Web developers invented a technique that Steve Souders called <em>revving</em><sup><a href="https://www.stevesouders.com/blog/2008/08/23/revving-filenames-dont-use-querystring/">[1]</a></sup>. Infrequently updated files are named in specific way: in their URL, usually in the filename, a revision (or version) number is added. That way each new revision of this resource is considered as a resource on its own that <em>never</em> changes and that can have an expiration time very far in the future, usually one year or even more. In order to have the new versions, all the links to them must be changed, that is the drawback of this method: additional complexity that is usually taken care of by the tool chain used by Web developers. When the infrequently variable resources change they induce an additional change to often variable resources. When these are read, the new versions of the others are also read.</p>

<p>This technique has an additional benefit: updating two cached resources at the same time will not lead to the situation where the out-dated version of one resource is used in combination with the new version of the other one. This is very important when web sites have CSS stylesheets or JS scripts that have mutual dependencies, i.e., they depend on each other because they refer to the same HTML elements.</p>

<p><img alt="" src="https://mdn.mozillademos.org/files/13779/HTTPRevved.png"></p>

<p>The revision version added to revved resources doesn't need to be a classical revision string like 1.1.3, or even a monotonously growing suite of number. It can be anything that prevent collisions, like a hash or a date.</p>

<h2 id="Cache_validation">Cache validation</h2>

<p>Revalidation is triggered when the user presses the reload button. It is also triggered under normal browsing if the cached response includes the "<code>Cache-control: must-revalidate</code>" header. Another factor is the cache validation preferences in the <code>Advanced-&gt;Cache</code> preferences panel. There is an option to force a validation each time a document is loaded.</p>

<p>When a cached document's expiration time has been reached, it is either validated or fetched again. Validation can only occur if the server provided either a <em>strong validator</em> or a <em>weak validator</em>.</p>

<h3 id="ETags">ETags</h3>

<p>The {{HTTPHeader("ETag")}} response header is an <em>opaque-to-the-useragent</em> value that can be used as a strong validator. That means that a HTTP user-agent, such as the browser, does not know what this string represents and can't predict what its value would be. If the <code>ETag</code> header was part of the response for a resource, the client can issue an {{HTTPHeader("If-None-Match")}} in the header of future requests – in order to validate the cached resource.</p>

<p>The {{HTTPHeader("Last-Modified")}} response header can be used as a weak validator. It is considered weak because it only has 1-second resolution. If the <code>Last-Modified</code> header is present in a response, then the client can issue an {{HTTPHeader("If-Modified-Since")}} request header to validate the cached document.</p>

<p>When a validation request is made, the server can either ignore the validation request and response with a normal {{HTTPStatus(200)}} <code>OK</code>, or it can return {{HTTPStatus(304)}} <code>Not Modified</code> (with an empty body) to instruct the browser to use its cached copy. The latter response can also include headers that update the expiration time of the cached document.</p>

<h2 id="Varying_responses">Varying responses</h2>

<p>The {{HTTPHeader("Vary")}} HTTP response header determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.</p>

<p>When a cache receives a request that can be satisfied by a cached response that has a <code>Vary</code> header field, it must not use that cached response unless all header fields as nominated by the <code>Vary</code> header match in both the original (cached) request and the new request.</p>

<p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="https://mdn.mozillademos.org/files/13769/HTTPVary.png" style="height: 817px; width: 752px;"></p>

<p>This can be useful for serving content dynamically, for example. When using the <code>Vary: User-Agent</code> header, caching servers should consider the user agent when deciding whether to serve the page from cache. If you are serving different content to mobile users, it can help you to avoid that a cache may mistakenly serve a desktop version of your site to your mobile users. In addition, it can help Google and other search engines to discover the mobile version of a page, and might also tell them that no <a href="https://en.wikipedia.org/wiki/Cloaking">Cloaking</a> is intended.</p>

<pre>Vary: User-Agent</pre>

<p>Because the {{HTTPHeader("User-Agent")}} header value is different ("varies") for mobile and desktop clients, caches will not be used to serve mobile content mistakenly to desktop users or vice versa.</p>

<h2 id="See_also">See also</h2>

<ul>
 <li><a href="https://tools.ietf.org/html/rfc7234">RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching</a></li>
 <li><a href="https://www.mnot.net/cache_docs">Caching Tutorial – Mark Nottingham</a></li>
 <li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching">HTTP caching – Ilya Grigorik</a></li>
 <li><a href="https://redbot.org/">RedBot</a>, a tool to check your cache-related HTTP headers.</li>
</ul>