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

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

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:

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:

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 🙂

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 🙂