GoCache CDN
  • Produtos
    • CDN
      • Pontos de Presença
    • WAF – Web Application Firewall
    • Rate Limit
    • Lithio – Otimizador de Imagens
    • WPO – Web Performance Optimization
    • Certificado SSL
  • Soluções
    • Portais de Conteúdo e Notícias
    • E-Commerce
    • Educação / Edtech
    • Plataformas de E-Commerce
    • Startup
    • Outros
  • Planos
  • Ajuda
  • Contato
  • Login
  • CADASTRE-SE

Por que a velocidade de um site é importante? Google Playbook

12 de janeiro de 2021/0 Comentários/em Dicas /por GoCache

No artigo de hoje vamos trazer alguns pontos citados no famoso playbook do Google, intitulado como Mobile Site Speed Playbook. Vamos lá?

Por que a velocidade é importante?

Os consumidores confiam cada vez mais no celular para acessar conteúdo e serviços digitais, e se você olhar as métricas do seu site, provavelmente verá essa história se desenrolando em seus próprios dados.

Os consumidores também estão mais exigentes do que nunca e, quando avaliam a experiência no seu site, não estão apenas comparando você com seus concorrentes, eles estão classificando você em relação aos melhores serviços que usam todos os dias.

Quando se trata de experiência do usuário, a velocidade é importante. Um estudo com consumidores mostra que a resposta ao estresse relacionado aos atrasos na velocidade do celular é semelhante à de assistir a um filme de terror ou resolver um problema matemático e maior do que esperar na fila do caixa em uma loja de varejo. E os atrasos causados pela velocidade móvel não são apenas frustrantes, mas também podem ter um impacto negativo nos resultados dos negócios.

Por exemplo, em um estudo da Ericsson, foi possível identificar que um atraso de um segundo no tempo de carregamento do celular pode afetar as taxas de conversão em até 20%.

O que é velocidade?

Sabe-se que a velocidade é importante, mas o que exatamente queremos dizer com isso? O que significa ter um site rápido? É comum ouvir as pessoas falarem em termos de carregamento de seu site em x, xx segundos ou algo semelhante, mas um carregamento não é um único momento no tempo – é uma experiência que nenhuma métrica única pode capturar totalmente.

Existem vários momentos durante a experiência de carregamento que podem afetar a percepção de um usuário como ‘rápido’, e se você se concentrar apenas em um, você pode perder experiências ruins que acontecem durante o resto do tempo. Em vez de medir com apenas uma métrica, você deve cronometrar cada momento, durante a experiência, que afete a percepção do usuário sobre a velocidade de carregamento.

Quando um usuário navega em uma página da web, ele normalmente está procurando por determinados tipos de feedback:

Está acontecendo?

  • A navegação começou com sucesso?
  • O servidor respondeu?

É útil?

  • Foi renderizado conteúdo suficiente para que os usuários possam interagir com ele?

É utilizável?

  • Os usuários podem interagir com a página ou ela ainda está carregando?

É prazeroso?

  • As interações são suaves e naturais, livres de atrasos e interrupções?

As métricas de desempenho tradicionais, como tempo de carregamento ou DOM Content Loaded, não são confiáveis, uma vez que sua ocorrência pode ou não corresponder a esses marcos de feedback. Então, surgiram métricas adicionais que podem ser usadas para entender quando uma página fornece esse feedback aos seus usuários.

É importante entender os diferentes insights oferecidos por essas métricas e, em seguida, estabelecer aqueles que são importantes para a experiência do usuário.

Algumas marcas até definem métricas personalizadas adicionais específicas às expectativas que as pessoas têm em relação ao seu serviço. No caso do Pinterest, os usuários desejam ver as imagens, por isso definiram uma métrica personalizada, Tempo de espera do Pinner, que combina o tempo de interação e os tempos de carregamento da imagem acima da dobra. Mesmo que o carregamento seja mais de um momento no tempo, ainda pode ser útil ter uma única métrica para fins de relatório ou comparação simplificados.

Como medir a velocidade?

O desempenho no mundo real é altamente variável devido às diferenças nos dispositivos dos usuários, conexões de rede e outros fatores. Por exemplo, se você carregar o seu site usando uma conexão de rede a cabo em seu escritório e compará-lo com o carregamento usando WiFi em uma cafeteria, as experiências provavelmente serão muito diferentes.

Existem muitas ferramentas no mercado que podem ajudá-lo a coletar dados de laboratório ou de campo para avaliar o desempenho da página.

Dados de laboratório versus dados de campo

Os dados de laboratório são dados de desempenho coletados em um ambiente controlado com dispositivos e configurações de rede predefinidos, enquanto os dados de campo são dados de desempenho coletados de carregamentos de páginas reais experimentados por seus usuários em liberdade. Cada tipo tem seus próprios pontos fortes e limitações.

Os dados de laboratório oferecem resultados reproduzíveis e um ambiente de depuração, mas podem não capturar gargalos do mundo real e não podem se correlacionar com os KPIs da página do mundo real.

Com os dados de laboratório, você precisa entender os dispositivos e redes típicos de seus usuários e espelhar adequadamente essas condições ao testar o desempenho. Tenha em mente que, mesmo em áreas com 4G, os usuários ainda podem experimentar conexões mais lentas ou intermitentes quando estiverem em elevadores, durante o trajeto ou em ambientes semelhantes.

Os dados de campo (também chamados de Real User Monitoring ou RUM) capturam a verdadeira experiência do usuário no mundo real e permitem a correlação com KPIs de negócios, mas têm um conjunto restrito de métricas e recursos de depuração limitados.

Os usuários ainda podem experimentar conexões mais lentas ou intermitentes quando em elevadores, durante o trajeto ou em ambientes semelhantes.

Como melhorar a velocidade?

Otimizações de velocidade

Esperamos que você agora tenha cumprido a missão de melhorar a velocidade de sua página – mas como fazer para aumentar a velocidade?

As métricas que queremos mover são influenciadas por vários fatores, muitos dos quais podem ser melhorados com a implementação de práticas recomendadas.

Ferramentas como o Lighthouse são um bom ponto de partida: junto com uma pontuação para cada métrica, elas também fornecem uma lista de oportunidades potenciais de aumento de velocidade, como a otimização de imagens ou JavaScript.

Web.dev é outro recurso para desenvolvedores que contém orientações e análises acionáveis.

WebPageTest e GTMetrix também são boas ferramentas para analises de otimização, mas considere realizar seus testes a partir de instâncias no Brasil.

Caso tenha interesse no tema, recomendamos a leitura do artigo: Se você se preocupa com SEO, saiba medir a velocidade do seu site corretamente.

Já conhece o AMP?

Outra maneira de acelerar e permanecer rápido é o AMP. AMP é uma biblioteca de código aberto que oferece uma maneira simples de criar páginas da Web que carregam quase instantaneamente para os usuários.

O AMP por si só é muito rápido, mas também pode acelerar seu site em níveis adicionais por meio do armazenamento em cache nos Caches de AMP e da pré-renderização.

Como permanecer rápido?

As marcas que otimizam a velocidade geralmente descobrem que regridem rapidamente. Isso ocorre porque o desempenho do site é muito parecido com o de entrar em forma:

Não é suficiente fazer um esforço único – você tem que mudar o seu estilo de vida.

Os orçamentos de desempenho são uma forma de resolver isso. Um orçamento de desempenho é um conjunto de limites de métricas que afetam o desempenho do site.

O conceito é semelhante a um orçamento financeiro – você define um limite e se certifica de mantê-lo. Em geral, um bom orçamento de desempenho combina diferentes tipos de métricas; então, por exemplo, o orçamento de desempenho para uma página de produto pode ser o seguinte:

