Índice

Otimize suas páginas AMP hospedadas

Important: this documentation is not applicable to your currently selected format ads!

Este guia fornece dicas e orientações para webmasters sobre como otimizar seus sites AMP hospedados.

O AMP não é rápido por default?

O runtime AMP foi otimizado tendo a velocidade como objetivo e se suas páginas AMP forem servidas por um cache AMP, elas serão plenamente otimizadas e garantirão o melhor desempenho de carregamento. Por exemplo, se seus usuários acessam suas páginas AMP a partir da Pesquisa Google em dispositivos móveis, por default essas páginas são servidas por um cache AMP.

No entanto, nem sempre as páginas AMP são servidas a partir de um cache AMP. Um site pode decidir mostrar páginas AMP dos seus próprios servidores para outras fontes de tráfego. O caso de uso mais frequente são os sites criados totalmente em AMP, como tasty.co, onde que os usuários vão direto para o site. Outra fonte de tráfego é o Twitter, que começou a incluir links para páginas AMP em vez de fornecer a versão padrão para dispositivos móveis. Isso significa que, se um usuário clicar num link em um dos aplicativos móveis do Twitter, o link vai para a versão AMP de sua página que está na sua própria origem (se houver uma disponível).

Como resultado, nem sempre você pode ter certeza de que suas páginas AMP são servidas apenas por um cache AMP. Para esses casos, onde você serve páginas AMP a partir dos seus próprios servidores, é importante verificar se suas páginas AMP estão garantindo o desempenho de carregamento ideal.

As páginas AMP carregam rápido por default, mas existem algumas otimizações de desempenho adicionais que você pode implementar para ajudar o navegador a carregar páginas AMP ainda mais rápido. Este guia descreve algumas otimizações que você deve considerar ao publicar páginas AMP. No entanto, antes de começar a ler este guia, certifique-se de que você já abordou todas as práticas recomendadas de desempenho web fundamentais. A otimização de imagens, em particular, tem um grande impacto no desempenho de carregamento.

Por exemplo, ao aplicar as seguintes técnicas de otimização:

Carga otimizada do AMP runtime
Imagem hero pré-carregada (não houve alterações no tamanho/encoding da imagem)
Otimização de fontes personalizadas (neste caso, Google fonts)

o modelo "The Scenic" carrega dois segundos mais rápido numa conexão 3G.

Se você quiser pular os detalhes, dê uma olhada no gerador de AMP Boilerplate, que pode ser usado para gerar páginas AMP personalizadas e otimizadas.

Otimize o carregamento do AMP runtime

Embora o AMP já seja bastante restritivo sobre a marcação permitida na seção <head>, ainda há espaço para otimização. A chave é estruturar a seção <head> de uma maneira tal que todos os scripts que bloqueiam a renderização e fontes personalizadas carreguem o mais rápido possível.

Eis a ordem recomendada para a seção <head> numa página AMP:

<!doctype html>
<html ⚡ lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width">
    <meta name="description" content="This is the AMP Boilerplate.">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">
    <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <script async custom-element="amp-experiment" src="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"></script>
    <!-- Import other AMP Extensions here -->
    <style amp-custom>
      /* Add your styles here */
    </style>
    <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet">
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <link rel="canonical" href=".">
    <title>My AMP Page</title>
  </head>
  <body>
    <h1>Hello World</h1>
  </body>
</html>

Veja uma descrição passo a passo:

A primeira tag deve ser a tag meta charset, seguida por quaisquer tags meta restantes.
Em seguida, faça o pré-carregamento da tag <script> com o runtime AMP v0.js usando <link as=script href=https://cdn.ampproject.org/v0.js rel=preload>. O runtime AMP deve começar a baixar o quanto antes porque o boilerplate AMP oculta o documento através de body { visibility:hidden } até que o runtime AMP termine de carregar. O pré-carregamento do runtime AMP avisa ao navegador que faça o download do script com uma prioridade mais alta. Dê uma olhada em server-side-rendering para saber como evitar isso. {amp-img6} {/amp-img6}
Se sua página incluir extensões que provocam atraso na renderização (por exemplo, amp-experiment, amp-dynamic-css-classes, amp-story), faça o pré-carregamento dessas extensões conforme sejam requeridas pelo runtime AMP para renderizar a página.

<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-custom-css-0.1.js">
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/story-1.0.js">

Use preconnect para acelerar a conexão com outra origem onde a URL completa do recurso não seja conhecida com antecedência, por exemplo, ao usar Google Fonts:

<link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>

Carregue o tempo de execução de AMP:

<script async src="https://cdn.ampproject.org/v0.js"></script>

Especifique as tags <script> para render-delaying extensions (por exemplo, amp-experiment amp-dynamic-css-classes e amp-story
Especifique as tags <script> para as extensões restantes (por exemplo, amp-bind ...). Essas extensões não atrasam a renderização e, portanto, não devem ser pré-carregadas, pois podem consumir uma largura de banda importante para a renderização inicial.
Especifique qualquer estilo personalizado usando a tag <style amp-custom>.
Adicione quaisquer outras tags permitidas na seção <head>. Em particular, quaisquer fontes externas devem vir por último, uma vez que bloqueiam a renderização.
Finalmente, especifique o código AMP boilerplate. Ao incluir o código boilerplate por último, ele evita que estilos personalizados acidentalmente sobrescrevam as regras de boilerplate css.

O cache AMP executa todas essas otimizações automaticamente (e mais algumas). Você pode usar a ferramenta AMP Optimizer para executar automaticamente essas otimizações na sua própria origem.

Faça o carregamento prévio de imagens hero

O AMP HTML usa seu próprio elemento de imagem: amp-img. Embora amp-img tenha muitas vantagens sobre a tag HTML img tradicional, uma desvantagem é que o runtime AMP precisa estar carregado antes que o download da imagem possa começar. Para algumas imagens, como imagens hero para uma página de produto, é essencial que as imagens carreguem o mais rápido possível. Nesses casos, é melhor pré-carregar a imagem para garantir que o navegador comece a baixá-la o quanto antes e não precise aguardar até que o runtime AMP seja carregado.

<head>
  <link rel="preload" href="/images/elephants.png" as="image">
</head>
<body>
  ...
  <amp-img width="404" height="720" layout="responsive"
           src="/images/elephants.png" alt="..." >
  </amp-img>
</body>

Mas e se o seu layout responsivo exigir imagens hero diferentes dependendo da largura da tela? Por exemplo, uma imagem larga para desktop e uma imagem estreita para celular assim:

<amp-img width="404" height="720"
    alt="..." layout="responsive"
    src="/images/elephants_narrow.png"
    media="(max-width: 415px)">
</amp-img>
<amp-img height="720"
    alt="..." layout="fixed-height"
    src="/images/elephants_wide.jpg"
    media="(min-width: 416px)">
</amp-img>

Como link rel=preload também oferece suporte a media queries, podemos usar as mesmas media queries em nossas instruções de pré-carregamento, assim:

<link rel="preload" as="image"
    href="/images/elephants_narrow.png"
    media="(max-width: 415px)">
<link rel="preload" as="image"
    href="/images/elephants_wide.jpg"
    media="(min-width: 416px)">

A propósito, a mesma solução funciona para imagens de pôster amp-video:

<link rel="preload" href="/images/poster.jpg" as="image">
...
 <amp-video width="480" height="270" src="elephant.mp4"
             poster="/images/poster.jpg"
             layout="responsive">
     ...
</amp-video>

Apenas certifique-se de colocar as instruções de pré-carregamento após a declaração viewport, pois o navegador precisa das dimensões da viewport para determinar a largura da tela:

<meta name="viewport" content="width=device-width">
...
<link rel="preload" media="(max-width: 415px)" ...>

Faça pré-carregamento apenas de imagens críticas, caso contrário, o download da imagem pode ocupar a largura de banda necessária para outros downloads críticos.

Considere o uso de um service worker

Agora que todos os principais navegadores oferecem suporte a service workers, é uma boa ideia avaliar se faz sentido adicionar um service worker ao seu site.

Existem dois padrões arquitetônicos diferentes que sabemos que funcionam para navegações rápidas e confiáveis:

Para aplicativos de página única (SPA): o modelo App Shell (no contexto AMP conhecido como AMP-in-PWA). Este padrão requer um service worker para promover um documento AMP em uma experiência PWA baseada em app-shell.
Para aplicativos multi-página: streaming de recursos compostos. Um service worker armazena em cache o cabeçalho e rodapé estáticos e usa streaming para retornar instantaneamente uma resposta parcial, em cache, ao carregar o conteúdo.

Se nenhum desses padrões for usado e não for possível armazenar em cache o site inteiro (o que só é razoável para sites muito pequenos), um service worker pode ter um impacto negativo no desempenho. A melhor solução neste caso é não usar um service worker.

Porém, se você deseja que seu site seja instalável a partir da tela inicial, ou deseja oferecer uma experiência off-line, você terá que usar um service worker. Nesse caso, é importante usar o pré-carregamento de navegação para mitigar uma possível desaceleração (Observação: atualmente, o pré-carregamento de navegação é suportado apenas no Chrome).

Se seu site AMP usa um service worker, eis algumas práticas recomendadas:

Faça cacheamento prévio do AMP runtime e extensões (ex.: amp-carousel).
Faça pré-cacheamento de logotipos, fontes e outros conteúdos estáticos que seja usado na maior parte de suas páginas.
Sirva logotipos, fontes e imagens usando uma estratégia cache-first.
Sirva o runtime e as extensões AMP usando uma estratégia stale-while-revalidate.
Ao usar uma estratégia network-first para solicitações de navegação, certifique-se de habilitar navigation preload.

Se você está procurando uma maneira de começar a trabalhar com um service worker no seu site AMP, veja este exemplo que fornece um service worker que implementa todas essas práticas recomendadas.

O runtime AMP é servido com uma max-age de apenas 50 minutos para garantir que as atualizações estejam disponíveis rapidamente. Para evitar possíveis perdas de cache do navegador, é uma boa ideia servir o runtime AMP a partir de um service worker.

O pré-cacheamento não é relevante apenas para a transição de páginas AMP armazenadas em cache para páginas não AMP da sua própria origem, mas também para a transição de páginas AMP armazenadas em cache para páginas AMP da sua própria origem. O motivo é que o cache AMP reescreve as URLs do runtime AMP a partir da URL permanente para a versão mais recente lançada, por exemplo:

https://cdn.ampproject.org/v0.js -> https://cdn.ampproject.org/rtv/001515617716922/v0.js.

A consequência é que uma página AMP servida a partir da sua própria origem não se beneficia do cache do navegador e, nesse caso, precisa baixar o runtime AMP (não-versionado) novamente. Com um service worker, você pode pré-armazenar em cache o runtime AMP não-versionado e acelerar a transição. Para saber mais sobre por que o cache AMP versiona as URLs do runtime AMP, leia este documento.

No Safari, há uma diferença fundamental na forma como os service workers são implementados - não é possível, no Safari, instalar um service worker para sua origem, se a página for servida a partir de um cache AMP.

Otimize fontes personalizadas

Com o AMP, existem algumas coisas que você pode fazer para otimizar o carregamento de fontes (a maioria delas não é restrita ao AMP):

Se possível, use font-display: optional: Isso só usará a fonte se ela já estiver no cache e retornará à fonte do sistema caso a fonte personalizada ainda não tiver sido carregada.
Otimize suas fontes Web (por exemplo, sirva fontes personalizadas usando WOFF2).
Pré-carregar fontes personalizadas:

<link rel="preload" as="font" href="/bundles/app/fonts/helveticaneue-roman-webfont.woff2" >

Se você estiver usando fontes do Google ou qualquer outro provedor de fontes com URLs de fontes desconhecidas, conecte previamente o servidor de fontes correspondente:

 <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>

Por último, mas não menos importante, tente minimizar o número de fontes personalizadas que você usa na sua página. Se possível, use as fontes do sistema em vez de fontes personalizadas, porque as fontes do sistema fazem com que seu site corresponda ao sistema operacional do usuário e ajuda a evitar o carregamento de mais recursos.

Layouts AMP renderizados no servidor

A renderização de layouts AMP no servidor é uma técnica que caches AMP usam para acelerar ainda mais o tempo de carregamento. Com a renderização do lado do servidor, é possível remover o bolierplate AMP para que o documento AMP possa ser renderizado sem executar o JavaScript do runtime AMP. Por exemplo, a versão do AMP Boilerplate Generator renderizada no servidor renderiza duas vezes mais rapidamente que a versão AMP normal!

Se você estiver publicando uma página AMP, com certeza deve considerar o uso do AMP Optimizer. O AMP Optimizer permite que você sirva páginas AMP otimizadas a partir do seu próprio back-end, que inclui a renderização de layouts AMP no servidor. O AMP Optimizer também executa automaticamente várias outras otimizações descritas neste documento.

Otimizações básicas

É claro que todos os princípios básicos para otimizações de desempenho da Web também se aplicam às páginas AMP:

Otimize imagens e vídeos. A otimização de imagens pode ter um grande impacto no desempenho do carregamento.
Comprima e minifique o CSS e o HTML. Como todo o CSS nas páginas AMP são inline, vale a pena usar algo como purifycss para eliminar o CSS não utilizado.
Use HTTP Caching
... e mais

Written by @sebastianbenz