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

Otimizando Imagens Mobile

Quem visa oferecer uma experiência de navegação mais rápida para sua audiência costuma fazer uso de alguma solução de otimização de imagens, dado que imagens pesadas podem impactar negativamente as métricas de Web Vitals, que estão diretamente ligadas ao motor de busca do Google

Há várias formas de otimizar imagens, seja construindo alguma aplicação local que otimize on demand, algum plugin de otimização de imagens, ou uma CDN que tem a feature pronta na sua borda.

O principal desafio na otimização das imagens é evitar que elas percam qualidade, o que pode deixar a equação ainda mais complexa se há diferentes imagens sendo servidas com diferentes tamanhos, em diferentes patchs. 

O otimizador de imagens da GoCache entrega 3 opções de otimização (webp, jpeg progressivo e remoção de metadados), e uma feature de compressão que pode ser definida em três níveis (baixo, médio e alto).

Uma das grandes vantagens de utilizá-lo é na granularidade da sua customização, sendo uma ferramenta poderosa para o cliente chegar no cenário ideal entre imagens performáticas, e com uma resolução que o satisfaça. 

Trazendo um caso hipotético na aplicação https://testecdn.com.br/, o cliente configurou todas as otimizações e definiu um nível de compressão alto. 

Feito isso, o cliente notou que as imagens que ficam no patch /wp-content/uploads/2021/06/, e que são servidas em dimensões maiores, perdeu um pouco de resolução, sendo o nível “baixo” mais adequado. 

Para não impactar todas as outras imagens que estariam mais adequadas no nível alto, foi criada uma regra definindo um nível de compressão diferente para o patch /wp-content/uploads/2021/06/

Entendendo que 70% da sua audiência é mobile, fez todo sentido para o cliente buscar uma customização que entregue um nível de compressão maior para esses acessos, entendendo também que eles normalmente vem de uma conexão menos potente e com um dispositivo que contempla uma tela menor a ponto de não se enxergar perda de qualidade.

Com pouco esforço, foi criado uma regra na GoCache para otimizar ao máximo as imagens de dispositivos mobile, independente do patch.

O resultado você consegue conferir fazendo um Curl no terminal, vendo o retorno do content-length variando o user-agents desktop ou mobile.

No exemplo acima, a imagem no acesso mobile foi servida com uma carga de 23,5kb ao invés de 60,1kb. Uma redução de tamanho em torno  2,5x menor.

Nesse exemplo tratamos um caso específico em um determinado contexto contexto. Podendo o cenário variar em infinitas possibilidades, a GoCache busca oferecer granularidade na customização do produto através do uso de diversos critérios, podendo ser combinados ou não, e com uso de regexp para englobar os mais variados casos numa única regra.

 

Por Hugo Hazboun, Sales Manager GoCache.

Como eliminar Render-Blocking Resources

O Lighthouse está dizendo para você eliminar os recursos de bloqueio de renderização? Aprenda o que isso significa, por que é importante e como corrigi-lo no seu HTML, CSS e JavaScript.

Você pode estar aqui porque o Lighthouse lhe disse para “eliminar recursos de bloqueio de renderização”. Recursos de bloqueio de renderização são um obstáculo comum para renderizar a sua página com mais rapidez. Eles impactam seus Web Vitals que agora impactam o seu SEO. Os tempos de renderização lentos também frustram os seus usuários e podem fazer com que eles abandonem a sua página.

Trabalhei com um cliente para reduzir os recursos de bloqueio de renderização e melhorar a velocidade de carregamento do site dele. Passamos de 13% para 80% das visitas à página experimentando o First Contentful Paint (FCP) em menos de 1,8 segundos. E ainda não terminamos!

Qual é o caminho crítico de renderização?

Escrevemos HTML, CSS e JavaScript em arquivos e, em seguida, entregamos esses arquivos ao navegador. O navegador converte esses arquivos na página que você vê por meio do caminho de renderização crítico. As etapas são:

1 Baixar o HTML

2 Ler o HTML e, ao mesmo tempo:

  • Construir o Document Object Model (DOM)
  • Observar uma tag <link> para uma folha de estilo e baixar o CSS

3 Ler o CSS e construir o CSS Object Model (CSSOM)

4 Combinar o DOM e o CSSOM em uma árvore de renderização

5 Usando a árvore de renderização, calcular o layout (tamanho e posição de cada elemento)

6 Pintar ou renderizar os pixels na página

Queremos que esse processo aconteça o mais rápido possível. Você consegue adivinhar o que o torna mais lento?

O que são recursos de bloqueio de renderização?

Recursos de bloqueio de renderização são arquivos que “pausam” o caminho de renderização crítico. Eles interrompem uma ou mais etapas.

O HTML é tecnicamente um bloqueio de renderização porque você precisa dele para criar o DOM. Sem o HTML, não teríamos nem uma página para renderizar.

No entanto, o HTML geralmente não é a causa dos nossos problemas…

CSS é um bloqueio de renderização. O navegador precisa disso antes de criar o CSSOM, o que bloqueia todas as etapas posteriores. Assim que o navegador encontra uma folha de estilo <link> ou tag <style>, ele deve baixar e analisar o conteúdo. Em seguida, ele deve criar o CSSOM antes que o resto da renderização possa continuar. Você pode ver isso representado no ponto do triângulo no diagrama. A árvore de renderização não pode continuar até que o CSSOM e o DOM sejam criados.

JavaScript PODE ser um bloqueio de renderização. Quando o navegador encontra um script que deve ser executado de forma síncrona, ele interrompe a criação do DOM até que a execução do script seja concluída:

Além disso, se CSS aparecer antes de um script, o script não será executado até que o CSSOM seja criado. Isso ocorre porque o JavaScript também pode interagir com o CSSOM e não queremos uma competição entre eles.

CSS bloqueia a execução do script e o JavaScript bloqueia a construção do DOM! Parece uma bagunça gigante, certo? Fique ligado para saber como podemos limpar isso!

Por que é tão importante eliminar recursos de bloqueio de renderização?

Os recursos de bloqueio de renderização podem desencadear uma cascata de falhas no desempenho da web. A primeira pintura fica mais lenta, o que faz com que a maior pintura com conteúdo (LCP) seja mais lenta. LCP é um dos Core Web Vitals que agora são usados ​​para calcular as classificações do seu mecanismo de pesquisa.

A Vodafone melhorou seu LCP em 31%, resultando em um aumento de 8% nas vendas, um aumento de 15% na taxa de lead por visita e um aumento de 11% na taxa de carrinho por visita.

Referencia: https://sia.codes/posts/render-blocking-resources/

Render Blocking – Novo indicador de bloqueio de renderização no Chrome e WebPageTest

Graças a um novo indicador fornecido pelo Chrome em seus rastros (começando na versão 91 do navegador, com uma notável correção de bug enviada com a versão 92 hoje), o WebPageTest começou a destacar todas as solicitações de bloqueio de renderização em suas cascatas, tornando mais fácil se concentrar rapidamente nas solicitações de bloqueio que podem estar causando gargalos significativos no desempenho da sua página.

Um dos gargalos de desempenho mais comuns que os sites enfrentam são atrasos causados ​​por recursos de bloqueio de renderização: recursos na página que impedem a exibição da página até que sejam baixados, analisados ​​e (no caso do JavaScript) executados.

Aqui está a essência: certos tipos de recursos – CSS e JavaScript – são bloqueados por padrão.

No caso do CSS, o navegador não pode exibir a página até que o CSS tenha sido baixado e analisado no CSSOM.

No caso do JavaScript, o navegador não consegue nem continuar analisando HTML, deixando de exibir a página, até que o JavaScript tenha sido baixado, analisado e executado.

Em ambos os casos, os recursos de bloqueio tendem a aumentar os tempos de Iniciar renderização e Primeira pintura com conteúdo em particular (e Maior pintura com conteúdo por associação). Se o seu site tiver recursos de bloqueio de renderização, carregá-los lentamente ou fazê-los carregar de forma assíncrona resultará em uma melhoria de desempenho considerável.

Pode ser um pouco complicado identificar recursos de bloqueio de renderização rapidamente, mas é aí que o novo indicador de status de Bloqueio de renderização do Chrome entra em ação.

A sinalização renderBlocking

A partir da versão 91 do Chrome, o Chrome agora marca todas as solicitações relevantes com um sinalizador renderBlocking, indicando se esse recurso está bloqueando ou não. Ter essas informações fornecidas pelo navegador é um grande passo. Houve algumas tentativas de ferramentas para identificar recursos de bloqueio de renderização usando as próprias heurísticas, mas obter essas informações diretamente do navegador fornece um nível mais alto de precisão, bem como mais granularidade.

A bandeira tem cinco valores potenciais diferentes:

  • blocking
  • non_blocking
  • dynamically_injected_non_blocking
  • in_body_parser_blocking
  • potentially_blocking

O status blocking

Este é bem direto – se a solicitação bloquear a exibição da página, o status de bloqueio será relatado como “blocking”. Este rótulo é aplicado a coisas como folhas de estilo e elementos de script que não têm um defer, async ou atributo de módulo.

O status de non_blocking

Este também é bastante direto. Se a solicitação não impedir que o navegador exiba a página, o status de bloqueio é relatado como “non_blocking”. Este rótulo se aplica a coisas como folhas de estilo com um atributo desativado ou folhas de estilo com consultas de mídia que não correspondem ao ambiente atual (como impressão). Também se aplica a scripts que possuem um atributo defer ou módulo.

O status dynamically_injected_non_blocking

Isso pode ser mais ou menos considerado o mesmo que non_blocking, pelo menos do ponto de vista do impacto no desempenho. Esse status é aplicado a um recurso que é injetado dinamicamente na página e não bloqueia a exibição da página.

Este status atualmente não é aplicado a scripts injetados dinamicamente, mas esse é um bug relativamente menor – “dynamically_injected_non_blocking” é apenas uma versão mais específica de “non_blocking”, então, embora seja bom limpar isso no futuro, é um problema na maioria das vezes insignificante.

O status in_body_parser_blocking

O status “in_body_parser_blocking” é definido sempre que o recurso é solicitado em algum lugar dentro do corpo de uma forma que bloqueia o analisador de analisar o documento abaixo do elemento.

Então, por exemplo, digamos que você tenha um elemento de script dentro do corpo da página em vez do cabeçalho. Isso impede que o navegador analise qualquer coisa abaixo desse elemento até que o recurso seja solicitado e baixado, para que esse status seja aplicado.

O status potencially_blocking

Este é muito interessante. Se o Chrome não puder dizer com certeza se a solicitação bloqueará ou não a exibição da página, o status “potencially_blocking” será aplicado.

Um bom exemplo aqui é um script async. Se um script for carregado com um atributo async, o navegador executará o script assim que chegar. Isso significa que se o script chega rapidamente, antes da renderização inicial da página, o script bloqueia a renderização até que toda a execução seja concluída. Se o script chegar após a renderização inicial da página, ele não bloqueia. Como a natureza do bloqueio depende de quando o script chega, o Chrome não pode dizer no momento da solicitação se ele estará bloqueando ou não, então ele o sinaliza como “potencially_blocking”.

Como encontrar o status de bloqueio de renderização no WebPageTest

Quando você clica em uma solicitação em uma cascata para visualizar os detalhes completos da solicitação, exibimos o status de bloqueio de renderização sempre que aplicável na caixa de diálogo que aparece.

Bloqueio de renderização

Ele ficou escondido à vista de todos há um tempo, mas quando estávamos testando o indicador no Chrome v91, identificamos um bug em que scripts async injetados dinamicamente eram sinalizados incorretamente como bloqueadores. Yoav da equipe do Chrome começou a trabalhar nisso rapidamente, obtendo a correção para a versão 92.

Ainda há mais um bug que identificamos que não será corrigido até a versão 93 (as solicitações de pré carregamento são sinalizadas como não bloqueadoras, mesmo se forem para um recurso de bloqueio), mas a sinalização é estável o suficiente para que possamos torná-la uma um pouco mais proeminente agora.

Com o indicador se tornando um pouco mais estável, também o tornamos um pouco mais proeminente. A partir de hoje, os recursos com status de “blocking” serão chamados com um ícone, facilitando a identificação de qualquer recurso de bloqueio de renderização.

No momento, não estamos mostrando nada se um recurso for sinalizado com “potencially_blocking” ou “in_body_parser_blocking”, mas se isso for algo que você consideraria útil, somos todos ouvidos. Por exemplo, uma coisa que estamos considerando é sinalizar todos os recursos “potencially_blocking” que chegam antes de ocorrer o início da renderização. Eles não são exatamente o mesmo que recursos “render_blocking”, pois nem sempre podem bloquear a renderização em todos os testes, mas o fato de que eles às vezes aparecem para desacelerar as coisas pode ser uma informação útil.

Referencia: https://blog.webpagetest.org/posts/new-render-blocking-indicator-in-chrome-and-webpagetest/

Cinco razões para usar o WebPageTest para medir as Core Web Vitals

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

Qual o impacto de usar diversas Web-Fonts em meu site?

De acordo com o HTTP Archive, aproximadamente 80% dos sites móveis e de desktop (no momento da escrita) usam fontes da web, destacando sua popularidade. No entanto, os seus aspectos de desempenho são frequentemente esquecidos.

Neste artigo, explicamos porque você deve ir devagar com as fontes e como obter o melhor desempenho delas.

Tipos de Fontes

Vamos dar uma olhada rápida nos dois tipos gerais de fontes e como eles diferem entre si:

1) Fontes Web seguras (também conhecidas como Fontes do Sistema)

  • Estas são as fontes padrão disponíveis no dispositivo de um usuário.
  • Elas não precisam ser baixadas, pois já estão incluídas na maioria dos dispositivos.
  • As fontes web seguras são limitadas em variedade, no entanto, elas carregam mais rápido do que as fontes da Web devido à sua ampla disponibilidade em todos os dispositivos.

2) Fontes da web

  • Também conhecidas como “fontes personalizadas”, que normalmente não estão instaladas na máquina do usuário.
  • As fontes da Web precisam ser baixadas para uso na página.
  • As fontes da Web podem ser hospedadas por um serviço de terceiros ou auto hospedadas.
  • As fontes da Web podem oferecer uma variedade de opções para se adequar ao design e à marca do seu site, mas elas vêm com sobrecarga extra para atendê-las.
  • O uso de várias fontes da web pode gerar um custo significativo de desempenho.

Como as fontes da web afetam o desempenho da página?

Analisamos todos os problemas de desempenho com o uso de fontes da web:

As fontes da web são descobertas tardiamente pelo navegador

As fontes da Web precisam ser carregadas antes que o texto seja renderizado para que os usuários possam visualizar o conteúdo na sua página.

No entanto, o navegador só toma conhecimento das fontes da web depois que o HTML é carregado e os arquivos CSS são analisados.

Isso pode levar algum tempo e, dependendo do design do site, podem haver várias fontes da web que precisam ser carregadas, o que pode atrasar o carregamento da página.

Se isso acontecer, os visitantes podem enfrentar o problema do Flash of Invisible Text (FOIT), em que o texto está pronto, mas a fonte da web ainda não foi carregada.

Como alternativa, o texto é estilizado com uma fonte de fallback até que a fonte da web termine de carregar, momento em que o texto muda para a fonte desejada. Isso é conhecido como Flash of Unstyled Text (FOUT).

Embora esses cenários possam ser resolvidos com o pré carregamento de fontes da web e o uso de estratégias de exibição de fontes apropriadas, as fontes da web também podem apresentar problemas de desempenho adicionais, como aumento do tempo de carregamento para outros recursos e aumento das mudanças de layout em sua página, respectivamente.

Fontes da web adicionam peso ao seu site

As fontes da Web geralmente requerem várias solicitações para funcionar corretamente. Isso inclui várias famílias de fontes com diferentes pesos, estilos e idiomas que podem ser rapidamente adicionados ao tamanho total da página.

As solicitações típicas feitas incluem:

Arquivos CSS de fonte

Este é o arquivo CSS que contém atributos relativos à fonte e seus vários pesos e estilos para que você possa usá-lo em seu próprio CSS.

Arquivo Real da fonte

Estes são os próprios arquivos de fonte (WOFF, TTF, etc.), que precisam ser baixados para o navegador usar quando referenciados em CSS.

Verificações de validação

Dependendo de qual fonte da web você usa, pode ser necessária a validação da sua licença para garantir que você está autorizado a usar a fonte na sua página.

Dependendo da complexidade e do número de fontes, algumas páginas podem resultar em fontes que representam a grande maioria de seu Tamanho total da página.

Fontes da web causam atrasos adicionais

As fontes da Web vêm com sobrecarga de desempenho adicional porque normalmente são baixadas de um servidor de terceiros.

Conectar-se a um servidor / domínio de terceiros é sempre caro, pois envolve novas pesquisas de DNS, tempos de conexão SSL, confiança no desempenho do servidor de terceiros e possíveis gargalos se a sua página contiver solicitações para um grande número de servidores de terceiros separados.

Dependendo do serviço de fonte da web utilizado, os tempos de conexão / resposta / download podem variar, pois cada solicitação está sujeita à variação e complexidade da Internet, bem como ao desempenho do servidor final do terceiro.

Essa é uma das razões pelas quais as fontes de auto hospedagem são comumente vistas como uma estratégia para melhorar o desempenho das fontes da web, no entanto, existem prós e contras para essa solução, conforme descrevemos a seguir.

Não use muitas fontes da Web

Se você usar muitas fontes da web, todos os problemas acima podem ser multiplicados várias vezes, impactando o desempenho da sua página de forma significativa.

Usar muitas fontes da Web é ruim para o desempenho e também é geralmente considerado uma má prática de design.

Em última análise, vale a pena ser inteligente com as escolhas de fonte, e selecionar menos fontes com opções de estilo mais simples no formato mais adequado, essa é a melhor maneira de garantir o desempenho ideal para sua página.

Devo auto hospedar fontes?

Este é um tópico amplamente debatido e não há uma resposta direta.

Dependendo de para quem você perguntar, você receberá recomendações para hospedar as suas fontes personalizadas ou optar por fontes da Web de terceiros.

Fontes da web de auto hospedagem

Fontes da web com hospedagem própria podem resultar em melhor desempenho pelos seguintes motivos:

  • Você não precisa se conectar a servidores de terceiros para buscar suas fontes, reduzindo potencialmente o tempo de carregamento geral. Isso também garante a exibição adequada de fontes no caso de o servidor de fontes da Web de terceiros apresentar problemas ou ficar totalmente inativo.
  • Você pode incorporar declarações de fontes em seu HTML ou pré carregá-las para que o navegador tenha conhecimento avançado de quais fontes são necessárias.
  • Você tem mais controle geral sobre o armazenamento em cache e outras estratégias para garantir um carregamento de fonte mais rápido.

No entanto, as possíveis desvantagens da auto hospedagem de fontes da web incluem:

  • Suas fontes da web não são mais atualizadas automaticamente, pois não são mais fornecidas por servidores de terceiros.
  • Você precisa se certificar de fornecer vários formatos e declarar fontes seguras para a Web como fallback.
  • Uso recomendado de um CDN, para garantir que seus arquivos de fonte sejam servidos no local mais próximo dos seus visitantes.

Possíveis problemas de licenciamento

O licenciamento é outro problema com o qual você pode ter que lidar, já que diferentes serviços de fontes têm políticas diferentes para fontes de auto hospedagem.

Embora alguns serviços de fontes (como Adobe Typekit) não permitam que você hospede fontes automaticamente sem uma licença separada, o Google (e alguns outros serviços de fontes) oferece uma licença aberta para as fontes da web.

Recomendamos pesquisar quais fontes você pode auto hospedar em sua página legalmente para que possa optar pelo design de que precisa com maior controle sobre como as fontes são carregadas.

Usando fontes da web hospedadas em servidores de terceiros

  • Embora as fontes da web hospedadas por terceiros tenham suas desvantagens, elas também têm vantagens sobre a auto hospedagem, incluindo:
  • Uso de um CDN para servir as fontes da web com base na localização do usuário para minimizar os tempos de carregamento.
  • Atualizações e otimizações regulares para fontes da web, às quais você terá acesso imediato.
  • Entrega otimizada para servir apenas as fontes da web que são realmente usadas na página.
Referencia: https://gtmetrix.com/blog/dont-use-too-many-web-fonts/

Como os códigos de status HTTP afetam o SEO

O Google publicou um novo documento de ajuda explicando como diferentes códigos de status HTTP afetam como um site aparece nos resultados de pesquisa.