Uma vez definido, um orçamento de desempenho deve ser aplicado, o que significa, por exemplo, incorporar o orçamento em seu processo de construção e aos relatórios.

Ferramentas como o Lighthouse podem ser incluídas em sua integração contínua, e você pode escrever testes que falham em uma construção se as principais métricas caírem abaixo de um limite definido. Além disso, relatórios regulares por meio de painéis ou relatórios resumidos podem ajudar com a visibilidade e responsabilidade.

O Pinterest é um exemplo de empresa que implementou orçamentos de desempenho para garantir que sua experiência rápida permaneça rápida, enquanto marcas como a Experian agora estão usando a velocidade do site como uma métrica chave em seus relatórios executivos mensais de KPI.

Fonte: https://www.thinkwithgoogle.com/_qs/documents/7353/Mobile_Site_Speed_Playbook.pdf


https://www.gocache.com.br/wp-content/uploads/2021/01/google-playbook-importancia-site-rapido.jpg 500 700 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2021-01-12 15:29:202021-01-14 16:40:33Por que a velocidade de um site é importante? Google Playbook

Como usar o ISPTools?

17 de dezembro de 2020/0 Comentários/em Dicas /por GoCache

Para quem ainda não conhece, o ISPTools é uma ferramenta direcionada para profissionais de infraestrutura de TI que oferece uma série de recursos para diagnosticar o status de infraestrutura, permitindo que administradores de redes possam ter mais controle sobre suas aplicações.

O projeto foi idealizado pelo Giovane Heleno, e hoje a ISPTools já conta com diversas ferramentas que possibilitam a analise de diferentes frentes, como:

CAIU:

Permite que você visualize se sua aplicação está sendo entregue por diferentes origens. Dentro deste teste, além de visualizar o status de sua aplicação para diferentes origens, também é possível ver o tempo em ms e o tipo de resposta HTTP.

Exemplo do recurso – Caiu

PING: 

Realiza um ping em diferentes hosts de destino/ips.

Exemplo do recurso – PING

MTR:

Visualize a rota com volume de saltos e ping de seu ip/hostname. É conhecido como “my traceroute”, comando bastante utilizado no terminal do linux.

Exemplo do recurso – MTR

DNS:

Permite acompanhar propagação de entradas DNS, como: CNAME, NAME SERVER, A, TXT, entre outras.

Exemplo do recurso – DNS

HTTP: 

Apresenta informações detalhadas sobre o status de uma página (equivalente ao comando curl do terminal linux).

Exemplo do recurso – HTTP

 


Definitivamente a ISPTools é uma ferramenta poderosa e super simples que permite que você realize testes em diferentes localidades para entender mais sobre a saúde de sua aplicação na web.

Para conhecer mais sobre a ISPTools, acesse: www.isptools.com.br

https://www.gocache.com.br/wp-content/uploads/2020/12/isp-tools-capa.png 500 700 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-12-17 11:16:172020-12-21 11:19:09Como usar o ISPTools?

Como gerar certificado SSL via terminal – Certbot com Wildcard

10 de novembro de 2020/0 Comentários/em Dicas /por GoCache

 

Neste tutorial, vamos explicar como gerar um certificado gratuito da Let’s Encrypt.

A Let’s Encrypt é um projeto da Linux Foundation que tem como objetivo popularizar a utilização de certificados SSL, facilitando a aquisição e instalação de certificados SSL.

Atualmente, os certificados gratuitos da Let’s Encrypt tem validade de 90 dias, obrigado webmasters a atualizar seus certificados com frequência, devido ao tempo de expiração. Dentro da GoCache, por exemplo, utilizamos certificados da Let’s Encrypt, porém, nossa gestão automatizada renova os certificados automaticamente, tirando a obrigatoriedade de renovação dos certificados SSL (entre CDN e usuário).

Para gerar um certificado SSL pelo terminal, basta utilizar o comando abaixo, alterando apenas os domínios destacados.


sudo certbot certonly –manual -d \*.meusite.com.br -d meusite.com.br –agree-tos –no-bootstrap –manual-public-ip-logging-ok –preferred-challenges dns-01 –server https://acme-v02.api.letsencrypt.org/directory


Feito isso, basta adicionar a entrada TXT com nome _acme-challenge.meusite.com.br para o valor gerado no terminal.

Agora, espere alguns minutinhos até que a entrada seja propagada (recomendamos utilizar o site ISPTools para acompanhar).

Assim que a entrada estiver propagada, basta dar ENTER no terminal para gerar seu certificado SSL com Wildcard.

E para abrir os patchs do certificado e chave privada (privat key), utilize o comando sudo cat + patch.


Você também pode se interessar pelos artigos:

  • SSL para WordPress: Aprenda como usar
  • Conheça os tipos de certificado SSL


https://www.gocache.com.br/wp-content/uploads/2020/11/gerar-certificado-ssl-pelo-terminal.png 720 1280 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-11-10 10:14:132020-11-18 15:32:09Como gerar certificado SSL via terminal - Certbot com Wildcard

O que é webP e como usar

29 de outubro de 2020/0 Comentários/em Dicas /por GoCache

WebP é uma formato de imagem desenvolvido pelo próprio Google com o intuito de diminuir o tamanho de imagens trafegadas dentro da internet para reduzir o tempo de carregamento e download de imagens, sem interferir na qualidade das imagens.

Segundo o Google, o formato webP pode ser até 45% menor do que imagens em formatos tradicionais como jpeg e png.

O formato webP foi criado pelo Google em meados de 2010, mas passou a ganhar mais aderência somente nos últimos anos, visto que um dos grandes limitadores do formato na época de seu lançamento era a incompatibilidade com navegadores, já que no início, o formato webP era compatível apenas com o Google Chrome, mas atualmente, boa parte dos navegadores já dão suporte ao webP.

Por exemplo, o Firefox, um dos navegadores mais utilizados em versões desktop, passou a suportar nativamente o formato de webP somente em agosto de 2018, 8 anos após o lançamento oficial.

Atualmente, os navegadores que dão suporte nativo para webP são:

  • Chrome (desktop e celular).
  • Firefox (desktop e celular).
  • Edge.
  • Opera (desktop e celular).

Quais as vantagens de usar webP em sites e apps?

Em média, mais de 65% do peso de um site é de imagens, sendo assim, webmasters tem o desafio de criar aplicações visualmente atrativas, mas sem afetar a performance da aplicação.

Pensando nisso, utilizar o formato webP é bastante vantajoso, já que é possível acelerar a entrega das imagens com baixo esforço técnico. Além disso, por ser um formato mais leve, a utilização de webP pode contribuir para que seu site ganhe relevância orgânica. Por exemplo, boa parte das ferramentas de performance utilizadas atualmente verificam o formato de suas imagens, classificando seu site com melhor pontuação, caso identifiquem que o formato webP é utilizado.

Outro ponto importante é o volume de uso de banda utilizado por imagens webP. Já que as imagens são menores, consequentemente é necessário utilizar menos dados de saída. Se considerarmos aplicações com alta escala de tráfego, reduzir o uso de banda pode representar uma economia significativa de custos.

Quais as desvantagens de usar webP em sites e apps?

Atualmente, a desvantagem de usar webP é a incompatibilidade com alguns navegadores, em especial, o Safari da Apple que por enquanto só dá suporte a imagens em webP em nas versões do iOS 14 e macOS 11.0. Porém, é possível contornar essa desvantagem utilizando um produto de otimização e conversão de imagens, que transformar as imagens jpeg e png em webP de acordo com o navegador do usuário, possibilitando ter uma boa eficiência de entrega em webP para navegadores que dão suporte e se eventualmente algum navegador não der suporte, a imagem é entregue automaticamente em seu formato original.

