Projeto AMP: Seus Sites Ficarão Mais Rápidos?

Desde 24 de Fevereiro, resultados do Google começaram a incluir links para versões de páginas móveis criadas usando Páginas Mobile Aceleradas (AMP), um projeto de código aberto que ele suporta. AMP tem o objetivo de tornar sites móveis carregarem mais rápido e darem uma experiência de usuário melhor.

Google e o Projeto AMP tem impulsionado a adoção de AMP pela web e já estão indo bem. Automattic adicionou suporte ao AMP no WordPress.com, Pinterest está se AMPficando também, Twitter é outro, além de Chartbeat, Parse.ly, Adobe Analytics & LinkedIn e vemos versões do AMP aparecendo em sites populares como Wall Street Journal, Buzzfeed, The Guardian, BBC News, The New York Times e muitos outros.

O motivo de toda essas empresas adotarem é simples: velocidade de carga. Não há o que discutir sobre sites rápidos serem melhores, logo, nesse artigo, não pregaremos nem mostraremos os motivos para ter um site rápido. Evitaremos, também, não focar muito em informações que encontramos facilmente ao visitar o site do Projeto AMP ou assistindo o vídeo promocional deles.

Ao invés disso, explicaremos direto o que AMP significa para nós ao codificar nossos sites. Veremos de forma simples o será requerido para usa AMP na prática, quais os potenciais benefícios e problemas e, mais importante, se ele torna sites mais rápido ou não.

Por Que Deveríamos nos Importar?

Para ser sincero, porque é o Google. Assim como a maioria das coisas relacionadas ao Google, é interessante ficar atualizado sempre já que nunca saberemos quando ou como nova tecnologia influenciará a performance de sites em mecanismos de busca. É provável que sites usando AMP virem a norma dos requisitos de velocidade e performance esperados pelo Google se queremos ir bem nos rankins de buscas.

Como dito por Richard Gingras, Diretor Senior de Notícias e Produtos Sociais do Google, ao falar sobre AMP:

"...Se tivermos dois artigos que seus fatores pontuam o mesmo em todas as características exceto velocidade, então, sim, daremos maior relevância ao mais veloz..."

Logo, se não planejamos usar AMP, é interessante dar uma olhada de qualquer forma, além de garantir que nossos sites móveis estão otimizados equiparadamente.

O Destaque ⚡  nos Resultados de Busca

Por hora, sites com AMP são listados nos resultados de busca com um pequeno raio destacando-os. Não é preciso dizer que isso fará esses sites se destacarem mais que os outros.

Apenas grandes sites de notícias serão destacados dessa forma? É muito cedo para dizer. Mas pode ser um fator que valhar a pena ficar de olho.

Usar AMP Fará Nossos Sites Mais Rápidos?

Eis a resposta mais sincera: provavelmente sim, mas não necessariamente.

O ponto é que a pergunta correta a se fazer é: "Mais rápido que o que?"

Mais rápido que sites lotados de mídia com otimizações padrões? Provavelmente.

Mais rápido que usar um estilo minimalista de design e otimização avançada? Não necessariamente.

A verdade é que o AMP não é milagroso. Não é um novo tipo de HTML (como alguns o descrevem) ou uma tecnologia nunca vista antes que, com certeza, fará nossos sites mais rápidos. Nas palavras do próprio Google:

"...criado inteiramente com tecnologias existentes, permitindo sites criarem páginas mais leves".

Se sabemos tudo sobre otimização de ponta e temos um alto conhecimento técnico para fazer sites carregarem muito rápido, AMP não ajudará. Na verdade, é possível que vejamos perda de velocidade em alguns casos, embora isso possa mudar com a evolução do projeto.

AMP não é perfeito, algo para ajustar tudo nem se propõe a isso. Paul Bakaus, Defensor e Desenvolvedor do Chrome e Web Livre no Google, diz em sua apresentação sobre AMP:

"Claro, se você cria seu próprio site e sabe o que está fazendo e é ótimo e rapido e tudo mais, AMP não tornará seu site melhor. Sendo direto, não ajudará seu site a melhorar".

