Introdução

Em 1991, foi introduzida a primeira versão documentada do protocolo HTTP de solicitação-resposta (HTTP 0.9). Desde então, a web se expandiu drasticamente e, 24 anos depois, a versão mais recente do HyperText Transfer Protocol (HTTP/2) foi lançada em 2015, apresentando uma infinidade de possíveis benefícios para o desempenho do site quando implementado corretamente.

Este artigo é destinado a SEOs que desejam implementar HTTP/2 como parte de suas iniciativas de otimização de velocidade de página.

HTTP/2 é um tópico extremamente rico que poderia ser discutido em grande detalhe. Há uma riqueza de informações on-line discutindo HTTP/2 e seus benefícios mais amplos para usuários finais e desenvolvedores, mas antes que você se encontre imerso na riqueza de informações sobre HTTP/2, certifique-se de obter as informações de que precisa. Isso começa com as perguntas certas:

1. Como isso afetará diretamente a otimização do mecanismo de pesquisa e/ou a velocidade da página?
2. Uma recomendação pode ser feita a partir do insight?
3. A recomendação pode ser executada de forma realista?

Essas perguntas ajudam você a perguntar “o que estou fazendo é eficaz e valioso?” e, finalmente, colocá-lo em uma posição melhor para avaliar como o HTTP/2 pode ajudar a melhorar um site.

Devido à natureza ampla do tópico, há uma grande quantidade de conhecimento em torno do HTTP/2 que não é necessário ao tentar entender a importância do SEO. O principal benefício do HTTP/2 para SEO é a velocidade da página.

Para ajudá-lo a navegar pela riqueza de informações on-line, aqui está uma introdução ao HTTP/2, descrevendo a evolução do HTTP 1.1 para o Spdy compatível com HTTP do Google e, eventualmente, para o HTTP/2.

Compreender como a web evoluiu ajudará a destacar as melhorias que foram feitas como consequência da adição do protocolo HTTP/2.

Como o Google avalia a velocidade da página?

Para ver como o Google avalia o Page Speed, basta consultar os Relatórios de experiência do usuário do Chrome . Esses relatórios fornecem métricas de experiência do usuário sobre como os usuários estão experimentando destinos populares na web. Isso é desenvolvido usando as principais métricas de engajamento do usuário (Primeira pintura, Primeira pintura de conteúdo, Primeira pintura significativa, Tempo para interação) e é ainda compatível com ferramentas comuns, como o Page Speed ​​Insights, o Public Google Big Query Project, o Lighthouse e o Web Page Test. A utilização dessas métricas e ferramentas pode ajudar a possibilitar melhorias na velocidade da página.

Introdução ao HTTP/2

HTTP 1.1

Em 2015, o HTTP 1.1 ficou desatualizado. Foi-se o tempo em que páginas/sites da web eram construídos/baseados em HTML básico, CSS e JavaScript, além de vários recursos e estruturas diferentes. A era pré-2015 foi baseada na ideia de que você estava limitado a uma solicitação por conexão TCP. Isso levou a situações em que os clientes da Web tinham vários recursos em fila para download, causando congestionamento da rede e tempos de carregamento de página lentos.

O HTTP/2 foi projetado para atingir três áreas principais de melhoria para aliviar os problemas discutidos acima:

• Simplicidade
• Alta performance
• Robustez

Benefícios de SEO para HTTP/2

A velocidade da página é provavelmente a principal razão pela qual os SEOs considerariam implementar o HTTP/2 em seus próprios sites ou nos sites de seus clientes. A velocidade/desempenho da página é um conjunto de métricas que tem sido um fator de classificação desde 2010 para consultas de desktop. Devido ao aumento do uso de dispositivos móveis, em julho de 2018, o Google anunciou oficialmente que a velocidade da página se tornaria um fator de classificação para dispositivos móveis.

O HTTP/2 fornece 3 funcionalidades principais que podem ser utilizadas ao otimizar sites para o Page Speed:

1. Multiplexação
2. Push do servidor
3. Priorização de fluxo

Multiplexação