Como usar webP em sites e apps?

Atualmente, a melhor prática para utilizar webP é através de um conversor de imagens, já que por enquanto, nem todos os navegadores dão suporte nativo a webP.

A GoCache possui uma ferramenta de otimização de imagens que realiza a conversão de imagens para webp, automaticamente e sem esforço técnico.

Basicamente, nosso produto de otimização de imagens considera o formato das imagens de seu site e app e realiza a conversão das imagens na borda, entregando o melhor formato para o usuário final, considerando tanto o navegador utilizado no acesso quanto a localização geográfica, reduzindo latência através da entrega via CDN.

Trata-se de um produto muito simples de ser ativado, disponível para todos os usuários que utilizam nossa rede de distribuição de conteúdo.

https://docs.gocache.com.br/imagens/lithio/01_video-li-optimization-optin.mp4

Caso queira conhecer mais sobre o Lithio, nosso otimizador de imagens, acesse a documentação oficial.

Existem também opções de plugin para WordPress que fazem a conversão de imagens, mas é necessário avaliar como a conversão é feita, já que muitos plugins passam a distribuir imagens por endereços externos, prejudicando a otimização do site para SEO e muitas vezes adicionando latência de entrega.


Caso esteja pesquisando sobre performance web, também recomendamos a leitura dos artigos:
  • Otimização de imagens no WordPress
  • GT Metrix: Como usar
  • Como usar CDN para distribuir imagens
  • WebPageTest: Aprenda como usar
  • Como usar webP no WordPress
  • CDN e SEO: Práticas recomendadas


https://www.gocache.com.br/wp-content/uploads/2020/11/webp-o-que-e.jpg 350 660 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-10-29 13:14:532020-11-03 13:30:53O que é webP e como usar

Disponibilidade e performance na Black Friday

27 de outubro de 2020/0 Comentários/em Dicas, E-commerce /por GoCache

A Black Friday é o segundo período mais importante para o comercio eletrônico brasileiro, perdendo em nível de faturamento apenas para o natal. Em 2019, as vendas nos 4 dias de Black Friday foram de R$ 3,2 bilhões segundo a revista Veja, aumento de 23,6% em relação ao ano anterior.

Ainda que em 2020 o comercio em geral tenha tido baixas devido ao COVID-19, a expectativa é que a Black Friday deste ano tem potencial de vendas ainda acima do ano anterior, sendo assim, é esperado que neste ano de 2020 a Black Friday no Brasil siga crescendo em faturamento.

Tecnicamente, a Black Friday é um grande desafio para equipes de infraestrutura de TI que precisam preparar suas aplicações para lidar com o aumento expressivo de tráfego da data, iniciando seu planejamento (na maioria dos casos) com meses de antecedência, regrados a testes de volumetria e escalabilidade.

Normalmente, times de infraestrutura buscam desenvolver aplicações escaláveis e que possam se adequar de acordo com o volume de tráfego e requisições que suas aplicações recebem, sempre buscando otimizar custos. É o desafio de operar algo complexo com o menor custo possível.

Neste artigo, falaremos um pouco sobre a aplicação de cache e CDN em comércios eletrônicos com o objetivo de apresentar soluções para lidar com o alto volume de tráfego da data.

Como a CDN pode ajudar na Black Friday:

Utilizar um recurso de CDN é essencial, principalmente se seu e-commerce tem a expectativa de receber um alto volume de tráfego durante a Black Friday.

Basicamente, a CDN faz cache de aplicações e passa a entrega-las através de múltiplos pontos, acelerando a entrega (por reduzir latência) e dando mais escalabilidade para aplicações. Caso queira conhecer mais sobre CDN, recomendamos a leitura dessa pagina – O que é CDN

Por exemplo, uma aplicação convencional normalmente é composta por um servidor de hospedagem que está preparado para receber um determinado volume de tráfego. Se eventualmente se este site recebe mais tráfego do que está preparado, haverá problemas de lentidão ou até mesmo, queda da infraestrutura.

Agora, se pensarmos nesta mesma infraestrutura utilizando uma CDN, este mesmo site passa a ser entregues através de outros pontos de distribuição, trazendo maior redundância para a infraestrutura de hospedagem e dando mais escalabilidade para a aplicação, uma vez que este site não precisa mais lidar com todas as requisições, já que boa parte será absorvida pelo serviço de CDN.

Porém, é fundamental entender que apenas utilizar uma CDN não é sinônimo de escalabilidade, afinal, por padrão, a grande maioria dos serviços de CDN faz cache de assets estáticos (imagens, js, css…), lendo automaticamente a extensão dos objetos, o que pode reduzir o uso e largura de banda de sua aplicação, mas ainda será necessário que elementos dinâmicos (como html, json…) sejam entregues diretamente de sua infraestrutura de hospedagem, sendo assim, para efetivamente dar mais escalabilidade para seu comercio eletrônico com uma CDN, é fundamental implementar estratégias de cache dinâmico.

Cuidados para implementar cache dinâmico em e-commerce:

Em boa parte dos casos, implementar cache dinâmico em um e-commerce é algo simples de ser feito, e na grande maioria dos casos, pode ser resolvido através de regras de cache (aqui na GoCache, chamamos de Smart Rules).

Primeiro, é necessário avaliar como seu site lida com carinhos de compras, áreas logadas, checkout de pagamento, etc.. É necessário nesta primeira etapa avaliar todo o conteúdo que pode ser “sensível a cache”.

Um exemplo são aplicações em Magento 1 em que normalmente os usuários logados recebem os cookies frontend e adminhtml, sendo assim, uma boa prática seria definir na CDN que qualquer usuário com esses cookies não recebam itens dinâmicos em cache. Outro exemplo, ainda pensando em Magento 1 é excluir alguns patchs do cache, como por exemplo /add /administrator /customer /index.php /cart.

Já as aplicações em Magento 2, normalmente utilizam carrinhos em ajax e que podem ser configurados para não fazer cache por padrão, trazendo ainda mais eficiência de cache para essas aplicações, mas ainda assim, é aconselhável entender os cookies que identificam sessões e usuários, como por exemplo admin, PHPSESSID e private_content_version que normalmente são excluídos do cache e os patchs /checkout /sales /admin /customer /rest /intelipost_quote /wishlist /giftcard /reward /review /newsletter que normalmente são configurados para não fazer cache. 

Outro CMS bastante utilizado é o WordPress, mais especificamente em sua versão Woocomerce, destinada para e-commerce.

Por padrão, o Woocomerce inseri alguns cookies sempre que um usuário coloca algo no carinho, como por exemplo, woocommerce_cart_hash e woocommerce_items_in_cart, sendo assim, uma boa prática para essa plataforma é deixar de fazer cache dinâmico para usuários com esses cookies. Além disso, também é interessante excluir de cache áreas mais sensíveis, como /carrinho /cart /minha-conta entre outros.

Basicamente, precisamos avaliar cada aplicação para entender seu funcionamento, evitando que informações sensíveis sejam cacheadas, comprometendo a experiência de seus usuários finais.


Precisa de ajuda para implementar cache dinâmico em seu e-commerce?

Caso você precise de ajuda para definir as melhores estratégias de cache e CDN para sua aplicação, basta entrar em contato conosco.


Além do poder de escala, a CDN também pode acelerar seu e-commerce:

Deve-se levar em consideração que além do aumento de disponibilidade e escalabilidade que a CDN pode trazer para sua aplicação, ela também pode contribuir bastante para que seu e-commerce ganhe performance de entrega.

