Conteúdos, dicas e sugestões sobre SEO em geral

O texto abaixo foi coletado da atualizações do WebPageTest sobre como medir métricas de Core Web Vitals.

Ao combinar as métricas Core Web Vital com a maior plataforma de monitoramento de Experiência Digital do mundo e nossos recursos de análise de desempenho, os usuários do Catchpoint serão capazes de:

• Passar de desenhar correlações soltas para fazer declarações de causalidade confiáveis ​​(entre o TI e a empresa).
• Combinar melhor os limites de percepção de desempenho por segmento de cliente ou jornada do usuário.
• Aproveitar o poder de nossa plataforma de inteligência para perceber o valor dos resultados centrados no cliente do mundo real.

O que são Core Web Vitals?

A equipe do Chrome no Google anunciou as Core Web Vitals no ano passado “para ajudar os proprietários de sites a medir a experiência do usuário na web”. Elas representam um subconjunto de métricas relacionadas à velocidade, capacidade de resposta e estabilidade visual – e incluem estas métricas:

1. Mudança de layout cumulativa (CLS – Cumulative Layout Shift)

2. Maior Pintura com Conteúdo (LCP – Largest Contentful Paint)

3. Atraso na primeira entrada (FID – First Input Delay)

Leia mais sobre Core Web Vitals em nosso artigo – Core Web Vitals: Você está preparado para as mudanças do Google?

Mudança De Layout Cumulativa (Estabilidade Visual)

O CLS mede a instabilidade visual de uma página, como realmente vista pelo cliente. Instabilidade, neste contexto, refere-se a “alvos móveis”, ou seja, quando um cliente clica em algo e esse algo mudou repentinamente para um local completamente diferente na janela de visualização. Isso pode significar a diferença entre clicar no resultado de pesquisa desejado e clicar em um anúncio que colocará 5.000 cookies no seu dispositivo!

Maior Pintura com Conteúdo (Carregando)

O LCP mede quando a navegação da página parece concluída para o cliente. Para contexto, estar “concluída” geralmente é o motivo pelo qual o cliente está em uma página em primeiro lugar. Diferente da Primeira Pintura com Conteúdo, que pode ser algo como “uma tela inicial” ou o ícone “sua página está carregando”, a Maior Pintura com Conteúdo mede a rapidez com que o conteúdo principal, relevante de uma página da web é carregado e fica visível para os usuários.

Atraso na Primeira Entrada (Interatividade)

O Atraso na Primeira Entrada (FID), por sua vez, mede a capacidade de resposta de experiências interativas em uma página da web. É a diferença entre “adicionar 1 item ao seu carrinho, ”versus“ adicionar múltiplos itens ao seu carrinho ”porque o botão adicionar ao carrinho parecia não responder, fazendo com que um cliente clicasse nele novamente, o que causava uma interrupção na jornada. Especificamente, o FID mede o tempo desde quando um usuário interage pela primeira vez com uma página até “o tempo em que o navegador é realmente capaz de começar a processar manipuladores de eventos em resposta a essa interação”.

Subindo na cadeia hierárquica das necessidades de monitoramento digital

Talvez a melhor maneira de resumir o valor dessas novas métricas é que elas moverão os usuários do Catchpoint para um escalão superior da cadeia hierárquica de necessidades de monitoramento digital. Há um oceano de métricas de indicadores de TI monitoráveis ​​para tempo de atividade, tempo de resposta e latência. E a ideia de métricas baseadas na experiência, como o tempo de carregamento da página ou a conclusão do documento, também existe há algum tempo. O que é diferente sobre as métricas Core Web Vital é que elas levam a ideia das métricas baseadas na experiência do cliente a um novo nível – um nível de capacidade baseado no que o cliente realmente vê e experimenta com os seus próprios olhos enquanto eles estão tentando completar as suas respectivas jornadas.

Por que usar o Catchpoint para medir Core Web Vitals?

