Enquanto escrevia o artigo para o blog de David Walsh, publiquei uma versão do artigo no Medium para que @cramforce, o líder do Google AMP, respondesse às perguntas feitas. Aqui está um link para o artigo em que ele publicou essas respostas: bit.ly/1VCLBr0
Como desenvolvedores, sabemos que a velocidade do site é extremamente importante. Nos últimos anos, a comunidade de desenvolvedores criou e apoiou novas especificações e técnicas de navegador para aumentar a velocidade do site. Assim, quando soube que o Google estava lançando o projeto Accelerated Mobile Pages (AMP), fiquei muito animado e quis começar imediatamente a usar os padrões definidos pelo Google para garantir que os sites da Aristotle Interactive tivessem o melhor desempenho possível.
Os desenvolvedores, designers e gerentes de projeto da Aristotle trabalharam arduamente no último ano para criar um documento de especificação de velocidade do site e um orçamento de desempenho para garantir que todos os sites que construímos sejam rápidos sem sacrificar o design ou a funcionalidade. Naturalmente, queríamos usar as AMP para tornar os sites de nossos clientes ainda mais rápidos, mas antes de começarmos a alterar o código, queríamos fazer alguns testes para explorar os benefícios do uso das AMP, além do aumento de SEO. Os testes levantaram uma questão entre nossa equipe e queríamos publicá-la na comunidade para iniciar uma discussão: O AMP é realmente necessário para aumentar a velocidade do site?
Primeiro, vamos dar uma olhada nos resultados dos testes. Usamos uma ferramenta chamada WebPageTest para verificar a velocidade do site de cada página abaixo. Testamos as páginas usando um iPhone 6 com iOS 9, simulando uma conexão 3G (1,6 Mbps/768 Kbps 300ms RTT). Testamos cada página cinco vezes e mostramos o resultado médio neste artigo. Nossa equipe de desempenho da Aristotle usa três métricas que comprovadamente medem a velocidade do site e a experiência do usuário: Tempo até o primeiro byte, índice de velocidade (desempenho percebido) e tamanho da página. Testamos as páginas que foram exibidas no link de demonstração de AMP fornecido pelo Google (http://g.co/amp), AMPs “in the wild” que encontramos por meio de pesquisas no Google e alguns sites que a Aristotle criou recentemente.
Resultados da demonstração de AMP do Google
“Resultados AMP de “In the Wild
Resultados interativos de Aristóteles
| Site | Tempo para o primeiro byte | Índice de velocidade | Tamanho da página | Teste WPT |
|---|---|---|---|---|
| Fort Smith * | A | 5.77 segs | 893 kb | link |
| Little Rock * | A | 8.30 segs | 754 kb | link |
| ASPSF | A | 7,24 segundos | 411 kb | link |
| Beacon Legal Group * | A | 6,78 segundos | 761 kb | link |
* significa que o site reformulado está quase sendo lançado e um link não está disponível.
Há uma diferença entre o conteúdo dos sites que a Aristotle criou e o das AMPs do Google. Nossos sites são sites de turismo, enquanto os AMPs são artigos de notícias. Esperávamos que os sites de turismo fossem muito maiores em tamanho e mais lentos em velocidade, considerando a quantidade de imagens e Javascript usados para criar experiências interativas, mas descobrimos que nem sempre era esse o caso.
Perguntas
- A maior pergunta: por que páginas como Buzzfeed e USA Today são impulsionadas e pré-carregadas no dispositivo do usuário, mas não páginas como Fort Smith e ASPSF (a menos que elas usem AMP)? As AMPs parecem carregar rapidamente porque há alguns ativos que são pré-carregados da página. Não faz mais sentido dar um impulso de SEO às páginas que inerentemente atendem a um padrão? Devemos recompensar as páginas (e os editores) que incorporam a velocidade do site em seu site como um recurso.
- Como há ativos que são pré-carregados da página de resultados de pesquisa do Google, há um limite para quantos kilobytes são baixados de lá? Sites como o Buzzfeed, que parecem abusar do uso de dados dos visitantes, podem ser um problema se o senhor estiver pré-carregando ativos.
- Parece que o algumas fontes estão dizendo que os editores devem “ter que manter pelo menos duas versões de qualquer página de artigo: A versão original da página do seu artigo que os usuários normalmente verão e a versão AMP dessa página”. Como a maioria das fontes de SEO recomenda um site responsivo em vez de um site móvel separado e a maioria dos sites gastou muito para fazer isso, não parece que o senhor está dando dois passos para trás ao ter um site AMP separado? Isso pode se complicar quando o senhor considera o Facebook Instant Articles e outros serviços que desejam atingir o mesmo objetivo.
- Existem alguns recursos interessantes que o AMP oferece, como a forma como as imagens e os ativos são carregados e exibidos, mas não seria melhor padronizar uma forma de fazer essas coisas em vez de fazer de uma forma diferente para cada serviço?
Serviços como o Google AMP e o Facebook Instant Articles parecem estar se preparando para premiar os editores que usam marcação “proprietária” (ou seja, marcação não padronizada), em vez de premiar os editores que criam seus sites tendo o desempenho como base. É essa realmente a Web que queremos promover? O que o senhor acha do Google AMP e de outros serviços semelhantes?
Compartilhe suas ideias e envolva outras pessoas compartilhando esta publicação.