A multiplexação permite que um cliente da Web inclua várias solicitações em uma única conexão TCP, resultando em menor carga do servidor e reduzindo o congestionamento da rede.

Clientes web modernos (Chrome, Firefox, Safari e Opera) que utilizam os protocolos HTTP 1/1.1 mais antigos têm um limite padrão no número de conexões TCP simultâneas por nome de host. Portanto, um cliente da Web que utiliza HTTP 1/1.1 pode facilmente ter dificuldade com o congestionamento do TCP. Com clientes da Web modernos, esse problema é resolvido usando multiplexação, que pode fornecer algumas das melhorias mais significativas na velocidade da página.

Demonstrado abaixo é o benefício da multiplexação usando uma comparação de HTTP/1.1 e HTTP/2, mostrando o comportamento típico para quando a multiplexação HTTP/2 está ou não habilitada.

( WebpageTest, HTTP/1.1, sem multiplexação demonstrada )

( WebpageTest, HTTP/2, Multiplexing demonstrado )

Nas imagens acima uma cascata baseada em desempenho é usada para demonstrar o carregamento de recursos entre um usuário (que solicita os recursos) e o servidor (quem responde quais os recursos) de uma página web. Normalmente, os recursos da página incluem HTML, JavaScript, CSS e imagens. A cascata baseada em desempenho demonstra o ponto exato de quando um recurso específico é chamado, baixado e renderizado no cliente, o que é fundamental para descobrir, avaliar e analisar problemas de velocidade de página em um site. Conforme demonstrado pela imagem acima “HTTP/2”, todos os recursos começam a ser baixados simultaneamente sem que nenhum recurso comece a carregar em um ponto diferente. Como o HTTP/2 utiliza multiplexação e não depende mais do envio de apenas 1 solicitação em uma única conexão TCP, vários recursos podem ser baixados ao mesmo tempo visto acima. Por outro lado, conforme demonstrado pela imagem “HTTP/1.1”, os recursos não são baixados simultaneamente, pois não podem utilizar a funcionalidade de multiplexação. O navegador moderno médio em HTTP/1.1 é capaz de ter simultaneamente 6 conexões, mas o benefício de implementar HTTP/2 é que um handshake TCP não é necessário para cada solicitação, enquanto não importa quantas conexões possam ser executadas simultaneamente com HTTP/1.1 inicial processo de conexão deve ser concluído todas as vezes. Portanto, eles estão começando a baixar em pontos diferentes, causando um carregamento de página mais longo para o usuário.

( Diagrama Upwork HTTP/1.1 vs HTTP/2 )

Rastreadores de pesquisa, como Google e Bing, não se beneficiam diretamente da implementação do HTTP/2. Conforme descrito acima, o principal benefício dessas otimizações pode ser o Page Speed. Portanto, embora a implementação do HTTP/2 possa não afetar o rastreador de pesquisa diretamente, ela pode afetar a velocidade da página, que é um fator de classificação direto para consultas do Google para computadores desde 2010 e consultas para dispositivos móveis desde julho de 2018. Como resultado, é fundamental que os sites não forneçam uma experiência lenta para os usuários, pois o Google pode suprimir o desempenho impactando as classificações ou, mais recentemente, sinalizando para os usuários que seu site pode estar lento.

Push do servidor

O Server Push permite que o servidor específico ou a rede de borda envie recursos para clientes da Web quando eles não tiverem sido solicitados pelo cliente. Para entender como funciona o push do servidor, primeiro é importante entender o padrão de solicitação-resposta que um site segue. Um usuário solicita uma página de um site e o servidor responde com o conteúdo/recurso solicitado.

Hipoteticamente, pense em um site que tem todos os seus estilos definidos em uma folha de estilo externa chamada styles.css. Quando o usuário solicita o esqueleto HTML da página (digamos, neste caso, index.html), o push do servidor pode “enviar” o CSS para o usuário logo após começar a enviar a resposta para index.html.

( S mashing Magazine, Server Push )