Conforme citamos anteriormente, o cache dinâmico é um ótimo recurso para trazer escala, porém, ele também pode ajudar na frente de performance, já que o usuário final receberá o conteúdo de seu site com mais rapidez, através de uma entrega de capilaridade.

Por exemplo, vamos supor que sua infraestrutura de hospedagem esteja em São Paulo, mas seu site recebe tráfego de todas as partes do país. Neste caso, todos os acessos precisam obrigatoriamente ser direcionado até São Paulo, aumentando latência e o volume de saltos. Agora, se pensarmos em uma distribuição via CDN com múltiplos pontos de presença no país, sua aplicação deve ser entregue com mais velocidade, já que a latência de entrega será menor.

É muito comum ver e-commerces que aplicam cache dinâmico, reduzir suas métricas de TTFB, Start Render e Load Time.


Esperamos que nossas dicas possam ajudar seu site a ter mais escalabilidade durante a Black Friday. Caso tenha qualquer dúvida, por favor, deixei seu comentário logo abaixo.

&


;

https://www.gocache.com.br/wp-content/uploads/2020/10/disponibilidade-e-performance-na-black-friday.png 350 660 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-10-27 16:06:262020-10-27 18:35:49Disponibilidade e performance na Black Friday

Alternativas ao WebPageTest

20 de outubro de 2020/0 Comentários/em Dicas /por GoCache

O WebPageTest é uma plataforma de testes para performance web onde é possível analisar uma determinada página e ter um diagnóstico completo de métricas de performance.

A ferramenta é bastante utilizada pela opção de realizar testes de performance a partir de instâncias no Brasil, o que traz uma visão bastante confiável sobre a entrega de uma aplicação para usuários que efetivamente estão em nosso país. Além desta característica, o WebPageTest também faz bastante sucesso por permitir a seleção de navegadores e tipos de conexão, facilitando bastante a vida dos profissionais que buscam entender mais sobre o desempenho de suas aplicações em conexões de 3G e 4G.

Porém, além do WebPageTest, existem várias outras alternativas para teste de performance web, e cada uma com suas características, vantagens e desvantagens. Neste artigo, iremos falar sobre algumas ferramentas de performance web que são alternativas ao WebPageTest.

GTmetrix:

O GTmetrix é uma ferramenta de performance web que tem ganhado bastante espaço nos últimos anos pela sua excelente composição visual, o que facilita bastante a vida de analistas de performance e permite que usuários com menos experiência consigam tirar insghts relevantes de melhoria para suas aplicações.

Um dos pontos fortes da GTmetrix é que a solução possui pontos de teste no Brasil, possibilitando que usuários daqui consigam mensurar os resultados de latência de suas aplicações. Além disso, a ferramenta também permite que você faça comparações de resultado, o que facilita bastante a vida de quem quer fazer testes A/B.

Caso você queira conhecer mais sobre o GTmetrix, recomendamos a leitura do artigo – GTmetrix: Como usar

PageSpeed Insights Google:

O PageSpeed Insights do Google é provavelmente a ferramenta de análise mais utilizada, porém os insights gerados através dela podem ser confusos, já que o nível de detalhamento é baixo. Além disso, por tratar-se de uma ferramenta do próprio Google, muitos webmasters consideram vital que sua performance seja positiva nessa ferramenta, com a ilusão de trazer mais tráfego orgânico, seguindo a lógica de que o Google utilizaria os resultados dos testes como fator de ranqueamento, o que certamente não é verdade.

Desde maio de 2020 o Google passou a exibir informações sobre o Core Web Vitals dentro dos resultados do PageSpeed Insights, e desde então muitos webmasters tem buscado otimizar seu score nesta ferramenta. Inclusive, caso queira aprender mais sobre o assunto, recomendamos a leitura do artigo – Core Web Vitals – Você está preparado para a nova mudança do Google?

Também recomendamos a leitura do artigo – Se você se preocupa com SEO, saiba medir a velocidade do seu site corretamente, onde é possível entender um pouco mais sobre o PageSpeed, com exemplos de teste em LightHouse local, onde é possível ter uma visão mais fidedigna dos resultados de sua aplicação.

Pingdom:

A Pingdom é uma ferramenta de performance web bastante utilizada no Brasil e que também oferece a opção de testes através de instâncias no Brasil. É provavelmente a ferramenta mais utilizada por incitantes, graças a sua excelente interface gráfica, o que facilita bastante a vida de quem precisa ter uma visão da saúde de sua aplicação, sem necessariamente precisar analisar profundamente cada um dos itens de performance.

Além do teste de performance, a Pingdom também oferece soluções para acompanhar latência de entrega e disponibilidade, mas que só estão disponíveis para assinantes da ferramenta.

Freshping:

O Freshping é uma ferramenta bastante utilizada para medir o tempo de resposta do HTML de sites, o que traz uma visão confiável de latência de entrega. Vale citar que a ferramenta permite que você configure suas monitorações através de instâncias em São Paulo, o que traz uma visão bem confiável dos resultados de seu site por aqui.

Além de medir a latência de entrega, a ferramenta também permite que você configure alertas automáticos de indisponibilidade que são enviados por e-mail. Trata-se de um ótimo recurso para webmasters que querem ficar por dentro do uptime de suas aplicações.

Os recurso de monitoramento são gratuitos e a ferramenta permite que você cadastre até 50 domínios diferentes. Caso tenha interesse, é possível assinar a versão premium para ter acesso aos relatórios de performance históricos, já que a versão gratuita possibilita visualizar apenas os últimos 30 dias.



https://www.gocache.com.br/wp-content/uploads/2020/10/alternativas-web-page-test.jpg 450 650 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-10-20 16:57:172020-10-21 17:45:39Alternativas ao WebPageTest

GTmetrix: Como usar

15 de outubro de 2020/0 Comentários/em Dicas /por GoCache


Se você chegou até este artigo, provavelmente está buscando aprender mais sobre os testes de performance da ferramenta GTmetrix. 

A GTmetrix é uma ferramenta de performance web criada pela empresa Carbon60 que atua com gerenciamento de Cloud. 

A ferramenta foi criada com o objetivo de realizar testes de latência através de múltiplas instâncias de testes, espalhadas em vários países, com o objetivo de trazer resultados mais fidedignos de performance web por localização. 

Além de trazer a visão de latência, a GTmetrix também fornece outras informações relevantes sobre a performance e saúde de aplicações web, apresentando informações sobre uso efetivo de CDN, visão em cascata das requisições, itens otimizados com minifiy, compressão, otimização de imagens entre outros. 

Como testar um site no GTmetrix? 

Basicamente, para testar um site dentro da ferramenta do GTmetrix basta que você insira uma URL na homepage do site, porém, é fundamental inserir os parâmetros de análise corretos para ter uma visão real da performance de seu site. Abaixo, compartilho um “setup” que considero relevante para testes de performance feitos em aplicações do Brasil. 

1° – É necessário criar uma conta gratuita. 

Por padrão, o GTmetrix só permite testes feitos a partir de instâncias no Canada para usuários sem registro, sendo assim, é fundamental que você crie uma conta gratuita na ferramenta, com o objetivo de liberar seu acesso para selecionar instâncias no Brasil. 

Para isso, clique sobre “log in to change options”, conforme vemos abaixo para criar sua conta ou clique sobre “sign up” na lateral superior direita. 

Crie seu cadastro para testar suas páginas em instâncias no Brasil

2° – Setup inicial para testes (somente para usuários logados na GTmetrix) 

Orientação para setup de teste

Agora que você já tem uma conta na GTmetrix, é possível criar seu primeiro setup de testes. Acima, compartilho uma screen da nossa sugestão de setup com considerações sobre cada uma das etapas: 

