Lighthouse para quem não conhece ele é o sistema de auditorias de performance, accessibilidade, SEO e PWA dentro do Chrome Dev tools. Também com a possibilidade de instalação no firefox através de extensão e com NPM.
Nesse mês de maio foi anunciado a versão 6.0 do Lighthouse, que estará disponível na versão 84 do Chrome. Essa nova versão contém as seguintes melhorias:
Novas métricas
Atualização da pontuação referente a performance
Novas auditoria sobre JavaScript não utilizado e Acessibilidade
Atualização no Lighthouse CI
Agora a aba Audits mudou para Lighthouse
Mudanças na emulação mobile
Performance Budget
Novas métricas
Largest Contentful Paint(LCP)
Maior pintura com conteúdo é uma medida da experiência de carregamento percebida. Ele marca o ponto durante o carregamento da página quando o conteúdo principal foi carregado e é visível para o usuário. O LCP é um complemento importante para First Contentful Paint(FCP), que captura apenas o início da experiência de carregamento.
Cumulative Layout Shift (CLS)
Deslocamento cumulativo de layout é uma medida da estabilidade visual. Quantifica quanto o conteúdo de uma página muda visualmente. Uma pontuação baixa no CLS é um sinal para os desenvolvedores de que seus usuários não estão passando por mudanças indevidas de conteúdo.
Total Blocking Time(TBT)
Tempo total de bloqueio quantifica a capacidade de resposta de carga, medindo a quantidade total de tempo em que o encadeamento principal foi bloqueado por tempo suficiente para impedir a capacidade de resposta da entrada. O TBT mede a quantidade total de tempo entre a FCP e tempo de interação.
Atualização de pontuação de Performance
A pontuação de performance é baseado nas seguintes métricas:
First Contentful Paint – 15%
Speed Index – 15%
Lagest Contentful Paint – 25%
Time to Interactive – 15%
Total Blocking – 25%
Cumulative Layout Shift – 5%
Lighthouse CI
No último Chrome Dev Summit foi anunciado o Lighthouse CI, um CLI em node de código aberto que realiza auditoria trazendo os resultados do Lighthouse para terminal de linha de comando. Agora Lighthouse tem suporte nativo de vários provedores de integração continua(CI), incluindo Travis, Circle, Gitlab e Github actions.
Para instalar o lighthouse CLI em seu terminal de linha de comando execute o seguinte código:
npm install -g lighthouse
Depois de instalado você pode realizar auditorias rodando o seguinte comado:
No post anterior falei sobre plugins de performance para WordPress, agora chegou a hora de falar de outro plugin relacionado a performance o Plugin do AMP para WordPress.
Assistindo conteúdo sobre WP no YouTube, por muitas vezes o plugin é vendido como plugin para deixar o WordPress rápido. Mas como isso é possível?
AMP é uma biblioteca que roda no front-end, ela foca na entrega do conteúdo e na experiência do usuário, ele possui três ferramentas cruciais para melhoria do desempenho:
AMP JS – Possui uma série de melhorias relacionadas a performance com tree shaking e lazy loading.
AMP HTML – Uma biblioteca de componentes HTML, como, slideshow, light-box, menu slideshow, player de vídeo entre outros.
AMP Cache – Esse item é ativado quando sua aplicação possui código AMP válido.
Umas das condições do plugin AMP é liberar a renderização de conteúdo não permitir que scripts terceiros aumentem o tempo de exibição do conteúdo da sua página.
Um bom exemplo de bloqueio da renderização de nossa página é a utilização embed de vídeos do YouTube quando criei o curso de PWA decidi criar uma página com todos os vídeos, inclui 17 embeds em uma mesma página, e o resultado foi o seguinte:
Auditoria de desempenho utilizando chrome devtools
Nos testes realizados na versão semAMP:
Primeira impressão de conteúdo é realizada em 3.4 segundos
O tempo de interação vai para 29.9 segundos isso significa que um usuário irá levar 30 segundos para interagir com o conteúdo.
O principal problema é causado por conta das várias requisições feita por múltiplos embeds do Youtube, por conta de rodarem um um iframe eles não conversam entre si acabam requisitando os mesmo scripts diversas vezes.
requisições realizadas pela página sem o plugin AMP
Como podemos ver na imagem acima temos varias requisições para o mesmo arquivo JavaScript totalizando 45 requisições, essas requisições aumentam o tamanho total da página, além de todas essas requisições serem disparadas ao mesmo tempo, assim impossibilitando o usuário de interagir com a página.
Quando ativamos o plugin AMP para mesma página temos o seguinte resultado.
Teste performance realizado como o plugin AMP ativo
Como podemos ver temos uma redução no tempo de carregamento e uma melhor na pontuação referente a performance
Primeira impressão de conteúdo é realizada em 2,8 segundos
O tempo de interação 5 segundo, essa foi a redução mais significativa.
Isso ocorre porque AMP passa a gerenciar esses recursos, como por exemplo conteúdo “embedado”agora o número de requisições JavaScript cai para 15 arquivos:
Requisições JavaScript feitas com o plugin ativo.
Além da redução do tempo de carregamento também temos a redução de transferências de arquivos de 2.2mb para 1.2mb. Essa comparação mostra um dos benefícios de se trabalhar com a biblioteca. Mas antes de sair ativando o plugin precisamos entender como ele funciona.
O plugin
Quando foi lançado em 2016, o AMP teve seu primeiro plugin criado por uma parceria entro Google e Automattic, o plugin era bem experimental. Nessa época outros plugins criados pela comunidade ofereciam muito mais recursos. Por muito tempo utilizei plugins criados pela comunidade.
Em 2019, visitando o stand do Google no WordCamp Europe tive a possibilidade de ver o trabalho feito pelo Google para reativar o plugin do AMP. Era visível nos últimos 2 anos uma movimentação do Google para contribuir com a comunidade WP.
Depois dos primeiros testes vi que as melhorias eram significativas comparado a última vez que tinha o utilizado o plugin. Os testes foram realizados utilizando o modo Padrão. Para entender mais o Plugin AMP funciona ele possui três modos:
Leitor(2016): Onde o usuário tem uma versão mais simples todas as páginas amp serão redirecionadas para uma nova url com /amp no final e o plugin irá gerenciar todos os erros de validação.
Transição: O plugin delega ao administrador do conteúdo a escolha de quais as páginas serão exibidas como AMP e não-AMP. O visual segue o mesmo visual do seu tema WordPress.
Padrão: Nessa modo sua aplicação irá tornar full AMP. Onde todo o conteúdo da sua aplicação irá utilizar somente em uma versão AMP.
Após ativar o plugin, acessamos no menu lateral do painel de controle da sua aplicação WordPress você irá encontrar a opção AMP.
Acessando o painel do plugin iremos ver as seguinte opções:
tela principal do plugin AMP
Inicialmente temos um banner de boas vindas, em seguida temos duas opções de experiência AMP website e AMP Stories.
AMP Website: irá habilitar AMP em sua aplicação, após a seleção dessa opção temos a opção de escolher qual template iremos utilizar
AMP Stories: vou dedicar um post para essa sessão mas uma breve introdução stories foi incluído recentemente na plataforma com ele temos a opção de adicionar chamadas aos nossos posts com animações. Caso queira saber mais confira a documentação oficial do AMP Stories.
painel com opções de templates
Como havia mencionado anteriormente, na tela principal do plugin temos a opção de selecionar os templates que iremos utilizar em nossa aplicação. Caso escolha o modo leitor, as páginas e posts que utilizam AMP terão as páginas corrigidas para AMP, automaticamente. É a versão que não requer nenhuma ação por parte do administrador mas sua experiência é bem simple.
Validação de conteúdo AMP
As versões de Transição e Padrão precisam de uma ação do administrador para obter um conteúdo válido AMP. Porque essas versões tentarão ser idêntica a versão não AMP. Para isso o processo de validação precisa ser direcionado pelo administrador da aplicação.
Mas qual a importância de ter um conteúdo válido AMP? Primeiro por uma questão de boas práticas manter a qualidade do código de sua aplicação e Segundo todo conteúdo válido pode fazer uso do AMP Cache.
AMP Cache é recurso disponibilizado por motores de busca como Google e Bing que melhora ainda mais a performance da sua aplicação os resultados vindo dos motores de busca serão servidos pelo AMP cache.
Primeiro item para obter o conteúdo AMP válido é ter um tema compatível, no meu caso que utilizo o Twenty Twenty não precisei realizar nenhuma alteração em meu tema. Segundo passo foi resolver os problemas de compatibilidade com plugins.
Podemos fazer a validação por dois caminhos por índice de erros ou por página. No meu caso não utilizo muitos plugins, apenas um plugin para exibir os códigos dos tutoriais no meu blog, o plugin não era compatível com AMP assim causando problemas de validação, como podemos ver na imagem abaixo:
Substitui pelo plugin Syntax-hightlighting Code block e resolvi o problema referentes a plugin. Caso isso não seja possível você pode desabilitar as partes que causam problemas e verificar como o plugin se comporta. Segunda opção é utilizar componentes AMP para substituir plugins posso fazer outro post sobre o assunto, caso tenha interesse.
Analytics
Outro ponto crucial é a para de monitoramento da sua aplicação, caso não utilize nenhum plugin de tracking o plugin disponibiliza uma área para você adicionar o código do analytics com AMP código possui um formato diferente ele trabalha com um formato JSON:
Na sessão do analytics do plugin do AMP você terá mais informações de como adicionar o código analytics mas o formato acima é o esperado no caso da propriedade account deve ser passado o código UA so seu analytics.
Caso não queira se preocupar como código uma alternativa para conectar seu plugin AMP para WordPress com Google Analytics é a utilização do plugin SiteKit, ele sincroniza todos os serviços de tracking:
Plugin site kit by Google
Essa é uma breve intro sobre o plugin do AMP para WordPress em meu canal do Youtube também gravei sobre o assunto:
intro sobre AMP
Caso queira saber mais sobre AMP tenho um curso de desenvolvimento de aplicações AMP em meu canal. E aqui no blog também tenho uma página dedicada sobre o assunto.
Quando trabalhamos com AMP temos restrição na utilização de algumas tag HTML e ia tag img se encontra nessa lista. A principal razão é que imagens são responsáveis pela maior parcela no tamanho total de uma aplicação. Por isso o framework tem um cuidado especial no carregamento de images para isso utilizamos o componente amp-img, responsável por série de melhorias em nossa aplicação, por exemplo, lazy-loading e compressão.
Os componentes AMP utilizam web components um conjunto de 4 apis web nativas que permitem a criação de blocos reutilizáveis. A plataforma possui uma série de componentes que agilizam o processo de criação de nossa aplicação. Os componentes priorizam accessibilidade e performance, caso queira conferir a lista completa só acessar a página de catálogo de components, mas para esse tutorial vamos especificamente iremos utilizar <amp-img>.
amp-img
Parece um componente simples mas tem uma série de melhorias de performance com lazy-load, resize e compressão de images. Mas para a redimensionamento de image acontecer precisamos sempre especificar a altura e a largura das imagens. O componente espera os seguintes parâmetros:
alt – texto alternativo assim como tag img precisa para produzir um conteúdo mais acessível.
width e height – necessário para definir as dimensões de nossa imagem
src – assim uma uma tag img define o endereço de nossa imagem
layout – estilo de layout que a image terá, AMP possui os seguintes formatos: fill, fixed, fixed-height, flex-item, intrinsic, nodisplay, responsive
Assim que sabemos como utilizar amp-img nosso componente ficará da seguinte forma:
WebP formato 25% a 30% menor que os formatos tradicionais, mas surgiu recentemente e atualmente é suportado por 80% dos broswers(Ago 2019), como podemos ver na imagem abaixo:
Caso queiramos utilizar Webp sem penalizar os usuários dos browsers antigos podemos adicionar um fallback em nosso amp-img sinalizado pela propriedade fallback. e a utilização ficará da seguinte forma:
Como podemos ver acima isso mesmo o componente de fallback fica dentro do nosso componente principal assim o AMP ficará responsável de verificar se o browser do usuário possui suporte ou não para o formato webp e carregar apenas uma imagem.
Esse post faz parte do conteúdo auxiliar do curso de AMP. Mais posts sobre AMP você confere aqui. Exercícios e exemplos você irá encontrar no meu github. Próximo post iremos falar mais sobre AMP components, caso tenha alguma dúvida deixe um comentário.
AMP se tornou um framework bastante popular nos últimos anos por renderizar e entregar conteúdo em alta perfomance, atualmente 10 milhões de domínios na internet entregam conteúdo utilizando a tecnologia, mas também surgiu alguns mitos sobre AMP e nesse post traduzir um post do blog do AMP: “Debuking Common AMP Myths” e vamos conferir abaixo.
MITO #01: AMP é um projeto exclusivo do Google. FATO #01: AMP é um projeto open source liderado pelo Google em conjunto de outras empresas e membros da comunidade.
Os desenvolvedores AMP, empresas e colaboradores individuais participam no desenvolvimento deste projeto: Nos últimos três anos, o AMP recebeu contribuições de 850 colaboradores, 78% desses colaboradores são funcionários de outras empresas como Twitter, Pinterest, Yahoo, Bing e eBay. O AMP mudou-se para um novo modelo de governança, uma preocupação atual de vários projetos open source.
O modelo adotado dá voz a todos os membros da comunidade decentralizando as tomadas de decisões. Também incluindo usuários finais não ficando restrito apenas nos desenvolvedores.
MITO #02: AMP somente funciona para Google.com FATO #02: Páginas AMP são acessíveis em toda a web, incluindo qualquer plataforma de distribuição e dispositivo.
Os usuários podem acessar páginas AMP por meio de qualquer plataforma de distribuição, por exemplo, mecanismos de pesquisa ou sites, como Linkedin ou Twitter que sempre distribuem páginas AMP como modelo padrão para celulares.
Plataformas como Google e Bing dão um passo além, elas armazenam o seu conteúdo para proporcionar um carregamento instantâneo.
MITO #03: AMP é apenas para mobile FATO #03: O AMP é projetado com “responsividade” em mente, para funcionar em todos os tamanhos de tela.
AMP agora é somente AMP, inicialmente era um padrão Accelerated Mobile Pages agora por se uma tecnologia cross device o acrônimo perdeu seu significado agora ele se chama apenas AMP. Inicialmente AMP foi projetado para ser mobile friendly, para devices com hardware lento e conexões com alta taxa de latência. O impacto da tecnologia visto em um smartphone será ainda maior em um desktop. Mas também devemos entender que alguns recursos são projetados para uma experiência mobile, por exemplo , carrossel do Google Stories.
MITO #04: Toda página AMP também precisa ter uma versão não AMP. FATO #04: Uma página AMP pode ser associada a uma não AMP, mas isso não é um requisito obrigatório.
Em alguns casos, convém ter uma versão não AMP e uma versão AMP da mesma página, especialmente é fases de migração de sua aplicação. Mas não é um requisito mantém ambas versões do mesmo conteúdo, se você achar que AMP atende todos os requisitos de sua aplicação você pode manter apenas a versão AMP.
MITO #05: AMP landing pages usualmente são mais difíceis de construir. FATO #05: Geralmente isso irá custar menos de uma semana para construir uma landing page na maioria dos casos.
80% dos desenvolvedores contactados em pesquisa, reportaram que precisaram menos de uma semana para construir uma Landing page utilizando AMP. Dito isso, esforço para construir uma página dependerá do tipo de página que será construída, alguns modelos custarão mais tempo que outras, confira o a lista de templates gratuitos eles podem reduzir ainda mais o tempo de desenvolvimento de sua aplicação.
MITO #06: AMP é apenas para editores ou site estáticos FATO #06: Mais de 60% dos cliques na consultas do Google são páginas sem ser páginas de notícias.
AMP foi construído graças a intensa colaboração com milhares de desenvolvedores, editores e plataformas de distribuição de conteúdo e empresas de tecnologia. Quando AMP foi lançado a primeira vez, ele foi adotado inicialmente por editores e portais de notícias. mas agora os anunciantes e as empresas de comércio eletrônico também estão aproveitando os benefícios da plataforma AMP.
MITO #07: AMP não suporta experiências interativas. FATO #07: Os componentes AMP agora permitem personalização de design e experiências interativas.
Quando AMP foi lançado a pela primeira vez, ele tinha limitações de design. Á medida que o projeto AMP cresceu graças à colaboração da comunidade open source, foram criados novos componentes que permitem que as empresas façam personalização do design e criem experiências interativas. Empresas como BMW, AliExpress possuem bons exemplos de como utilizar a plataforma. Hoje a maioria das experiências interativas suportam:
Rich Media: O número de componentes AMP é cada vez maior e qualquer contribuidor pode contribuir na inclusão de novos componentes caso necessite.
Integração de terceiros: Existem uma vasta quantidade de integração com outras plataformas e você pode conferir aqui.
MITO #08: AMP não suporta sites de comercio eletrônico. FATO #08: AMP é uma opção natural de comercio eletrônico, pois AMP torna as páginas Web mais rápidas e performance é um ponto importante para conversão de compras.
Quando AMP foi lançado, inicialmente editores e portais de noticias foram a principal adoção da plataforma. A medida que o projeto AMP cresceu, novos componentes foram criados para permitir que as marcas criassem suas experiências interativas. Agora AMP pode ser utilizado para construir experiência de comércio eletrônico de alta performance e atrativa. Para mais informações veja os posts “Getting started with AMP for e-commerce” e “E-commerce At The Speed of AMP” .
MITO #09: Não é possível atualizar conteúdo de páginas AMP. FATO #09: Existem muitas opções de manter o conteúdo das páginas AMP atualizado.
Você pode veicular conteúdo novo em AMP usando o mecanismo de cache AMP padrão(stale-while-revalidate), usando a funcionalidade de atualização de cache ou usando componentes dinâmicos (como lista de AMP). Muitas das grandes empresas de e-commerce obtém bons resultados quando a implementação é planejada adequadamente.
MITO #10: AMP não é seguro/privado o suficiente. FATO #10: O framework AMP foi criado para preservar a privacidade e garantir a segurança dos dados.
Ás páginas AMP são geralmente veiculadas Google AMP Cache, que simplesmente armazena em cache uma versão da sua página para fins de validação de documentos AMP e fornecer a entrega confiável e rápida do conteúdo. Google AMP Cache, assim como JavaScript AMP, são veiculados em domínios sem cookies que não rastreiam os usuários de forma alguma. Além disso, AMP tem um processo de análise de segurança que é usado rotineiramente ao lançar novos componentes AMP. Para ler mais, confira o post “Privacy and user choice in AMP’s software architecture”.
MITO #11: Páginas AMP não convertem tão bem quanto páginas não-AMP. FATO #11: As páginas AMP otimizadas com frequência costumam ter um desempenho melhor do que as páginas não-AMP.
Muitos anunciantes e editores tiveram sucesso com o AMP, muito dos depoimentos você pode encontrar no portal amp.dev. Um estudo da Forrester descobriu que um site que implementa AMP pode esperar um aumento de 20% na taxa de conversão de vendas nas páginas AMP, um aumento de 10% no tráfego anual do site AMP e um aumento de 60% páginas por visitante.
Existem alguns motivos pelos quais uma página AMP pode apresentar um desempenho inferior a uma página não AMP.
*Caso não tenha um desempenho satisfatório, estas são algumas áreas para explorar:
Problemas de medição e monitoramento: certifique que as configurações do analytics na sua página AMP está seguindo os guias de configurações.
Inconsistências na sua página: se a Página AMP esteja sendo exibida diferente de uma página não-AMP, isto pode estar influenciando suas taxas de conversão. As páginas AMP devem ser identicas a páginas não-AMP em funcionalidades e aparência.
Tem uma categoria dedicada a AMP e no meu canal estou gravando um curso sobre AMP, se quiser saber mais sobre o curso voce pode conferir aqui:
