Táticas de crescimento de editores para época eleitoral | WEBINÁRIO
Táticas de crescimento de editores para época eleitoral | WEBINÁRIO
No final deste módulo, você deverá ter uma compreensão clara dos vários componentes que contribuem para a experiência da página, por que eles são importantes e como cada um pode ser otimizado para melhorar a experiência do usuário do seu site e seu SEO.
Duração do vídeo
17:09
Responder ao questionário
Faça um teste atual do módulo
Materiais
Modelos prontos para usar
Recursos
Relatórios e recursos
2.3.1 O que é a experiência da página?
A experiência da página é um conjunto de sinais — incluindo as Core Web Vitals (CWVs), a compatibilidade com dispositivos móveis, o HTTPS e as diretrizes sobre anúncios intersticiais intrusivos — que o Google usa para extrapolar a experiência do usuário em um site.
A experiência da página é uma avaliação do desempenho de um site, e não do seu conteúdo. Embora o Google ainda priorize a relevância do conteúdo ao responder às consultas dos usuários, a experiência da página funciona como um critério de desempate quando vários sites oferecem um nível semelhante de abrangência.
Os quatro sinais de experiência da página são:
Os CWVs (Current Web Values - Valores de Página Útil) medem a experiência do usuário focando na velocidade de carregamento de uma página, sua capacidade de resposta à interação do usuário e também sua estabilidade visual. Existem três métricas para isso:
A atualização do Google em abril de 2015 introduziu a métrica de compatibilidade com dispositivos móveis, que melhora o posicionamento de páginas otimizadas para dispositivos móveis nos resultados de busca para dispositivos móveis.
Na prática, o Google dará prioridade aos sites que garantem que seu conteúdo seja facilmente legível em dispositivos móveis — ou seja, não há necessidade de zoom, os elementos interativos, como botões de login, não estão muito próximos uns dos outros, não há rolagem horizontal e o conteúdo não reproduzível é evitado.
A atualização se aplica a páginas individuais, não a sites inteiros, e também não afeta o conteúdo visualizado em navegadores de computadores desktop/laptop.
O HTTPS, ou protocolo de transferência de hipertexto seguro, é uma versão segura do protocolo de comunicação da Internet HTTP.
O HTTPS, ou HTTP, forma a primeira parte de cada URL, conhecida como "esquema". Ele vem antes do nome de domínio, que é o segmento da URL conhecido como "autoridade".
A diferença entre HTTPS e HTTP é que o primeiro é seguro, enquanto o segundo não. Na prática, isso significa que os usuários que acessam um site por meio de uma conexão HTTP enviam seus dados pessoais em texto simples não criptografado.
O HTTPS protege essa conexão, o que significa que todos os dados enviados entre o navegador do usuário e o servidor do site são criptografados durante a transmissão. Sites que desejam conexões seguras precisam de um certificado SSL, que o navegador do usuário verifica e valida.
Os anúncios intersticiais são um formato exclusivo para dispositivos móveis que aparece apenas em pausas naturais no conteúdo — como quando um usuário passa de um artigo para outro — cobrindo a tela durante o processo.
Os elementos intersticiais são considerados intrusivos quando bloqueiam ou obscurecem parcialmente a visualização do conteúdo pelo usuário. As caixas de diálogo em sites para dispositivos móveis que se comportam de maneira semelhante também se enquadram nessa categoria.
A maioria dos editores possui como principais competências a criação de conteúdo, a publicação e o marketing, o que deixa pouco espaço para compreender e otimizar os diversos pilares da experiência da página.
Recursos limitados significam que as editoras terão dificuldades em justificar o tempo e o dinheiro necessários para analisar o funcionamento interno de páginas web individuais, quanto mais de um website inteiro.
Mesmo que as editoras consigam dedicar tempo para resolver o problema, como podemos ver acima, a experiência da página é uma questão multifacetada que exige uma abordagem holística para gerar ganhos de desempenho significativos.
Saber em qual dos quatro sinais de experiência da página começar a trabalhar pode ser uma dor de cabeça por si só.
A experiência do usuário na página é extremamente importante para o SEO do editor, já que um ótimo conteúdo não é suficiente para garantir uma posição de destaque nos resultados de busca.
O Google ainda valoriza a melhor informação acima de tudo, o que significa que conteúdo exclusivo ou notícias exclusivas terão um bom desempenho mesmo que a experiência da página seja considerada "inferior" . No entanto, em casos onde vários veículos de comunicação oferecem uma excelente cobertura do tema, a experiência da página se torna um fator decisivo importante que influencia o posicionamento nos resultados de busca.
Cada um dos quatro pilares da experiência da página tem um impacto diferente no SEO de um site. O impacto mais imediato vem do foco em CWVs (valores de cliques), o que se traduzirá em um site que carrega mais rápido.
Diversos estudos demonstraram que quanto mais tempo um site demora para carregar, mais rápido o público perde o interesse e maior se torna a taxa de rejeição.
Por exemplo, um estudo do Google de 2018 descobriu que a probabilidade de rejeição aumentou 32% quando o tempo de carregamento da página subiu de 1 segundo para 3 segundos.
Outro estudo do Google, de 2020, constatou que os sites de notícias que passaram no teste CWV apresentaram uma taxa de abandono 22% menor do que aqueles que não passaram. O Yahoo! Japão, por sua vez, melhorou sua pontuação CLS em 0,2 e registrou um aumento de 15,1% nas visualizações de página por sessão e de 13,3% na duração da sessão.
Embora o Google tenha afirmado explicitamente que não usa taxas de rejeição como um fator de classificação , uma alta taxa de rejeição indica fatores que o Google considera importantes — principalmente a velocidade de carregamento da página, a capacidade de resposta e a estabilidade visual.
Editores que visam o público em dispositivos móveis precisam garantir que seus sites enviem sinais de compatibilidade com dispositivos móveis que tanto o Google quanto o Bing possam reconhecer. Ambos os mecanismos de busca priorizam sites compatíveis com dispositivos móveis ao exibir resultados de pesquisa para usuários de dispositivos móveis.
Em comparação com os CWVs e a compatibilidade com dispositivos móveis, a implementação do HTTPS terá um impacto muito menor no SEO de um editor. O Google afirmou em 2014 que o utilizaria como um fator de classificação e começou a marcar todos os sites HTTP como "não seguros" no Chrome em 2018. No entanto, o maior benefício aqui é a segurança de dados aprimorada, especialmente se o seu modelo de negócios for baseado em receita por assinatura.
Anúncios intersticiais intrusivos ou caixas de diálogo, por sua vez, podem limitar a capacidade dos rastreadores da web de rastrear e indexar uma página, impedindo que os mecanismos de busca sequer consigam classificá-la, muito menos exibi-la em posições elevadas nos resultados de pesquisa.
O primeiro passo para melhorar a experiência do usuário na página começa com a avaliação da eficácia atual do seu site.
Existe uma ampla variedade de ferramentas próprias e de terceiros para realizar essa tarefa, mas, para este guia, vamos analisar as ferramentas próprias do Google.
Agora sabemos que os CWVs são um fator importante de classificação. Mas como são medidos? A tabela abaixo lista os parâmetros dentro dos quais os valores ideais de CWV devem se enquadrar para a melhor experiência da página.
Agora que sabemos o que precisamos medir e em que medida, podemos analisar como medir a experiência da página.
Abaixo segue uma lista de alguns dos métodos mais comumente utilizados.
A primeira opção disponível para as editoras é, de longe, a mais complexa tecnicamente e não recomendamos que seja sequer considerada, a menos que você tenha um bom desenvolvedor para auxiliar na sua implementação.
Estamos falando sobre coletar dados de usuários do seu site, um processo conhecido como monitoramento de usuários reais (RUM, na sigla em inglês), e depois analisar os resultados no Google Analytics 4 (GA4). O Google oferece outras ferramentas, como o PageSpeed Insights (PSI), que usam amostragem de dados para avaliar seu site. Mas, se o objetivo é ter uma visão completa da experiência do usuário no seu site, você precisa de dados reais coletados diretamente do seu site.
Recomendamos o uso do GA4 para essa tarefa pelo simples motivo de que o Google pretende começar a desativar a geração anterior do Google Analytics, o Universal Analytics (UA), a partir de meados de 2023.
Como editor, você já deveria ter configurado uma conta do GA4 em antecipação à transição. Caso contrário, siga os guias do Google sobre como configurá-la pela primeira vez ou como adicioná-la a um site que já possui um usuário cadastrado no Google Analytics .
Feito isso, o próximo passo é vincular o data warehouse BigQuery do Google ao GA4 a partir do painel de administração do Analytics. Vincular o BigQuery permitirá que você consulte seus dados usando SQL. Aqui está um guia sobre como vincular os dois .
Com esses passos concluídos, agora podemos adicionar a biblioteca de web vitais ao seu site.
A biblioteca, que é uma biblioteca JavaScript modular extremamente pequena para coleta de dados, está disponível no GitHub.
A biblioteca pode ser instalada a partir do repositório online de código aberto npm, executando “npm install web-vitals” no seu terminal de comandos, ou via<script> tags on a content distribution network (CDN).
Eis um exemplo de tal script:
Após a instalação da biblioteca web-vitals, os dados do usuário podem ser enviados para o Google Tag Manager (GTM), utilizando uma tag de modelo personalizada recomendada pelo Google, criada e mantida por Simo Ahava.
Após a instalação da tag, as métricas CWV e os dados de atribuição associados podem ser encaminhados para o GA4.
Depois de configurar as análises para rastrear os dados do GTM, você poderá visualizar os dados de eventos na interface do BigQuery. Esses dados podem ser consultados da seguinte forma:
Após a consulta ser retornada, o relatório deverá ter uma aparência semelhante a esta:
Precisamos ressaltar novamente que esta é uma solução para desenvolvedores e, na verdade, é bem mais complexa do que isso. No entanto, adotar essa solução lhe proporcionará a leitura mais precisa do desempenho do seu site.
Para uma explicação mais detalhada desse processo, consulte o guia do Google sobre como visualizar CWVs no GA4 .
Embora essa seja a abordagem mais precisa para monitorar as CWVs, existem abordagens mais simples para lidar com esse problema.
O PSI é menos preciso do que usar uma abordagem GA/RUM; no entanto, é frequentemente citado como uma das ferramentas mais importantes para medir CWVs — graças à sua facilidade de uso.
Embora utilize apenas amostras de experiências reais de usuários extraídas do Relatório de Experiência do Usuário do Chrome (CrUX) dos últimos 28 dias, o PSI oferece uma interface de usuário simples e fácil de entender . Isso significa que interpretar os dados é um processo muito mais simples.
Como você pode ver em nosso exemplo abaixo, examinar o site da Forbes fornece imediatamente uma grande quantidade de informações tanto na versão para desktop quanto na versão para dispositivos móveis do site da editora.
A PSI utiliza as categorias verde, âmbar e vermelha acima ao atribuir as classificações de desempenho Bom, Precisa Melhorar e Ruim.
A abordagem de amostragem da CrUX significa que, embora a avaliação da Forbes acima tenha levado em consideração algumas experiências reais de usuários do site, ela não pode considerar todos os dados de usuários do site.
Essa abordagem de amostragem torna-se problemática para locais menores, muitos dos quais não estarão presentes nos dados de campo do CrUX.
No entanto, a PSI ainda pode oferecer um diagnóstico virtual do seu site usando dados de laboratório extraídos da ferramenta de código aberto Lighthouse . Veja o exemplo abaixo:
O problema dessa abordagem é que o Lighthouse coleta seus dados usando configurações predefinidas de dispositivos e redes, que não refletem as configurações dos seus usuários. Isso significa que é um substituto inadequado para a solução real.
O GSC é uma ferramenta projetada para fornecer aos editores uma visão geral dos problemas de CWV (Content Workbench) de seus sites, abrindo caminho para uma abordagem holística na melhoria do desempenho do site.
Isso é feito agrupando os relatórios de desempenho de URLs com base no status, tipo de métrica ou similaridade temática. A ferramenta não identifica problemas em páginas individuais, o que impede a implementação de correções em um nível granular.
É aí que a PSI entra em cena. Vale ressaltar, porém, que o relatório de páginas individuais da PSI pode diferir consideravelmente dos resultados de grupo do GSC. Isso ocorre porque a página individual é apenas um componente dos resultados agregados de grupo do GSC.
Ao acessar o painel de controle do GSC, os usuários verão a aba Core Web Vitals no lado esquerdo. Clicar nessa aba exibe relatórios CWV separados para dispositivos móveis e desktops, agrupados por URL.
Apesar de existirem três métricas CWV — LCP, FID e CLS — os URLs receberão uma classificação geral com base na métrica de pior desempenho para um dispositivo específico, o que também afetará os relatórios do grupo.
Por exemplo, se um URL em um dispositivo móvel receber um FID ruim e um LCP bom, ele será classificado como ruim em dispositivos móveis.
Novamente, é importante ressaltar que o GSC não foi projetado para correções granulares. No entanto, ele é excelente para editores que possuem muitas páginas semelhantes. Por exemplo, sites de notícias podem ter um design e layout relativamente padronizados para suas páginas de artigos, utilizando uma imagem como o maior elemento visível na parte superior da página. Nesse caso, o GSC pode ajudar rapidamente a identificar problemas de LCP em uma variedade de URLs.
A ferramenta final no conjunto de ferramentas de medição de desempenho do Google é o Lighthouse . Essa ferramenta é completamente diferente das anteriores, pois emula o desempenho do usuário com base em um conjunto predefinido de parâmetros.
Não utiliza dados de campo e, portanto, é mais limitado em termos de aplicações práticas. Por exemplo, os dados de campo são influenciados pela conexão de rede do usuário e pela sua distância aos servidores do site, enquanto o Lighthouse emula um dispositivo de médio alcance para coletar dados em um ambiente controlado.
É importante também entender que a pontuação do Lighthouse não é apenas uma soma das pontuações do CWV. Ela exclui o FID, já que os dados de laboratório, por sua natureza, excluem as interações do usuário final, enquanto adicionam métricas como o tempo total de bloqueio (TBT), o índice de velocidade (SI) e o tempo até a interação (TTI). Para aqueles que desejam simular uma experiência FID em laboratório, o TBT pode ser usado como um indicador.
No entanto, recomendamos não usar o Lighthouse como principal recurso de medição. Em vez disso, ele deve ser usado como uma ferramenta complementar ao PSI para ajudar a solucionar problemas específicos da página.
Os editores que desejarem usar o Lighthouse em seus testes podem fazê-lo por meio das Chrome Devtools , que estão integradas diretamente ao navegador Chrome, por meio de uma extensão para o navegador ou em web.dev/measure .
O Lighthouse analisará sua página da web e fornecerá pontuações de 0 a 100 em quatro áreas:
Veja como fica quando configuramos nossa página inicial com a opção web.dev.
O design web para dispositivos móveis difere do design web tradicional para desktops, pois os dispositivos móveis têm telas menores, geralmente possuem hardware menos potente e dependem exclusivamente de entradas por toque.
Sites otimizados para dispositivos móveis priorizam a experiência do usuário seguindo um conjunto de boas práticas que exploraremos mais adiante. Por enquanto, a melhor maneira de verificar se suas páginas são compatíveis com dispositivos móveis é usando o Teste de compatibilidade com dispositivos móveis .
Ao inserir o URL de uma página da web otimizada para dispositivos móveis, o resultado é o seguinte:
As páginas que não passarem neste teste exibirão diversas opções de correção. Abordaremos essas opções mais adiante.
Verificar se o seu site possui uma conexão segura é um processo extremamente simples, que envolve abrir o navegador e observar o símbolo à esquerda do URL na barra de endereços.
No Chrome, uma conexão segura será indicada por um símbolo de cadeado fechado, como este:
Uma conexão não segura terá um símbolo de informação como este:
Determinar se seus anúncios intersticiais são intrusivos ou não não é tão simples quanto inserir o endereço do seu site em uma ferramenta online e esperar que ela retorne um sinal de positivo ou negativo.
Isso exige o estudo dos anúncios intersticiais e das caixas de diálogo em seu site e a verificação se eles atendem a determinados parâmetros.
Considere esses parâmetros como perguntas, por exemplo:
Se você responder sim a alguma dessas perguntas, provavelmente é um indicativo de que o anúncio ou a caixa de diálogo é intrusiva.
Agora que temos um domínio sólido sobre os diferentes componentes dos quatro elementos que contribuem para a experiência da página, bem como os meios para monitorar seu desempenho, vamos explorar exatamente como podemos impulsionar os sinais de classificação de nossos sites
Vamos analisar primeiro os CWVs, pois a depuração e otimização de LCP, CLS e FID terão o maior impacto na sua capacidade de competir pelas primeiras posições em rankings SERP altamente disputados.
Embora a compatibilidade com dispositivos móveis seja extremamente importante para sites voltados a usuários de dispositivos móveis, aprimorar os CWVs (valores de conteúdo da página) aumentará o desempenho das páginas, independentemente de serem visualizadas em dispositivos móveis ou computadores.
Combater o HTTPS e os anúncios intersticiais intrusivos foi deixado para o final, pois são conquistas mais fáceis e menos recompensadoras.
Existem diversas opções para melhorar o desempenho do CWV, que listamos em ordem de importância, de acordo com o que consideramos importante para cada uma.
Otimizar os principais indicadores vitais da web de qualquer página envolve um conjunto de ações, e é importante saber por onde começar para maximizar seus recursos.
Como já mencionamos acima, o Largest Contentful Paint (LCP) mede quanto tempo leva para carregar completamente o maior texto ou imagem visível acima da dobra.
Use o PSI para identificar qual conteúdo da página aciona o teste LCP. Para isso, acesse a seção de diagnóstico do relatório e clique em "Elemento com Maior Conteúdo Pintado". Veja o que observamos na página inicial do SODP:
Uma pontuação LCP baixa geralmente pode ser atribuída a tempos de resposta lentos do servidor, JavaScript e CSS que bloqueiam a renderização, tempos de carregamento de recursos ou renderização do lado do cliente, ou até mesmo uma combinação de todos os quatro.
A otimização da sua página envolve, na verdade, a otimização de quatro subpartes diferentes do processo de carregamento do LCP:
Todas essas etapas devem ser otimizadas para que você veja uma melhora na sua pontuação LCP. No entanto, isso não significa que todas as subpartes sejam igualmente importantes.
O Google sugeriu que o tempo total do LCP seja dividido em TTFB (tempo até o primeiro byte) e tempo de carregamento de recursos, cada um representando cerca de 40%, enquanto o carregamento de recursos e os atrasos na renderização de elementos devem representar menos de 10% cada.
Idealmente, estes dois últimos valores devem estar o mais próximo possível de zero e ter prioridade sobre as outras duas fases.
Existem duas maneiras de ajudar a reduzir o atraso no carregamento de recursos o mais próximo possível de zero:
Para começar, recomendamos consultar seu desenvolvedor web antes de tentar essas correções. Essa é uma operação de backend e requer experiência para funcionar como esperado.
Descoberta de recursos
Todo navegador web vem com um scanner de pré-carregamento, cuja função é auxiliar o analisador HTML principal do navegador na detecção do conteúdo da página.
Enquanto o analisador HTML principal processa a marcação bruta até encontrar um recurso bloqueador — como um script que não contém um async ou defer —, o analisador de pré-carregamento desempenha um papel mais especulativo.
Em outras palavras, o scanner de pré-carregamento procura recursos para buscar antes que o analisador HTML principal os alcance e continua funcionando mesmo se o analisador for bloqueado. O scanner de pré-carregamento pode ser usado para encontrar e carregar o LCP o mais próximo possível da solicitação inicial da página.
Para garantir que o recurso LCP seja detectável a partir do código-fonte HTML, os desenvolvedores têm opções específicas para cada recurso.
Por exemplo, se o LCP for uma imagem, seus `src` ou `srcset` precisam estar presentes no código-fonte. Imagens de fundo em CSS, por sua vez, podem ser pré-carregadas incluindo... em marcação HTML ou no cabeçalho. Por fim, as fontes podem ser carregadas de forma semelhante através de .
Vale ressaltar, no entanto, que usar o pré-carregamento para reduzir os tempos de carregamento do LCP pode introduzir novos problemas, como a despriorização assíncronos . Há um motivo pelo qual recomendamos que você converse com seu desenvolvedor sobre isso.
Para obter mais informações sobre este assunto, confira as análises detalhadas do Google sobre a otimização de LCP e o scanner de pré-carregamento .
Prioridade de recursos
Os navegadores tentam baixar recursos de CSS, fontes, scripts, imagens e iframes da maneira mais otimizada possível, atribuindo prioridades. Os navegadores são excelentes em determinar as prioridades dos recursos, mas isso não significa que sejam perfeitos.
Para otimizar a priorização de recursos, os desenvolvedores podem usar dicas de prioridade baseadas em marcação para sinalizar aos navegadores quais recursos têm maior prioridade. Por exemplo, um desenvolvedor pode usar JavaScript e a API Fetch para marcar a imagem LCP com o fetchpriority="high" , acelerando essa métrica CWV específica.
Vale ressaltar que as Dicas de Prioridade funcionam apenas em navegadores baseados no Chromium , como o Google Chrome e o Microsoft Edge.
Seu desenvolvedor pode já ter implementado o carregamento lento (lazy loading) para os recursos abaixo da dobra (abaixo da dobra), verifique com ele para ter certeza, mas também vale a pena pedir que ele use dicas de prioridade (Priority Hints) para os recursos acima da dobra.
Para obter mais informações sobre carregamento prioritário, recomendamos consultar o guia do Google sobre carregamento de recursos .
A equipe de desenvolvimento da gigante das buscas conseguiu usar as Dicas de Prioridade para melhorar o LCP de 2,6 segundos para 1,9 segundos em um teste do Google Flights.
O FID rastreia quanto tempo o navegador de um usuário leva para começar a processar a primeira entrada — excluindo rolagem e zoom.
Essa métrica visa capturar a experiência do usuário ao interagir com uma página da web, o que significa que páginas lentas terão uma pontuação baixa. O objetivo é manter a pontuação FID abaixo de 100 milissegundos.
A baixa capacidade de resposta geralmente se deve ao uso excessivo de JavaScript, que os navegadores processam antes dos comandos do usuário.
Códigos que consomem o foco do navegador por 50 milissegundos ou mais são chamados de "Tarefas Longas" e são vistos como um sinal de inchaço do JavaScript. Dividir essas Tarefas Longas em partes menores de código pode resolver problemas de desempenho e melhorar o FID (Índice de Desempenho de Falhas).
Mas essa não é a única área que vale a pena discutir com seu desenvolvedor. É importante discutir como a execução de scripts, tanto de primeira quanto de terceiros, pode estar deixando seu site mais lento. O carregamento progressivo de código e recursos pode ajudar a resolver os problemas da primeira parte, enquanto o carregamento sob demanda e a priorização de carga podem ajudar com os da segunda.
Outra opção seria usar web workers para executar JavaScript em segundo plano e evitar que seu navegador fique sobrecarregado processando scripts.
O CLS é basicamente uma medida da estabilidade visual do seu site. Se os visitantes se perderem na página devido ao conteúdo ser reorganizado para dar espaço ao carregamento de anúncios e imagens, seu site terá uma pontuação baixa.
Quanto menos o layout da sua página oscilar, melhor será sua pontuação CLS. O Google avalia os sites considerando a interrupção dentro da área visível, bem como a distância que os elementos da página percorreram em relação a ela.
Minimizar mudanças inesperadas no layout basicamente envolve designar espaço para anúncios, imagens e vídeos incorporados.
Lembra dos src ou srcset que analisamos quando falamos sobre descoberta de recursos? Pois bem, eles são fundamentais para melhorar as pontuações do CLS.
Para imagens estáticas, defina a largura e a altura usando os src para indicar ao navegador que reserve espaço para recursos de carregamento mais lento, evitando assim alterações no layout.
Veja o código de exemplo do Google abaixo:
Imagens responsivas exigem um atributo srcset para definir os limites máximos de largura e altura que o navegador pode selecionar. Certifique-se de usar imagens com a mesma proporção.
Eis outro exemplo:
Ao lidar com anúncios, você pode seguir alguns passos:
Reservar espaço estático também é aconselhável caso você pretenda implementar iFrames, conteúdo incorporado e conteúdo dinâmico, como chamadas para ação (CTAs).
Quando os navegadores baixam e renderizam fontes da web, existe a possibilidade de ocorrer um breve aparecimento de texto sem estilo (FOUT) ou um breve aparecimento de texto invisível (FOIT). O primeiro acontece quando uma fonte de fallback é substituída por uma nova fonte, enquanto o segundo resulta de um atraso na renderização da nova fonte.
Você pode resolver ambos os problemas usando Para instruir o scanner de pré-carregamento a buscar as fontes da web mais cedo. As fontes pré-carregadas têm maior probabilidade de serem exibidas na primeira renderização.
Existem outras soluções no guia de resolução de problemas do CLS , bem como uma análise detalhada sobre o uso do preload para evitar o FOIT .
Se você busca melhorias na velocidade do seu site e ainda utiliza uma opção de hospedagem tradicional em servidor único, provavelmente é hora de considerar a migração para uma rede de distribuição de conteúdo (CDN).
Uma CDN consiste em uma rede de servidores localizados em diferentes data centers ao redor do mundo que distribuem o conteúdo de um site para melhorar seu desempenho. Embora tanto a opção de servidor único — também conhecida como hospedagem local — quanto a CDN entreguem o conteúdo do site aos visitantes, somente uma CDN pode levar em consideração a localização geográfica do usuário e, em seguida, escolher o servidor mais próximo para reduzir os tempos de carregamento.
A geografia não é a única vantagem, no entanto, pois os CDNs também estão melhor equipados para gerenciar picos de trânsito repentinos, bem como recursos de servidor raiz, como a largura de banda.
Em última análise, uma experiência de navegação mais rápida envia um forte sinal de CWV (Cloud Web Value) para o Google. Embora a Cloudflare seja uma das provedoras de CDN mais conhecidas do mercado, existem vários concorrentes importantes a serem considerados .
Independentemente do provedor de hospedagem que você usar, os servidores estarão sujeitos a certas limitações de hardware.
Os servidores contêm, em grande parte, os mesmos componentes principais que permitem o funcionamento do seu laptop/desktop — ou seja, CPU e RAM — que executam todas as tarefas da sua conta. Você deve conseguir usar o painel de controle do seu provedor de hospedagem para verificar a CPU e a RAM instaladas no seu servidor e até mesmo solicitar recursos adicionais para melhorar o desempenho do seu site.
Se você está analisando a CPU do seu servidor, é importante entender que apenas um único núcleo é usado para atender à solicitação de um visitante por uma página da web. Isso significa que velocidades de clock mais rápidas em núcleos únicos são sempre vantajosas. CPUs com múltiplos núcleos são capazes de processar múltiplas visualizações de página e outros serviços do servidor.
Esta é mais uma para o seu desenvolvedor.
Analise seu banco de dados com certa frequência para garantir que ele não esteja sobrecarregado com fotos e arquivos não utilizados. Excluir arquivos desnecessários o deixará mais organizado, acelerando o tempo médio de carregamento das páginas.
Usar imagens muito grandes pode, e vai, deixar seu site mais lento. Quão grandes? Qualquer imagem acima de 1 MB é simplesmente grande demais.
E como já sabemos, tempos de carregamento mais lentos levam a taxas de rejeição mais altas e enviam sinais indesejados ao Google.
Para quem usa WordPress, existem diversos plugins de otimização de imagens disponíveis que podem agilizar uma tarefa manual tediosa. Além disso, muitos também oferecem outros recursos, como carregamento lento e redimensionamento automático.
A compatibilidade de um site com dispositivos móveis depende de como ele foi simplificado e otimizado para a experiência de navegação em celulares.
Usuários de dispositivos móveis interagem com as páginas de forma diferente e têm muito menos paciência para tempos de carregamento lentos e sites de navegação difícil. Se o seu site não passou no teste de compatibilidade com dispositivos móveis descrito acima, ou mesmo se passou, mas você está interessado em otimizá-lo ainda mais, vamos analisar algumas das melhores práticas.
Essa deve ser a principal preocupação de qualquer editora. Uma maneira simples de abordar a facilidade de uso é se fazer perguntas como:
Essas respostas serão de grande ajuda para identificar os principais problemas enfrentados pelos usuários. Por exemplo, você não quer que seus usuários precisem ajustar a tela para visualizar seu conteúdo. Veja o que queremos dizer no exemplo abaixo.
Para otimizar seu conteúdo para dispositivos móveis, existem três opções de desenvolvimento:
Ordenamos as opções de acordo com a facilidade de implementação e recomendamos a adoção de um design responsivo, pois é a menos exigente das três opções.
Os desenvolvedores simplesmente adicionam a meta name="viewport" ao código existente de uma página da web
A vantagem aqui é que você só precisa manter um site, que pode ser exibido facilmente em qualquer tipo de tela.
Em contraste, os designs dinâmicos funcionam fornecendo código HTML diferente com base no dispositivo do usuário. As páginas precisam usar o cabeçalho HTTP Vary para evitar que o código errado seja enviado para o dispositivo errado.
Por fim, existem os subdomínios para dispositivos móveis, que não recomendamos devido à quantidade de recursos necessários para implementá-los de forma eficaz. Os subdomínios para dispositivos móveis são sites completamente separados, com necessidades de hospedagem distintas. Para garantir que os mecanismos de busca entendam a relação entre o domínio principal e o subdomínio, você precisará incluir a rel="canonical" .
Como o design responsivo é a opção mais simples, é a que recomendamos para editores. Para obter mais informações sobre design responsivo, consulte o guia de implementação do Google .
Segue uma lista rápida de considerações técnicas para qualquer projeto:
Esta última etapa é a maneira mais simples de melhorar a experiência do usuário na página, mas também contribui muito para aumentar a tranquilidade dele.
A mudança para HTTPS protege e criptografa as informações dos seus usuários, além de ajudar a prevenir ataques Man-in-the-Middle (MitM). Ademais, ter um certificado SSL elimina os avisos do navegador sobre falta de segurança.
Seu provedor de hospedagem deveria ser capaz de fornecer segurança HTTPS; caso contrário, talvez valha a pena considerar a mudança para um que ofereça. Já existem diversos provedores de hospedagem renomados que oferecem HTTPS gratuitamente . Além disso, os provedores que fornecem certificados SSL utilizam seu próprio serviço em vez de um externo, tornando o processo ainda mais fácil e rápido de implementar.
Se você deseja solicitar e instalar um certificado SSL de uma Autoridade Certificadora (AC), há quatro etapas que você precisa seguir. São elas:
É importante garantir que a migração do seu site para HTTPS não afete sua estratégia de receita publicitária. O problema é que um HTTPNão funcionará em um site que utilize HTTPS.
Recomendamos consultar seus parceiros de tecnologia de publicidade antes de fazer qualquer alteração em seu site.
Para obter mais detalhes, consulte o guia completo do Google sobre o assunto.
Anúncios intersticiais e caixas de diálogo intrusivas dificultam a compreensão do conteúdo de uma página da web pelos mecanismos de busca, o que pode prejudicar o desempenho nos resultados de pesquisa (SERP).
Seria ótimo se houvesse uma maneira de criar anúncios intersticiais que não interrompessem a experiência do usuário, mas esse é justamente o objetivo desse tipo de anúncio. Eles ocupam a tela inteira durante as pausas no conteúdo para chamar a atenção do usuário.
Sendo assim, os editores teriam melhor desempenho usando banners em vez de anúncios intersticiais, já que ocupam apenas uma pequena parte do espaço da tela. Melhor arriscar a cegueira aos banners do que a frustração do usuário.
Os editores podem usar banners compatíveis com navegadores ou banners HTML simples que direcionem para a página de destino da chamada para ação (CTA).
As caixas de diálogo também podem ser usadas para campanhas promocionais, mas podem ser projetadas para serem discretas. É preciso garantir que os usuários possam acessar o conteúdo sem interrupções.
Não existem atalhos para otimizar a experiência da sua página e é fundamental corrigir os pontos mencionados acima. Dito isso, vale ressaltar que, embora o WordPress seja facilmente a plataforma de publicação mais popular do mundo, isso não significa necessariamente que seja o melhor CMS quando se trata de melhorar o desempenho do CWV.
Analisando o Relatório de Tecnologia CWV, verifica-se que apenas cerca de 29% dos sites WordPress possuem bons CWVs, enquanto 41% dos sites Wix recebem o selo verde.
Vale a pena avaliar se a mudança para um CMS especializado poderia melhorar seus CWVs nativamente.
Há muito a ser explorado quando se trata de otimizar a experiência da página, e começar pode ser um pouco intimidante. No entanto, é importante lembrar que se come o elefante dando uma mordida de cada vez.
Buscar uma pontuação "Boa" em todas as suas métricas de CWV não é necessário para ajudar seu site a subir nos resultados de busca. Além disso, definir metas tão ambiciosas pode ser contraproducente, pois pode se tornar uma busca desmotivadora.
Em vez disso, busque pequenas vitórias em relação às suas Avaliações de Desempenho, concentrando-se em resolver os resultados "Ruim" sem se preocupar excessivamente com a barra "Precisa melhorar". Isso pode vir depois, quando você tiver mais tempo e recursos para se dedicar ao processo.
Já falamos sobre a melhoria na pontuação CLS do Yahoo! Japão, vamos analisar mais alguns sites dos quais podemos aprender algumas lições.
O jornal indiano The Economic Times, que conta com mais de 45 milhões de usuários ativos mensais, reduziu sua pontuação CLS em 250%, de 0,25 para 0,09, e seu tempo LCP em 80%, de 4,5 segundos para 2,5 segundos.
Entre outubro de 2020 e julho de 2021, a editora reduziu as pontuações LCP na faixa "Ruim" em 33%, enquanto os valores CLS na mesma faixa caíram 65%. Esses ganhos permitiram que o The Economic Times ultrapassasse os limites de CWV em toda a sua origem, reduzindo as taxas de rejeição em 43%.
A editora conseguiu isso de várias maneiras, sendo a primeira delas priorizar o download de recursos usando Dicas de Prioridade. Ela também lidou com Tarefas Longas, dividindo blocos de código para garantir que os recursos essenciais para a renderização da página acima da dobra fossem carregados primeiro.
O site de notícias do Reino Unido melhorou sua pontuação CLS de 0,25 para 0,1 , ao mesmo tempo em que aumentou o número de URLs que receberam uma nota de aprovação de 57% para 72%.
O jornal The Telegraph utilizou as ferramentas de desenvolvedor do Chrome para identificar instâncias individuais de alteração de layout.
Antes disso, usei o WebPageTest para descobrir em que ponto da linha do tempo ocorreu a mudança de layout.
Com esses dados em mãos, a equipe começou a se concentrar em reduzir as alterações de layout, abordando essas áreas
Para os anúncios, o The Telegraphed começou a reservar espaço para eles e usou o tamanho de anúncio mais comum para especificar as dimensões. Isso também ajudou a evitar que os anúncios se deformassem quando visualizados em um tablet.
A equipe enfrentou um problema semelhante com imagens embutidas no topo dos artigos, que não tinham dimensões especificadas.
O jornal The Telegraph fez outros ajustes, como mover o cabeçalho para o topo da marcação e usar espaços reservados para vídeos incorporados, mas, no fim das contas, descreveu o processo como "bastante fácil", embora ainda tenha tido um impacto significativo.
Melhorar a experiência do usuário na página não precisa ser algo complexo. Avalie os quatro pilares da experiência do usuário e, em seguida, decida quais recursos você pode investir para aprimorar seus resultados.
Se você for uma editora menor, o equilíbrio de recursos será crucial e recomendamos identificar oportunidades relativamente fáceis de implementar para o seu primeiro projeto.
Analisando a abordagem do Telegraph, eles se concentraram em um aspecto dos CWVs em vez dos três e obtiveram melhorias significativas. O Economic Times focou em dois dos três aspectos, alcançando resultados impressionantes.
Ativo agora
Ver mais