Antes de entender como o Server Push pode ajudar a melhorar a velocidade da página, é importante entender como um navegador funciona com diferentes recursos, como imagens, CSS e JavaScript, para aparecer em seu navegador. Veja bem, o navegador envia instruções sobre como baixar imagens, CSS e recursos JavaScript. Ao visitar um site pela primeira vez, você geralmente faz uma solicitação GET, que é o arquivo .html. Uma vez que este arquivo .html é recebido, o navegador o examina para entendê-lo e, em seguida, pode fazer solicitações GET adicionais dependendo do que está contido no arquivo HTML.

Como o Server Push ajuda a melhorar a velocidade da página?

Com o uso do Server Push, o número de solicitações GET necessárias do navegador (ida e volta) é reduzido e os atrasos na renderização que causam maiores tempos de carregamento da página são evitados. Isso pode ajudar a melhorar drasticamente o tempo de renderização do cliente da Web, o que ajuda a página da Web a aparecer mais rapidamente para os usuários, proporcionando uma experiência muito melhor.

Embora o Server Push não afete diretamente como o Googlebot rastreia seu site, ou mesmo outros rastreadores, o benefício de SEO é obtido por meio de melhorias em fatores centrados no usuário, como First Paint e First Meaningful Content.

Utilizando o Web Page Test, Lighthouse, Page Speed ​​Insights e o Chrome User Experience Report, você pode determinar o desempenho de um site/página em comparação com concorrentes nos mesmos setores. Abaixo estão duas imagens demonstrando a implementação sem (Imagem 1) e com Server Push (Imagem 2).

(WebpageTest, sem servidor push)

(WebpageTest, HTTP/1.1, com servidor push)

Com o server push, o servidor pode ser configurado para que ele sempre envie quaisquer componentes de página adicionais (como arquivos CSS, JavaScript e imagens) se for solicitado a enviar o arquivo .html que os contém.

Nas cascatas acima podemos ver que o push.php usa quatro arquivos CSS.

Sem o push do servidor, o navegador precisa receber o arquivo push.php, analisar o HTML e fazer solicitações específicas para cada arquivo CSS adicional. Somente depois de receber todos os arquivos CSS, ele pode começar a usá-los no processo de renderização.

Quando o push do servidor está ativado, a solicitação de push.php aciona automaticamente o servidor para enviar os quatro arquivos CSS. O navegador os recebe e pode começar a usá-los no processo de renderização muito antes. Isso significa que o navegador pode começar a renderizar o conteúdo da página muito mais cedo, o que resulta em melhores métricas de velocidade da página.

Priorização HTTP/2

A priorização HTTP/2 entrega o controle da ordem em que os recursos são carregados, de volta aos proprietários do site. Feito corretamente, a priorização beneficia a experiência do usuário e a velocidade da página/site, fornecendo recursos de página em uma ordem otimizada, criando assim uma experiência de usuário “rápida”.

Se olharmos para o predecessor HTTP/1.1 do HTTP/2, o cliente web controlava a ordem de quando os recursos seriam carregados. Conforme discutido acima, isso se deve ao fato de que cada conexão TCP só era capaz de suportar um recurso por vez. Cabe ao navegador agendar solicitações decidindo quais recursos escolher e quantas conexões abrir em paralelo.

Antes de entrar em como isso é feito, é importante entender por que queremos usar a priorização de nossos recursos.

Se tivermos uma imagem na parte superior de uma página e uma imagem na parte inferior da página, logicamente, gostaríamos de garantir que a imagem na parte superior seja carregada antes da imagem na parte inferior. Esse conceito ajuda a demonstrar a importância e o impacto que a priorização HTTP/2 pode trazer. A priorização HTTP/2 nos permite especificar quais recursos devem ser entregues primeiro e carregados antes de outros (sejam eles JavaScript, CSS ou imagens), garantindo assim o tempo de carregamento mais rápido para a página.