O AMP é uma coleção de técnicas de otimizações relativamente complexas agrupadas para conveniência, de forma que não precisamos pensar sobre todas as partes por trás dos panos. Ele nos dá um conjunto de regras estritas que, se seguirmos, teremos sites mais rápidos que os que não estão otimizados ou não são otimizados no mesmo nível.

Ao mesmo tempo, porém, se preferirmos fazer tudo manualmente, podemos criar nossas próprias técnicas equivalentes sem usar AMP. Utilizar AMP, por hora, não é essencial - mas saber como otimizar a um nível equivalente ao dele logo será.

Vejamos mais a fundo o que o AMP é, como funciona e vejamos resultados de teste de busca, então revisitemos a pergunta "Nosso site ficará mais rápido?" ao final do artigo.

O Que AMP É para o Desenvolvedor

AMP é descrito, oficialmente, como a combinação de três coisas: AMP HTML, AMP JS e AMP CDN. Isso será, independente de qual perspectiva de desenvolvedor que tivermos, as coisas mais pertinentes ao programar:

1. Boas práticas do AMP para codificação
2. Elementos HTML customizados do AMP
3. Validação do AMP verificando os dois itens acimas

Em resumo, começaremos um documento AMP copiando e colando o código que encontramos na página exemplo da documentação. De lá, começamos a preencher as páginas usando os três itens da lista, todos alimentados pelo AMP HTML e AMP JS.

Nota: a AMP CDN pode ser usada automaticamente e de graça por usuários AMP, contudo, é possível fazê-lo usando qualquer outra CDN, como a CloudFlare. Por conta disso e pelo fato da CDN não ser parte do processo de codificação, deixei-a fora da lista dos 3 itens pertinentes para desenvolvedores.

Permita-me resumir cada uma das três.

1. Regras do AMP para CSS, HTML e JS

Para começar, há regras para se trabalhar com AMP que ajudam a otimizar qualquer página, então, é importante familiar-se com elas, trabalhando ou não com AMP. Ela são bem estritias e há algumas coisas que já estamos acostumados a fazer que não poderemos usar, então, preparemo-nos para achar o código um pouco estranho.

Por exemplo, todo o CSS deve estar contido em linha, dentro do head, envolvido nas tags <style amp-custom>...</style> - nada de vincular folhas de estilo externas.. É provável que não escreveremos nosso CSS direto no HTML, então é bom usar algo como as inclusões do Jade ou usar algum mecanismo de retorno (via PHP, por exemplo) do conteúdo da folha de estilo em linha.

Nosso CSS também não pode ser maior que 50kb. Para ter uma ideia, a versão padrão minificada do CSS do Bootstrap, sem temas, é 121kb. Um tema adicionaria algo em torno de 23kb, chegando a 144kb, quase 3 vezes o total permitido. Então, é bom sermos capaz de usar código de estilização de forma eficiente.

Além disso, há seletores CSS proibidos, como o *, então, nada de usar  * { box-sizing: border-box } para controlar o espaçamento do site. Da mesma forma, há elementos HTML proibidos, como o base, frame e embed, além de alguns outros. Suporte a formulários está em desenvolvimento, logo, por hora, também não se pode usar o elemento form ou qualquer elemento de entrada.

Podemos carregar fontes web externas, apenas do Google Fonts ou Fonts.com, através do https://fonts.googleapis.com e https://fast.fonts.net, respectivamente.

Para uma descrição completa do que pode ou não no CSS e HTML, podemos ver a Especificação HTML do AMP.

A "grande regra" do AMP é não ter qualquer tipo de JavaScript customizado. Se gostamos de usar JavaScript em menus responsivos ou qualquer outra coisa, estamos sem sorte e teremos de buscar outra forma. Contudo, isso é contra-balanceado pela presença de componentes próprios do AMP, como janela suspensa (lightbox) e carossel, entre outros, o que nos leva à próxima seção: elementos customizados.

2. Elementos HTML Customizados