1 – Analyze Performance of: Selecione a URL que você pretende analisar. Nesta etapa é importante que você preencha corretamente a URL, inclusive citando se ela abre em HTTP, HTTPS, com www ou sem www. 

2 – Test URL in: Aqui, selecione a opção São Paulo, Brazil. Caso você precise ter uma visão de fora do país, também é possível selecionar instâncias de teste em: USA, China, UK, India, Australia e Canada. 

3 – Using: É possível selecionar os navegadores Firefox e Chrome.

4 – With: Selecione o tipo de conexão do teste. É possível escolher entre 3G, Broadband (banda larga), 2G, LTE. Infelizmente o site ainda não dá suporte para 4G. Caso você precise dessa visão, recomendamos a ferramenta de teste WebPageTest. 

5 – Create Vídeo: Você pode registrar em vídeo o carregamento de seu site. Trata-se de um recurso interessante para ver na prática o site sendo carregando, mas para uma analise mais detalhada, ele não tem tanta função, já que com base nas métricas de performance é possível analisar a saúde de uma aplicação. 

6 – Adblock Plus: O recurso de Adblock inibi que anúncios sejam exibidos em seu site. É um bom recurso para quem quer entender mais sobre o impacto de usar anúncios de terceiro em seu site (AdSense, Criteio, etc…). 

7 – Stop test onload: Você pode parar o teste automaticamente quando a tela de seu teste estiver pronta. O comportamento padrão da GTmetrix é interromper o teste após 2 segundos de inatividade da rede (após o onload disparar). 

3° Analisando os resultados de seu teste 

Após preencher todos os campos da etapa acima, agora basta clicar sobre “Analyze”. É necessário aguardar alguns minutos até que seu teste seja concluído. Feito isso, você terá um resultado similar ao apresentado abaixo:

Resumo do resultado GTmetrix

Performance Scores: Aqui você pode avaliar o resumo das notas de seu teste de performance. O PageSpeed Score e o YSlow Score são um resumo de seus resultados de acordo com os critérios da GTmetrix.

Page Details: O page details traz informações sobre a página analisada, sendo Fully Loaded Time o tempo médio de carregamento total da página, Total Page Size o tamanho da página analisada e Requests o volume de requisições necessárias para carregar essa página.

Aba para analise de métricas individuais

Logo após o resumo de sua nota é possível analisar algumas métricas individualmente. Estás métricas estão organizadas nas opções “PageSpeed”, “YSlow”, “Waterfall” e “Timings”.

PageSpeed:

Analisar métrica por métrica, GTmetrix

A aba de PageSpeed traz recomendações de melhorias que afetam diretamente a nota de “Performance Score”, exibida no resumo do teste.

Por aqui vamos encontrar métricas de cache de browser, otimização de imagens, minify de css e js, compressão gzip, keep-alive entre outros.

Clicando nos campos é possível ver as requests afetadas por cada uma das recomendações. Além disso, também é possível clicar sobre o campo “What’s this means?” para acessar a documentação da GTmetrix de cada um dos itens.

Avaliar métrica individual – GTmetrix

No nível de PageSpeed é possível analisar as métricas:

Leverage browser caching Enable compression Minify JavaScript
Optimize images Inline small JavaScript Minify CSS
Combine images using CSS sprites Minimize redirects Avoid a character set in the meta tag
Specify a cache validator Minimize request size Prefer asynchronous resources
Defer parsing of JavaScript Put CSS in the document head Specify a character set early
Serve scaled images Specify image dimensions Serve resources from a consistent URL
Inline small CSS Enable Keep-Alive Avoid CSS @import
Avoid bad requests Avoid landing page redirects

Yslow:

Assim como em PageSpeed, o YSlow analisa algumas métricas e traz recomendações de melhorias individuais. Por aqui, podemos encontrar uma métrica estreitamente ligada ao uso de CDN, identificada como: Use a Content Delivery Network (CDN).

No nível de YSlow é possível analisar as métricas:

Add Expires headers Remove duplicate JavaScript and CSS
Use a Content Delivery Network (CDN) Avoid AlphaImageLoader filter
Make fewer HTTP requests Avoid HTTP 404 (Not Found) error
Use cookie-free domains Use GET for AJAX requests
Reduce the number of DOM elements Avoid CSS expressions
Minify JavaScript and CSS Reduce DNS lookups
Compress components Reduce cookie size
Avoid URL redirects Make favicon small and cacheable
Make AJAX cacheable Configure entity tags (ETags)
Make JavaScript and CSS external

Waterfall:

Visão em Waterfall – GTmetrix

Em Waterfall é possível ver os resultados em modo cascata, onde é possível filtrar as requests por HTML, CSS, JSS, XHR, Fontes, Images e other.

A vantagem de analisar o modo cascata é avaliar o tempo necessário para entrega de cada uma das requisições. Por aqui, é possível tirar insights valiosos sobre a performance da aplicação, como por exemplo, reduzir o tamanho de assets, alterar a ordem de carregamento e até mesmo, avaliar itens externos que possam prejudicar seu desempenho.

Waterfall – Detalhes

Além disso, clicando sobre as requests do Waterfall é possível verificar os Headers e Response individualmente, conforme vemos acima.

Timings: 

Timings GTmetrix

Dentro da aba “timings” é possível analisar um resumo dos tempos de entrega da página. Entre as métricas disponíveis, em “timings” você encontra:

TTFB: É o time to first byte ou tempo para primeiro byte. É o tempo entre o primeiro byte do browser e da resposta do servidor. Trata-se de uma métrica que a CDN pode ajudar bastante, principalmente se considerarmos uma estratégia de cache dinâmico.

DOM int: DOM interactive time é o tempo necessário para o navegador carregar e analisar o HTML.

DOM loaded: O tempo de carregamento do conteúdo DOM loaded é o ponto em que o DOM está concluído, e não há mais folhas de estilo bloqueando a execução de JavaScript.

First Paint: É o tempo em que o navegador precisa para renderizar algo na página, ou seja, o primeiro elemento antes da página estar completamente branca.

Contentful Paint: O First contentful paint time é acionado quando qualquer conteúdo é exibido. Pode ser um texto, imagem ou qualquer outra renderização na tela. Está métrica costuma ser bem representativa na experiência do usuário, já que ela sinaliza quando o conteúdo real foi carregado na página (muitas vezes pode ser o mesmo tempo do First Paint, dependendo da aplicação).

Onload: O onload time é o tempo de carregamento de todo o processamento da página. É necessário que o browser conclua o carregamento de todos os recursos da página, como imagens, css, js e etc.


Basicamente, essas são as principais áreas de analise do GTmetrix. Analisando cada um dos pontos, certamente será possível ter um bom diagnóstico dos resultados de suas páginas.

Caso queira aprender um pouco mais sobre ferramentas de performance, também recomendamos a leitura do artigo – Webpagetest – Aprenda como usar

E se houver qualquer dúvida sobre o uso do GTmetrix, deixe seu comentário 🙂



https://www.gocache.com.br/wp-content/uploads/2020/10/gtmetrix-performance-aprenda-como-usar.jpg 320 660 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-10-15 11:16:482020-11-23 16:39:35GTmetrix: Como usar

O que é CloudFlare?

2 de outubro de 2020/0 Comentários/em Dicas /por GoCache

Criada em 2009 com o objetivo de oferecer uma solução básica de segurança com valor atrativo, a CloudFlare foi oficialmente lançada em 2010 durante uma conferência da TechCrunch. 

