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

CDN e SEO: Práticas recomendadas para melhorar seus resultados

/0 Comentários/em , /por

Sabe-se que o trabalho de SEO é bastante complexo e envolve uma série de fatores que vão desde a qualidade do conteúdo produzido até os aspectos técnicos da aplicação.

Nesta publicação vamos falar especificamente sobre como o uso da CDN pode contribuir com o SEO de seu projeto, otimizando algumas frentes de performance web que podem trazer ótimos resultados e diferenciar sua aplicação de seus concorrentes, já que com um mercado bastante maduro em relação a otimização orgânica, ajustes finos podem ser seu diferencial competitivo.

Qual a função de uma CDN?

Antes de efetivamente explicarmos como a CDN pode ajudar seu SEO, é importante entender a sua função dentro de aplicações web.

Basicamente, a tecnologia de CDN foi criada para encurtar a distância entre o conteúdo web e seus usuários, consequentemente diminuindo latência de entrega e melhorando a experiência de uso. Por exemplo, digamos que você tenha um e-commerce ou portal de noticias que receba tráfego de todo o país. Se sua infraestrutura está alocada em São Paulo, usuários de qualquer localidade precisam chegar até seus servidores para efetivamente consumir seu conteúdo. Agora, se você utilizar uma CDN com capilaridade de entrega, seus usuários passam a receber o conteúdo através de pontos de presença mais próximos, reduzindo latência e trazendo ganhos em performance.

Como a CDN reduz latência

Além da redução de latência, uma CDN também pode fazer com que sua infraestrutura ganhe disponibilidade e escalabilidade, já que boa parte de seu conteúdo será entregue em cache, sem a necessidade de consultar sua hospedagem. Vale o adendo que a disponibilidade de um website nos tempos de hoje tem sido essencial para projetos digitais, então se você costuma receber mensagens do Google Search Console sobre erros de 5xx, este é um sinal sobre possíveis problemas de disponibilidade que podem afetar seus resultados orgânicos.

Já na questão de escalabilidade, imagine que uma determinada promoção ou artigo tenha ganhado bastante visibilidade, fazendo com que seu website receba muito mais tráfego do que o usual. Caso você não tenha uma CDN ou uma infraestrutura escalável, provavelmente seu site não aguentara essa carga, fazendo com que você fique offline exatamente no momento mais importante e lucrativo.

Como a CDN pode ajudar a melhorar o tempo de carregamento de um site

Definitivamente melhorar o tempo de carregamento de um site tem sido um grande desafio para profissionais de SEO, ainda mais desde 2018 quando o Google oficializou  que a velocidade de um site é um fator de ranqueamento.

Referência: Google Developers: Velocidade é um fator de ranqueamento

Latência: Conforme citamos no inicio desta publicação, a CDN faz que seu site seja entregue com mais capilaridade, reduzindo latência de entrega e consequentemente faz com que sua aplicação seja entregue com mais velocidade.

Tempo de resposta de seu site: O tempo de resposta (server response time) basicamente é afetado pela quantidade de visitas que seu site recebe, pelos recursos utilizados para carregar cada uma de suas páginas e pela qualidade de sua infraestrutura de hospedagem.

Uma das formas de reduzir o tempo de resposta de seu site é fazendo cache dinâmico (html, json..) o que pode acelerar ainda mais sua entrega, reduzindo métricas como TTFB (time to first byte), Start Render e Load Time, além de desonerar sua infraestrutura.

Vale citar que o próprio Google recomenda que sites reduzam o tempo de resposta do servidor para menos de 200 ms.

Politica de cache mais eficiente: O uso de CDN faz com que sua aplicação tenha politicas de cache mais eficientes, permitindo que você personalize seus tempos de TTL. Dentro da GoCache é possível determinar tanto o tempo de expiração de cache dos assets entregues pela CDN quanto pelo navegadores. Inclusive, alguns testes de performance usam essas informações na composição de suas notas. Por exemplo, o PageSpeed do Google considera a configuração de cache-control max-age e sugere, quando possível, que o tempo de cache de navegador seja de um ano ou mais.