AMP traz um conjunto de elementos HTML customizados para mídia, com prefixos amp-. Há componentes que substituem elementos HTML e alguns outros que trazem funcionalidades que, geralmente, precisaríamos usar JavaScript para tê-las.

Elementos padrão como img, video, audio e iframe são substituidos pelos amp-img, amp-video, amp-audio e amp-iframe, respectivamente.

Também há vários elementos criados para embutir conteúdo de terceiros, como o amp-ad, amp-analytics, amp-pinterest, amp-twitter e amp-youtube.

E, por fim, há aqueles que trazem novas funcionalidades como o amp-lightbox, amp-carousel e amp-anim.

Veja a especificação dos Componentes AMP para mais.

Os elementos do AMP estão lá para duas coisas:

1. Garantir código otimizado
2. Facilitar priorização de carga e otimização

Mencionamos antes que os três aspectos mais pertinentes do AMP par desenvolvedores são suas boas práticas, elementos customizados e validador para garantir tudo.  Com isso em mente e dada a possibilidade de seguir a boas práticas usando ou não o AMP, achamos que o determinante se um site deve ou não usar o AMP é o nível de elementos customizados a ser usado.

Se um site usá-los frequentemente, é provável que o AMP ajudará na carga rápida e eficiente de mídia.

Se um site usá-los com menos frequência, os resultados podem ser tão bons mesmo deixando AMP fora da questão, apenas implementando as boas práticas sem ele.

Um ponto a se verificar se o AMP trará aprimoramentos ou não é o fato do JavaScript necessário ter 44kb. Assim, é preciso ter muita mídia na página para o AMP coordenar o carregamento eficiente e compensar sua adição (na forma de 44kb) e gerar as vantagens prometidas. Alguns elementos customizados, como os do Twitter e YouTube, requerem scripts adicionais para serem carregados.

No nossos testes, o script do AMP carrega entre 779ms - 932ms em uma conexão 3G simulada de 750kbps, o do Twitter entre 367ms - 468ms e do YouTube entre 318ms e 386ms.

Importância do Elemento amp-ad

Uma das grandes razões do projeto AMP existir é dar a editores uma forma de montizar seus sites através de propaganda que não seja lenta ou ofensiva aos visitantes.

O projeto AMP tenta eliminar experiências como ter de esperar cinco segundos na carga de um site e ver uma propaganda tela cheia bloqueando o artigo. Ou de tentar ler um texto e não poder ver algo porque há um banner gigante tomando quatro quintos do espaço disponível.

Contudo, eles tentam acabar com essas situações possibilitando editores ainda possam ganhar dinheiro suficiente através das propagandas que suportam seu negócio. É aqui que o elemento amp-ad entra em jogo.

O elemento <amp-ad>...</amp-ad> parece estranha por fora, mas é uma forma unificada e performática de mostrar propaganda de uma lista grande provedores:

• A9
• Adform
• AdReactor
• AdSense
• AdTech
• Dot and Media
• Doubleclick
• Flite
• plista
• Smart AdServer
• Yieldmo
• Revcontent

Se propagandas são a maior parte dos nossos sites, vale a pena chegar o AMP só pelo elemento amp-ad.

Para maiores informações em como usá-lo, viste: https://www.ampproject.org/docs/reference/amp-ad.html

3. Validação

O validador AMP existe para garantir que usamos as regras do AMP. Ele dirá se criamos código que não se encaixa nas boas práticas e se usamos elementos nativos que deveriam ser trocados pelos customizados.

Ao começar a trabalhar numa página AMP, usar o validador é questão de adicionar #development=1 ao final da URL de pré-visualização e ver o console nas Ferramentas de Desenvolvedores do Chrome.

Se fizermos algo errado, o validador nos informará.

Especialmente por codificar para AMP requerer ajustes é uma boa ideia manter o validador aberto o tempo todo para vermos quaisquer erros na hora que aparecerem.

Como AMP Gera Velocidade

A melhor explicação dos por menores técnicos dos métodos de otimização do AMP pode ser lido no blog oficial. Contudo, prometemos uma versão em português, então aqui está:

Código Que Não Está Lá