Um tweet recente sugere que Gary Illyes, do Google, ajudou na elaboração deste documento.

Este é o novo guia para referência quando você não tiver certeza de como um código de status específico afeta o SEO.

Vamos dar uma olhada no que está incluído no novo guia do Google para proprietários e desenvolvedores de sites.

Muito disso já pode ser familiar para você, mas não custa nada atualizar o seu conhecimento dos códigos de status com as informações mais recentes disponíveis.

Como os códigos de status HTTP afetam a Pesquisa Google

O novo documento do Google cobre os 20 principais códigos de status que o Googlebot encontra na web e os erros de rede e DNS mais proeminentes.

Os códigos de status HTTP são gerados pelo servidor que hospeda um site quando o conteúdo é solicitado por um navegador ou rastreador.

Por exemplo, se um navegador solicitar conteúdo que não está mais hospedado no servidor, um código de status 404 (não encontrado) será gerado.

O primeiro número do código de status indica a qual categoria ele pertence. Todos os códigos 2xx referem-se ao rastreamento bem-sucedido, todos os códigos 3xx referem-se a redirecionamentos e assim por diante.

Em vez de passar por todos os 20 códigos de status, reuni as principais conclusões de cada categoria.

HTTP 2xx (sucesso)

Esses códigos significam que o Googlebot pode rastrear o conteúdo e passá-lo para o canal de indexação.

O Google faz questão de observar que um código de status HTTP 2xx não garante a indexação, simplesmente significa que nenhum erro foi encontrado.

A exceção é um código de status 204, que significa que a página foi acessada com sucesso, mas nenhum conteúdo foi encontrado.

O Google pode mostrar um soft 404 no Search Console para páginas que atendem a um código 204

HTTP 3xx (redireciona)

Nem todos os redirecionamentos são iguais.

Um código de status HTTP 301 envia um sinal mais forte do que um código 302, 303 ou 307 em termos de qual URL deve ser considerado canônico.

Um código de status 304 sinaliza ao Google que o conteúdo é o mesmo da última vez que foi rastreado. Não tem efeito na indexação, mas pode fazer com que os sinais para o URL sejam recalculados.

O que acontece se o redirecionamento não funcionar?

O Googlebot segue até 10 saltos de redirecionamento antes de parar de tentar.

Se o conteúdo não for recebido em 10 saltos, o Search Console mostrará um erro de redirecionamento no relatório de cobertura do índice do site.

HTTP 4xx (erros de cliente)

As páginas que retornam um código de status 4xx não são consideradas para indexação nos resultados de pesquisa do Google.

Todos os erros 4xx, exceto 429, são tratados da mesma forma. Eles sinalizam para o Googlebot que o conteúdo não existe. Se o conteúdo já existia, o URL será removido do índice de pesquisa do Google.

Um código de status 429 significa que o Googlebot não conseguiu acessar um URL porque o servidor está sobrecarregado. Esses URLs serão preservados no índice do Google.

HTTP 5xx (erros de servidor)

Os erros do servidor 5xx fazem com que o Googlebot fique temporariamente mais lento com o rastreamento.

URLs indexados anteriormente que agora têm um erro de servidor serão eventualmente descartados se continuarem a servir um código de status 5xx.

Referencia: https://www.searchenginejournal.com/how-http-status-codes-impact-seo/411762/#close

O que é Pops? Pontos de Presença

Uma pergunta comum no mundo de entrega de conteúdo e que ouvimos muito é “De quantos PoPs meu site precisa?” Para responder a essa pergunta, primeiro vamos conhecer o histórico dos PoPs de CDN e porque eles foram utilizados pela primeira vez.

O que é um CDN PoP?

Os pontos de presença (Points of Presence – PoPs) estão no centro da infraestrutura de CDN: quando os CDNs surgiram, seu objetivo principal era servir conteúdo de servidores distribuídos globalmente ou PoPs que estavam mais próximos dos usuários finais de um site do que do servidor de origem do site. Ao colocar PoPs em todo o mundo, os visitantes globais de um site seriam direcionados ao PoP mais próximo a eles, em vez de ter que viajar de volta ao servidor de origem. Isso resolveu um problema central nos primeiros dias da internet, já que os centros de hospedagem tinham baixa largura de banda e conforme mais e mais pessoas tentavam acessar os sites, havia um gargalo que fazia com que os sites respondessem às solicitações lentamente ou entrassem em colapso sob a pressão de muitos pedidos e ficassem offline.