O Google já oferece aos clientes várias maneiras de medir essas métricas. Então, por que os usuários do Catchpoint deveriam se preocupar com o fato de essas métricas agora estarem disponíveis nessa plataforma?

Ignore por um momento que a maioria das ferramentas de desenvolvimento oferecidas pelo Google são apenas Chrome (o que para alguns será um desqualificador) ou que algumas de suas fontes de dados são atualizadas apenas uma vez por mês. Mais importante, essas ferramentas têm 75ºpercentil como o limite “bom” versus “ruim”. Essa visão de tamanho único é muito restrita e pode levar a ações incorretas e / ou desperdício de recursos de otimização preciosos. Afinal, seus clientes são únicos. Dito de outra forma, os perfis de desempenho do cliente variam de acordo com o ISP, dispositivo, tipo de navegador, jornada do usuário, objetivo pessoal e muitas outras variáveis. Portanto, o uso e a medição ideais dessas métricas do Core Web Vital também precisam corresponder e levar em consideração essas combinações variadas de usuários.

Além disso, se você pensar sobre as outras ferramentas fornecidas pelo Google, seja DevTools ou PageSpeed ​​Insights, que medem localmente ou perto da fonte, você logo perceberá que precisa de mais alcance e reprodutibilidade do que o uso do Google sozinho pode oferecer. Pense no desenvolvedor A compartilhando seus resultados do DevTools com o desenvolvedor B e vendo resultados completamente diferentes com base em onde eles estão localizados.

Resumindo, nossos usuários se beneficiarão com o uso do Catchpoint para medir o Core Web Vitals por cinco razões principais:

1. Acionabilidade: Mais sinais com menos ruído para concentrar recursos de otimização preciosos.

2. Granularidade: Limites de percepção de correspondência por segmento de cliente, geografia ou outra dimensão (executar WebPageTest em um M1?).

3. Alcance: Combine essas novas métricas com o maior footprint de telemetria de monitoramento digital do mundo.

4. Confiabilidade: Única fonte de verdade para medições normalizadas e reprodutibilidade.

5. Coesividade: Ambas as medições de laboratório e de campo em uma plataforma única e unificada.

Quer aprender mais sobre o Web Page Test? Confira nosso artigo – WebPageTest: Como usar? 

Referencia: https://blog.catchpoint.com/2021/04/27/five-reasons-to-use-catchpoint-for-measuring-core-web-vitals

Martin Splitt, do Google, explica porque alguns que aprimoraram o Core Web Vitals estão experimentando aumentos de classificação antes da atualização de experiência na página.

Os editores de sites estão relatando um aumento nas classificações após melhorarem as suas pontuações do Core Web Vitals. Martin Splitt, do Google, responde à pergunta se esses aumentos de classificação se devem a um teste de atualização da Experiência na página e explicou porque as classificações do Google melhoraram para esses editores.

Loren Baker observou que houve muitos comentários de editores que melhoraram as suas pontuações principais do Core Web Vitals e obtiveram melhores classificações. Isso levou à especulação de que o Google pode estar testando novas pontuações do Core Web Vitals.

Loren perguntou a Martin Splitt:

“Isso é uma indicação de que a Atualização de experiência na página pode estar sendo testada agora, talvez nos fins de semana, e/ou sendo lançada lentamente antes de oficialmente?

Ou é uma coincidência?”

Enquanto Loren lia a pergunta, Martin Splitt podia ser visto na tela balançando a cabeça, indicando que sua resposta seria não.

Apesar de balançar a cabeça, ele pode ter surpreendido os espectadores com sua resposta.

Martin Splitt respondeu:

“Não é nada disso. Não é nem coincidência.

A velocidade da página foi um fator de classificação antes.

Não tem nada a ver com a experiência na página neste caso.

Mas coincidentemente, ao tornar o site melhor, você obteve um aumento de classificação de algo que não é a experiência na página.”

Neste ponto, Martin Splitt dá um sinal de positivo entusiasmado e gesticula com as mãos em comemoração a todos os editores que experimentaram aumentos de classificação depois de melhorarem as suas pontuações principais do Core Web Vitals.