Boa parte do porque as páginas AMP serem mais rápidas é pelo código que não está lá.

Não há CSS maior que 50kb e ele não precisa da sua própria requisição http pra ser carregada. Não temos certo CSS nem certo HTML. Não temos que escrever nosso próprio JavaScript o que significa que não temos janelas modais, abas, dicas e alertas em JavaScript. E acima de tudo, não temos códigos para cinco provedores de propaganda e três serviços de relatórios diferentes.

A inexistência desses elementos já nos dá muita vantagem. Código que não existe não atrasa nosso site. Claro, não precisamos do AMP para remover código, então é importante manter iso em mente, usando AMP ou não.

Priorização de Carga e Otimização

Já falamos dos elementos customizados do AMP e do fato deles facilitarem a priorização de carga e otimização.

Como isso acontece na prática é quando chegamos a uma página com AMP, a mídia visível na tela ("acima da dobra"), carregará primeiro, permitindo o início da visualização e o resto da mídia é carregada depois disso. Há casos, também, onde uma página pode ser carregada antes de um usuário navegar para ela, parecendo instantânea.

Isso tudo acontece através de algumas técnicas, incluindo carga sob demanda, pré-renderização, pré-conexão e pré-busca. Podemos implementar esses métodos por conta própria se não usarmos o AMP. No artigo do blog do AMP mencionado antes, temos:

"Toda página web pode ter essas otimização, mas o AMP não podem não tê-las. Embora o artigo seja sobre otimizações no AMP, também pode ser uma espécie de lista de otimização para sites não-AMP".

No fim, é bom ver como o AMP lida com carregamento para termos novas ideias do que podemos fazer em nossos sites.

Eficiência de Layout

Toda mídia adicionada a uma página AMP deve ter altura e largura definidas. Isso significa que embora seja possível ter elementos dimensionáveis e responsivos, AMP saberá como posicioná-los antes da mídia ser carregada. Isso evita que tenhamos de esperar a carga da imagem para então recalcular a estrutura da página, economizando tempo de renderização no processo.

Alguns Testes de Velocidade

Se tivermos seguindo todo o bafafá sobre o AMP, é possível ter visto que o Google compartilhou os resultados de testes com parceiros beta, com taxas de até 85% de aprimoramento. Pinterest usou recentemente e viu que "páginas AMP carregam 4x mais rápida e usam 8x menos dados que uma página móvel tradicional e otimizada".

São números muito significativos, e fomos atrás dos porquês dessas diferenças de velocidades. Como mencionado antes, a questão é "Mais rápido que?"

Para descobrir, começamos do zero, com nada além do código base provido pela documentação do AMP e uma página HTML básica equivalente. Queríamos ver o que aconteceria se adicionássemos conteúdo a uma página via AMP e n'outra como de costume.

Nos testes, usamos a Ferramenta de Desenvolvedores do Chrome para emular um iPhone 6 com 3G "padrão" de 750kb/s. Nos testes do Google foi basicamente o mesmo, mas com "conexão 3G simulada e um aparelho Nexus 5".

Repetimos os testes diversas vezes para remover qualquer problema aleatório causando carregamento lento. Nos resultados, mostramos os menores valores de cada teste. Eles usaram o método de recarda de página "Cache Limpo e Recarga Bruta" para simular chegada na página pela primeira vez.

Teste 1: Image Única

Primeiro, começamos simples, com uma imagem de 500kb (do Unsplash) em cada página.

Resultados

• AMP: 6.23 segundos
• Normal: 5.48 segundos

Nesse teste, o AMP foi um pouco mais devagar e se olharmos o painel de rede nas capturas de tela, veremos que foi pela carga do AMP JS e um tamanho um pouco maior do HTML. O tamanho maior do HTML é pela necessidade de adicionar CSS para prevenir o FOUT (lampejo de texto não estilizado) enquanto o AMP JS faz seu processamento.

Nota: No primeiro teste, mostramos uma captura de tela da página toda para ver a configuração usada. Nos próximos, apenas descreveremos o que fizemos e mostraremos o painel de rede, caso contrário seriam muitas imagens grandes pra serem carregadas.

