Conteúdos, dicas e sugestões sobre CDN, WAF, SSL, otimização de WordPress, Magento e aplicações web em geral.

PoP de Brasília: A GoCache agora está em todas as regiões do Brasil

Como a população depende ainda mais de uma boa qualidade da internet neste momento, seguimos avançando. Com nossa equipe trabalhando remotamente, estamos a todo vapor com novos lançamentos e acabamos de anunciar nosso mais novo ponto de presença: Brasília. A implantação física deste PoP ocorreu no período pré-epidemia o que permitiu que continuássemos o processo, mesmo adotando as medidas de isolamento. E ainda temos duas outras ativações para realizar.

A chegada deste novo PoP faz com que a GoCache agora tenha presença em todas as regiões do Brasil, reforçando nossa estratégia de suprir as lacunas que grandes provedores de CDN deixam no país. Com ele esperamos reduzir a latência da região central do Brasil, envolvendo estados do Centro-Oeste, e algumas cidades de Minas Gerais, Bahia, e Tocantins, podendo também trazer benefícios para algumas cidades das regiões Norte e Nordeste.

Assim, se você possui ou administra sites como e-commerces, blogs, portais de notícias, EADs ou outros tipos de aplicações web, você pode proporcionar experiências mais rápidas para seus clientes que estejam nessas regiões, e não apenas para aqueles do eixo Rio-São Paulo. Isso pode representar grande parte de sua audiência.

Fique atento, pois, além deste lançamento, temos muitos outros programados, que vão te ajudar a trazer uma experiência rápida, segura e sem quedas para sua audiência online.

Cloudfront x Cloudflare x GoCache: um comparativo de latência

Quando se trata de plataformas de CDN, um dos atributos mais importantes é a latência de rede. Afinal, é para esse propósito que as CDNs surgiram: encurtar a distância entre o conteúdo (e mais recentemente, processamento) e os visitantes de uma aplicação web, tornado a experiência mais rápida.

Encurtar a distância entre conteúdo e visitante não é uma metáfora. Uma CDN consiste de uma rede de servidores em diferentes data centers, distribuídos geograficamente. Quando um visitante se conecta a um website que usa esta tecnologia, ele se comunica com o servidor mais próximo desta rede.

Latência no Brasil

Para comparar a latência entre Cloudfront, Cloudflare e GoCache, vamos usar uma ferramenta de monitoramento de performance de usuários reais anonimizados chamada PerfOps. O projeto consiste na inserção de um arquivo estático em diversos sites e na coleta do tempo de resposta do servidor (TTFB) a partir da API Resource Timing dos navegadores mais modernos. Nela, os principais provedores de CDN, cloud e DNS são monitorados. O gráfico abaixo compara a mediana entre as soluções em questão, o que significa dizer que 50% dos usuários apresentam tempos de resposta abaixo dos valores do gráfico.

Mediana do tempo de resposta do servidor

Você pode perceber no gráfico acima que quando se trata de latência no Brasil, a GoCache sai na frente. Uma justificativa está na presença da GoCache em 4 regiões do país. São 8 pontos de presença, sendo 3 em São Paulo, e os outros no Rio de Janeiro, Curitiba, Salvador, Fortaleza e Manaus. Enquanto isso, a CDN da AWS, o Cloudfront, possui apenas 2 PoPs, sendo um em São Paulo e o outro no Rio de Janeiro, e a Cloudflare possui 5 PoPs distribuídos entre em São Paulo, Rio de Janeiro, Curitiba, Porto Alegre e Fortaleza, contabilizando um total de 5.

Você pode estranhar a Cloudflare apresentar o pior desempenho comparado com as outras CDNs, mesmo com uma quantidade razoável de PoPs no Brasil, mas isso pode ser explicado por sua posição estratégica. A estratégia de freemium e preços fixos potencialmente entra em choque com os altos custos de banda da internet brasileira, obrigando-a a limitar sua capacidade no país. E essa capacidade acaba sendo priorizada para seus clientes Enterprise, através dos ranges de IP priorizados, em detrimento dos outros planos. Dessa forma, se um visitante acessa um site atendido por um plano abaixo do Enterprise, pode ser direcionado para um PoP mais distante para evitar congestionamentos, inclusive podendo ser para fora do Brasil.

Explicação sobre os range de IPs priorizados