PoPs de CDN resolveram esse problema dispersando o número de solicitações que vão para o servidor do site em muitos servidores em todo o mundo e, ao mesmo tempo, armazenando conteúdo em cache em cada PoP que poderia ser servido imediatamente aos visitantes do site sem voltar ao servidor do site. Quando um cache de PoP estava cheio (mais sobre isso abaixo), determinado conteúdo poderia ser servido diretamente desse cache de PoP. Os itens mais comuns a serem armazenados em cache no PoP eram objetos estáticos, como arquivos de imagem. Hoje em dia, os CDNs são muito mais poderosos e muitos outros itens, incluindo arquivos dinâmicos, também podem ser armazenados em um cache.

Conforme o uso da Internet cresceu, os CDNs legados adicionaram mais e mais PoPs, e hoje esses CDNs mais antigos têm, segundo algumas estimativas, centenas de milhares de PoPs em todo o mundo. Mas voltando ao ponto em questão – seu site realmente precisa de todos esses PoPs?

Nos últimos anos, os CDNs modernos surgiram e desafiaram a noção de que um número maior de PoPs é melhor, colocando PoPs mais poderosos em pontos estratégicos ao longo do backbone da Internet. O backbone da Internet é a série de cabos que conectam locais ao redor do mundo à Internet: quanto mais longe um usuário final estiver do backbone da Internet, mais tempo o conteúdo levará para ser entregue a ele. Ao colocar os PoPs próximos ao backbone da Internet, os CDNs modernos reduzem o tempo que o conteúdo leva para viajar entre os locais.

Além de colocar PoPs em locais estratégicos, os CDNs modernos também têm muito menos PoPs do que os CDNs legados. Em vez de dezenas de milhares, eles podem ter menos de 50 PoPs em todo o mundo. Os proprietários de sites podem se preocupar com o fato de que ter menos PoPs tornará os seus sites mais lentos, mas, na verdade, para todos, exceto o menor número de sites, menos PoPs resultará em melhor armazenamento em cache e desempenho do site.

Aqui está uma explicação rápida de porque isso ocorre: Quando o primeiro usuário visitar uma página da web (neste exemplo, usaremos a página inicial de um site), ele será direcionado ao CDN PoP mais próximo. No entanto, esse PoP ainda não terá nenhum conteúdo em cache armazenado e precisará voltar ao servidor de origem para obter o conteúdo da página inicial. O PoP então entregará esse conteúdo ao primeiro visitante e armazenará uma cópia do conteúdo que pode ser veiculada do cache para o segundo visitante e os visitantes subsequentes.

A porcentagem de “acertos de cache” indica a porcentagem de solicitações que podem ser atendidas a partir de um cache preenchido, e os sites devem ter como objetivo ter uma porcentagem de acertos de cache o mais próximo possível de 100%. Para fazer as contas, se a página inicial de um site tem 100 visitantes da Costa Leste indo para um PoP em Nova York, o primeiro visitante contaria como uma “falha de cache” e o resto seria “acessos de cache”, resultando em uma taxa de acerto de cache de 99%. No entanto, se esses mesmos visitantes estivessem espalhados por 10 PoPs ao longo da Costa Leste, a porcentagem de acertos do cache de cada PoP seria de 90%, supondo que os visitantes sejam distribuídos igualmente. Se os visitantes não forem distribuídos igualmente entre os 10 PoPs, alguns PoPs terão uma taxa de acerto de cache mais baixa.

-Mais visitantes experimentando um tempo de carregamento mais lento devido ao cache do PoP não estar preenchido

– Aumento de solicitações ao servidor do site para preencher os vários PoPs

Por isso, o único tipo de site que se beneficia de um CDN com milhares de PoPs em todo o mundo é aquele que atende apenas algumas páginas a um público global muito distribuído. Na verdade, para muitos sites, o desempenho e a taxa de acertos do cache melhorarão com menos PoPs.

> Aprenda mais sobre CDN