Teste 2: Duas Imagens

Sabíamos que a ideia do AMP começaria a funcionar com mais mídia. Assim, no segundo teste, adicionamos outra imagem de 500kb.

Resultados

• AMP: 11.14 segundos
• Normal: 10.44 segundos

De novo, o AMP foi um pouco mais devagar, pelo mesmo motivo.

Teste 3: Cinco Imagens

Até agora, a marcação e JS extras tem feito o AMP ficar um pouco para trás, mas agora seria a hora de ver o efeito da priorização de carga do AMP, onde o conteúdo abaixo da dobra é adiado. Dessa vez, usamos mais três imagens de 500kb, totalizando cinco.

Resultados

• AMP: 16.14 segundos
• Normal: 26.08 segundos

Aqui vemos o salto do AMP e por uma grande margem. Se olharmos atentamente o gráfico de rede da carga do AMP, veremos que ele carregas as três primeiras imagens em 16.14s e permite o usuário começar a navegar. Ele carrega as duas iamgens restantes após isso, onde podemos ver por volta da marca dos 22 e 34 segundos.

Na versão normal, por outro lado, todas as cinco imagens tem de ser carregadas, levando 26.08s.

Teste 4: Cinco Imagens Com Rolagem de Página

Nesse teste, queremos ver como AMP se compara quando a página é rolada durante o carregamento, algo que a maioria dos visitantes fazem de tempos em tempos.

Resultados

• AMP: 26.87 segundos
• Normal: 26.09 segundos

Nesse teste, rolar a página preveniu qualquer conteúdo ser visto como acima da dobra, trazendo o tempo de carga ao mesmo patamar que a versão normal. A versão normal, como esperado, não alterou o tempo ao rolar a barra durante o carregamento.

Teste 5: Cinco Imagens Com Script de Carga Sob Demanda

Como a vantade de velocidade do AMP no "Teste 2" vinha de uma técnica de carga sob demanda, queríamos ver como competiria contra um script de funcionalidade semelhante. Para testar isso, carregamos o jQuery e o plugin Lazy Load, ambos minificados, na versão normal do HTML, e configuramos o Lazy Load com valores padrão.

Resultados

• AMP: 16.14 segundos
• Normal: 6.59 segundos

Como esperado, a velocidade do AMP foi o mesmo no "Teste 2". A página normal, por outro lado, caiu de 26.08s para 6.59s com o script Lazy Load.

Vale notar aqui que, com a configuração padrão, o Lazy Load apenas baixou a primeira imagem, aquela visível na área de exibição. AMP, por outro lado, também carregou as outras duas que ele achou que veríamos.

Teste 6: Mudança de Limite de Carga Sob Demanda

Para deixar as comparações próximas, garantimos que o Lazy Load carregasse as três primeiras imagens, como o AMP. Então, mudamos a propriedade threshold do script para 1400, informando que qualquer imagem até 1400px também carregaria, fazendo o script carregar as três primeiras.

Resultados

• AMP: 16.14 segundos
• Normal: 16.51 Segundos

Aqui, ambas as páginas carregas três imagens e o AMP saiu na frente por uma margem pequena.

Carregar o mesmo número de imagens deixou ambos parecidos, mostrando que uma abordagem não é muito melhor que a outra, embora tivemos de configurar a versão com jQuery e a do AMP foi automatizada.

Teste 7: Embutidos do Twitter e YouTube

Nesse teste, queríamos ver como os elementos customizados amp-twitter e amp-youtube se sairiam se comparados a códigos embutidos para cada serviço. Embutimos um vídeo e um tweet em cada página, usando cada método.

Resultados

• AMP: 11.22 segundos
• Normal: 9.56 segundos

Nesse teste, os elementos customizados do AMP ficaram um pouco para trás. Contudo, não empilhamos vários vídeos e tweets para ver o poder de priorização do AMP em prática.

Com imagens, vimos ganhos apenas quando havia conteúdo suficiente na página para a priorização ajudar, então deve ser o mesmo con vídeos do YouTube e Tweets.