Embora o navegador agora possa solicitar vários recursos simultaneamente em uma única conexão TCP usando multiplexação, agora ele também pode especificar informações de prioridade com cada solicitação para ajudar a determinar quando/como o recurso deve ser entregue. Se tanto o servidor quanto o navegador suportam priorização HTTP/2, o navegador deve definir as regras para priorização utilizando largura de banda total sem ter recursos competindo entre si. Para entender melhor como funciona o processo de priorização, é importante discutir três parâmetros importantes para a priorização HTTP/2:

Stream: Este é um fluxo bidirecional de bytes dentro de uma conexão estabelecida que pode transportar uma ou mais mensagens.

Fluxo pai: Este é um fluxo do qual os recursos dependem

Fluxo filho: Este é um fluxo dependente do fluxo pai. Eles compartilham o mesmo pai e, portanto, são conhecidos como fluxo filho

Peso: Este é um número alocado entre 1 e 256 que identifica quanta largura de banda alocar ao fluxo se vários fluxos estiverem compartilhando uma conexão. A largura de banda é alocada em relação aos pesos de todos os outros fluxos ativos.

Bit exclusivo: Este é um sinalizador que indica que o fluxo deve ser baixado sem compartilhar largura de banda com outros fluxos.

Headers Frame: Esta é a identificação do stream a qual frame ele pertence

Binary Framing Layer: É assim que as mensagens HTTP são encapsuladas e transferidas entre cliente e servidor

Um exemplo abaixo demonstra um exemplo do acima:

( Priorização de fluxo HTTP/2 do Google Developers )

Para realizar a priorização HTTP/2, você precisará adicionar informações de priorização no quadro de cabeçalhos localizado na nova camada de enquadramento binário HTTP/2. O fluxo pai e a dependência/não dependência de outros fluxos filho determinarão a prioridade/ponderação e, portanto, a entrega do recurso ao cliente web.

Embora a priorização HTTP/2 agora seja compatível com várias plataformas, muitos CDNs e provedores de hospedagem não oferecem suporte à priorização HTTP/2. Portanto, é importante certificar-se de que você está utilizando um provedor de hospedagem/CDN que suporte a priorização HTTP/2 se desejar usar essa técnica de otimização. Abaixo está uma tabela que descreve quais CDN/hosting/servidores são capazes e não suportam a priorização HTTP/2.

Priorização HTTP/2 - Compatibilidade Common Server/Hosting/CDNs

Essa comparação estava correta em 01/02/2020 , mas vale a pena verificar se os provedores de serviços em potencial melhoraram sua compatibilidade antes de tomar sua decisão sobre qual escolher.

Também é importante olhar para navegadores específicos de forma crítica porque, infelizmente, nem todos os navegadores suportam a priorização HTTP/2 e priorizam de forma diferente devido a serem clientes da web diferentes. Abaixo está uma tabela que descreve quais clientes da Web podem oferecer suporte à priorização HTTP/2.

Compatibilidade do cliente Web de priorização HTTP/2

A priorização HTTP/2 pode melhorar significativamente a percepção do usuário sobre a velocidade da página/site e afetará positivamente os dados acumulados no Relatório de experiência do usuário do Chrome. Embora essa otimização não tenha impacto nos rastreadores de pesquisa, como o Googlebot, ferramentas como o Lighthouse e o Page Speed ​​Insights ajudarão você a avaliar o impacto da priorização HTTP/2 no desempenho da velocidade da página da perspectiva do usuário.

Ao configurar corretamente o peso do fluxo com servidor e cliente utilizando um CDN/host compatível com HTTP/2, você poderá melhorar drasticamente suas métricas de velocidade de página para seu cliente.

Quais são os pré-requisitos para HTTP/2

Antes de poder aproveitar os benefícios de velocidade do HTTP/2, certifique-se de poder utilizá-lo. Existem alguns pré-requisitos que devem ser considerados:

1. É importante certificar-se de que o HTTPS esteja ativado.
2. Utilize um certificado TLS de uma autoridade autenticada e ative e instale o certificado.
3. Certifique-se de que seu software de servidor Web, como Nginx, Apache e IIS, suporte HTTP/2. Uma lista autenticada completa para suporte pode ser encontrada em http://ayi.ma/browsershttp2 , que mostrará o suporte do navegador para HTTP/2. Se você estiver procurando por suporte HTTP/2 para CDNs/Hosting, consulte http://ayi.ma/serverhosting .