Por usar uma amostra de todos usuários de alguns sites, o PerfOps pode carregar vieses dessa audiência. Um exemplo de viés acontece se a maior parte da audiência destes sites estiver localizada na região sudeste, o que provavelmente ocorre e faz com que as medianas tendam a ficar mais próximas, pois a maioria das soluções possuem PoPs nesta região. Isso pode explicar a proximidade entre a GoCache e o Cloudfront, que tende a ser menor quando comparamos nas regiões Nordeste e Norte. Você pode visualizar isso comparando o tempo de ping (latência de rede) em centenas de provedores de internet no Brasil para as duas CDNs, através da ferramenta ISPTools (links: http://www.isptools.com.br/ping#287!0!www.gocache.com.br e http://www.isptools.com.br/ping#548!0!aws.amazon.com). E você pode esperar um desempenho ainda melhor em breve, pois lançaremos um PoP na região Centro-Oeste. Fique atento!

De toda forma, para reforçar a veracidade dessas informações, sugiro que você mesmo faça o teste, que pode ser realizado através de soluções de RUM, como New Relic e App Dynamics, ou você mesmo pode fazer um esquema de coleta e análise destes dados. Aproveite também para experimentar a flexibilidade na configuração, a implantação em tempo real das configurações e o suporte usando os 7 dias gratuitos para teste que você tem direito em nossa plataforma!

 

A alternativa ao Cloudfront paga em reais

O Cloudfront é uma das principais CDNs (Content Delivery Networks) usadas no mundo, principalmente por integrar o portfólio de serviços oferecidos pela AWS (Amazon Web Services), o que o torna uma alternativa prática para muitos usuários que possuem outros serviços neste provedor de cloud. Porém, ele traz um dos principais pontos fracos dessa plataforma: o billing complexo e cobrado em dólares. Além disso, ele está sujeito à tributação sobre a importação de serviços de cloud, o que pode elevar seu custo total em até 50%. A maioria dos usuários não pagam este imposto, mas, com isso, estão gerando um grande passivo tributário

Quanto o Cloudfront pode custar?

Vamos calcular o valor de 10TB de transferência. O billing da AWS é muito complexo, o que deixa muitos usuários confusos, mas vamos parte por parte. O custo do Cloudfront para entrega na America do Sul é de 0,11 USD/GB. Este já é um fator que traz muita confusão. O custo para entrega de conteúdo por pontos de presença em diferentes continentes varia. Você pode até escolher entregar seu conteúdo por pontos de presença na América do Norte para pagar um valor mais barato no tráfego, porém, isso compromete o principal propósito de uma CDN: entregar conteúdo em servidor próximo ao usuário para reduzir latência. Desta forma, convertendo este valor para uma cotação do dólar a 5 reais, temos que 10TB custam cerca de 5.500 reais.

Porém, um importante ponto que é esquecido por grande parte do usuários é que o Cloudfront não é cobrado apenas pelo tráfego, mas também por requisições. A quantidade de requisições (ou solicitações http/https) varia muito de aplicação para aplicação, mas vamos fazer uma estimativa conservadora. Suponha que esta aplicação que trafega 10TB por mês tenha um tamanho médio de requisição de 20KB (o que já é maior que muitas imagens). Para a conta bater, são necessárias 500 milhões de solicitações. O custo por cada 10.000 solicitações https em servidores na América do Sul é de 0,022 USD (https por que vamos convir que site sem criptografia é uma péssima prática). Usando a mesma cotação acima para converter os valores, temos que 500 milhões de solicitações https também custam 5.500 reais. Ou seja, as requisições podem até dobrar a fatura.

Sem considerar outras cobranças, como, por exemplo, por invalidação ou limpeza de cache, temos um total de 11.000 reais para uma aplicação de 10TB, sem impostos. Com impostos a conta pode chegar a até 16.500 reais. Na GoCache, um dos maiores provedores de CDN no Brasil, esta aplicação geraria um custo de apenas  de 3.399 reais, sem cobrança por solicitações http/https.

A GoCache pode substituir o Cloudfront?

Para maioria dos casos a resposta é sim! Você pode duvidar que uma CDN brasileira tenha desempenho comparável à CDN da AWS, mas quando se trata de performance para audiência brasileira, a competição é acirrada, como você pode ver nos dados extraídos da ferramenta de medição de performance PerfOps, apresentados abaixo abaixo.

Comparação do tempo de reposta do servidor entre Cloudfront e GoCache no Brasil

Comparação do tempo de reposta do servidor entre Cloudfront e GoCache no Brasil

 

Estes dados ainda podem conter o viés da audiência usada pela ferramenta, caso esta se concentre no Sudeste. Neste caso, a performance da GoCache pode ser ainda superior ao Cloudfront, pois possui pontos de presença nas regiões Nordeste, Sul e Norte, enquanto o Cloudfront possui apenas dois pontos de presença, um em São Paulo e outro no Rio de Janeiro. Você pode comparar o tempo de ping (latência) em mais de 100 provedores de todas as regiões do Brasil através do ISPTools (links: http://www.isptools.com.br/ping#287!0!www.gocache.com.br e http://www.isptools.com.br/ping#548!0!aws.amazon.com)

Em termos de migração, você não precisa abandonar seus servidores de DNS atuais. A GoCache suporta apontamento via CNAME. Basta configurar o endereço de origem de cada entrada a ser migrada no painel e substituir o endereço de distribuição do Cloudfront pelo da GoCache na sua zona de DNS. A partir daí, o cache dos conteúdos estáticos já é feito automaticamente. Mas caso prefira, a GoCache também tem seus próprios servidores de DNS, cujas configurações também podem ser feitas via API.

Se você aplica cache de conteúdo dinâmico em seu site, também não precisa se preocupar. A GoCache tem um motor de regras de comportamento similar ao Cloudfront com todas as opções de comportamento, como evitar o cache na presença de determinados cookies ou headers, chave de cache por cookie, header ou localização, entre outras possibilidades. Essa estratégia de cache também é viabilizada pela limpeza instantânea de cache e pela limpeza via API. E para aqueles que fazem uso do Lambda@Edge, alguns dos principais casos de uso podem ser feitos por meio do mesmo motor de regras, como redirecionamentos customizados, sobrescrever headers, apontar para uma origem diferente, entre outros.

Critérios do motor de regras

Critérios do motor de regras

 

Ações do motor de regras

Ações do motor de regras

 

Poderia falar de outros recursos como analytics em tempo real, com granularidade de até minutos, ou suporte com gerente de contas dedicado para a maioria dos planos, mas não vou me alongar muito. Te convido a entrar em contato conosco para conhecer a plataforma, ou aproveitar os 7 dias de trial para avaliá-la em ação.

Como uma CDN pode reduzir custos?

Pode parecer contraintuitivo a adição de mais um serviço à sua aplicação reduzir seus custos com infraestrutura. Porém, a arquitetura de uma CDN (Content Delivery Network), ou em português, rede de distribuição de conteúdo, permite que conteúdos sejam entregues com mais eficiência, reduzindo o Custo Total de Propriedade (TCO).

Se você ainda não conhece, uma CDN realiza cache em servidores mais próximos do usuário, ou seja, parte do conteúdo é “copiada” e quando um usuário requisita estes conteúdos, estes são entregues por meio do servidor mais próximo.

Sem CDN

Sem CDN o tráfego se concentra na infraestrutura de origem

Com CDN

Com CDN apenas parte do tráfego vai pra origem e diminui o caminho percorrido

Por causa deste processo, grande parte do tráfego requisitado a uma aplicação nem chega à sua infraestrutura, reduzindo custos com transferência externa de dados (Data Transfer Out) no caso de provedores de cloud, ou com banda de link de internet, caso sua infraestrutura seja on-premises.

Você pode se perguntar: mas este custo que foi reduzido não será cobrado pelo mesmo valor na CDN? A resposta é não. Devido à eficiência no processo, geralmente as CDNs entregam um custo menor por banda. Por exemplo, para efeito de comparação, o custo de Data Transfer Out para 5TB e entrega pelo Brasil na Amazon Web Services (AWS) seria de 1279,75 dólares por TB e o mesmo custo na Azure seria de 905 dólares. Convertendo para reais, a uma cotação de 4 reais, isso daria respectivamente R$ 5119,00 e R$ 3620,00. Enquanto isso, 5TB na GoCache tem o custo de R$ 1799,00.

Você ainda pode continuar se questionando, pois a CDN não absorve todo o conteúdo. Porém, temos observado em nossos clientes que pelo menos nos casos de e-commerces e portais de conteúdo, a eficiência de cache não costuma ficar abaixo de 80%. Neste caso, em um cenário em que a aplicação de um e-commerce está na AWS, seu custo com data transfer out seria reduzido para 1023,80 reais. Somando aos custos da CDN, daria um gasto total de 2823,80 reais, ou seja, uma economia de 2296,20 reais, que no caso, representa 49%. Uma outra alternativa seria transferir via CDN apenas conteúdo estático, ampliando ainda mais a economia obtida.

Eficiência de cache para apenas conteúdo estático

Falando mais especificamente de GoCache agora, você tem a vantagem de se proteger das variações de câmbio. A maioria dos provedores de Cloud e CDN são internacionais e mantêm sua cobrança ancorada no dólar (a exemplo de AWS e Azure). Isso é um fator que traz um enorme risco, pois, como você sabe, o Brasil é um país de economia extremamente instável. Além disso, existem impostos para a importação de serviços de TI que, somados, podem representar a um acréscimo de 50% no valor contratado. Isso vale mesmo que você utilize uma região do cloud localizada no Brasil. Estes impostos são de responsabilidade do contratante, e, apesar de muitas empresas não o pagarem, estão criando o risco de ter um enorme passivo tributário.

Uma outra frente em que a GoCache pode ajudar é na facilidade de fazer cache de conteúdo dinâmico, que nada mais é que o cache de conteúdo que demanda processamento, como páginas html e chamadas de API. Se parte deste conteúdo é idêntico para diversos usuários, por que seus servidores precisam processá-los toda vez que alguém os requisita? Ao realizar uma política eficiente de cache dinâmico, você pode reduzir o consumo de CPU, memória, disco e banco de dados de sua aplicação, podendo redimensioná-los e potencializar ainda mais a redução de custos. Exemplos de clientes seguiram esta estratégia são a Constance e a Promobit.

Discorremos aqui diversos benefícios em termos de redução de custos que uma CDN, e, especialmente a GoCache pode trazer, sem nem mencionar os benefícios de ganhos de performance que nossos 8 servidores distribuídos pelo Brasil podem oferecer. Caso você enfrente desafios de redução de custos, te convidamos a entrar em contato com nossa equipe para lhe ajudarmos a conquistar esses objetivos.

Se você se preocupa com SEO, saiba medir a velocidade do seu site corretamente.

Se você busca ser um especialista em SEO já deve ter ouvido falar que o desempenho do website afeta seu posicionamento na SERP do Google. Essa discussão teve origem em 2010, quando o Google anunciou que passaria a usar o desempenho do site como um sinal em seus algoritmos de ranking. O motivo da inclusão se deve ao resultado de estudos internos da empresa, que indicaram que quando um site responde lentamente, os visitantes passam menos tempo nele. O efeito dessa decisão pode ser visualizado em um estudo conduzido em 2013, que indicou uma correlação entre a posição nas buscas e o tempo de resposta do primeiro byte (TTFB), como pode ser visto abaixo.

Porém, a falta de clareza de como o Google usa as informações de desempenho em seus algoritmos conduz muitos desenvolvedores e analistas de SEO ao erro, ao fazerem testes que podem conduzi-los a caminhos opostos aos objetivos ou gastarem tempo excessivo otimizando métricas que geram pouco impacto. Todo mês converso com dezenas de pessoas realizando seus testes equivocadamente, por isso achei muito importante desenvolver esse artigo para ajudar outras pessoas que passam pelo mesmo problema.

Dessa forma, espere ver neste artigo os seguintes assuntos:

  • Cuidado com métricas que não te levam a lugar nenhum;
  • Você pode estar configurando as ferramentas de teste de forma errada;
  • Você não deve se contentar apenas com ferramentas de teste.

Preocupe-se com a experiência do usuário e não com métricas pontuais

Uma das métricas mais comentadas quando se trata de otimização de desempenho de páginas web é Load Time (tempo de carregamento total da página). Porém, a suspeita de que essa não seja uma métrica ideal começa com a mesma pesquisa citada acima que indicou correlação entre TTFB e a posição no ranking do Google, quando também indicou a inexistência de correlação entre o Load Time e o posicionamento, independente do método de cálculo.

O próprio uso do TTFB como critério de indexação pelo Google foi negado no Twitter pelo conhecido integrante da empresa, John Mueller. Mas calma, isso não significa que a métrica ou o próprio desempenho não seja importantes. No mesmo tweet, ele afirma que o TTFB é um bom indicador para o desempenho sentido pelo usuário e, mais importante, “se você está focando em velocidade somente por razões de SEO, você está fazendo isso errado”.

Portanto a dica está dada: o Google procura que você faça uma página que seja rápida na percepção do usuário e não uma página otimizada para métricas específicas. Se fizer isso, por consequência, isso impactará no SEO.

Neste artigo, o Google apresenta um bom framework de como analisar se uma página é rápida. Coloque-se no lugar do usuário e faça as seguintes perguntas durante a navegação:

  • A página está funcionando?
  • A página é útil?
  • A página pode ser usada?
  • A página é agradável?

A experiência do usuário se baseia no quão rápido essas perguntas são respondidas. Por isso o Load Time não é uma métrica precisa. O carregamento total é um evento simplório que ocorre após todas essas perguntas terem sido respondidas. Já o TTFB, apesar de não dever ser o foco, como ocorre antes e é um limitante para o tempo em que todos esses eventos acontecem, tem bastante uso na hora de debugar e entender onde estão alguns gargalos que comprometem a experiência de navegação.

Como visto acima, a experiência do usuário na navegação é um assunto que pode ser extenso, portanto, para não deixar este artigo extenso, publicaremos em breve outro artigo explorando como analisar se sua página oferece uma experiência rápida ao visitante. Quer ser notificado quando for lançado? Clique aqui.

Use as ferramentas de teste corretamente

Quando vejo pessoas procurando testar a performance de seus websites, a maioria usa o PageSpeed Insights, o GT-Metrix e em menor proporção, o Webpagetest.org. O grande problema reside na forma como os testes são feitos: muitos usuários não conhecem as limitações, configurações e funcionamento de cada ferramenta de teste, executam os testes nas configurações padrão e obedecem cegamente às recomendações dadas nos resultados, podendo tomar decisões que deixarão seus sites mais lentos para os usuários e não o contrário.

Por exemplo, você sabia que o PageSpeed Insights, muito provavelmente, executa seus testes em um servidor localizado fora do Brasil? A localização exata não é conhecida, mas já fizemos testes internos que deram indícios que os IPs de onde partiam as requisições dos testes apresentavam menor latência para a Flórida, nos EUA. Por causa disso, se seu website tiver audiência brasileira e seus servidores estiverem localizados no Brasil, você pode receber uma recomendação de reduzir o TTFB, mesmo que seu website ofereça uma resposta rápida aos visitantes.

Quer outro exemplo? O GT-Metrix executa seus testes, por padrão, de uma instância localizada em Vancouver no Canadá, causando o mesmo problema citado acima sobre o PageSpeed Insights, se você não configurar corretamente. E você sabia que o GT-Metrix não detecta todas as CDNs que existem?

Isso não significa que você não deva usar essas ferramentas, basta entender seu funcionamento corretamente. No caso do PageSpeed Insights, você pode usar seu algoritmo, o Lighthouse, em suas próprias instâncias de teste, podendo realizar os teste em condições de localização que simulem melhor a localização de seus usuários. Você pode inclusive fazer o teste de seu próprio navegador: a partir da versão 60, o Chrome disponibiliza o Lighthouseem suas ferramentas de desenvolvedor, localizado na aba “Audits”. Já o GT-Metrix permite, para usuários logados, escolher a instância de teste (uma delas é no Brasil) e configurar para que ele reconheça sua CDN, caso não seja detectada.

O uso correto das ferramentas de teste também é um tema extenso e que merece ser abordado com atenção, por isso, lançaremos nos próximos dias publicaremos um guia de como aproveitar ao máximo as ferramentas de teste de desempenho. Clique aqui para receber em primeira mão.

Vá a campo

Por último, uma coisa precisa ser dita. Ferramentas de teste retratam apenas um pequeno pedaço da realidade sobre o desempenho de seu site. Diferentes usuários possuem diferentes dispositivos, navegadores, provedores de internet, localização, etc., o que faz variar bastante a experiência de um para outro. Elas são boas para fornecer um ambiente controlado para testar otimizações, mas existem formas mais apuradas de saber se seu site é realmente rápido.

W3C lançou há alguns anos a padronização para as APIs Navigation Timing e Resource Timing, uma interface a partir da qual webmasters podem consultar os tempos que o usuário experimentou em sua navegação pelo website. As versões mais novas da maior parte dos navegadores suportam essas APIs, permitindo a geração de dados de grande parte das visitas.

Existem algumas opções de ferramentas que exploram essa API. O PageSpeed Insights, por exemplo, oferece uma análise dos últimos 30 dias das métricas Primeira Exibição de Conteúdo e Atraso na Primeira Interação.

Como pode ser visto na imagem abaixo, as barras verdes indicam qual porcentagem dos usuário tiveram uma experiência considerada rápida, as barras laranja uma experiência média e as barras vermelhas, uma experiência lenta.

Existem outras ferramentas mais completas para essa análise, denominadas Real User Monitoring (RUM), como o New Relic Browser e Pingdom. Elas oferecem a visão de diversas métricas do ponto de vista dos visitantes. Caso você não tenha orçamento para contratar essas ferramentas, o Google tem um artigo que introduz como começar a aferir os tempos de navegação reais usando as APIs Navigation Timing e Resource Timing.

Conclusão

Como você pode ver acima, não existe uma métrica chave de velocidade para otimizar o SEO de seu website. Como o próprio Google busca informar, se você oferecer uma boa experiência de navegação ao visitante, isso poderá impactar o seu ranking. E você só poderá otimizar essa experiência de forma efetiva olhando para as métricas corretas e fazendo as avaliações corretamente. Fique atento que em breve lançaremos dois artigos: um retratando quais as melhores métricas de velocidade com foco no usuário e como aferir corretamente a velocidade de um site.

Se estiver com pressa em otimizar, te convidamos a fazer um teste gratuito de nossa CDN. A partir dela, seu website será entregue aos usuários em servidores mais próximos, contribuindo para reduzir o tempo de carregamento da maioria dos elementos de sua página, o que melhora sensivelmente a velocidade percebida pelo usuário. Quando for se cadastrar, entre em contato, que teremos o prazer em ajudá-lo na configuração e a testar devidamente a evolução do desempenho. Conheça em: https://www.gocache.com.br/cdn-inteligente-brasil/.

Novo Ponto de Presença (PoP) em Fortaleza

Novo Ponto de Presença em Fortaleza

PoP em Fortaleza

 

Fortal agora faz parte da rede GoCache CDN!

 

Anunciamos oficialmente a ativação do nosso mais novo Ponto de Presença em Fortaleza.

clientes GoCache com visitantes na região Nordeste passarão a ter mais um Ponto de Presença (além do PoP Salvador) melhorando a latência na região. E graça à tecnologia AnyCast toda a rede de clientes GoCache se beneficia de mais um ponto para redundância, mitigação de ataques DDoS e troca de tráfego.

 

E pode ficar de olho pois vem mais PoP por aí, em breve na Região Sul!

 

Equipe GoCache

Novo Ponto de Presença (PoP) no Rio de Janeiro

Novo Ponto de Presença no Rio de Janeiro

Rio de Janeiro

 

A Cidade Maravilhosa agora faz parte da rede GoCache CDN!

 

É um grande prazer anunciar a ativação do nosso mais novo Ponto de Presença no Rio de Janeiro.

Clientes GoCache com visitantes nesta região passam a ter o benefício da latência ainda mais baixa e toda a rede de clientes se beneficia de mais um ponto para redundância, segurança e troca de tráfego.

 

E pode ficar de olho pois vem mais PoP por aí, em breve ativaremos Porto Alegre e Fortaleza!

 

Equipe GoCache

Case Promobit – economizando custos na AWS com a GoCache CDN

Este post é muito especial, pois foi escrito espontâneamente pelo Leandro Menezes dos Anjos, CIO da Promobit.

Aprecie sem moderação!

 

Redução de custos com AWS e CDN

 

Neste artigo, eu gostaria de compartilhar meu feedback de como a GoCache ajudou o Promobit a trafegar com 8x mais requisições por segundo na BlackFriday sem aumentar nossos custos e, o mais importante, com alta performance.

 

Ocupo a posição de CIO no Promobit, sendo o responsável pela infraestrutura da Startup, ou seja, minha responsabilidade vai desde a segurança, estabilidade e escalabilidade até os cuidados com os custos de servidor que nossa plataforma possa gerar.

 

Somos hoje a maior comunidade de compartilhamento de ofertas do Brasil. Desde 2014 estamos desenvolvendo uma plataforma colaborativa capaz de reunir as melhores promoções do e-commerce, sem esquecer da segurança e da qualidade do conteúdo.

A situação

Com o alto crescimento da nossa plataforma, precisamos mudar nossa infraestrutura e, como qualquer empresa, ainda mais sendo uma startup, o custo é uma questão muito importante. Optamos por escolher a AWS (Amazon Web Services) como solução para nossos servidores, pela facilidade de implementação e pelo aparente preço justo pelo serviço.

 

Não se engane: a AWS possui um leque de soluções sem igual, que facilita e muito a vida do seu SysAdmin e muitas vezes até dispensa tal cargo em sua empresa, quando bem praticada a cultura de DevOps. Mas toda facilidade tem seu preço. No caso da AWS, você paga pelo uso.

O problema

Parece justo não é mesmo? O problema acontece quando você precisa escalar. Quando você deixa 1 servidor web virar 8 para aguentar um pico de acessos no BlackFriday e seu trafego de dados passa de 1 terabyte para 3 ou 4 terabytes mensais.

 

Apenas nesses dois fatores o custo se elevaria significativamente, não concorda?

 

Vamos ao mundo real.

 

Em um acesso na timeline do Promobit, temos aproximadamente 30 requisições apenas de produtos listados e fotos de usuários, fora o HTML, Javascript e CSS que são utilizados para renderizar a página.

 

Vamos pensar que essas imagens possuam uma média de 190 bytes (peguei uma como base), 190 x 30 requisições = 5,7KB. Parece pouco, mas vamos pensar que esse trafego é apenas um acesso e um único usuário.

Em um pico de BlackFriday, em que tivemos cerca de 50 mil usuários simultâneos entre Web e Mobile, você chega a 1.500.000 requisições e 285 megabytes, isso com apenas um acesso de cada usuário.

 

Estamos falando apenas de imagens, que são arquivos estáticos e que eu poderia cachear em algum lugar por não haver nenhum processamento por parte do servidor, é apenas servir a imagem.

A solução

Pensando nisso adotamos a GoCache para servir como nossa CDN, ficando responsável por cachear parte do conteúdo e servir esse mesmo conteúdo a nossos usuários sem precisar encostar em nossos servidores novamente.

 

Agora quando um usuário acessa a Timeline e faz aquelas 30 requisições, elas são cacheadas. Na prática, o que acontece é que das 1.500.000 requisições que eu deveria receber apenas por servir imagens, agora eu recebo apenas 30. As outras 1.499.970 requisições a GoCache responde por mim com o conteúdo correto.

 

Com isso obtivemos a economia de uma máquina, uma vez que eu recebia essas requisições pelo meu EC2 e depois redirecionava o acesso aos arquivos em um S3.

Agora eu preciso de menos maquinas WEB e meu site responde mais rápido, uma vez que ele se preocupa apenas com o conteúdo dinâmico, e eu economizo banda do meu S3, que é um dos fatores de custo da AWS.

 

Falando em números:

consumo promobit

Hoje economizamos em média 95% da nossa banda com a CDN e uma média de 87% das requisições nós não precisamos nos preocupar em processar a resposta.

 

Isso reflete em toda a infraestrutura da aplicação. Não utilizamos esse conceito apenas para arquivos estáticos, mas algumas páginas com conteúdo dinâmico também. Então economizamos com nosso trafego interno entre as máquinas, processamento e memória RAM de servidor de banco de dados, servidor de cache, load.balancer, servidores web etc. Ou seja, tudo que possa envolver uma requisição e que eu possa de alguma forma cachear a resposta HTTP, eu posso deixar nas mãos desse serviço.

O resultado

Essa economia resulta diretamente em nosso financeiro, uma vez que um valor que giraria em torno de $1.800,00 na AWS passa a custar uma média de $700,00.

 

Acertamos em adotar a GoCache como parceira. No dia-a-dia, ela não apenas se paga pela economia que gera, mas também agrega em todo nosso ecossistema, oferecendo uma experiência melhor a nossos usuários e entregando nosso conteúdo de forma mais rápida, além da proximidade com seus clientes, em que fazem um ótimo trabalho de coletar feedbacks e implementar funcionalidades que realmente utilizamos.

Estratégias de Cache, Políticas, Cabeçalhos e Terminologias

Noções básicas de políticas de cache: terminologia, cabeçalhos HTTP e estratégias de cache

 

O armazenamento de conteúdo em cache é uma das formas mais eficazes de melhorar a experiência para os visitantes do seu site. O armazenamento em cache, ou armazenamento temporário de páginas e conteúdo, faz parte da estratégia de aceleração da navegação, usando protocolos HTTP ou HTTPS.

Neste artigo, discutiremos alguns dos conceitos básicos de armazenamento de conteúdo nas caches de navegadores e em proxies reversos (CDN). Vamos falar sobre as diferentes políticas de cache, os benefícios que o cache oferece, os efeitos colaterais que se deve ter em mente, e as diferentes estratégias para fornecer a melhor combinação entre desempenho e flexibilidade.

O que é cache?

Resumidamente, cache é o armazenamento de dados em uma memória de rápido acesso, visando acelerar a entrega de conteúdos que já foram solicitados anteriormente e armazenados nessa memória.

Por exemplo, uma página pode levar 3 segundos para ser gerada, contando o processamento do conteúdo, acesso ao banco de dados, etc. Mas se, após ser gerada pela primeira vez, armazenarmos essa página em um cache, as requisições futuras a esta página poderão ser entregue em milésimos de segundos. Isto aumentará muito o desempenho do seu site, reduzindo drasticamente a sobrecarga no seu servidor e melhorando a experiência do usuário.

Existem diferentes tipos de cache e cada um possui suas próprias características.

O cache de Web, ou web caching, é um tipo diferente de cache utilizado em CDNs e Navegadores, e é o foco deste artigo. O armazenamento em web cache é um recurso muito importante do protocolo HTTP/HTTPS, destinado a minimizar o tráfego de rede, ao mesmo tempo em que melhora a capacidade de resposta do sistema como um todo. Caches são encontrados em todos os níveis do percurso feito entre o conteúdo, no servidor, até o usuário, no navegador.

O web cache funciona armazenando, em um servidor intermediário ou em seu navegador, as respostas HTTP(S) para pedidos já efetuados, de acordo com determinadas regras. Futuras solicitações deste conteúdo poderão ser entregues a partir dos dados no cache mais próximo do usuário, em vez de reenviar o pedido de volta ao servidor original.

Benefícios:

O armazenamento em cache auxilia tanto os visitantes dos sites (consumidores de conteúdos), quanto os fornecedores de conteúdo. Alguns dos benefícios que o cache pode trazer são:

  • Redução dos custos de rede: o conteúdo pode ser armazenado em cache em vários pontos do caminho entre o usuário e a origem do conteúdo. Por exemplo: pode ser armazenado em uma CDN ou mesmo no próprio Navegador do usuário. Quando o conteúdo é armazenado próximo do usuário, os pedidos causarão menos atividade na rede e menos consumo de banda.
  • Melhor capacidade de resposta : o armazenamento em cache permite que o conteúdo seja recuperado mais rápido, pois a requisição não precisa ir até o servidor original e nem precisa ser recriado a partir do zero. Caches mantidos perto do usuário, como no cache do navegador, podem fazer essa recuperação instantaneamente.
  • Maior desempenho com o mesmo hardware : no servidor onde o conteúdo se originou, pode-se conseguir um grande aumento de desempenho, através de politicas de cache mais agressivas. Pode-se também aproveitar os servidores que estão ao longo do caminho para dividir a carga do sistema.
  • Disponibilidade de conteúdo durante interrupções de rede : usando as politicas de cache corretas, o armazenamento em cache pode ser usado para servir conteúdo para usuários mesmo se o seu servidor principal ficar fora do ar.

Terminologia:

Ao lidar com o armazenamento em cache, há alguns termos que provavelmente você encontrará e que talvez não sejam familiares. Alguns dos mais comuns estão abaixo:

  • Servidor de origem : o servidor de origem é o local onde está o conteúdo original. Se você atua como administrador de um servidor web, provavelmente esta é a máquina que você controla. Este servidor é responsável por servir qualquer conteúdo que não possa ser armazenado no cache, ou que tenha que, de tempos em tempos, ser atualizado.
  • Cache hit ratio (Taxa de acerto de cache) : a eficiência do sistema é medida conforme a taxa em que os dados são encontrados na cache. O Cache Hit Ratio é a relação entre o total de pedidos feitos à cache e o total destes pedidos que foram encontrados na cache. Uma alta taxa ‘hits’ (acertos) de cache significa que você está recuperando de forma rápida a maior parte do conteúdo desejado. Este é geralmente o resultado almejado pela a maioria dos administradores.
  • Freshness (Frescor): Freshness é um termo usado para descrever se um item dentro do cache ainda é considerado “fresco”, ou seja, apto para ser entregue ao usuário. O conteúdo em um cache só será usado para responder uma requisição se estiver dentro do tempo de ‘freshness’, ou período de validade, especificado pela política de cache. Caso contrário, ele será considerado obsoleto e será descartado. Um novo conteúdo será então requisitado ao servidor de origem.
  • Conteúdo obsoleto: um conteúdo é considerado obsoleto quando o tempo que ele está na cache é maior que o tempo definido como freshness. Conteúdo “expirado” é o mesmo que      “obsoleto”. Em geral, o conteúdo expirado não pode ser usado para responder às solicitações do cliente. O servidor de origem deve ser contactado para recuperar o novo conteúdo ou, pelo menos, confirmar que o conteúdo em cache ainda é atual.
  • Validação: os itens obsoletos no cache podem ser revalidados para atualizar seu tempo de expiração. A revalidação envolve uma verificação com o servidor de origem para ver se o conteúdo em cache ainda representa a versão mais recente do item, ou se precisa ser atualizado.
  • Invalidação: a invalidação é o processo de remoção de conteúdo do cache, antes mesmo que este extrapole a data de validade previamente especificada. Isso é necessário, por exemplo, se o item foi alterado no servidor de origem e existe uma cópia antiga no cache. Neste caso, a versão antiga que está no cache precisará ser invalidada.

Existem muitos outros termos sobre cache, mas os acima mencionados devem ajudar bastante por agora.

 

O que pode ficar em cache?

Alguns conteúdos são melhores para armazenamento em cache do que outros. Podemos citar, por exemplo:

  • Logotipos, fotos e imagens em geral
  • Imagens não rotativas (ícones de navegação, por exemplo)
  • Folhas de estilo (CSS)
  • Arquivos Javascript
  • Conteúdos disponíveis para download
  • Arquivos de mídia (fotos, vídeos, etc)

Estes conteúdos são conhecidos como conteúdos estáticos, pois tendem a mudar com muito pouca frequência. Com isso, eles podem ficar armazenados no cache por longos períodos de tempo.

Alguns itens que você precisa ter cuidado no armazenamento em cache são:

  • Páginas HTML
  • Imagens rotativas
  • JavaScript e CSS frequentemente modificados
  • Conteúdo solicitado com cookies de autenticação

Alguns itens que quase nunca devem ser armazenados em cache são:

  • Dados relacionados a operações sensíveis (informações bancárias, etc.)
  • Conteúdo que é específico de cada usuário e freqüentemente alterado

Além das regras gerais acima, é possível especificar políticas que permitem armazenar em cache, de forma adequada, diferentes tipos de conteúdo. Por exemplo, se os usuários autenticados veem a mesma versão do seu site, pode ser possível armazenar em cache essa visualização. Se os usuários autenticados tem uma visualização muito personalizada do site, você pode pedir para o navegador do usuário armazenar os dados no cache local, e estes dados não precisam ser armazenados em caches intermediárias.

 

Locais onde o conteúdo da Web fica em cache (ou “cacheado”)

O conteúdo de seu site pode ser armazenado em caches presentes em diferentes pontos do caminho de entrega dos dados:

  • Cache do navegador : os próprios navegadores da Web mantêm um pequeno cache. Normalmente, o navegador define uma política que determina os itens mais importantes para armazenar em cache. No entanto, através do cabeçalho HTTP(S), você pode também sugerir ao navegador os arquivos que ele deve armazenar no cache e por quanto tempo deve mantê-los.
  • Proxies de cache intermediário: qualquer servidor que fique entre o usuário e o seu servidor de origem pode armazenar alguns conteúdos em cache. Esses caches são normalmente mantidos por provedores ou outras empresas. Por exemplo, seu provedor de internet provavelmente possui um servidor de cache para dados do Netflix e Youtube.
  • Cache ou Proxy Reverso: em sua-infraestrutura você pode ter um servidor de cache para serviços back-end. Desta forma, o conteúdo pode ser servido a partir de um ponto mais próximo do cliente, ao invés de ter que acessar o servidor de origem a cada nova requisição. Uma CDN implementa este tipo de Cache ou Proxy Reverso.

Cada um desses locais pode armazenar itens no cache, de acordo com suas próprias políticas e as políticas de cache definidas na origem do conteúdo.

 

Caching Headers (Cabeçalhos de cache)

A própria entidade de cache (navegador, servidor, etc) pode decidir se deve ou não armazenar um conteúdo no sistema. No entanto, a maioria do comportamento de cache é determinada pela política de cache, que é definida pelo proprietário do conteúdo. Essas políticas são definidas principalmente através do uso de cabeçalhos HTTP específicos.

Através da evolução do protocolo HTTP, alguns cabeçalhos para cache foram surgindo, com diferentes níveis de sofisticação. Os descritos abaixo você necessariamente precisa conhecer:

  • Expires : O cabeçalho Expires é muito direto. Basicamente, ele define um tempo no futuro, quando o conteúdo irá expirar. Após a data definida em Expires, o conteúdo é considerado obsoleto e qualquer requisição precisará chegar até o servidor de origem.
  • Cache-Control : Esta é a substituição mais moderna do cabeçalho Expires . É bem suportado e implementa um mecanismo muito mais flexível. Em quase todos os casos é preferível utilizá-lo ao invés de Expires, mas não há problema utilizar os dois. Discutiremos as diferentes formas de configurar o Cache-Control um pouco mais tarde.
  • Etag : O cabeçalho Etag é usado para a validação do cache. O servidor de origem pode fornecer um Etag exclusivo para cada item, quando ele é inicialmente entregue. Quando o cache precisa validar o conteúdo de um item, ele pode enviar o Etag ao servidor, que dirá se aquele item ainda é válido ou se precisa ser atualizado (recebendo um o novo Etag). Pode também ser considera um tipo de fingerprint, ou impressão digital do arquivo.
  • Last-Modified : Este cabeçalho especifica a última vez que o item foi modificado. Isso pode ser usado como parte da estratégia de validação para garantir conteúdo atualizado.
  • Content-Length : Embora não envolvido especificamente no cache, o cabeçalho Content-Length é importante ao definir políticas de cache. Certos softwares se recusam a armazenar em cache o conteúdo se ele não conhece antecipadamente o tamanho, pois ele precisará reservar espaço de armazenamento.
  • Vary : um cache normalmente utiliza o endereço do ‘host’ (ou servidor) e o caminho do arquivo como identificador para armazenar um item na memória. O cabeçalho Vary pode ser usado para dizer ao cache que ele deve prestar atenção também a outros cabeçalhos adicionais, antes de decidir se um pedido é para um mesmo conteúdo. Isso é mais comumente utilizado em conjunto com cabeçalho Accept-Encoding, solicitando que o cache diferencie itens com conteúdo comprimido ou descompactado.

Um pouco mais sobre o Header Vary

O cabeçalho Vary fornece a capacidade de armazenar diferentes versões do mesmo conteúdo à custa de dividir as entradas no cache.

No caso de Accept-Encoding , a configuração do cabeçalho Vary permite uma distinção entre o conteúdo comprimido e não comprimido. Isso é necessário para atender corretamente os navegadores que não podem manipular o conteúdo compactado. Um ponto que mostra que Accept-Encoding é normalmente um bom candidato para Vary é o fato de que ele só tem dois ou três valores possíveis.

No entanto, à primeira vista uma outra boa ideia seria utilizar o Vary junto com o header User-Agent, como forma de diferenciar entre a versão de seu site para celulares e a versão convencional. No entanto, uma vez que os dados de User-Agent não são padronizados, você terá provavelmente muitas versões de um mesmo item no cache, deixando-o muito ineficiente. Portanto o cabeçalho Vary deve ser utilizado com moderação.

 

Como as flags de controle de cache impactam no desempenho

Anteriormente, mencionamos que o cabeçalho Cache-Control é usado para definir políticas de cache modernas. Uma série de instruções diferentes podem ser definidas usando este cabeçalho, com as instruções sendo separadas por vírgulas.

Algumas das opções de Cache-Control que você pode usar são:

  • no-cache : Esta instrução define que o conteúdo armazenado em cache deve ser re-validado em qualquer nova solicitação. Ou seja, esta flag marca o conteúdo como obsoleto imediatamente, mas permite que o cache use técnicas de revalidação para evitar baixar o item inteiro novamente.
  • no-store : esta instrução indica que o conteúdo não deve ser armazenado em cache de forma alguma. Isso é apropriado para, por exemplo, definir dados confidenciais.
  • public : marca o conteúdo como público, o que significa que ele pode ser armazenado em cache pelo navegador e em quaisquer outros caches intermediários. Nas solicitações que utilizam a autenticação HTTP, as respostas são marcadas como private por padrão. Este cabeçalho, public, server para substituir essa configuração.
  • private : marca o conteúdo como privado. O conteúdo privado pode ser armazenado pelo navegador do usuário, mas não deve ser armazenado em caches intermediárias. Isso geralmente é usado para dados que se referem a cada usuário.
  • max-age : Esta configuração define a “idade máxima” de um conteúdo, ou seja, o tempo máximo que ele pode ficar no cache sem ser revalidado com o servidor de origem. Em essência, isso substitui o cabeçalho Expires. Esta opção tem seu valor definido em segundos, com um tempo máximo de um ano (31536000 segundos).
  • s-maxage : Este cabeçalho é muito semelhante ao max-age, pois indica a quantidade de tempo que o conteúdo pode ser armazenado em cache. A diferença é que esta opção é aplicada apenas a caches intermediários e não ao navegador. Combinar isso com o cabeçalho “max-age” permite uma construção de políticas mais flexíveis de cache.
  • must-revalidate : Este header reforça que o tempo de expiração, indicado por max-ages-maxage ou por Expires, deve ser obedecido de forma estrita. O conteúdo obsoleto não pode ser entregue ao usuário sob nenhuma circunstância. Isso evita que o conteúdo em cache seja usado em caso de interrupções de rede, queda de servidores, ou cenários semelhantes.
  • proxy-revalidate : Isso funciona da mesma forma que a configuração acima (must-revalidate), mas se aplica apenas aos proxies, CDNs, ou servidores intermediários. Nesse caso, o navegador do usuário pode usar um conteúdo obsoleto se ocorrer uma falha na rede, mas serviços de caches intermediários devem, obrigatoriamente, revalidar o conteúdo se o mesmo ficar obsoleto.
  • no-transform : esta opção determina que o cache não tem permissão para modificar o conteúdo recebido, nem  por motivos de desempenho, nem  qualquer outra circunstância. Isso significa que, por exemplo, o cache não pode enviar versões compactadas do conteúdo se recebeu do servidor de origem uma versão não compactada.

Estas flags podem ser combinadas de diversas maneiras para configurar diferentes comportamentos de cache. Apenas algumas flags mutuamente exclusivos:

  • no-cache ou no-store são opostos ao comportamento padrão de uma cache
  • public e private são opostos entre si

A opção no-store substitui o no-cache se ambos estiverem presentes.

Para respostas a pedidos não autenticados, o cabeçalho public estará implícito e para respostas a pedidos autenticados, o cabeçalho private estará implícito. No entanto eles podem ser substituídos, incluindo a opção oposta no cabeçalho Cache-Control .

 

Desenvolvendo uma estratégia de cache

Em um mundo perfeito, tudo poderia ser armazenado em cache, de forma agressiva, e seus servidores só seriam acessados ocasionalmente para validar o conteúdo.  Isso geralmente não acontece na prática, então você precisa tentar definir algumas políticas de cache, visando o equilíbrio entre um cache de longo prazo e resposta às demandas de mudanças em um site.

Problemas comuns

Existem muitas situações em que o cache não pode ou não deve ser implementado devido à forma como o conteúdo é produzido (gerado dinamicamente para cada usuário ou a cada momento) ou a natureza do conteúdo (informações bancárias confidenciais, por exemplo).

Outro problema que muitos administradores podem enfrentear é a existência versões ainda válidas no cache, mesmo após novas versões das páginas terem sido publicadas.

Estes são problemas frequentemente encontrados e que podem ter sérios impactos no desempenho do cache ou na precisão do conteúdo que você está servindo. No entanto, podemos atenuar essas questões ao desenvolver políticas de cache antevendo tais problemas.

Recomendações gerais

Sua estratégia de cache será determinada pelas necessidades do seu site, no entanto, as recomendações a seguir podem ajudá-lo a tomar decisões razoáveis.

Existem alguns passos que você pode dar para aumentar a eficiência de seu cache, antes mesmo de se preocupar com detalhes ou cabeçalhos específicos. Algumas idéias são:

  • Estabeleça diretórios específicos para imagens, css e conteúdo compartilhado : Ao desenvolver seu site, coloque conteúdos em diretórios dedicados, que permitirá que você se refira facilmente a eles a partir de qualquer página em seu site. Isso aumenta a reusabilidade desses arquivos e a probabilidade de encontrá-los no cache.
  • Use o mesmo URL para se referir aos mesmos itens : como dissemos, o host e o caminho do arquivo são normalmente usados para identificar um conteúdo. Portanto, utilize sempre o mesmo URL para se referenciar a um mesmo conteúdo, evitando duplicar conteúdos idênticos no cache. A recomendação anterior torna isso significativamente mais fácil.
  • Use os sprites de imagem do CSS: os sprites de imagem CSS permitem colocar várias imagens e ícones em um único arquivo. Desta forma, você diminui o número de requisições ao seu servidor e aumenta a probabilidade de encontrar o arquivo com sprites no cache.
  • Armazene alguns Scripts e recursos externos localmente : se você utilizar scripts de javascript e outros recursos externos, considere hospedar esses recursos em seus próprios servidores caso os cabeçalhos não estejam sendo corretamente configurados no servidor externo. No entanto, note que você terá que sempre manter atualizada a cópia desse recurso externo em seu servidor.
  • Uso de fingerprint (impressão digital) : para conteúdo estático, como arquivos CSS e Javascript, pode ser interessante o uso do que chamamos de Impressão Digital, ou fingerprint. Isso significa adicionar um identificador exclusivo ao nome do arquivo para que, se o recurso for modificado, o novo recurso possa ser solicitado através do novo nome. Isso fará com que os novos pedidos ignorem a versão antiga do arquivo que poderá estar no cache. Há uma variedade de ferramentas que podem ajudar a criar impressões digitais e modificar, automaticamente, as referências a elas nos documentos HTML.

Sobre escolher adequadamente os cabeçalhos, para diferentes itens, pode-se utilizar as seguintes dicas:

  • Permitir que todos os caches armazenem itens genéricos : o conteúdo estático e o conteúdo que não é específico de um usuário podem, e devem, ser armazenados nos caches em todos os pontos da cadeia de entrega.
  • Permitir que os navegadores armazenem os recursos específicos do usuário : para o conteúdo referente a cada usuário, é geralmente aceitável e útil permitir o armazenamento no cache do navegador. Embora este conteúdo não seja apropriado para armazenar no cache de proxies intermediários, o cache no navegador permitirá uma recuperação instantânea nas próximas visitas destes usuários.
  • Faça exceções para conteúdos importantes e sensíveis ao tempo : se você tiver algum conteúdo que muda com o tempo, faça exceções às regras acima para que este conteúdo esteja sempre atualizado no cache. Por exemplo, se o seu site tiver um carrinho de compras, ele deve sempre refletir os itens no carrinho, imediatamente. Dependendo da natureza do conteúdo, as opções no-cache ou no-store podem ser definidas no cabeçalho Cache-Control para conseguir isso.
  • Forneça sempre validadores : os Validadores permitem que o conteúdo obsoleto seja atualizado sem precisar baixar o item inteiro novamente. Configurando os headers Etag e Last-Modified,permite-se que o cache valide se o conteúdo não foi modificado na origem, evitando baixá-lo novamente, reduzindo assim a carga na rede e aumentando a velocidade.
  • Defina longos tempos para a expiração do conteúdo de base : para otimizar o cache, os elementos que são solicitados como conteúdo de base para renderização do site, devem ter longos períodos de expiração. Isso geralmente é apropriado para itens como Imagens e arquivos CSS, que são usado para desenhar a página HTML solicitada pelo usuário. Definir tempos de expiração longos, combinados com impressões digitais, permitem que os caches armazenem esses recursos por longos períodos de tempo. Se os conteúdos mudarem, a nova impressão digital invalidará o item armazenado em cache e desencadeará o download do novo conteúdo.
  • Defina tempos curtos de expiração para o conteúdo original : para que o esquema acima funcione bem, conteúdos que dependem de cado usuário ou que mudam constantemente, devem ter tempo de expiração relativamente curto ou nem devem ser armazenados em cache. Normalmente são páginas dinâmicas, que geram um HTML que pode mudar conforme o momento, e que irão utilizar a ideia de impressões digitais (fingerprint) para carregar novos conteúdos estáticos caso seja necessário.

A ideia chave é encontrar um equilíbrio que favoreça um armazenamento em cache agressivo, ou seja, generalizado e por longo tempo, sempre que possível. Mas que preveja formas de invalidar alguns conteúdos no futuro, caso mudanças sejam feitas.

Seu site provavelmente terá uma combinação de:

  1. Itens agressivamente armazenados em cache
  2. Itens em cache com um curto período de expiração e a capacidade de revalidação
  3. Itens que não devem ser armazenados em cache

O objetivo é mover o conteúdo para as primeiras categorias quando possível, mantendo um nível aceitável de precisão.

 

Conclusão

Gastar um tempo para garantir que seu sistema tenha políticas de cache apropriadas terá um impacto significativo na velocidade do seu site. O armazenamento em cache permite que você reduza os custos com uso de banda. Seu servidor também poderá lidar com uma maior quantidade de tráfego com o mesmo hardware. E o mais importante, os clientes terão uma experiência mais rápida no seu site, o que pode levá-los a retornar com mais freqüência, aumentando as vendas de seu comércio eletrônico ou o numero de visitantes em seu blog.