Teste 8: AMP CDN vs GitHub

O próximo teste foi o ganho potencial em velocidade ao ter as página com cinco imagens usada no "Teste 3" servida da AMP CDN.

Se quisermos testar qualquer página AMP online para ver como se sai servida da CDN basta usar cdn.ampproject.rg/c/ antes da URL ou cdn.ampproject.org/c/s/ se for carregada via https. Por exemplo:

• http://myampsite.com → http://cdn.ampproject.org/c/myampsite.com
• https://myampsite.com → https://cdn.ampproject.org/c/s/myampsite.com

A forma que a CDN funciona na prática e a versão padrão da página incluindo um link para a versão AMP no cabeçalho. Google seguirá o link e ao reconhecer a nova página como um site AMP, salva-la-á na AMP CDN automaticamente.

Ao testar a AMP CDN por conta própria, tenhamos certeza de permitir uma tempo maior na primeira vez para ser salva e só então acessemos diversas outras vezes.

Hospedamos nossa página no GitHub e então adicionamos uma versão carregada pela AMP CDN. A comparação no tempo, ainda simulando uma conexão 3G num iPhone, é a seguinte:

Resultados

• AMP via CDN: 16.71 segundos
• AMP via GitHub: 16.50 segundos

Os dois resultados foram, basicamente, os mesmos com o GitHub servido 1/5 de segund mais rápido.

Teste 9: AMP CDN vs Servidor Próprio

Não tínhamos certeza se o GitHub estava fazendo alguma mágica para servir as páginas tão rápido quando a AMP CDN então testamos contra uma hospedagem pessoal que sabíamos não ter qualquer otimização de carga especial.

Resultados

• AMP via CDN: 17.28 segundos
• AMP via Servidor Próprio: 16.33 segundos

Nossa hospedagem pessoal, incrivelmente, serviu a página tão rápido quanto a CDN. Nesse teste, a CDN fez foi diminuir um pouco, indo a 17s.

Infelizmente, não pudemos criar um teste onde a AMP CDN serviu uma página mais rápida. Contudo, ao morar na Austrália e longe de cidades grandes tenha influenciado tudo. Os resultados podem variar.

Teste 10: The Guardian Antes e Depois do AMP

Todos os testes até agora, usamos páginas quase sem CSS, puras. Mas não é assim que design funciona, certo? Trabalhamos duro para estilizar e estruturar, colocamos um pouco de JavaScript para funcionalidades e, não menos que desejado, acabamos usando mais código que o necessário.

Adicionalmente, executar testes com conteúdo básico não é o mesmo que testar sites completos com conteúdo real e online. Nesse contexto, indiscutivelmente, o teste de verdade vem da comparação entre antes e depois do uso do AMP.

O que fizemos, então, foi usar um artigo do The Guardian. Primeiro, testamos a versão HTML normal do artigo e depois a versão AMP do mesmo artigo.

Resultados

• Antes do AMP: 5.05 segundos
• Depois do AMP: 3.87 segundos

Aqui, começamos a ver melhorar significativas entre versão pré e pós AMP, cortando 1.18s de carga. Uma melhora de 23%. Muito bom!

Teste 11: BBC News Antes e Depois do AMP

O próximo teste, o último que falaremos, comparamos uma página de notícia da BBC normal com a AMP. Assim como no teste do The Guardian, o mesmo artigo foi testado em ambos os formatos.

Resultados

• Antes do AMP: 20.44 segundos
• Depois do AMP: 2.74 segundos

Agora, sim! Essa melhora em velocidade é extrama. Saindo de 20.44s para 2.74s é um pouco mais que os 85% de melhora dos testes AMP iniciais. Na verdade são 86% de melhora.

Veja bem as capturas de tela, particularmente os gráficos mostrando a carga de cada recurso com barras horizontais verde/vermelha/azul. O número de recursos carregados na versão pré AMP é louco. Comparando com a versão pós AMP, o número de recursos melhorou demais. Não por acaso a otimização foi capaz de criar tanta melhora.

