Accelerated Mobile Pages ou AMP é um conjunto de diretrizes e biblioteca baseada em componentes da web para construir sites mais rápidos do que os normalmente desenvolvidos. Ele foi criado pelo Google, provavelmente como um projeto paralelo de alguns de sua equipe de pesquisa, para ajudar a tornar a web mais rápida.
Do ponto de vista do código, é um projeto de código aberto, o que significa que qualquer pessoa pode clonar ou bifurcar o código-fonte e manipulá-lo como quiserem. O projeto ou conceito não é patrocinado apenas pelo Google, mas também conta com o suporte do Bing, Baidu, Twitter, Pinterest e muitas outras partes.
Como recompensa por desenvolver seu site usando as páginas de recompensas do Google AMP com posicionamento favorável em mecanismo de pesquisa, especificamente em resultados de pesquisa para celular.
Observe como o carrossel de notícias é apresentado no topo dos resultados e há uma fila visual de que a página é AMP?
Muitos sites que foram convertidos para AMP relatou resultados surpreendentes . Não apenas no SEO aprimorado, mas no tráfego, nas vendas e em uma série de outras métricas de negócios importantes.
Mas isso é porque eles converteram para AMP ou simplesmente mudaram seu site para implementar práticas melhores, especificamente fazendo com que suas páginas carreguem mais rápido ?
Sabemos que o Google classifica as páginas mais rápidas acima das páginas mais lentas. Quero dizer, John Mueller e a equipe de pesquisa do Google parecem sempre enfatizar isso como um sinal importante de classificação.
Então eu acho que há dois aspectos aqui quando você olha para a velocidade do servidor. Por um lado, há o tipo de velocidade percebida no navegador, no tempo que leva para renderizar uma página, e isso é algo que definitivamente é um fator de classificação
Portanto, melhorar o tempo médio de carregamento da página de, digamos, 20 segundos para 5 deve melhorar suas métricas, quase imediatamente.
Mas o AMP é realmente a melhor maneira de fazer sites?
É é a melhor maneira de criar sites rápidos?
Você pode tornar seu site tão rápido, se não mais rápido, sem AMP?
Uma das percepções comuns sobre AMP é que é uma maneira de construa seu site para que carregue mais rápido. Mas’mais rápido’é um termo relativo. Como demonstrarei neste artigo, as AMP não aplicam as práticas recomendadas para fazer as páginas carregarem quase instantaneamente.
Como a maioria das páginas já é muito lenta, qualquer melhoria é melhor do que nada. Embora o AMP possa certamente fazer com que a maioria das páginas carregue muito mais rápido, ele deixa a velocidade sobre a mesa ao não aplicar ferramentas de auditoria de práticas recomendadas como o Lighthouse do Google e a ferramenta Page Speed Tool.
Recente comentários a um artigo da ArsTechnica sobre o Bing adicionar suporte para AMP demonstram a frustração dos usuários com páginas da web inchadas.
É uma solução (ruim) para um problema que não deveria existir-sites tão inchados com todos os tipos de besteiras que usam megs e megs de dados apenas para mostrar um artigo.
Além disso, você está terceirizando o controle de seu conteúdo da web para o Google. Eles’raspam’suas páginas e as hospedam em seus servidores e domínio. Eles estão em processo de eliminação dessa parte ainda este ano. Imagino que eles precisem fazer isso para evitar litígios antitruste sérios, mesmo que não seja por outro motivo.
Há alguns meses, postei sobre AMP Carta assinada por mim e muitos de meus colegas preocupados com a direção de AMP. Acho que a equipe de AMP ouviu e declarou publicamente algumas alterações do programa que espero ver implementadas mais cedo ou mais tarde.
É absolutamente necessário que suas páginas carreguem rápido, instantaneamente, se possível. As AMP fornecem algumas diretrizes importantes que você pode seguir para fazer suas páginas carregarem mais rápido. Adoro o fato de o Google ter criado outro canal para divulgar algo pelo qual sou apaixonado.
Por quê?
Porque fornecer uma melhor experiência do usuário, que, a propósito, o tempo de carregamento da página é normalmente a expectativa do usuário nº 1, on-line pode levar a métricas de site mais positivas (como serps e tráfego orgânico) e receita por meio de maior envolvimento e satisfação do cliente. > Estive acompanhando os vídeos do Google I/O na semana passada e várias sessões sobre AMP me chamaram a atenção. Portanto, decidi que era hora de revisitar as AMP para ver se realmente valia a pena ou se devo continuar com o que estou fazendo.
Aqui está o problema real: a página da web leva em média 15 segundos para carregar em 4G e 19-20 segundos em 3G. Esses números são importantes, pois a maior parte do tráfego da web vem de um dispositivo móvel, o que, claro, muitas vezes não é feito em WiFi de alta velocidade.
Como a web é essencial para o sucesso do Google, eles decidiram ajudar a todos criando AMP. Como incentivo, você obtém um posicionamento preferencial em mecanismos de pesquisa, especialmente em resultados para celular.
Até este ponto, eles têm buscado sites de notícias porque, convenhamos, os sites de notícias são as piores experiências.
Sério!
Eu auditei vários sites de notícias e registrei alguns fazendo mais de 800 solicitações HTTP!
E pesando cerca de 10 MB para cada página.
É preciso dizer que não são exemplos de como construir uma página da web adequada. Eles são exemplos de como não construir uma página da Web.
Portanto, a equipe de AMP direcionou esses sites primeiro. E tem havido muitos resultados positivos.
Como funciona a AMP?
O projeto AMP fornece diretrizes para você criar páginas da web, mas você deve usar a estrutura dela, que é, acredite, uma bifurcação do projeto Polymer.
Bifurcação é um conceito de código aberto onde você pega um repositório de código-fonte e faz sua própria cópia nova e começa a fazer sua própria versão. É aqui que existem cerca de 3 versões do Linux para cada usuário do Linux 😜.
Se você não está familiarizado com o Polymer, é uma estrutura de componentes da web baseada em, bem, as especificações dos componentes da web.
Um problema com os componentes da web é que, até recentemente, eles não eram amplamente suportados. Isso significava que a Polymer tinha que incluir um conjunto bastante grande de código polyfil para fazer o projeto funcionar em todos os navegadores.
Esse excesso de gordura permanece em o projeto AMP atual.
Existem três partes principais no quebra-cabeça das AMP:
- HTML AMP: uma versão reformulada do HTML inclui um novo conjunto de comandos personalizados relacionados às AMP.
- AMP JS: uma nova estrutura Javascript para páginas móveis que permite todo o carregamento de recursos externos de forma assíncrona.
- AMP CDN (Content Delivery Network): isso pegará seu conteúdo otimizado para AMP e armazene-os em cache para entrega rápida. Você verá isso conhecido como cache de AMP
O HTML de AMP é apenas uma diretriz de prática recomendada simples e mínima para fazer a marcação principal da sua página. Existem alguns requisitos mínimos de que você precisa para seguir o padrão AMP.
- Você precisa designar que é uma página AMP incluindo amp-html ou ⚡ na tag HTML de abertura.
- Você precisa incluir a tag meta charset=”utf-8″como o primeiro elemento no documento’s HEAD
- Inclua uma diretiva ViewPort mínima
- Inclua uma tag canônica apontando para o URL de origem original da página
- Inline o CSS AMP principal e qualquer CSS de que a página precisa
- Carregar de forma assíncrona o pacote AMP JavaScript
Além do AMP JavaScript, essas são todas as coisas que você deve fazer com qualquer página da Web.
O AMP CDN é onde o Google copia seu conteúdo e hospeda no Seus servidores usam seu domínio interno, não o seu. Este eu tenho um grande problema.
Por que eles estão fazendo isso?
O Google rastreia bilhões de páginas da web por dia e sabe que a maioria dos servidores da web não está configurada corretamente. Além disso, a maioria dos sites não está usando uma rede de distribuição de conteúdo. Novamente, essas são coisas que você pode e deve fazer.
10 anos atrás, um CDN era acessível apenas para empresas maiores com receita para justificar um Akamai ou um de seus concorrentes de alto preço. Hoje a nuvem mudou isso. AWS, Azure, Google e outros oferecem soluções CDN acessíveis. Eu pago menos de $ 0,10/mês na AWS por mais de 60.000 sessões de usuário exclusivas neste site. Então, acho que você pode pagar por isso 😁.
Mas o JavaScript AMP… o que é isso e por que ou por que preciso incluir esse pacote gigante de script, a maioria do qual não será usado?
Como mencionei anteriormente, o AMP é criado usando componentes da web, que geralmente requerem um polyfil para funcionar porque os componentes da web ainda não são amplamente suportados. Os componentes da Web dependem de algo chamado Shadow-DOM. No momento, o Chrome é o único navegador importante que oferece suporte. E deveriam, já que foram eles que criaram o conceito.
Microsoft, Mozilla (FireFox) e Apple hesitaram em implementar essa API. O principal motivo são as preocupações com o desempenho. Eu não vou mergulhar naquela toca do coelho porque fica muito técnico. No momento, o FireFox está em processo de adição de suporte. A Apple implementou alguns recursos e a Microsoft ainda está investigando se vai investir recursos de engenharia.
Isso significa que, além do Chrome, você não tem uma plataforma confiável para componentes da web. O que significa que a AMP deve fornecer um grande pacote de JavaScript ( 245 kb ), o que, obviamente, é o principal assassino de desempenho.
Não tenho problemas com o conceito de alto nível dos componentes da web , Eu acho que é uma boa ideia. Mas também conversei com engenheiros de navegador que começaram a suar pensando em como fazê-lo funcionar de maneira eficiente. Espero que em algum momento de 2020 tenhamos um bom suporte, mas por agora vamos supor que haja outras coisas mais importantes para implementar, como trabalhadores de serviço.
Sei que estou em minoria, mas normalmente posso olhar para a maioria das páginas da web e quebrar diferentes componentes de IU e conceituar o CSS e JavaScript necessários para conduzir a maior parte da experiência do usuário. Na maioria dos casos, posso ver como criar a maioria das páginas com menos de 50kb de JavaScript, muito menos do que os 245kb necessários como base para AMP.
E esse é o problema real. JavaScript demais.
Decidi realizar uma auditoria de desempenho simples na página de práticas recomendadas do projeto AMP usando o teste de página da web. A única coisa em que tiveram uma pontuação baixa foi no cache de ativos da página.
Nada mal…
Até que você vá um pouco mais fundo
A página não renderiza até 1,6 segundos, não exatamente quase instantaneamente. E isso foi em um desktop em uma conexão de alta velocidade.
Como o AMP foi projetado para ajudar você a carregar mais rápido em dispositivos móveis, executei o mesmo teste em um Nexus 5 em uma conexão LTE . Isso deve simular um telefone comum em uma boa conexão de celular.
A página não renderiza até 3,5 segundos!
Para provar ainda mais meu ponto de não aderir às práticas recomendadas de desempenho da web, executei Lighthouse, ferramenta de auditoria de páginas do Google para ver se atendeu bem às diretrizes de desempenho e práticas recomendadas.
É uma droga…
Vários princípios básicos perdidos. Basicamente, muito script e muito CSS junto com imagens não otimizadas, etc.
Não exatamente perto do instante. Quer dizer, é muito melhor do que a média da indústria de aproximadamente 20 segundos.
Honestamente, não sei por que a página leva tanto tempo para pelo menos renderizar a marcação. Apenas uma rápida revisão dos estilos, que estão devidamente alinhados no documento HEAD, deve ajudar a renderizar o conteúdo antes que o JavaScript seja carregado. Mas a página não é renderizada até que todo o JavaScript seja carregado, analisado e executado.
Você pode dizer isso observando a haste dourada no perfil da CPU.
Você também deve observar que quaisquer componentes da web carregados pelo também podem fazer com que scripts adicionais sejam carregados. A página do projeto AMP tem alguns pequenos scripts para conduzir diferentes componentes.
Acho que o principal atraso da página é aguardar o download dos arquivos de fontes personalizadas antes que o CSS possa ser totalmente avaliado. E se você não sabia, CSS é outro processo de bloqueio de renderização.
Eu acho que há algum tipo de convergência entre o tempo que leva para o mecanismo de renderização completar a análise de JavaScript e CSS. Eu sei que estou entrando nos componentes internos do mecanismo do navegador, mas não tenho nenhum conhecimento direto dos componentes internos para fornecer uma resposta absoluta. Mas o perfil me diz que é esse o caso.
O que você pode aprender com a página lenta do projeto AMP?
Minimize sua dependência de JavaScript e fontes personalizadas são a grande vantagem, sem com essas dependências, a página renderizaria, provavelmente, em um segundo ou menos no celular e LTE e quase instantaneamente na banda larga.
É difícil ter uma página perfeita para desempenho. Portanto, não descarte totalmente a equipe AMP. Mas acho que o perfil de suas páginas ajuda a revelar por que não acho que AMP seja o caminho certo a seguir.
O que eles poderiam fazer é uma melhor detecção de recursos para determinar se os polyfils Shadow-DOM devem ser carregados ou não. Fiz esses testes usando o Chrome, que suporta o que AMP precisa. Então, em teoria, eu não deveria depender do script polyfil sendo carregado, o que permitiria que a página carregasse muito mais rápido com quase nenhum JavaScript.
Vou cobrir as fontes personalizadas em outra postagem, então certifique-se de inscreva-se para saber mais sobre essa postagem quando estiver disponível.
Mas há mais do que isso.
O Google deu um passo além e realmente hospeda seu site em seus servidores, em um domínio do Google. Isso garante que o servidor do seu site seja devidamente otimizado para servir o conteúdo o mais rápido possível. Além disso, ele usa uma rede de distribuição de conteúdo (CDN) para distribuir o conteúdo.
Finalmente, cada site é servido usando HTTPS, um requisito mínimo para a web moderna.
Existem regras adicionais para você devem aderir, todas as quais são práticas recomendadas da web ou um conjunto mínimo de requisitos que cada página da web deve implementar.
Como eles alcançam o carregamento quase instantâneo
Um dos’mágicos’partes de ter páginas AMP é que sua página carrega quase instantaneamente, se for selecionada na página de resultados de pesquisa. E essa parte é uma parte fundamental.
Em uma entrevista com Jonathan Abrams da Fortune Nuzzel se gabou do benefício do carregamento instantâneo:
Uma página é carregada em menos de meio segundo quando as Accelerated Mobile Pages do Google estão ativadas. Em vez de levar três segundos para carregar a página média.
Isso parece incrível e é claro que eu também quero. Mas como isso funciona?
Assim como os grandes mágicos, não há mágica, apenas um toque leve. E não tenho certeza se é a página de resultados de pesquisa do Google fazendo mágica ou alguma coordenação com o Chrome. Eu me inclino para o primeiro, mas agora não sei realmente.
Os resultados da pesquisa são pré-carregados enquanto você está na página de resultados. Isso é ótimo para fornecer uma experiência de carregamento de página mais rápido, mas é brutal para a largura de banda do cliente porque, para fazer isso, várias páginas devem ser carregadas com antecedência. É claro que o pesquisador provavelmente escolherá apenas um resultado.
Acho que parte da lógica aqui é que o pacote JavaScript do projeto AMP é armazenado em cache pelo navegador, portanto, não precisará fazer parte do download. E a maior parte da carga útil inicial de qualquer página AMP é o pacote de scripts do projeto AMP, que novamente pesa bem mais de 250 kb.
Se as páginas seguirem as diretrizes de AMP, a carga útil de marcação real deve caber confortavelmente no limite de 14 kb, acionando uma única conexão de URL com o servidor.
O que pode ser problemático com essa abordagem é análise distorcida porque você registraria sessões de usuário adicionais, mesmo quando eles não escolheram sua lista de pesquisa. Isso seria registrado em seus registros de servidor, não necessariamente em seu pacote de análise, se você estiver usando um pacote baseado em JavaScript, como o Google Analytics, que informa as estatísticas ao servidor por meio de uma chamada de API.
As páginas AMP também são apenas aqueles recebendo esse benefício de pré-carregamento?
Honestamente, não sei. Eu me lembro de Bing fazer algo semelhante com resultados no passado. O objetivo é ajudar a tornar a web mais rápida. Contanto que o mesmo benefício esteja sendo feito para todos os resultados, eu não tenho nenhum problema com esse recurso.
Resumo
Embora eu goste do objetivo principal do projeto AMP e aplauda por ajudar a tornar a web melhor, acho que ainda têm muito trabalho a fazer. Considere as diretrizes deles como um bom começo para aplicar as práticas recomendadas ao seu site.
Como meus amigos que usam cartas AMP, sei que você pode criar sites mais rápido sem AMP. Também estou feliz em ver o Google expandindo o tratamento preferencial para outros sites rápidos. Espero que eles implementem isso mais cedo ou mais tarde. É claro que eles precisarão fornecer diretrizes e maneiras mais claras de medir o desempenho para que você possa. Eu terei um alvo claro para atingir.