Referencia: https://www.section.io/blog/more-pops-cdns/

Core Web Vitals melhoram posicionamento orgânico no Google

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

Como o Google classifica sites de notícias

O Google compartilha novos detalhes sobre como classifica as fontes de notícias, com a transparência sendo um fator importante.

Google valoriza a transparência quando se trata de elevar as fontes de notícias. A empresa compartilha mais informações sobre o que isso significa na prática.

Em uma postagem do blog, o Google detalha como avalia a transparência para determinar quais editores priorizar em superfícies como o Google Notícias e o carrossel de notícias principais nos resultados de pesquisa.

A transparência é tratada como um elemento importante porque ajuda a garantir que os visitantes possam aprender mais sobre a publicação da qual estão recebendo as notícias e os autores que as escrevem.

O Google observa que a transparência é um fator que contribui para avaliar a confiabilidade e a autoridade das fontes de notícias.

O Google compartilha os detalhes a seguir em um esforço para ajudar os editores a entenderem o que eles procuram em uma fonte de notícias transparente e a como atenderem a esses critérios.

Como o Google avalia a transparência em fontes de notícias

O Google procura esses elementos no site de um editor para determinar o seu nível de transparência:

  • Data de publicação
  • Assinatura do autor
  • Bios do autor
  • Informações de Contato
  • Informações básicas sobre o editor, empresa ou rede

O Google considera essas coisas informações que uma pessoa normal consideraria útil se quisesse avaliar a credibilidade de um site. Além disso, o Google diz que isso está de acordo com a pesquisa acadêmica, as práticas recomendadas de jornalismo e seus próprios testes de usuário.

Outros princípios que orientam a abordagem do Google para avaliar a transparência incluem:

  • Expectativas regionais e nacionais: o Google reconhece que existem áreas do mundo onde nomear um jornalista acarreta um risco significativo.
  • Diversas práticas editoriais: filosofias editoriais distintas, como publicar artigos sem assinaturas, não afetarão a credibilidade de uma fonte de outra forma confiável.
  • Disponibilidade para os usuários: o Google visa oferecer igualdade de condições a grandes sites com interfaces de usuário técnicas e sites menores que usam interfaces de usuário simples baseadas em texto.

“Nossos sistemas são projetados para usar esses princípios orientadores ao avaliar se um site está em conformidade com nossa política de transparência.”

O Google detalha ainda como usa esses princípios para avaliar a transparência a nível do site e a nível do artigo.

Avaliação da transparência a nível do artigo

A nível do artigo, o Google procura informações que ajudem os usuários a obterem rapidamente o contexto sobre a história ou sobre os jornalistas que cobrem as histórias.

Os editores podem enviar esses sinais ao Google incluindo assinaturas de artigos com links para uma página de biografia, datas de publicação e rótulos para indicar o tipo de artigo.

Avaliação da transparência a nível do site

A nível do site, o Google procura informações que ajudem os visitantes a entenderem o propósito da publicação, sua estrutura organizacional e os tipos de informações que podem esperar ler.

Existem várias maneiras de comunicar essas informações ao Google, como:

  • Uma declaração de missão
  • Políticas editoriais e padrões
  • Informações da equipe e biografias para a equipe editorial e de negócios
  • Informações de contato não genéricas
  • Outras informações de nível organizacional, como proprietários e/ou fontes de financiamento (por exemplo, patrocínio do estado, relacionamento com partidos políticos ou PACs)
  • O Google conclui sua explicação com uma nota sobre como pretende desenvolver essas políticas, ao mesmo tempo em que estará atento às diferenças nas normas locais e nas filosofias editoriais:

“A transparência requer uma abordagem cuidadosa que esteja em sintonia com as diferenças nas normas locais, filosofias editoriais e recursos, além de ser dinâmica e reflexiva dos padrões em evolução. Esperamos que nosso compromisso aqui e com todas as nossas políticas de notícias ajude as pessoas ao redor do mundo a se manterem melhor informadas sobre as notícias e ajude as fontes de notícias a serem reconhecidas por seu trabalho”.

Referencia: https://www.searchenginejournal.com/google-on-how-it-ranks-news-sources/409118/#close

GZIP vs Brotli – Qual método de compressão você deve usar e porque

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/