Eis duas dúvidas que surgiram.

1) Seria possível essa otimização sem AMP? Sim, é provável que sim.

2) Seria possível alcançar esse nível de otimização sem AMP? Não, é bem provável que não.

Fora do teste controlado, em uma empresa real, desenvolvedores querem otimizar sites em produção mas podem não conseguir por conta dos colegas que precisam focar em montização e relatórios. Ambas os lados tem de fazer seus trabalhos e talvez não consiga encontrar um meio termo.

É aí que a AMP busca entrar e preencher esse vazio. Ela cria um framework estrito de otimização que precisa ser aderido se quisermos a aprovação do AMP, o que faz os desenvolvedores felizes. Mas também proveem motização, relatórios e possível maior exposição do Google integrada, fazendo a pessoa responsável pelo fluxo de capital feliz.

Se somos desenvolvedores nessa situação, esses resultados sugerem que o AMP é o remédio.

E Agora, O AMP Tornará Meus Sites Mais Rápidos?

Vimos muita coisa nesse artigo, tudo para descobrir se, no fim do dia, o AMP fará nossos sites mais rápidos. A resposta, parece, depende não apenas nos detalhes técnicos do site, mas também nas necessidades práticas dos negócios que ele suporta.

Se tomamos todas as decisões sobre como os sites são feitos, AMP torna-los-á mais rápidos se:

• Usarmos muita mídia para nos beneficiarmos dos processos de carga otimizados.
  
• Se preferirmos que o AMP guia nosso processo de otimização ao invés de colocar mãos na massa.

Ao mesmo tempo, se for nossa decisão otimizar os sites do jeito que quisermos, podemos obter resultados tão bons ou melhores ao usar nossos próprios métodos, desde que sejam comparáveis ao que o AMP faz.

Se não tomamos todas as decisões sobre como os sites são construídos, AMP ajudará a tornar os sites mais rápidos se:

• Ele ajudar a convencer colegas de trabalho a aprovar sua implementação, assim, dando a possibilidade de aplicar técnicas que não teríamos sinal verde.

Acredito que o ponto chave é que o AMP em si não é rápido - essa é a forma errada de se ver.

AMP dá-nos um método para deixar sites rápidos.

Não precisamos, necessariamente, usar esse método, mas se quisermos uma abordagem convicente ou uma que colegas aceitem, AMP pode ser a escolha certa.

Resumindo

AMP ainda é bem novo, então é bom ficar de olho em sua evolução. O que isso significa para nossas rankings em buscas pode mudar a qualquer momento, assim como os requerimentos de uso do AMP ou sua performance.

Nos testes que fizemos, AMP foi um pouco mais lento em algumas circunstânias, mas com o avanço do projeto, cremos que ele ficará mais eficiente e os resultados serão masi relevantes. Ao mesmo tempo, fora dos testes controlados, ficou claro que sites grandes que usam AMP tiveram ganhos de performance enormes.

Sinto que, usando ou não AMP, todo devemos ficar de olho. É um recurso muito bom, no mínimo, para ideias para desenvolvedores em como aprimorar sua otimização de sites.

Com o lançamento das páginas AMP nos resultados de busca do Google, será bem interessante ver o feedback dos vanguardistas do AMP. O motivo disso é que eles apenas continuarão usando AMP se os resultados forem de maior retenção de tráfego e receita. O que sair disso pode ser a alavanca ou o martelo do AMP.

Até lá, o grande aprendizado do surgimento do AMP é que a otimização de sites, nesse nível, é possível e será cada vez mais importante. Os dias das folhas de estilo carregadas e JavaScript excessivo, sem mencionar a propaganda, pode está com os dias contados, assim como apresnetações animadas em Flash.

E isso é algo que podemos ficar felizmente.

Links Relacionados

• Introdução ao Projeto Páginas Móveis Aceleradas, no blog oficial do Google
• www.ampproject.org
• Projeto AMP no GitHub
• Plugin para WordPress do AMP
• Páginas Móveis Aceleradas (AMP) para WordPress na Envato Market