Armadilhas/coisas comuns que devem mudar com a introdução do HTTP/2

Devido às limitações dos protocolos HTTP 1.0 e HTTP 1.1 anteriores, os desenvolvedores e SEOs se esforçaram para encontrar maneiras de contornar a infinidade de problemas que essas limitações apresentavam para o desempenho e a segurança da velocidade da página.

Eventualmente, eles conseguiram encontrar “hacks” para contornar algumas dessas limitações, mas muitos desses métodos causaram ainda mais trabalho aos desenvolvedores. Quais são alguns desses hacks que você pode perguntar? Aqui estão alguns dos hacks mais comuns que você verá em sites que podem ser resolvidos através da implementação correta do HTTP/2.

Evite a fragmentação de domínio

Surpreendentemente, muitos sites ainda usam esse hack, embora tenham o HTTP/2 implementado corretamente. Quando o HTTP/2 estiver ativado, será importante evitar a utilização de fragmentação de domínio. Domain Sharding é a técnica de dividir recursos entre diferentes nomes de host, permitindo assim que mais recursos sejam servidos simultaneamente.

Graças ao protocolo HTTP/2 atualizado, a fragmentação de domínio não é mais necessária e, de fato, causa mais problemas do que resolve. Se o HTTP/2 estiver configurado e habilitado corretamente para o seu site e você também usar o Domain Sharding, na verdade você estará contrariando alguns dos benefícios do HTTP/2, pois o navegador não poderá se beneficiar da multiplexação e downloads em vários nomes de host.

Além disso, por meio do Fragmentação de Domínio, você está realmente quebrando a Priorização de Stream e seus recursos não poderão ser carregados para aproveitar ao máximo o Page Speed.

Utilize corretamente o push do servidor

O Server Push tem algumas desvantagens das quais você deve estar ciente. O Server Push pode, de fato, ser usado em excesso e você deve ser seletivo ao escolher quando usá-lo. Você não necessariamente deseja enviar muitos recursos, pois isso pode fazer com que o cliente da Web baixe não apenas o HTML, mas tudo o que é "enviado". Isso significa que a página pode levar mais tempo para carregar e renderizar (aumentando as métricas centradas no usuário que são focadas pelo Google, como o Tempo para Interação).

Uma segunda armadilha comum para o push do servidor é descobrir como não enviar recursos que o cliente da Web já possui. Isso pode ser controlado através de vários métodos. Um método é optar por não enviar recursos para usuários recorrentes e, portanto, permitir que os usuários retornados utilizem seus ativos em cache. Esta é de longe a implementação mais fácil. Isso pode ser feito simplesmente verificando os cabeçalhos de cache dos recursos, certificando-se de que os cabeçalhos não se sobreponham à implementação de push do servidor.

Testes da vida real em HTTP/2

O conhecimento teórico é sempre importante para estabelecer as bases para entender o HTTP/2 e seus benefícios. Uma vez que os conceitos são compreendidos e compreendidos, é importante testar essas teorias para medir o impacto que o HTTP/2 pode causar na velocidade da página.

A parte 2 desta série de velocidade de página HTTP/2 na vida real - usando testes e análises de sites discutirá o verdadeiro benefício do HTTP/2 em relação à velocidade da página e valor para SEO, então não perca!

E o HTTP/3?

Embora o HTTP/3 demonstre um claro potencial como o protocolo sucessor do HTTP/2, ele não sinaliza e não deve sinalizar o fim do HTTP/2 para SEOs em toda a web. Como acontece com todos os novos grandes desenvolvimentos para a web mundial, ele passará por uma fase normal de lançamento e provavelmente levará tempo para um site adotar o novo protocolo e antes que ele se torne um padrão de fato na indústria de SEO. A implementação do HTTP/2 ainda representa um ganho simples e benéfico que, quando implementado corretamente, pode ajudar a melhorar o desempenho do seu site.