Ambos riram e Loren respondeu:

“Isso faz muito sentido, na verdade. Portanto, parabéns por acelerar a sua página antes que a atualização da Experiência na Página seja lançada. Você pode estar vendo uma melhoria na classificação por causa das mudanças que você fez, mas não necessariamente por causa da atualização da Experiência na Página. Ok, isso faz todo o sentido!”

Aumento da classificação da velocidade da página?

No passado, o aumento do fator de classificação da velocidade da página era considerado um fator um tanto pequeno. Mas, aparentemente, para Martin Splitt, pode ser um fator de classificação que pode ajudar a melhorar as classificações de uma maneira mais dramática.

Fator de classificação de velocidade da página (Page Speed)

O Page Speed ​​tem sido um fator de classificação para usuários de desktop desde 2010. O Google anunciou em julho de 2018 que agora era um fator de classificação para pesquisas em dispositivos móveis.

De acordo com o anúncio oficial:

“… A partir deste mês (julho de 2018), a velocidade da página também será um fator de classificação para pesquisas em dispositivos móveis.

Se você é um desenvolvedor que trabalha em um site, agora é um bom momento para avaliar o seu desempenho usando nossas ferramentas de velocidade.”

O anúncio na época recomendava reduzir muito o JavaScript e tamanhos de imagem excessivos como parte de uma iniciativa para aumentar a velocidade da página.

“Você está enviando muito JavaScript? Muitas imagens?

Imagens e JavaScript são os contribuidores mais significativos para o peso da página que afetam o tempo de carregamento da página com base nos dados do Arquivo HTTP e do Relatório de experiência do usuário do Chrome – nosso conjunto de dados públicos para as principais métricas de experiência do usuário experimentadas pelos usuários do Chrome em condições do mundo real.”

A atualização da experiência na página não está ativa até Junho de 2021

Qualquer editor que tenha aumentos de classificação após corrigirem os seus problemas de velocidade da página pode provavelmente considerar o fator de classificação da velocidade da página um possível motivo.

A atualização da Experiência na página ainda não está sendo lançada de nenhuma forma no momento e, portanto, não pode ser o motivo para nenhum aumento de classificação no momento.

Referência: https://www.searchenginejournal.com/google-why-fixing-core-web-vitals-already-boosts-rankings/408462/#close

O Gzip se tornou o padrão ouro para compactação de arquivos no início dos anos 1990, mas se você ainda o usa em 2018, convém mudar para um método de compactação mais recente.

Embora o Gzip ainda tenha seu lugar no coração de muitos, os desenvolvedores da web estão cada vez mais se voltando para opções superiores, como o algoritmo de compressão Brotli do Google.

Uma breve história sobre a compactação de arquivos

O “G” em Gzip é a abreviação de GNU. GNU é um sistema operacional de código aberto baseado em Unix que foi desenvolvido na década de 1980. Naquela época, a Unisys e a IBM já haviam patenteado seus próprios algoritmos para compactar e descompactar arquivos, o que permitia que suas máquinas armazenassem mais dados. Portanto, os programadores Jean-loup Gailly e Mark Adler criaram o Gzip como uma alternativa gratuita para usuários GNU.

O novo Gzip não era apenas uma cópia barata; era realmente mais rápido do que os seus concorrentes protegidos por direitos autorais. Como resultado, as pessoas ainda o usam para compactação de arquivos até hoje. Embora seja fácil manter o que você está acostumado, existem vários algoritmos de compactação que atualmente fornecem melhores resultados de compactação do que o Gzip. É aí que entra o Brotli.

O que é o Brotli?

Brotli é uma especificação de formato de dados mais recente que aproveita a vantagem de vários algoritmos para condensar os dados com mais eficiência do que o Gzip. Em 2015, a especificação Brotli foi generalizada para compressão de fluxo HTTP com o tipo de codificação de conteúdo ‘br’.

