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

Mitigando ataques DDoS com uma CDN: como funciona?

/em

Os ataques distribuídos de negação de serviço (DDoS) representam uma ameaça significativa para a disponibilidade e estabilidade de serviços online. Esses ataques visam sobrecarregar servidores e redes, tornando os serviços inacessíveis para usuários legítimos. Uma solução eficaz para mitigar os efeitos prejudiciais desses ataques é o uso de uma content delivery network (CDN). Neste artigo, vamos explorar como uma CDN pode ser uma ferramenta vital na defesa contra ataques DDoS.

Primeiro, precisamos saber o que é uma CDN:

Uma content delivery network (CDN) é uma infraestrutura distribuída de servidores geograficamente dispersos, projetada para fornecer conteúdo de forma eficiente e segura aos usuários finais. Essa distribuição geográfica permite que os servidores mais próximos ao usuário forneçam o conteúdo, otimizando a entrega e melhorando o desempenho.

E como a CDN mitiga ataques DDoS?

A CDN atua como um escudo protetor contra ataques DDoS, distribuindo o tráfego em uma ampla rede de servidores. Vamos analisar as principais maneiras pelas quais uma CDN ajuda a mitigar esses ataques:

Distribuição de tráfego

Ao utilizar uma CDN, o tráfego é distribuído entre os diversos servidores da rede, evitando a sobrecarga em um único ponto. Isso reduz a probabilidade de um servidor ser alvo de um ataque DDoS com êxito, pois o tráfego é distribuído e balanceado.

Filtragem de tráfego malicioso

A CDN implementa algoritmos e regras de filtragem avançados para identificar e bloquear tráfego malicioso. Os pacotes suspeitos são interceptados e filtrados antes de alcançar o servidor de origem, protegendo-o contra sobrecargas.

Escalabilidade elástica

As CDNs têm a capacidade de dimensionar vertical e horizontalmente em resposta a picos de tráfego, incluindo ataques DDoS. Elas podem alocar recursos automaticamente para lidar com um volume inesperado de tráfego, mantendo a disponibilidade dos serviços.

E quais são outras estratégias de mitigação DDoS?

Além das funcionalidades gerais da CDN, existem estratégias específicas para mitigar ataques DDoS:

Bot Mitigation:
Muitos DDoS são realizados através de botnets. Utilizar uma solução que identifica e separa esse tipo de acesso dos acessos legítimos é uma excelente alternativa para lidar com este desafio.

Rate limiting (limitação de taxa)

Limitar taxas de requisições máximas de um mesmo IP em diferentes partes da sua aplicação web é uma estratégia comum para minimizar a sobrecarga do servidor de origem durante um ataque DDoS.

WAF
A utilização de um Web Application Firewall (WAF) para proteção de aplicativos web é uma ferramenta que contribui na mitigação de ataques DDoS

O WAF avalia parâmetros de uma requisição e identifica as anomalias e violações no protocolo HTTP. Não é incomum que um atacante o qual realize um DDoS deixe rastros nos seus acessos que ativam alguma regra de negócio do WAF.

Além disso, criar regras de bloqueio, combinando critérios de IP, URL, geolocalização, user-agent, também entrega uma proteção extra que pode ser útil durante um ataque DDoS.

Cache de conteúdo estático

A CDN armazena em cache o conteúdo do site, sendo muitas vezes uma barreira para o DDoS não chegar até a infraestrutura de hospedagem do cliente.

Como a GoCache ajuda?
A GoCache contempla na sua suite de segurança todas essas soluções, além de contar com uma gama de serviços como monitoração proativa e gestão de seus produtos, potencializando-os, e entregando alta disponibilidade perante ataques DDoS 

Load Balancer – Aumente a escalabilidade e desempenho de suas aplicações

/em

Garantir uma experiência online fluida e confiável é fundamental para o sucesso de qualquer aplicação na era digital. E para alcançar esse objetivo, apresentamos uma ferramenta poderosa: o Load Balancer da GoCache, que oferece alta disponibilidade e otimização de desempenho, distribuindo o tráfego de maneira eficiente entre os servidores.

Como o Load Balancer pode te ajudar na prática?

Alta disponibilidade para aplicações críticas:

É crucial assegurar que suas aplicações permaneçam acessíveis, mesmo em situações de falha de servidores. O Load Balancer da GoCache proporciona essa estabilidade ao distribuir o tráfego de forma inteligente.

Redução de sobrecarga em servidores:

A sobrecarga de servidores pode impactar negativamente o desempenho de suas aplicações. Controlar a distribuição das requisições é essencial para evitar sobrecargas e manter um desempenho estável e consistente.

Identificação da saúde dos servidores de origem:

O recurso de Health Check é uma funcionalidade valiosa que monitora continuamente a saúde dos servidores, garantindo a disponibilidade e integridade do sistema.

Elimine o Lock-in em um único provedor de hospedagem:

Com o Load Balancer da GoCache, você pode utilizar uma arquitetura multi-cloud, híbrida ou on-premise, independentemente do provedor de hospedagem. Liberte-se de dependências e tenha flexibilidade em suas escolhas.

Migre gradativamente sua infraestrutura de hospedagem:

Durante um processo de migração de servidor de hospedagem, é fundamental ter controle sobre a porcentagem do tráfego que vai para cada servidor. O Load Balancer da GoCache permite essa definição, facilitando a transição gradual e suave.

Convidamos você a conhecer este recurso poderoso

Quer proporcionar uma experiência excepcional aos seus usuários e garantir alta disponibilidade para suas aplicações? Conheça mais sobre o Load Balancer da GoCache e descubra como ele pode transformar sua infraestrutura digital.

Otimizando Imagens Mobile

/em

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

/em

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

/em

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

/em

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?

/em

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

/em

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

/em

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

/em

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