É recomendado distribuir seus assets pela raiz de seu site ou por subdomínios

Evidentemente nem sempre é possível seguir dessa maneira, porém, muitos profissionais de SEO acabam negligenciando essa questão, já que por comodidade acabam usando plugins de cache que distribuem o conteúdo estático por hashs de distribuição, o que pode reduzir a autoridade de seu domínio.

Uma prática recomendada em SEO é usar a CDN para distribuir seus assets por subdomínios (exemplo: cdn.seudominio.com.br) ou atrelados diretamente ao a raiz de seu domínio (exemplo: seudominios.com.br).

Otimize suas imagens com a CDN sem esforço técnico

Otimizar as imagens da sua aplicação fazem com que você possa ter bons ganhos de performance, e definitivamente este é um ponto importante em SEO. Normalmente, webmasters costumam otimizar suas imagens antes mesmo do upload, mas nem sempre isso é possível ou viável.

Como a otimização de imagens funciona

Nem todas as soluções de CDN conseguem otimizar imagens, mas se você optar por usar a GoCache, é possível otimizar suas imagens sem nenhum esforço técnico. Para isso, basta habilitar nosso recurso de otimização chamado de Lithio, que faz compressão de imagens, remove metadados e converte imagens para webP ou JPEG progressivo.

HTTPS é um fator de ranqueamento

Assim como o tempo de carregamento, o Google também já sinalizou oficialmente que a abertura em HTTPS é usada como fator de ranqueamento orgânico.

Sabe-se que certificados SSL não precisam ser necessariamente administrados pela CDN, mas certamente utilizar o certificado de borda é uma maneira simples de adequar seu site para HTTPS. Um ponto positivo de usar o certificado SSL da GoCache é não precisar se preocupar com a renovação, garantindo que seu site responda sempre em HTTPS.

Inclusive, caso você use WordPress e queira aprender sobre como usar o SSL da GoCache, recomendamos o artigo abaixo:

Atenção com seu robots.txt e sitemap.xml

Caso você faça cache dinâmico, é importante avaliar se seu robots.txt e sitemap.xml estão em cache e qual a periodicidade em que esse cache é renovado para garantir que esses documentos estejam sempre atualizados.

Se necessário é possível configurar a CDN para dar BYPASS nestes documentos, obrigando que a entrega desses arquivos sejam feitas diretamente por sua infraestrutura.

Fique atento as métricas de Core Web Vitals

Em Maio de 2020 o Google se manifestou explicitamente sobre quais métricas de performance seriam usadas em seu mecanismo de busca: as chamadas Core Web Vitals.

Atualmente o Core Web Vitals usa três métricas:

  • Largest Contentful Paint (LCP) – mede a renderização do maior conteúdo visível da página.
  • First Input Delay (FID) –  mede o tempo que o navegador demorou para responder após a primeira interação do usuário.
  • Cumulative Layout Shift (CLS) –  mede a quantidade de mudanças de layout visíveis e inesperadas que aconteceram na página.

Sabe-se que a CDN pode ajudar a reduzir significativamente o tempo de carregamento e renderização, contribuindo para ganhos em Core Web Vitals. Além disso, a otimização de imagens pode reduzir drasticamente o tempo de download das imagens, acelerando o carregamento da página como um todo, mas principalmente, do maior conteúdo renderizado, que costuma ser uma imagem.

Caso queira conhecer mais sobre o Core Web Vitals, recomendamos a leitura do artigo abaixo:

Teste a CDN da GoCache gratuitamente

Se você busca melhorar algumas frentes de SEO com a ajuda de uma CDN, conte com a GoCache. Experimente nosso trial gratuito de 7 dias!

O que é CloudFront da Amazon?