Trata-se de uma solução de segurança e CDN com distribuição em nível global, e que desde sua concepção foi desenhada para oferecer soluções “freemium”, onde seus usuários podem usufruir de produtos básicos gratuitamente, mas precisam pagar por recursos intermediários e avançados. 

Por ser a primeira solução a oferecer essa modalidade, a CloudFlare ganhou bastante espaço no mercado de segurança e CDN, mas desde seu IPO em 2019, é possível perceber que os esforços da empresa tem sido direcionados principalmente ao lançamento de features pagas e que efetivamente possam trazer resultados comerciais para a solução. 

Como a CloudFlare funciona? 

O funcionamento da CloudFlare é similar a maioria das empresas de CDN, fazendo cache de assets elegíveis de sites, e distribuindo o conteúdo através da rede de distribuição mais próximas do usuário final com o intuito de reduzir latência de entrega e dar mais escalabilidade para a infraestrutura. 

Além do seu funcionamento como CDN, a CloudFlare também conta com features de segurança, como: 

  • DDoS: Mitigar ataques direcionados na camada 7. 
  • WAF: O WAF inspeciona as requisições de um site para determinar se o acesso é malicioso ou elegível de forma automática. 
  • SSL: Emissão de certificados SSL para usuários da rede 

Para entender mais sobre o funcionamento da CloudFlare na prática, é fundamental conhecer os três response headers mais utilizados por eles: 

  • cf-cache-status: HIT
    • Demonstra que um item foi entregue por cache 
  • cf-cache-status: MISS
    • É um item elegível a cache, mas que ainda não foi cacheado. Um MISS deve virar um HIT na pŕoxima requisição. 
  • cf-cache-status: DYNAMIC
    • O response header DYNAMIC da CloudFlare, também pode ser chamado de BYPASS. Trata-se do asset entregue diretamente pela hospedagem e que só deverá ser cacheado com uma configuração específica. 

Caso queira conhecer mais sobre response headers de cache, recomendamos a leitura do artigo: CDN Cache Headers – Aprenda a inspecionar 

Quais os pontos de distribuição da CloudFlare? 

Referência externa – Pontos de presença da CloudFlare

Com distribuição em todo o mundo, a CloudFlare é uma empresa bastante consolidada no mercado americano e europeu, onde concentra a maior parte de seus pontos de presença. 

Segundo o site da empresa, atualmente a CloudFlare está presente em mais de 200 cidades e 100 países, porém, é necessário salientar que a atuação da empresa dentro do mercado brasileiro é tímida, operando com pontos de presença apenas em São Paulo, Curitiba, Fortaleza, Porto Alegre e Rio de Janeiro. 

Caso você queira descobrir em qual ponto de presença seu site tem sido entregue pela CloudFlare, basta analisar o response header cf-ray que indica o “air port” que entregou determinado asset, como por exemplo: 

  • cf-ray: GRU – Entrega feita em São Paulo, Brasil 
  • cf-ray: GIG – Entrega feita no Rio de Janeiro, Brasil
  • cf-ray: CTU – Entrega feita em Chengdu, China 

Quais as vantagens de usar CloudFlare? 

A principal vantagem do CloudFlare no Brasil são seus planos gratuitos. Para aplicações básicas e que não dependem de grande otimização, é possível utilizar alguns recursos de CDN e WAF sem custos, mas com a desvantagem de não ter nenhuma prioridade de entrega, sendo assim, é possível que seu site seja roteado por rotas mais distantes. 

Além disso, se sua aplicação recebe bastante tráfego fora do Brasil, a CloudFlare se torna uma solução ainda mais atrativa, já que conta com pontos de presença em diversos países. 

Quais as desvantagens de usar CloudFlare? 

Conforme citamos acima, a CloudFlare utiliza um modelo “fremium”, onde o usuário da plataforma tem custos adicionais por features ou regras de negócio.

Prioridade de rotas: Apenas em planos pagos você tem acesso a priorização de ips, o que acaba fazendo com que sua aplicação seja entregue muitas vezes por caminhos mais longos, anulando a principal função de uma CDN, reduzir latência.

SLA apenas em contas pagas: O SLA (service level agreement), também conhecido como acordo de nível de serviço, é o compromisso da solução de CDN em entregar sua aplicação 24 horas por dia. Por padrão, praticamente todas as soluções de CDN oferecem SLA de 99% a 100%, porém, para ter SLA dentro do CloudFlare, é necessário utilizar um plano Business com valor a partir de U$ 200,00.

WAF e Otimização de imagens: Atualmente o serviço de segurança WAF e o serviço Polish de otimização de imagens está disponível apenas para contas em planos pagos.

Suporte por telefone ou chat: Caso você queira ter acesso a suporte por telefone, é necessário fazer parte dos planos em nível Enterprise. Já para acesso por chat, é necessário utilizar planos Business.

Analytics: Para ter acesso a informações de sua aplicação, como volume de requests, consumo de banda, itens entregues em cache, entre outros, é necessário assinar um plano pago.

Baixa capilaridade de entrega no Brasil: Como citamos na área de pontos de presença, o CloudFlare ainda tem uma presença timida no Brasil, concentrando a maior parte de sua infraestrutura apenas no mercado norte americano e europeu.

GoCache é uma alternativa de CDN viável em comparação ao CloudFlare?

Certamente!

A GoCache é uma solução de CDN com foco no mercado brasileiro e que oferece uma solução de CDN mais atrativa para sites, aplicações e e-commerces que rodam exclusivamente dentro do país.

Referencia: Comparativo de latência – CloudFlare e GoCache via PerfOps

Caso você queira entender um pouco mais sobre a entrega da GoCache em comparação ao CloudFlare, recomendamos a leitura do artigo – GoCache VS CloudFront VS CloudFlare 



https://www.gocache.com.br/wp-content/uploads/2020/10/cloudflare-como-funciona.jpg 315 512 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-10-02 12:15:462020-10-08 13:32:22O que é CloudFlare?

WebPageTest: Aprenda como usar

29 de setembro de 2020/0 Comentários/em Dicas /por GoCache


O WebPageTest é uma ferramenta que foi desenvolvida pela AOL para uso interno, mas em 2008 o time decidiu compartilhar o recurso para qualquer usuário pelo modelo de open source (código aberto). Já em 2020, a ferramenta foi comprada pela Cathchpoint que até então, segue mantendo o WebPageTest de forma gratuita.

Como funciona o WebPageTest:

O WebPageTest é uma ferramenta de teste de performance web que analisa uma série de métricas de carregamento, renderização, segurança entre outras.

Basicamente, dentro do WebPageTest é possível selecionar instâncias de testes em diferentes locais do mundo, o que permite uma análise bastante detalhada da performance de seu site ou aplicação, a partir de países ou estados diferentes. Além da questão de instâncias espalhadas pelo mundo, o WebPageTest também permite testes em diferentes web browsers e dispositivos móveis, trazendo a possibilidade de analisar sua aplicação tanto em desktop, quanto em mobile.

Outro ponto bastante positivo do WebPageTest é a possibilidade de selecionar o tipo de conexão, permitindo que você teste o resultado de seu site para conexões banda larga, 3G, 4G, LTE, entre outras.

Como usar o WebPageTest: 

Conforme vimos acima, existem diversas opções de configuração no WebPageTest, mas como nosso intuito nesse artigo é testar um site que rode no Brasil, faremos uma configuração para teste em uma instância em São Paulo.