Desenvolvido por Jyrki Alakuijala e Zoltan Szabadka, o Brotli usa os mesmos algoritmos de compactação do Gzip, mas também é compatível com um dicionário de palavras e frases usadas com frequência para oferecer uma taxa de compactação melhor.

Lembre-se de que Gzip e Brotli devem ser usados ​​apenas para compactar arquivos de texto. Arquivos binários como JPEGs e MP4s contam com seus próprios algoritmos de compactação específicos de formato. Se você tentar compactar um JPEG com Brotli, o arquivo resultante será na verdade maior do que o original.

Embora nem sempre tenha sido assim, o Brotli agora é compatível com todos os principais navegadores.

No caso de um navegador, que não suporta os quesitos do Brotli, solicitar um ativo de um site que entrega arquivos compactados por Brotli, o servidor fará fallback para o Gzip e entregará ativos codificados que o navegador suporta – desde que o servidor esteja configurado corretamente.

O que torna o Brotli melhor?

• Os pacotes JavaScript compactados com Brotli são 14 por cento menores do que os pacotes Javascript compactados com Gzip.
• Os arquivos HTML compactados pelo Broti são 21 por cento menores do que seus equivalentes no Gzip.
• Os arquivos CSS compactados pelo Brotli são 17% menores do que aqueles compactados pelo Gzip.
• Como a maioria dos sites depende de todos esses três tipos de ativos, há uma diferença considerável nos tamanhos dos ativos quando comparados com o Gzip. Essa economia, por sua vez, fará uma melhoria perceptível no desempenho do seu aplicativo.

Gzip vs Brotli: Obtendo o máximo do Brotli

Apesar do que você pode ter ouvido, compactar ativos com Brotli não é mais demorado do que com o Gzip. Dito isso, Gzip e Brotli oferecem níveis variáveis ​​de compactação, e as configurações padrão do Brotli podem resultar em uma compactação mais lenta do que as configurações padrão do Gzip. Você terá que fazer alguns ajustes no Brotli para encontrar um equilíbrio aceitável entre o tamanho do arquivo e a velocidade de compressão.

A configuração de compactação ideal depende do que e quando você está compactando. Um bom ponto de partida é o Brotli 4 para compressão mais rápida de conteúdo dinâmico. Por outro lado, os ativos estáticos podem ser compactados de forma mais densa de antemão, sem sacrificar a velocidade, de modo que a configuração padrão “11” é mais apropriada para esse conteúdo.

Usando Brotli com ativos pré-compactados

O Brotli é ótimo para fornecer ativos pré-compactados muito mais rápido do que o Gzip. Isso se deve ao fato de que você pode compactá-los no nível mais alto do Brotli e fazer com que o servidor de origem os pegue quando solicitado.

Este tipo de configuração funciona muito bem com o Webpack, pois um plugin Webpack está disponível para compactar automaticamente seus ativos estáticos como Gzip e Brotli. Portanto, nenhuma compactação dinâmica é necessária, o que significa que o tempo gasto na compactação dos arquivos é salvo.

Gzip vs Brotli: em resumo

A pequena quantidade de esforço necessária para adicionar o Brotli ao seu servidor web vale a pena comparada a economia substancial no tamanho do arquivo. Embora o Brotli às vezes funcione mais devagar nas configurações de compressão mais altas, você pode facilmente atingir um equilíbrio ideal entre a velocidade de compressão e o tamanho do arquivo ajustando as configurações.

Embora o uso do Brotli possa transformar aplicativos da web rápidos em mais rápidos, ele não necessariamente tornará aplicativos lentos mais rápidos. Uma vez que o Brotli comprime apenas ativos baseados em texto, você precisará otimizar as suas imagens por outros meios. Se você ainda não fez o salto para HTTP / 2, isso pode fazer uma grande diferença no desempenho do seu aplicativo. Cada milissegundo conta, portanto, qualquer ação que você execute para acelerar o seu aplicativo aumenta as suas chances de reter usuários.

Referencia: http://www.instantshift.com/2018/03/02/gzip-vs-brotli-compression/

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 é 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