/0 Comentários/em /por

O CloudFront é o serviço de CDN (Content Delivery Network) da AWS, lançado em 2008 em versão beta e implementado definitivamente em 2009.

Trata-se de uma solução de CDN que é utilizada principalmente por clientes da AWS pela comodidade de implementação e é encontrado normalmente dentro de aplicações web, como por exemplo em servidores EC2 e Buckets S3, com o intuito de entregar assets estáticos como .jpg, .png, .js, .css ou dinâmicos como .html e .json em cache para reduzir latência de entrega.

Normalmente, o CloudFront da AWS é implementado dentro de aplicações web que recebem tráfego de múltiplos países e que podem se beneficiar de uma cobertura em nível global. Além das questões de redução de latência, usuários CloudFront também se beneficiam pelo aumento de disponibilidade e escalabilidade que a CDN pode trazer, já que os elementos cacheados serão distribuídos por múltiplos pontos de distribuição, também conhecidos como edge locations.

É possível servir assets da CDN da Amazon utilizando uma hash de distribuição do próprio CloudFront, como por exemplo, http://d111111abcdef8.cloudfront.net/nome-do-asset.extensao ou configurando a solução dentro de sua aplicação, permitindo que você distribua assets pela raiz de seu domínio, via www ou através de subdomínios, por exemplo http://cdn.nome-do-dominio.com.br/nome-do-asset.extensao.

Como o CloudFront funciona:

O funcionamento do CloudFront da AWS é o mesmo da maior parte das soluções de CDN. Basicamente, a CDN faz cache dos assets de acordo com as requisições dos usuários que são roteados via DNS (Domain Name System) para o ponto de presença (POP) que pode atender melhor cada uma das requisições. Sendo assim, o usuário passa a receber assets em cache através do ponto de presença mais próximo, reduzindo latência de entrega. Eventualmente se um item não está em cache, ele será entregue diretamente pela infraestrutura de hospedagem e na próxima requisição, será distribuído através de um ponto de presença.

Para entender mais sobre o funcionamento do CloudFront, confira abaixo os response headers (x-cache) mais comuns:

x-cache: HIT from CloudFront

O response header HIT é gerado sempre que um asset é entregue diretamente pelo CloudFront.

x-cache: MISS from CloudFront

O response header MISS quer dizer que o CloudFront ainda não tem o conteúdo salvo em seu edge, logo será necessário consultar o servidor de origem.

Após entregar o conteúdo com MISS, o CloudFront faz o cache desse asset. Um MISS deve virar um HIT na próxima requisição.

x-cache: BYPASS from CloudFront

Sempre que o response header BYPASS for apresentado quer dizer que o CloudFront não fará cache desse asset e a entrega será sempre feita diretamente pela origem.

Quais os pontos de presença do CloudFront?

Referência: AWS Cloudfront – POP’S CloudFront

Atualmente o CloudFront possui mais de 200 pontos de presença em todo o mundo, mas sua presença no Brasil ainda é tímida. Por aqui a empresa conta com pontos de distribuição apenas em São Paulo e Rio de Janeiro.

Caso você queira descobrir qual ponto de distribuição está servindo um determinado asset no CloudFront, é possível analisar o response header x-amz-cf-pop que apresenta o nome do edge location que distribuiu o conteúdo. Para conteúdos distribuídos por pops do Brasil, os códigos encontrados são:

  • GIG51-C2 – Rio de Janeiro
  • GRU1-C1 – São Paulo
  • GRU50-C1 – São Paulo

Quais as vantagens de usar CloudFront:

Disponibilidade: Conforme citamos no início deste artigo, o CloudFront pode aumentar a disponibilidade de uma aplicação, mas para isso é necessário que seja feita uma configuração de full cache, o que naturalmente exige algum esforço técnico de implementação.