Passo 1 – Configuração inicial do WebPageTest

  1. URL – Adicione a página que pretende analisar. É importante adicionar o endereço exatamente da forma que ele é aberto, respeitando se ele abre em HTTP ou HTTPS e se tem algum subdomínio.
  2. Test Location –  Nesta etapa você deve selecionar a instância de teste. É fundamental levar em consideração esse passo, caso contrário você pode ter uma visão incorreta de sua aplicação.
  3. Browser – Nesta etapa é possível selecionar o browser utilizado no teste. Uma sugestão é analisar os browsers que mais geram tráfego para seu site, buscando entender melhor a experiência que seus usuários tem tido.
  4. Connection – Selecione o tipo de conexão que pretende analisar.
  5. Number of Tests to Run – Nesta etapa é possível selecionar até 9 testes de uma vez. Recomenda-se rodar acima de 3 testes para que você tenha amostragem.
  6. Start Test – Após configurar os 5 passos acima, basta apertar o botão de start para iniciar seu teste.

Após apertar sobre Start Test, aguarde alguns minutos até que os testes sejam concluídos. Feito isso, você ira se deparar com o resultado abaixo:

Resumo dos três testes no WebPageTest

Este é o resumo da média dos 3 testes. Por enquanto não vamos entrar em detalhes, já que iremos escolher um dos três resultados abaixo para ter acesso a uma analise completa. Agora, selecione um dos Test Results, conforme vemos abaixo:

Número de testes – WebPageTest

Após selecionar um dos testes, você vai receber um resumo especifico do teste.

As notas são definidas de F a A+, sendo F a pior nota, e A+ a melhor nota. Além disso, também é possível receber uma nota X quando o recurso é inexistente, como vemos abaixo em “Effectiive use of CDN”.

Resumo das notas – WebPageTest

Security Score – A nota de security score é gerada pela ferramenta Snyk. Basicamente, eles analisam alguns parâmetros de sua aplicação, como suas bibliotecas JavaScript e seus cabeçalhos de requisição HTTP:

  • X-Content-Type-Options (adiciona 25 pontos em seu score)
  • X-Frame-Options (adiciona 20 pontos em seu score)
  • Content-Security-Policy (adiciona 20 pontos em seu score)
  • X-XSS-Protection (adiciona 20 pontos em seu score)
  • X-Content-type-options (adiciona 20 pontos em seu score)
  • Strict-transport-security (adiciona 25 pontos em seu score)

First Byte Time – É o tempo de primeiro byte de seu servidor (tempo de resposta). Para otimizar seu score de First Byte Time, é necessário que sua infraestrutura responda rapidamente, sendo assim, é recomendado que você hospede seu site dentro do Brasil (para testes de instâncias em São Paulo) ou use uma CDN com capilaridade em nosso país, aliada uma estratégia de cache dinâmico, já que o primeiro byte provavelmente será calculado em seu HTML.

Keep-alive Enabled – Basicamente, para aumentar sua nota neste critério é necessário ter o Keep-alive ativo em sua aplicação.

Compress Transfer – Para melhorar seu score de comrpress transfer, basta usar modelos de compressão, como GZIP ou Minify. Caso queira consultar quais arquivos são comprimidos em GZIP pela ferramenta da GoCache, basta acessar nossa documentação aqui.

Compress Images – A nota de compress images considera se suas imagens tem algum nível de compressão. Para otimizar esse score, é recomendado utilizar algum produto de compressão de imagens, preferencialmente que faça JPEG progressivo e conversão para webP. Uma boa alternativa é utilizar o otimizador de imagens da GoCache.

Cache static content – Para aprimorar a nota de static content, é necessário implementar ou alterar sua configuração de cache control max-age. Neste caso, tanto a implementação de CDN, quanto boas políticas de cache local, devem contribuir com ganhos neste score.

Effective use of CDN – Você deve ter até 80% de seu conteúdo estático sendo servido via CDN para melhorar seu score neste quesito.


Agora que já sabemos avaliar as notas do WebPageTest, podemos seguir para os indicadores de performance detalhados.

WebPageTest – Indicadores de performance

First Byte – É uma abreviação para TTFB (time to first byte / tempo para primeiro byte). É o tempo entre a troca do primeiro byte entre o requisitante e o servidor de origem (após todos os redirecionamentos). Basicamente, para otimizar essa métrica é necessário reduzir a latência de entrega de sua aplicação, sendo assim, recomenda-se que seu host esteja no Brasil ou que você faça cache dinâmico em uma CDN com capilaridade em nível nacional. 

Start Render – Também conhecido como tempo de renderização, essa métrica mede o tempo desde o inicio da navegação até a exibição do primeiro conteúdo na tela (da tela em branco, até a aparição do primeiro conteúdo). 

First Contentful Paint – O First Contentful Paint (FCP) é uma métrica que mede o tempo desde o inicio do carregamento da página, até o momento em que qualquer parte do conteúdo da página é renderizado na tela. Refere-se a textos, imagens (incluindo BG), elementos (svg) ou elementos de <canvas>. 

Speed Index – Representa a velocidade em que a página foi renderizada. Quanto menor, melhor. Infelizmente, o WebPageTest não dá mais detalhes dessa métrica em sua documentação oficial. 

Result (error code) – Infelizmente a documentação do WebPageTest não traz nenhum detalhe sobre o error code, mas sabemos que ele mede alguns erros na página, como por exemplo, a quantidade de 404. 

Web Vitals: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Total Blocking Time (TBT) – Nesta métrica, o WebPageTest considera as notas de Core Web Vitals. Caso queira aprender sobre elas, recomendo a leitura do artigo – Core Web Vitals – Você está preparado para a nova mudança do Google?

Document Complete: As métricas agrupadas nessa coluna são coletadas até o momento em que o browser considera que a página foi carregada. Isso geralmente acontece depois que todo o conteúdo de imagens foi carregado. A métrica “Time” considera o tempo que o processo levou, “Requests“considera o volume de requisições necessárias para o carregamento da página e “Bytes in” é o tamanho da página, considerando todos os assets (js, css, html, imagens, etc..).


Após reconhecer todos os indicadores de performance, podemos descer para a área de Waterfall (cascata), onde conseguiremos analisar todas as requests que foram carregadas na página analisada.

Waterfall – Visão em cascata das requests

Dentro do waterfall é possível verificar o tempo em milissegundo (ms) que cada request precisou para ser entregue, dando uma visão bastante acurada da aplicação e trazendo insights de melhoria, como por exemplo, reduzir o tamanho de imagens que estão levando muito tempo para carregar ou até mesmo, deixar de usar elementos externos de baixa qualidade e que possam prejudicar seu resultado.

Além de analisar o modo cascata, também é possível clicar sobre a request para ter mais detalhes, conforme vemos abaixo:

Waterfall – Analisar request específica

Analisando a request de número 40, conseguimos ter alguns detalhes. Abaixo, destacamos algumas informações:

  • URL – Extensão da URL deste asset
  • IP – Origem que entregou este asset
  • Errror/Status Code –  Por aqui é possível identificar se existem redirecionamentos (301, 302), erros 4xx e etc.
  • Protocol – Vemos o protocolo de entrega desse asset.
  • Time to First Byte – Tempo necessário para o primeiro byte do asset
  • Bytes in (downloaded) – Tamanho do asset. Neste exemplo, temos uma imagem com mais de 800 kb, e que certamente poderia ser reduzida para otimizar a aplicação.

E além dos detalhes, é possível selecionar outras opções de uma request, como o “Response” que traz todo o response header da requisição:

Por exemplo, na imagem acima conseguimos visualizar informações, como:

  • Content-Type – Ainda que a extensão seja .PNG, aqui conseguimos ver como a imagem efetivamente foi entregue. Por exemplo, se o site utilizasse um otimizador de imagens, ainda que a extensão fosse .PNG, o content-type poderia ser diferente.
  • Connection – Por aqui podemos ver o tipo de conexão. É interessante analisar esse parâmetro, principalmente se você tem uma nota baixa em keep-alive.
  • Age – A idade de um arquivo se ele estiver em cache.
  • X-Cache: Hit – Vemos que o asset foi entregue por um cache local, aparentemente servido via Varnish. É importante analisar os response headers de x-cache para entender se o asset está efetivamente sendo entregue em cache. Em casso de MISS, inicie o teste novamente e veja se ele se transforma em um HIT.
  • X-Cache-Hits – É possível ver a quantidade de vezes que o asset foi entregue em cache.

Caso queira entender mais sobre response headers de cache, recomendamos o artigo – CDN Cache Headers


Espero que nosso guia tenha ajudado em sua jornada para aprender um pouco mais sobre a ferramenta do WebPageTest. Caso tenha qualquer dúvida, é só deixar um comentário que responderemos o quanto antes 🙂


https://www.gocache.com.br/wp-content/uploads/2020/10/web-page-test-como-usar.jpeg 628 1200 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-09-29 10:07:152020-11-23 16:42:10WebPageTest: Aprenda como usar

CDN Cache Headers: Aprenda a inspecionar

22 de setembro de 2020/0 Comentários/em Dicas /por GoCache

Os response header (cabeçalhos de resposta) fazem com que o cliente e o servidor transmitam informações adicionais com a solicitação ou resposta HTTP. Normalmente são compostos por um nome seguido por dois pontos, como por exemplo, x-cache:

Provavelmente você já deve ter se deparado com algum dos response headers citados abaixo:

  • content-encoding: Especifica o algoritmo de compressão.
  • content-type: Especifica o tipo de mídia do recurso.
  • date: Indica a data e hora que a mensagem foi gerada.
  • set-cookie: Envia cookies do servidor para o usuário.
  • content-length: Tamanho do corpo da mensagem em decimal.

Além dos response headers citados acima, também é frequente encontrar response headers de cache. Os mais frequentes são:

  • age: Tempo em segundos em que o objeto está em cache.
  • cache-control: Especifica diretivas para mecanismos de cache em requisições e respostas. Entre as principais diretivas estão: no-cache, max-age, public, private, no-cache.
  • expires: Data/hora que a resposta passa a ser considerada como obsoleta.
  • x-cache: Apresenta qual o status de cache do asset inspecionado. Pode ser MISS (não cacheado), HIT (entregue por cache) ou BYPASS (entregue diretamente pela infraestrutura).

Como inspecionar os response headers?

Google Chrome:

Inspecionar response headers é algo bem simples de ser feito. Em seu Google Chrome, basta segurar CTRL + SHIFT + I. Feito isso, acesse a aba de “Network” e “Headers”.

Como inspecionar response headers no Chrome

Firefox:

O processo de inspecionar response headers no Firefox é o mesmo do Google Chrome. Basta segurar CTRL + SHIFT + I,  e selecionar a opção “rede” ou “network”, dependendo do idioma de sua instalação.

Como inspecionar response headers no Firefox

Terminal: 

E caso prefira inspecionar os response headers via terminal, é possível utilizar o comando “curl -I”, conforme vemos abaixo:

Exemplo de inspeção via terminal linux


CDN Cache Headers: Quais os mais frequentes?

Cada solução de CDN personaliza seus headers, o que acaba gerando bastante confusão para webmasters que estão familiarizados com response headers de cache convencional.

Abaixo, confrima os principais response headers enviados pela GoCache:

  • x-gocache-cachestatus: BYPASS
    • Item entregue diretamente pela infraestrutura, sem influência de cache.
  • x-gocache-cachestatus: HIT
    • Item entregue em cache pela CDN.
  • x-gocache-cachestatus: MISS
    • Item elegível a cache que ainda não está armazenado na CDN. Na próxima requisição um MISS deve virar um HIT.
  • x-gocache-cachestatus: EXPIRED
    • Item com cache expirado. Na próxima requisição um EXPIRED deve virar um HIT.
  • x-gocache-image:  optimized
    • Imagem otimizada pelo conversor de imagens da GoCache
  • x-gocache-image: unmodified
    • Imagem não foi modificada/otimizada pelo conversor de imagens da GoCache

E caso esteja em dúvida sobre outros response headers, citamos abaixo exemplos de outras soluções de CDN: 

CloudFlare
  • cf-cache-status: DYNAMIC
    • Entregue diretamente pela infraestrutura, sem influência de cache.
  • cf-cache-status: HIT
    • Entregue em cache.
  • cf-cache-status: MISS
    • Elegível a cache, mas ainda não foi entregue pela CDN.
  • cf-cache-status: EXPIRED
    • Item que estava em cache, mas expirou.
  • cf-ray: local de entrega
    • Indica o pop que serviu um determinado asset. Por exemplo, GRU (SP), ATL (Atlanta), BOS (Boston)
CloudFront
  • 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.
  • 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.
  • x-amz-cf-pop: Localização de entrega
    • Indica por onde o asset foi entregue. Exemplo, GIG51-C2 (RIO), GRU1-C1 (São Paulo).


https://www.gocache.com.br/wp-content/uploads/2020/09/curl-response-header-terminal.jpeg 140 463 GoCache https://www.gocache.com.br/wp-content/uploads/2016/11/logo_cor_menu-1-1.png GoCache2020-09-22 13:23:342020-10-02 15:37:24CDN Cache Headers: Aprenda a inspecionar
Página 1 de 212

Procurar

Últimas publicações

  • Por que a velocidade de um site é importante? Google Playbook 12 de janeiro de 2021
  • Web Scraping: O que é, e suas aplicações 7 de janeiro de 2021
  • Quais as verticais mais exploradas por bad bots? 5 de janeiro de 2021
  • Histórico de Alterações – Novo recurso da GoCache 22 de dezembro de 2020
  • Como usar o ISPTools? 17 de dezembro de 2020
  • CDN para Elementor – Como reduzir tempo de carregamento do WordPress 14 de dezembro de 2020
  • CDN para WooCommerce com integração via Plugin 10 de dezembro de 2020
  • Como melhorar o resultado orgânico do meu site 8 de dezembro de 2020
  • Queda de tráfego orgânico? Pontos em que a CDN pode ajudar 2 de dezembro de 2020
  • Site fora do ar/indisponível? Saiba como a CDN pode dar mais poder de escala para sua aplicação 26 de novembro de 2020

Produtos

  • Content Delivery Network
  • SSL
  • Web Performance Optimization
  • Web Application Firewall

Soluções por vertical

  • Portais de conteúdo e notícias
  • E-Commerce
  • Educação / Edtech
  • Plataformas de E-Commerce
  • Startup
  • Outros

Empresa

  • Central de Ajuda
  • Carreiras
  • Blog
  • Contato
  • Planos
  • Calculadora de Preços
  • Termos de Uso e Politica de Privacidade

Acompanhe nosso Blog!

  • Por que a velocidade de um site é importante? Google Playbook
  • Web Scraping: O que é, e suas aplicações
  • Quais as verticais mais exploradas por bad bots?
  • Histórico de Alterações – Novo recurso da GoCache
  • Como usar o ISPTools?
© Copyright - GoCache - 2020
  • Linkedin
  • Facebook
  • Twitter
Este site utiliza cookies para aprimorar sua navegação. Na GoCache o uso de cookies é feito apenas para reconhecer um visitante constante e melhorar a experiência no uso dos Serviços. Os cookies são pequenos arquivos de dados transferidos de um site da web para o disco do seu computador, e não armazenam dados pessoais. Se preferir, você pode apagar os cookies existentes em seu computador através do browser utilizado. Leia nossos termos de usoOkRecusar
Scroll to top