{"id":20746,"date":"2026-08-17T18:25:40","date_gmt":"2026-08-17T16:25:40","guid":{"rendered":"https:\/\/webhosting.de\/http-cache-control-header-richtig-einsetzen-web-optimierung\/"},"modified":"2026-08-17T18:25:40","modified_gmt":"2026-08-17T16:25:40","slug":"utilizacao-correta-do-cabecalho-cache-control-do-http-otimizacao-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/http-cache-control-header-richtig-einsetzen-web-optimierung\/","title":{"rendered":"Utilizar corretamente o cabe\u00e7alho HTTP Cache-Control para uma otimiza\u00e7\u00e3o eficiente da Web"},"content":{"rendered":"<p>Vou mostrar-te como configurar o cabe\u00e7alho HTTP <strong>Controlo da cache<\/strong> utiliza de forma espec\u00edfica para reduzir os tempos de carregamento, poupar pedidos e gerir de forma eficaz as caches dos navegadores. Receber\u00e1s orienta\u00e7\u00f5es claras, combina\u00e7\u00f5es \u00fateis e configura\u00e7\u00f5es pr\u00e1ticas para HTML, CSS, JS, imagens e APIs \u2013 sem ter de adivinhar, mas com <strong>concretos<\/strong> Passos.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Os seguintes aspetos fundamentais v\u00e3o certamente conduzir-te a uma r\u00e1pida e <strong>fi\u00e1vel<\/strong> Estrat\u00e9gia de cache.<\/p>\n<ul>\n  <li><strong>idade m\u00e1xima<\/strong> como temporizador: controla o tempo de conserva\u00e7\u00e3o em segundos<\/li>\n  <li><strong>p\u00fablico\/privado<\/strong>: determina quem pode armazenar em cache<\/li>\n  <li><strong>sem cache<\/strong> vs. <strong>n\u00e3o armazenar<\/strong>: revalidar em vez de proibir<\/li>\n  <li><strong>ETag<\/strong> e <strong>\u00daltima modifica\u00e7\u00e3o<\/strong>: As chamadas condicionadas poupam dados<\/li>\n  <li><strong>Versionamento<\/strong> + <strong>imut\u00e1vel<\/strong>: caches longas sem res\u00edduos<\/li>\n<\/ul>\n\n<h2>No\u00e7\u00f5es b\u00e1sicas: Qual \u00e9 a fun\u00e7\u00e3o do cabe\u00e7alho Cache-Control?<\/h2>\n<p>O cabe\u00e7alho cont\u00e9m instru\u00e7\u00f5es que determinam se, durante quanto tempo e por quem uma resposta no <strong>Cache<\/strong> pode estar. Nesse contexto, fa\u00e7o a distin\u00e7\u00e3o entre as caches do cliente no navegador e as caches partilhadas, como proxies ou CDNs, que frequentemente servem v\u00e1rios utilizadores e, por isso, proporcionam <strong>Efici\u00eancia<\/strong> Enquanto o cabe\u00e7alho \u201eExpires\u201c, j\u00e1 desatualizado, funciona com uma data, no \u00abCache-Control\u00bb utilizo intervalos de tempo relativos atrav\u00e9s do \u00abmax-age\u00bb, o que \u00e9 menos propenso a erros. Desta forma, determino durante quanto tempo um recurso permanece \u00abatualizado\u00bb e se deve ser revalidado antes de ser utilizado. Desta forma, mantenho a possibilidade de controlar conte\u00fados din\u00e2micos e de manter ficheiros est\u00e1ticos armazenados localmente durante muito tempo.<\/p>\n<p>O Cache-Control aplica-se tanto \u00e0s respostas como aos pedidos, o que me \u00e9 \u00fatil para a revalida\u00e7\u00e3o, por exemplo, em conjunto com o ETag ou o Last-Modified para <strong>Condicional<\/strong> Solicita\u00e7\u00f5es. Por exemplo, defino valores agressivos para recursos inalterados e regras cautelosas para HTML. Esta separa\u00e7\u00e3o garante que as chamadas subsequentes sejam, na medida do poss\u00edvel, obtidas a partir da cache do navegador e, assim, a <strong>Carga do servidor<\/strong> diminui. \u00c9 importante uma coordena\u00e7\u00e3o bem planeada, para que eu n\u00e3o bloqueie recursos involuntariamente nem os deixe expirar demasiado cedo. Quem tiver em conta estes princ\u00edpios fundamentais est\u00e1 a estabelecer as bases para tempos de carregamento curtos e regras claras no comportamento da cache.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/weboptimierung-cachecontrol-4732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diretivas importantes explicadas de forma compreens\u00edvel<\/h2>\n<p>Com <strong>idade m\u00e1xima<\/strong> Defino o tempo de vida de um recurso em segundos, a contar a partir da data de entrega. Para imagens, CSS, JS e tipos de letra, costumo escolher 31536000 (um ano), para que as visitas repetidas utilizem quase tudo localmente. Para as p\u00e1ginas HTML, defino um per\u00edodo mais curto, cerca de 300 segundos, ou combino-as com a revalida\u00e7\u00e3o, para que as altera\u00e7\u00f5es fiquem vis\u00edveis rapidamente. Um per\u00edodo de validade longo sem versionamento de ficheiros leva facilmente \u00e0 presen\u00e7a de vers\u00f5es antigas na cache; por isso, altero os nomes dos ficheiros em cada lan\u00e7amento. Desta forma, combino uma atualiza\u00e7\u00e3o rigorosa com <strong>elevado<\/strong> Taxa de acertos na cache.<\/p>\n<p>As diretivas <strong>p\u00fablico<\/strong> e <strong>privado<\/strong> controlar quem pode armazenar em cache. Defino como \u00abP\u00fablico\u00bb para conte\u00fados sem personaliza\u00e7\u00e3o, para que tamb\u00e9m os proxies e as CDNs os armazenem em cache. Defino como \u00abPrivado\u00bb quando pretendo que apenas o navegador do utilizador mantenha uma c\u00f3pia, por exemplo, nas p\u00e1ginas de conta. Desta forma, evito que os dados pessoais acabem em caches partilhados e ali <strong>dar errado<\/strong>. Esta distin\u00e7\u00e3o evita problemas e protege as informa\u00e7\u00f5es confidenciais.<\/p>\n<p><strong>sem cache<\/strong> \u00e9 frequentemente mal interpretado: n\u00e3o pro\u00edbe o armazenamento, mas exige uma revalida\u00e7\u00e3o junto do servidor antes de uma nova utiliza\u00e7\u00e3o. Isto \u00e9 adequado para conte\u00fados que mudam regularmente, sem terem de ser recarregados na \u00edntegra a cada acesso. Com o ETag ou o Last-Modified, o cliente mant\u00e9m os dados localmente e apenas verifica se estes ainda est\u00e3o atualizados. Desta forma, evito bytes desnecess\u00e1rios e, mesmo assim, mantenho o <strong>Conte\u00fado<\/strong> recente. No entanto, para dados altamente confidenciais, a op\u00e7\u00e3o \u00abno-cache\u00bb continua a ser demasiado permissiva.<\/p>\n<p><strong>n\u00e3o armazenar<\/strong> \u00e9 a medida mais rigorosa, pois pro\u00edbe qualquer armazenamento no navegador e nos proxies. Utilizo-a em p\u00e1ginas de in\u00edcio de sess\u00e3o, processos de pagamento ou documentos com dados confidenciais. Desta forma, n\u00e3o ficam c\u00f3pias em pastas tempor\u00e1rias que possam cair acidentalmente nas m\u00e3os erradas. Sempre que utilizo \u00abno-store\u00bb, combino-a frequentemente com \u00abmax-age=0\u00bb, para impedir qualquer reutiliza\u00e7\u00e3o <strong>excluir<\/strong>. A seguran\u00e7a tem aqui prioridade sobre o desempenho.<\/p>\n<p><strong>deve revalidar<\/strong> obriga a consultar o servidor assim que o prazo expirar. Se o servidor ficar indispon\u00edvel, a cache n\u00e3o pode simplesmente continuar a fornecer a recurso. Esta diretiva \u00e9 adequada para \u00e1reas em que a consist\u00eancia \u00e9 mais importante do que uma estrat\u00e9gia flex\u00edvel em caso de falha. Utilizo-a quando dados desatualizados poderiam levar a decis\u00f5es erradas. A regra estabelece claramente <strong>Car\u00e1cter vinculativo<\/strong> durante o processo.<\/p>\n\n<h2>Diretrizes avan\u00e7adas para caches partilhadas e resili\u00eancia<\/h2>\n<p>Para al\u00e9m das defini\u00e7\u00f5es b\u00e1sicas, utilizo <strong>s-maxagem<\/strong>, <strong>obsoleto-enquanto-revalidado<\/strong> e <strong>estagna\u00e7\u00e3o em caso de erro<\/strong>, para gerir de forma espec\u00edfica os proxies\/CDNs e garantir um servi\u00e7o fluido aos utilizadores, mesmo em caso de falhas. <em>s-maxagem<\/em> define um TTL pr\u00f3prio apenas para caches partilhadas (os navegadores ignoram-no). Assim, posso, por exemplo, manter o tempo de cache no navegador curto (max-age=600), mas prolong\u00e1-lo no Edge (s-maxage=86400). <em>obsoleto-enquanto-revalidado<\/em> permite que as caches continuem a disponibilizar conte\u00fados caducados durante um per\u00edodo de tempo definido, enquanto a atualiza\u00e7\u00e3o j\u00e1 est\u00e1 a decorrer em segundo plano. <em>estagna\u00e7\u00e3o em caso de erro<\/em> entra em a\u00e7\u00e3o em caso de erros (por exemplo, 500\/timeout) e protege a experi\u00eancia do utilizador, apresentando uma vers\u00e3o ligeiramente mais antiga em vez de mostrar um erro grave.<\/p>\n<p>Um modelo pr\u00e1tico para respostas de API p\u00fablicas, que raramente s\u00e3o alteradas, ou para mapas de site em JSON tem o seguinte aspeto: <code>Cache-Control: public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600<\/code>. Desta forma, os navegadores mant\u00eam-se relativamente atualizados, as CDNs s\u00e3o eficientes e os utilizadores n\u00e3o sentem nem pequenas interrup\u00e7\u00f5es nem atrasos nas revalida\u00e7\u00f5es. Deixo deliberadamente de fora dessas diretivas flex\u00edveis as \u00e1reas cr\u00edticas ou personalizadas.<\/p>\n\n<h2>Intera\u00e7\u00e3o com Expires, ETag e Last-Modified<\/h2>\n<p>Eu uso <strong>Expira\u00e7\u00f5es<\/strong> no m\u00e1ximo como alternativa, pois o Cache-Control permite um controlo mais preciso e tem prioridade quando ambos est\u00e3o definidos. Com o ETag, forne\u00e7o uma impress\u00e3o digital \u00fanica do recurso, para que o navegador possa iniciar uma revalida\u00e7\u00e3o simples atrav\u00e9s do If-None-Match. O \u00abLast-Modified\u00bb fornece a data e a hora da \u00faltima altera\u00e7\u00e3o e funciona em conjunto com o \u00abIf-Modified-Since\u00bb. Ambas as abordagens poupam largura de banda, pois, se o conte\u00fado n\u00e3o tiver sido alterado, o servidor apenas devolve o c\u00f3digo de estado 304. Esta intera\u00e7\u00e3o mant\u00e9m os dados pr\u00f3ximos do utilizador e reduz <strong>Viagens de ida e volta<\/strong>.<\/p>\n<p>Vou compr\u00e1-lo <a href=\"https:\/\/webhosting.de\/pt\/pacote-de-otimizacao-da-validacao-da-cache-de-pedidos-condicionais-http\/\">Pedidos condicionais<\/a>, os custos por visualiza\u00e7\u00e3o de p\u00e1gina diminuem significativamente, sem que eu bloqueie conte\u00fados novos. Esta t\u00e9cnica complementa valores \u00abmax-age\u00bb reduzidos no HTML e garante visualiza\u00e7\u00f5es atualizadas. Por outro lado, no caso de recursos com controlo de vers\u00f5es, recorro sobretudo a per\u00edodos de validade prolongados e evito valida\u00e7\u00f5es desnecess\u00e1rias. Desta forma, alivio a carga do <strong>Servidor<\/strong> e acelera significativamente as visitas subsequentes. No geral, resulta num fluxo de dados simplificado com regras claras.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimizationCacheControl1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>ETag\/Last-Modified na pr\u00e1tica: forte, fraco e escal\u00e1vel<\/h2>\n<p>Em configura\u00e7\u00f5es distribu\u00eddas, certifico-me de que os ETags <em>coerente<\/em> ser calculados em todas as inst\u00e2ncias. Os ETags baseados em ficheiros, que incluem inodes, provocam erros desnecess\u00e1rios em clusters. Por isso, no Apache, defino deliberadamente o c\u00e1lculo do ETag:<\/p>\n<pre><code># Apache: ETags consistentes para ficheiros est\u00e1ticos\nFileETag MTime Size\n# Opcional: remover o ETag padr\u00e3o e definir a pr\u00f3pria l\u00f3gica\n\n  #Header unset ETag\n<\/code><\/pre>\n<p>No Nginx, muitas vezes basta <code>etag ativado;<\/code> para ficheiros est\u00e1ticos. Para <em>din\u00e2mico<\/em> Eu pr\u00f3prio gerei os ETags das respostas \u2013 idealmente como um hash do corpo da resposta. Se precisar de toler\u00e2ncia para pequenas altera\u00e7\u00f5es (por exemplo, carimbos de data\/hora formatados), utilizo <strong>ETags fracos<\/strong> (<code>W\/\"...\"<\/code>), que permitem identificar conte\u00fados semanticamente id\u00eanticos como inalterados, apesar das diferen\u00e7as a n\u00edvel de bytes. Como alternativa, defino o \u00abLast-Modified\u00bb, por exemplo, com a data e hora da \u00faltima atualiza\u00e7\u00e3o do registo. Importante: ETag e Last-Modified <em>ao mesmo tempo<\/em> Oferecer n\u00e3o faz mal nenhum \u2013 \u00e9 o cliente que escolhe o que suporta.<\/p>\n\n<h2>Utilizar o Vary de forma correta: personaliza\u00e7\u00e3o sem confus\u00e3o na cache<\/h2>\n<p><strong>Variar<\/strong> determina quais cabe\u00e7alhos de pedido s\u00e3o inclu\u00eddos na chave da cache. Opto deliberadamente por manter o \u00abVary\u00bb simples: <em>Aceitar codifica\u00e7\u00e3o<\/em> \u00e9 o padr\u00e3o (Gzip\/Brotli), <em>Aceitar idioma<\/em> apenas se eu der respostas espec\u00edficas sobre a l\u00edngua. De <em>Vary: User-Agent<\/em> N\u00e3o recomendo, porque faz com que o volume do cache dispare. Se os conte\u00fados dependerem de cookies, prefiro <strong>privado<\/strong> ou <strong>n\u00e3o armazenar<\/strong>, em vez de ter de gerir regras Vary extensas. No que diz respeito aos recursos, sempre que poss\u00edvel, elimino os cookies desnecess\u00e1rios, para que <strong>p\u00fablico<\/strong>- O armazenamento em cache na periferia entra em a\u00e7\u00e3o. Se utilizar uma autentica\u00e7\u00e3o por API atrav\u00e9s do cabe\u00e7alho, pode <em>Vary: Autoriza\u00e7\u00e3o<\/em> impedir que as caches partilhadas misturem as respostas de diferentes utilizadores \u2013 mas, muitas vezes, aqui <strong>privado<\/strong> a escolha melhor e mais clara.<\/p>\n<p>Verifico no DevTools se o campo \u201eVary\u201c est\u00e1 a ser definido inadvertidamente (por exemplo, por middlewares), pois um \u00abVary\u00bb muito abrangente reduz drasticamente a taxa de acertos. Poucos cabe\u00e7alhos, escolhidos de forma consciente, mant\u00eam a cache mais f\u00e1cil de gerir e <strong>eficaz<\/strong>.<\/p>\n\n<h2>Estrat\u00e9gias por tipo de conte\u00fado<\/h2>\n<p>Fa\u00e7o uma distin\u00e7\u00e3o rigorosa entre conte\u00fados est\u00e1ticos e din\u00e2micos, para poder tirar partido das vantagens de ambos. Os recursos est\u00e1ticos t\u00eam um per\u00edodo de validade prolongado e s\u00e3o facilmente identific\u00e1veis atrav\u00e9s de nomes de ficheiros versionados. Trato o HTML e os conte\u00fados pessoais com mais cautela, para que as altera\u00e7\u00f5es fiquem rapidamente dispon\u00edveis e os dados n\u00e3o fiquem retidos em caches incorretos. Classifico as APIs de acordo com a frequ\u00eancia de altera\u00e7\u00f5es e a sensibilidade das informa\u00e7\u00f5es. Esta classifica\u00e7\u00e3o proporciona <strong>Velocidade<\/strong> sem comprometer a confidencialidade e <strong>Corre\u00e7\u00e3o<\/strong>.<\/p>\n<p>A tabela seguinte resume as configura\u00e7\u00f5es pr\u00e1ticas e apresenta as vantagens num relance.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tipo de recurso<\/th>\n      <th>Exemplo de cabe\u00e7alho<\/th>\n      <th>Porqu\u00ea<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CSS\/JS\/Imagens\/Fontes<\/td>\n      <td>Cache-Control: public, max-age=31536000, immutable<\/td>\n      <td>Utiliza\u00e7\u00e3o prolongada de <strong>Cache do navegador<\/strong>, menos pedidos<\/td>\n      <td>Nomear ficheiros com vers\u00f5es para uma organiza\u00e7\u00e3o mais clara <strong>Rolamento<\/strong> Atualiza\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>HTML n\u00e3o personalizado<\/td>\n      <td>Cache-Control: no-cache, must-revalidate (ou max-age=300)<\/td>\n      <td>A atualidade mant\u00e9m-se elevada, o volume de dados continua reduzido<\/td>\n      <td>Com ETag\/Last-Modified para uma f\u00e1cil <strong>reabilita\u00e7\u00e3o<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>HTML personalizado<\/td>\n      <td>Cache-Control: private, no-cache, must-revalidate<\/td>\n      <td>N\u00e3o se armazena em caches partilhadas<\/td>\n      <td>Proteger os dados da sess\u00e3o e <strong>Fugas<\/strong> Evitar<\/td>\n    <\/tr>\n    <tr>\n      <td>APIs est\u00e1ticas \/ que raramente sofrem altera\u00e7\u00f5es<\/td>\n      <td>Cache-Control: public, max-age=3600<\/td>\n      <td>Elevada taxa de acerto em muitos casos <strong>Clientes<\/strong><\/td>\n      <td>Mantenha-se flex\u00edvel para implementa\u00e7\u00f5es frequentes<\/td>\n    <\/tr>\n    <tr>\n      <td>APIs altamente din\u00e2micas \/ sens\u00edveis<\/td>\n      <td>Cache-Control: no-store, max-age=0<\/td>\n      <td>N\u00e3o armazenar dados confidenciais<\/td>\n      <td>Direto <strong>Atualidade<\/strong> em vez de risco<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>No caso de galerias de imagens, grandes pacotes JS ou fontes web, valores elevados de `max-age` compensam-se rapidamente. Presto aten\u00e7\u00e3o \u00e0s sequ\u00eancias de vers\u00e3o nos nomes dos ficheiros, para que os utilizadores nunca vejam pacotes desatualizados. O HTML mant\u00e9m-se conciso e recorre \u00e0 revalida\u00e7\u00e3o, para que mesmo pequenas corre\u00e7\u00f5es em textos ou pre\u00e7os sejam rapidamente publicadas. As APIs recebem as suas regras consoante o perfil de utiliza\u00e7\u00e3o e a necessidade de altera\u00e7\u00f5es. Esta combina\u00e7\u00e3o proporciona resultados duradouros <strong>frota<\/strong> Visualiza\u00e7\u00f5es de p\u00e1ginas e poupa <strong>Largura de banda<\/strong>.<\/p>\n\n<h2>SPA vs. MPA: HTML de \u00edndice curto, recursos extensos<\/h2>\n<p>No que diz respeito \u00e0s aplica\u00e7\u00f5es de p\u00e1gina \u00fanica, considero que a <em>\u00cdndice HTML<\/em> de vida particularmente curta (por exemplo,. <code>no-cache, must-revalidate<\/code> ou <code>max-age=60<\/code>), pois \u00e9 ela que determina qual a vers\u00e3o dos pacotes que \u00e9 carregada. Por outro lado, todos os chunks, tipos de letra e imagens compilados t\u00eam uma vers\u00e3o rigorosamente definida e recebem <code>p\u00fablico, max-age=31536000, imut\u00e1vel<\/code>. Desta forma, garanto que uma nova vers\u00e3o com o ficheiro HTML de \u00edndice atualizado fa\u00e7a refer\u00eancia imediatamente aos novos nomes de ficheiros corretos, enquanto os utilizadores existentes continuam a utilizar o <em>grandes<\/em> Recuperar os recursos da sua cache local.<\/p>\n<p>Cadeias de consulta como m\u00e9todo para anular o cache (<code>?v=123<\/code>) S\u00f3 utilizo isso nos casos em que os nomes dos ficheiros n\u00e3o podem ser alterados facilmente. \u00c9 prefer\u00edvel utilizar nomes de ficheiros \u00fanicos (hashes), porque segmentam os caches de forma mais clara e geram menos casos especiais.<\/p>\n\n<h2>Configura\u00e7\u00e3o do servidor: Apache e Nginx<\/h2>\n<p>No Apache, costumo definir os cabe\u00e7alhos no ficheiro <strong>.htaccess<\/strong>, desde que o m\u00f3dulo mod_headers esteja ativo. Atribuo um prazo de validade longo aos recursos est\u00e1ticos, enquanto o HTML \u00e9 tratado de forma mais rigorosa. No Nginx, fa\u00e7o isso em blocos \u00ablocation\u00bb, muitas vezes em conjunto com a diretiva \u00abexpires\u00bb como op\u00e7\u00e3o alternativa. Testo cada altera\u00e7\u00e3o com o DevTools no separador \u00abRede\u00bb, para ver os valores reais dos cabe\u00e7alhos. Desta forma, evito regras incorretas que, de outra forma, poderiam causar dispendiosas <strong>Pedidos incorretos<\/strong> produzir.<\/p>\n<pre><code># Apache (.htaccess)\n\n  \n    Header set Cache-Control \"public, max-age=31536000, immutable\"\n  \n\n  \n    Header set Cache-Control \"no-cache, must-revalidate\"\n<\/code><\/pre>\n<pre><code># Nginx (bloco de servidor)\nlocation ~* \\.(jpg|jpeg|png|gif|css|js|woff2?)$ {\n    expires 365d;\n    add_header Cache-Control \"public, immutable\";\n}\n\nlocation ~* \\.(html)$ {\n    add_header Cache-Control \"no-cache, must-revalidate\";\n}\n<\/code><\/pre>\n<p>Certifico-me de que n\u00e3o existem regras concorrentes nos servi\u00e7os a montante que interfiram com estes cabe\u00e7alhos. Uma CDN a montante, por exemplo, pode definir os seus pr\u00f3prios TTLs, o que tenho de controlar de forma deliberada. Se todos os n\u00edveis estiverem em conson\u00e2ncia, os recursos permanecem fi\u00e1veis <strong>localiz\u00e1vel<\/strong> e consistente. Quem verificar cuidadosamente nesta fase evita sess\u00f5es de depura\u00e7\u00e3o demoradas. Pequenas verifica\u00e7\u00f5es poupam muito mais tarde <strong>Tempo<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Pr\u00e1ticas de CDN e proxy: configurar o s-maxage e as estrat\u00e9gias \u00abStale\u00bb<\/h2>\n<p>No caso dos caches de borda, acrescento o seguinte \u00e0 configura\u00e7\u00e3o do servidor: <em>s-maxagem<\/em> bem como as diretivas Stale. Exemplo do Apache:<\/p>\n<pre><code># Apache: Regras otimizadas para CDN\n\n  \n    Header set Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\"\n<\/code><\/pre>\n<p>E no Nginx:<\/p>\n<pre><code># Nginx: Otimiza\u00e7\u00e3o da cache partilhada\nlocation ~* \\.(json|xml|map)$ {\n    add_header Cache-Control \"public, max-age=600, s-maxage=86400, stale-while-revalidate=30, stale-if-error=600\";\n}\n<\/code><\/pre>\n<p>Muitas CDNs respeitam estas diretivas diretamente. Caso a tua camada de borda (edge layer) espere cabe\u00e7alhos pr\u00f3prios (por exemplo, cabe\u00e7alhos \u00absurrogate\u00bb), replico essa l\u00f3gica nessa camada e mantenho a estrat\u00e9gia do navegador e a do cache partilhado claramente separadas. Gra\u00e7as ao controlo de vers\u00f5es, raramente preciso de purgas; quando isso acontece, planeio-as como uma interven\u00e7\u00e3o pequena e espec\u00edfica.<\/p>\n\n<h2>Casos especiais: redirecionamentos, p\u00e1ginas de erro e fluxos de trabalho de formul\u00e1rios<\/h2>\n<p><strong>Redirecionamentos:<\/strong> As respostas 301 s\u00e3o armazen\u00e1veis em cache, de acordo com a especifica\u00e7\u00e3o. Quando defino redirecionamentos tempor\u00e1rios (302\/307), atribuo TTLs claros ou defino deliberadamente <code>n\u00e3o armazenar<\/code>, para que nada se torne permanente. As rotas 301 permanentes podem ter um TTL moderado \u2013 as altera\u00e7\u00f5es s\u00e3o, nesse caso, uma medida deliberada e coordenada.<\/p>\n<p><strong>P\u00e1ginas de erro:<\/strong> As respostas 404\/410 podem ser armazenadas em cache por um curto per\u00edodo (por exemplo,. <code>max-age=60<\/code>), para reduzir a carga dos bots. Com os 500, dependendo do ambiente, <code>estagna\u00e7\u00e3o em caso de erro<\/code> ativo, para que os utilizadores prefiram ver uma p\u00e1gina mais antiga, mas que funcione, em vez de uma mensagem de erro.<\/p>\n<p><strong>POST\/Download:<\/strong> As respostas \u00e0s solicita\u00e7\u00f5es POST n\u00e3o s\u00e3o, regra geral, armazenadas na cache do navegador. Para exporta\u00e7\u00f5es de ficheiros com dados pessoais (por exemplo, faturas), defino sistematicamente <code>n\u00e3o armazenar<\/code> al\u00e9m de uma entrega segura (por exemplo, Content-Disposition), para que nada permane\u00e7a acidentalmente. Por outro lado, os downloads de grande dimens\u00e3o n\u00e3o personalizados (por exemplo, lan\u00e7amentos) podem tirar partido das caches p\u00fablicas durante longos per\u00edodos de tempo.<\/p>\n\n<h2>Evitar erros t\u00edpicos<\/h2>\n<p>Muitos confundem <strong>sem cache<\/strong> com \u201esem cache\u201c, o que gera uma carga desnecess\u00e1ria. Como se pode ver, \u00abno-cache\u00bb permite o armazenamento em cache, mas exige a revalida\u00e7\u00e3o. Outro erro cl\u00e1ssico: valores elevados de \u00abmax-age\u00bb sem versionamento em CSS ou JS, o que mant\u00e9m ficheiros desatualizados. A falta de separa\u00e7\u00e3o entre HTML e recursos est\u00e1ticos prejudica a velocidade, porque o HTML raramente pode ser armazenado em cache de forma agressiva. Quem ignorar isto est\u00e1 a abrandar o <strong>Experi\u00eancia do utilizador<\/strong> de.<\/p>\n<p>Os conflitos entre o servidor, a CDN e a aplica\u00e7\u00e3o prejudicam os efeitos do cache sem que se d\u00ea por isso. Por isso, verifica as substitui\u00e7\u00f5es e os n\u00edveis interm\u00e9dios quando os cabe\u00e7alhos mudarem \u201ecomo por arte de magia\u201c. Neste caso, analisar os registos e a cadeia de respostas ajuda a identificar prioridades erradas. Uma lista de verifica\u00e7\u00e3o concisa e armadilhas t\u00edpicas relacionadas com <a href=\"https:\/\/webhosting.de\/pt\/http-cache-headers-sabotam-o-cache-cachefix\/\">Cabe\u00e7alho da cache de sabotagem<\/a> facilitam o controlo. Prioridades claras evitam <strong>Efeitos secund\u00e1rios<\/strong> nas implementa\u00e7\u00f5es.<\/p>\n\n<h2>Tornar mensur\u00e1vel o ganho de desempenho<\/h2>\n<p>Avalio os efeitos do Cache-Control com m\u00e9tricas como o TTFB, o LCP e o n\u00famero de <strong>Pedidos<\/strong> por visualiza\u00e7\u00e3o de p\u00e1gina. Uma olhadela nas DevTools mostra-me se os ficheiros prov\u00eam do \u201ecach\u00ea do disco\u201c ou do \u201ecach\u00ea da mem\u00f3ria\u201c. O Lighthouse, o WebPageTest e ferramentas semelhantes indicam se o cach\u00ea do navegador est\u00e1 a funcionar de forma consistente. Fa\u00e7o medi\u00e7\u00f5es antes e depois de uma altera\u00e7\u00e3o, para poder ver claramente as melhorias reais. Esta disciplina mant\u00e9m as otimiza\u00e7\u00f5es <strong>compreens\u00edvel<\/strong> e orientada para os objetivos.<\/p>\n<p>As imagens de grande dimens\u00e3o, os tipos de letra web e os pacotes t\u00eam um impacto particularmente forte, uma vez que deixam de ser carregados em visitas subsequentes. Para tal, o HTML permanece pr\u00f3ximo do servidor, para que os utilizadores obtenham novos conte\u00fados rapidamente. As APIs beneficiam significativamente quando as rotas mais utilizadas t\u00eam um TTL moderado. Os resultados traduzem-se em tempos de carregamento mais curtos, menor volume de dados e uma carga mais est\u00e1vel no servidor. Quem verificar isto de forma consistente poupa a longo prazo <strong>Recursos<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimierung4102.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Service Worker e cache HTTP: n\u00e3o os deixe a funcionar em conflito<\/h2>\n<p>Se eu utilizar um Service Worker, a estrat\u00e9gia deste deve estar em conson\u00e2ncia com os meus cabe\u00e7alhos HTTP. Para recursos est\u00e1ticos e versionados, a op\u00e7\u00e3o \u201ecache-first\u201c com um TTL longo e <em>imut\u00e1vel<\/em> Excelente. Para HTML ou dados de API que mudam frequentemente, prefiro \u201enetwork-first\u201c ou \u201estale-while-revalidate\u201c, para que os utilizadores vejam respostas rapidamente e a atualiza\u00e7\u00e3o chegue em tempo \u00fatil. Importante: o Service Worker deve respeitar as revalida\u00e7\u00f5es (reencaminhar If-None-Match\/If-Modified-Since), em vez de reter o conte\u00fado artificialmente.<\/p>\n<p>Al\u00e9m disso, fa\u00e7o uma distin\u00e7\u00e3o clara: o cache HTTP j\u00e1 pode assumir grande parte do trabalho; o Service Worker complementa esse comportamento, n\u00e3o o substitui. Desta forma, a depura\u00e7\u00e3o e a opera\u00e7\u00e3o mant\u00eam-se simples e control\u00e1veis.<\/p>\n\n<h2>Compreender as diretivas do lado do pedido<\/h2>\n<p>As solicita\u00e7\u00f5es tamb\u00e9m podem controlar o armazenamento em cache. <code>Cache-Control: no-cache<\/code> em <em>Pedido<\/em> obriga a uma revalida\u00e7\u00e3o no servidor, <code>max-age=0<\/code> \u00e9 semelhante. <code>n\u00e3o armazenar<\/code> Na solicita\u00e7\u00e3o, pro\u00edbe-se o armazenamento da resposta ao longo da cadeia. Para casos em que n\u00e3o h\u00e1 liga\u00e7\u00e3o \u00e0 Internet, pode <code>somente se estiver em cache<\/code> pode ser \u00fatil: o cliente passa a aceitar apenas respostas provenientes da cache. Este mecanismo \u00e9 \u00fatil em aplica\u00e7\u00f5es que devem proporcionar uma experi\u00eancia definida mesmo com uma liga\u00e7\u00e3o fraca.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/WebOptimization_9254.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Boas pr\u00e1ticas para o teu fluxo de trabalho<\/h2>\n<p>Come\u00e7o por fazer um balan\u00e7o: que tipos de ficheiros existem, quais s\u00e3o personalizados e quais raramente sofrem altera\u00e7\u00f5es. Depois, aplico regras de forma diferenciada, para que os recursos permane\u00e7am por muito tempo no <strong>Cache<\/strong> permanecer e o HTML se manter atualizado. As sequ\u00eancias de vers\u00e3o no nome do ficheiro eliminam o risco de pacotes desatualizados e permitem tempos de execu\u00e7\u00e3o mais eficientes. Em janelas de manuten\u00e7\u00e3o regulares, verifico os cabe\u00e7alhos e as taxas de sucesso, para identificar tend\u00eancias atempadamente. Esta rotina mant\u00e9m o site <strong>eficaz<\/strong> e previs\u00edvel.<\/p>\n<p>Documento as configura\u00e7\u00f5es de forma concisa e clara, para que futuras altera\u00e7\u00f5es n\u00e3o causem danos acidentais. Os scripts de implementa\u00e7\u00e3o atualizam automaticamente os hashes dos ficheiros, para que eu n\u00e3o me esque\u00e7a de nenhum passo. Para as vers\u00f5es, utilizo implementa\u00e7\u00f5es com alcance limitado, a fim de testar o comportamento em ambiente real. O feedback proveniente da monitoriza\u00e7\u00e3o e dos registos \u00e9 incorporado diretamente nas regras de cabe\u00e7alho. Desta forma, a estrat\u00e9gia mant\u00e9m-se realista e <strong>efetivo<\/strong>.<\/p>\n\n<h2>Controlo de vers\u00f5es e ativos imut\u00e1veis<\/h2>\n<p>Acrescento hashes aos nomes dos ficheiros, por exemplo, app.20260817.js, e, em seguida, defino \u00abpublic\u00bb, \u00abmax-age=31536000\u00bb, <strong>imut\u00e1vel<\/strong>. Desta forma, o navegador sabe que o ficheiro nunca muda \u201esilenciosamente\u201c e evita novas valida\u00e7\u00f5es. Na pr\u00f3xima vers\u00e3o, o ficheiro recebe um novo nome, o que faz com que o navegador carregue exatamente a nova vers\u00e3o. Assim, evito vers\u00f5es desatualizadas ap\u00f3s uma implementa\u00e7\u00e3o. Esta t\u00e1tica est\u00e1 em sintonia com muitas <a href=\"https:\/\/webhosting.de\/pt\/http-cache-control-strategies-hosting-cachemaster\/\">Estrat\u00e9gias de Cache-Control<\/a> as mais diversas pilhas.<\/p>\n<p>No HTML, n\u00e3o utilizo o \u00abimmutable\u00bb porque a p\u00e1gina muda frequentemente e pretendo uma revalida\u00e7\u00e3o flex\u00edvel. O mesmo se aplica \u00e0s respostas de API com dados vari\u00e1veis. As fontes e as imagens de grande dimens\u00e3o beneficiam particularmente, uma vez que os utilizadores as utilizam v\u00e1rias vezes em diferentes dispositivos. Continua a ser importante uma correspond\u00eancia completa entre os hashes e as vers\u00f5es de lan\u00e7amento. A documenta\u00e7\u00e3o e a clareza <strong>Nomes<\/strong> evitar confus\u00f5es na equipa e nas builds.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/weboptimization-header-8274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Passos pr\u00e1ticos de teste e depura\u00e7\u00e3o<\/h2>\n<p>Abro o DevTools e, no separador \u00abRede\u00bb, inspeciono os cabe\u00e7alhos da resposta para verificar o Cache-Control, o ETag, o Expires e <strong>Variar<\/strong> verificar. Uma nova atualiza\u00e7\u00e3o sem cache (Ctrl+F5) permite-me verificar se as regras est\u00e3o realmente a funcionar. Depois, carrego a p\u00e1gina normalmente e verifico quais os elementos que s\u00e3o servidos a partir do cache. No caso de proxies e CDNs, analiso cabe\u00e7alhos como \u00abAge\u00bb ou \u00abX-Cache\u00bb, se estiverem dispon\u00edveis. Estas verifica\u00e7\u00f5es permitem detetar conflitos e erros <strong>Prioridades<\/strong> rapidamente.<\/p>\n<p>Ao n\u00edvel do servidor, comparo a configura\u00e7\u00e3o e os registos para detetar discrep\u00e2ncias. Um erro frequente: uma aplica\u00e7\u00e3o insere cabe\u00e7alhos posteriormente e substitui as regras do servidor. Nos pipelines de CI\/CD, testo automaticamente os cabe\u00e7alhos no ambiente de teste, para evitar surpresas no sistema de produ\u00e7\u00e3o. Em caso de problemas, recorro temporariamente a TTLs curtos at\u00e9 que a causa seja identificada. Com testes claros, mantenho <strong>Controlo<\/strong> sobre o comportamento de armazenamento em cache em todas as camadas.<\/p>\n\n<h2>A realidade dos navegadores: tipos de mem\u00f3ria e limpeza<\/h2>\n<p>Os navegadores distinguem entre cache de mem\u00f3ria e cache de disco. Os ficheiros pequenos e frequentemente utilizados beneficiam do cache de mem\u00f3ria (acessos extremamente r\u00e1pidos), enquanto os ficheiros de grande dimens\u00e3o acabam frequentemente no disco. Os dispositivos m\u00f3veis limpam a cache de forma mais agressiva \u2013 por isso, n\u00e3o planeio nenhuma estrat\u00e9gia que se baseie exclusivamente numa persist\u00eancia muito longa do navegador, mas protejo-me com bons mecanismos de revalida\u00e7\u00e3o. <em>imut\u00e1vel<\/em> Embora evite reavalia\u00e7\u00f5es desnecess\u00e1rias, isso s\u00f3 se aplica enquanto o registo n\u00e3o tiver sido removido por falta de espa\u00e7o.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/futuristic-web-optimization-7643.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Para tirar<\/h2>\n<p>Conjunto <strong>Controlo da cache<\/strong> Aplica de forma seletiva: prazos de validade longos e imut\u00e1veis para recursos versionados; regras cautelosas e revalida\u00e7\u00e3o para HTML e conte\u00fados pessoais. Combina o `max-age` com o `ETag` ou o `Last-Modified`, para poupar largura de banda e garantir a atualidade. Verifique todos os n\u00edveis, incluindo a CDN, para garantir que as regras n\u00e3o entrem em conflito. Evite utilizar o `no-store` por puro reflexo e utilize-o apenas nos casos em que a prote\u00e7\u00e3o de dados seja uma prioridade absoluta. Com uma separa\u00e7\u00e3o clara por tipo de conte\u00fado, um controlo de vers\u00f5es consistente e uma medi\u00e7\u00e3o cont\u00ednua, conseguir\u00e1 p\u00e1ginas visivelmente mais r\u00e1pidas e manter\u00e1 a <strong>Soberania<\/strong> sobre o teu caching.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a utilizar corretamente os cabe\u00e7alhos HTTP Cache-Control para melhorar o armazenamento em cache do navegador e a otimiza\u00e7\u00e3o da Web. O foco est\u00e1 em estrat\u00e9gias de cache seguras e de alto desempenho.<\/p>","protected":false},"author":1,"featured_media":20739,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[679],"tags":[],"class_list":["post-20746","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seo"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"172","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Cache-Control","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20739","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20746","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20746"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20746\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20739"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20746"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20746"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20746"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}