Latência: É possível reduzir latência de entrega utilizando uma solução de CDN como CloudFront, porém é necessário lembrar que dentro do Brasil existem pontos de distribuição apenas no sudeste do país (São Paulo e Rio de Janeiro).

Segurança: Por padrão, a CDN lida com as requisições de uma aplicação trazendo ganhos em segurança, funcionando como um “escudo” contra ataques primários como DDoS. Além disso, é possível utilizar SSL/TLS para entrega.

Quais as desvantagens de usar CloudFront:

Custos: O CloudFront é uma solução de CDN atrativa para usuários AWS pela comodidade de integração, porém é importante entender os custos atrelados a isso. Atualmente o custo de cada GB trafegado via CloudFront é de 0,11 USD. Trata-se de um custo ancorado ao valor do dólar, o que acaba trazendo imprevisibilidade para a operação, ainda mais se considerarmos o cenário de oscilação cambial em que vivemos hoje.

Outro ponto negativo da precificação do CloudFront é que existe um abismo entre os planos de consumo. É necessário trafegar mais de 40 TB por mês para reduzir os custos de 0,11 USD por GB para 0,105 USD.

Além dos custos por tráfego, o CloudFront também realiza cobranças por requisições (ou solicitações HTTP/HTTPS), sendo 0,022 USD a cada 10.000 requisições. Ainda que sua aplicação seja bem construída e otimizada para economizar banda, você será cobrado por todas as requisições entregues pelo CloudFront.

Capilaridade de entrega no Brasil: É inegável que a AWS possui um portfólio com serviços de qualidade, mas sua presença com o CloudFront no Brasil é bastante tímida já que a empresa conta com pontos de distribuição apenas no Rio de Janeiro e São Paulo. Vivemos em um país com dimensões continentais e com grandes desafios de conectividade, principalmente em regiões mais afastadas do eixo RJ/SP, sendo assim a aderência do CloudFront para aplicações dentro do país é baixa.

Configuração complexa: É possível fazer regras com bastante granularidade dentro do Amazon CloudFront, mas para isso existe uma curva de aprendizagem longa. Vários usuários AWS relatam ter dificuldade em encontrar diversas informações e opções dentro do painel e o reflexo disso acaba sendo a implementação de configurações simples com apenas cache de assets estáticos e por muitas vezes com baixa eficiência de cache.

GoCache é uma alternativa viável em comparação ao CloudFront?

Sim. Ainda mais quando a maior parte do tráfego está concentrado no Brasil.

É natural duvidar que uma solução brasileira tenha desempenho comparável com a solução de CDN da Amazon, mas graças a nossa capilaridade de entrega, certamente a GoCache pode ser uma solução mais aderente ao seu negócio. Você pode ver abaixo um gráfico extraído da ferramenta de performance PerfOps comparando a entrega do CloudFront x GoCache:

Referência: Dados do PerfOps extraídos em março de 2020

Também é possível fazer comparações de latência por múltiplas origens utilizando a ferramenta de testes da ISP Tools que conta com mais de 100 provedores em todas as regiões do Brasil através dos links abaixo:

Consulta de resultados AWS:
http://www.isptools.com.br/ping#548!0!aws.amazon.com

Consulta de resultados GoCache:
http://www.isptools.com.br/ping#287!0!www.gocache.com.br

E caso queira entender um pouco mais sobre as vantagens de utilizar os serviços da GoCache como alternativa ao CloudFront, recomendamos a leitura dos artigos:

Quer conhecer nossa plataforma de CDN?

Experimente os recursos da GoCache gratuitamente por 7 dias.

Como uma CDN mitiga ataques DDoS?

/0 Comentários/em , /por

Ataques DDoS são uma das maiores dores de cabeça para quem administra uma infraestrutura ou aplicações web hoje em dia. O termo é uma abreviatura para Distributed Denial of Service, o que em português significa Ataque Distribuído de Negação de Serviço. O objetivo de quem está por trás deste tipo de ameaça é tirar do ar o servidor de uma aplicação específica, por meio do congestionamento de sua rede ou pela sobrecarga de seus servidores. Ele faz isso usando uma rede de computadores escravos que enviam simultaneamente uma grande quantidade de requisições e pacotes de rede, em um nível que a infraestrutura da vítima não suporta, ou pelo menos tenha sua performance degradada.

A natureza distribuída do DDoS é o que torna sua mitigação um desafio. No caso de um ataque DoS simples (de apenas uma máquina), o comportamento é mais fácil de detectar, pois destoa dos demais, e um simples bloqueio do IP do atacante pode resolver o problema. Mas, mesmo neste cenário, ainda desestabiliza a equipe de operações de uma empresa que não possui nenhum tipo proteção, pois pode ocorrer a qualquer hora e não deixa avisos.

Neste contexto as CDNs surgiram como alternativa de proteção contra essa ameaça. Por estarem na linha de frente em termos de rede e por possuírem grande capacidade de tráfego e processamento, se tornaram soluções ideais para tratar e resolver estes casos. Nos próximos tópicos vamos mostrar o procedimento adotado pela CDN GoCache na mitigação de DDoS, mas antes vamos dar uma visão geral sobre as 3 principais categorias de ataques.

Categorias de ataques DDoS

Ataques de Negação de Serviço podem ser classificados em 3 categorias: Ataques Volumétricos (Volumetric Attacks), Ataques por Exploração de Protocolos (Protocol Attacks) e Ataques na Camada de Aplicação (Application Layer Attacks).

Ataques volumétricos têm o objetivo de saturar banda do aplicação alvo, ou seja, buscam congestionar o tráfego dela. Alguns exemplos  são UDP floods e ICMP floods. Ataques por exploração de protocolos almejam esgotar toda a capacidade de equipamentos de rede e transporte (conhecidas como camadas 3 e 4) através da exploração de vulnerabilidades nos protocolos de comunicação, como em ataques SYN flood, e Ping of Death. Já os ataques a camada de aplicação (ou camada 7) exaurem os servidores que geram e enviam os conteúdos que os visitantes veem, ao enviarem inúmeras requisições HTTP/HTTPS, que podem ser em seções que oneram bastante o servidor. HTTP flood é um tipo deste ataque.

Camadas do modelo OSI

Tolerância ao aumento de tráfego trazido por ataques

A mitigação de DDoS reside na filtragem do tráfego, permitindo apenas tráfego legítimo o tanto quanto possível. Porém, quem realiza essa filtragem precisa ter a disposição uma grande largura de banda e uma grande capacidade de processamento, sob pena de ter os recursos esgotados antes de responder à ameaça devidamente. Fazer isso em uma CDN é uma proposta muito mais eficiente, uma vez que, por processar milhares de sites simultaneamente, ela possui capacidade ociosa muito maior do que a de um site isolado, seja em termos de banda de internet ou de capacidade de processamento e memória.

Dentro deste mesmo aspecto, a rede Anycast da GoCache também auxilia neste papel. Anycast é um método de roteamento no qual um IP pode fazer referência a diferentes destinos, no caso, algum de nossos 8 pontos de presença (PoPs) em data centers. Em situações normais, o IP aponta para o ponto de presença mais próximo, mas em situações de ataque, o método pode distribuir sua carga entre todos os PoPs de nossa rede, o que potencializa o uso de toda nossa capacidade no processo de mitigação e minimiza o risco de falhas pontuais.

Mitigação nas camadas de rede e transporte

Um ataque que nossos clientes recebem é um ataque que nós recebemos diretamente. Por mais que abusos nas camadas 3 e 4 não são repassados aos servidores de nossos clientes, pois não possuem nenhum conteúdo que faça sentido para a aplicação, precisamos tratá-los para não desperdiçar recursos e correr o risco de degradar nossa própria performance.

Exemplo de padrão de ataque na camada 4 (SYN Flood)

Para isso, lançamos mão tanto de recursos automatizados, quanto de nossa equipe de SREs. Separar o joio do trigo é uma tarefa árdua, principalmente em ataques bem distribuídos, mas algumas pistas sempre são deixadas. Tamanho dos pacotes, conteúdo dos cabeçalhos, tipo são alguns dos fatores analisados para entender se uma tentativa de conexão é maliciosa ou não. Além disso, alguns endereços de IP são conhecidos por participar de ataques (os chamados botnets) tornando a tarefa mais fácil.

Mitigação na camada de aplicação

Ataques à camada de aplicação são mais desafiadores, pois podem parecer mais como tentativas de acessos normais. Por padrão, quando um ataque que gera uma carga perceptível na camada de aplicação, nossa equipe de SREs o mitigam para resguardar nossa infraestrutura. Porém, dependendo do quanto a infraestrutura de um site seja enxuta, um ataque muito pequeno na camada de aplicação pode derrubá-lo. Mesmo assim, alguns recursos de nossa plataforma auxiliam nessa situação

Cache de conteúdo dinâmico

O cache de conteúdo dinâmico nada mais é que fazer cache de conteúdos que exigem processamento, como HTML ou respostas de APIs, na CDN. Com isso, as respostas dessas partes da aplicação são entregues direto pela CDN, sem precisar de consultas à infraestrutura de origem que podem consumir CPU, memória, ou banco de dados. Porém, o uso deste recurso tem suas limitações. Essa estratégia não funciona com conteúdos que variam de usuários para usuário. Para ser efetiva, as respostas devem ser iguais para mais de um usuário (por exemplo, uma homepage que varia de estado para estado e não contenha dados pessoais de quem visita).

Mitigação Avançada de DDoS

A mitigação avançada de DDoS é um recurso que oferecemos para clientes a partir do plano Business no qual nossa equipe monitora proativamente sinais da aplicação como taxa de erros, tempo de resposta e taxa de requisições, para reagir imediatamente em casos suspeitos, inclusive, podendo trabalhar conjunto com a equipe do cliente atacado para resolver o problema.

Web Application Firewall

O Web Application Firewall ou WAF é um recurso de nossa plataforma que avalia características de uma requisição, e a bloqueia caso ela siga o padrão de alguma ameaça conhecida. Esse Firewall também permite que o usuário crie suas próprias regras de acordo com o conhecimento que tem sobre sua aplicação. O WAF não é um recurso feito para lidar diretamente com ataques DDoS, mas pode ajudar, pois muitos ataques possuem características em comum, como cabeçalhos de requisição incorretos e serem provenientes de outros países.

Rate Limiting

Por fim, o Rate Limiting é um recurso que limita a velocidade com que um usuário acessa determinada aplicação. Usuários legítimos normalmente levam algum tempo entre a execução de duas ações. Se um usuário acessa uma quantidade de páginas muito grande em um tempo muito pequeno, isso pode ser considerado suspeito, principalmente se for feito em uma seção específica de um site. Se um usuário conhece bem o padrão de acessos em sua aplicação, ele pode aplicar regras que bloqueiam visitantes que excedam uma taxa de requisições considerada normal, tendo controle inclusive para configurar diferentes limites em diferentes áreas e liberar agentes conhecidos, como bots de mecanismos de busca.

Conclusão

Usar uma plataforma de CDN para mitigar DDoS é uma das estratégias mais efetivas hoje. Ela atua como um escudo que permite que o máximo de requisições legítimas e o mínimo de requisições maliciosas atinjam o servidor onde aplicação hospedada. E ela faz isso usando uma capacidade que seria muito cara para ser adquirida dono de um site individual.

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

/0 Comentários/em , /por

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

/0 Comentários/em /por

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

/0 Comentários/em /por

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?

/0 Comentários/em /por

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.

/1 Comentário/em , , /por

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.

A 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

/0 Comentários/em /por

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