Categorias
AMP Accelerated mobile pages

Como trabalhar com imagens no AMP

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:

<amp-img src="./assets/images/caipirinha.webp" 
    alt="About Caipirinha"
    width="700" 
    height="526" 
    layout="responsive">
</amp-img>

Fallback

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:

<amp-img src="./assets/images/caipirinha.webp" alt="Sobre Caipirinha"
          width="700" height="526" layout="responsive">
            <amp-img alt="Sobre Caipirinha"
            fallback
            width="700"
            height="526"
            layout="responsive"
            src="./assets/images/caipirinha.jpeg"></amp-img>
        </amp-img>

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.

Categorias
Geral

11 Mitos sobre AMP

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 a plataforma 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.

Categorias
JavaScript PWA - Progressive web apps

Estratégias de cache para PWAs

Continuando a série sobre PWA tivemos uma introdução sobre Service Worker. Vimos que o service worker permite o suporte a aplicações offline mas também podemos controlar as requisições feitas pelo o navegador isso nos dá a habilidade de pensar em diferentes estratégias de cache para a nossa aplicação e esse será o tema do nosso post.

Desenvolvendo uma aplicação web alguns dados dentro da nossa solução tem uma periodicidade maior ou menor de atualização, por exemplo a logo de nosso site é tipo de dado que pode passar anos sem alteração, já no caso de uma sessão de últimas notícias podem ter uma periodicidade de minutos. Com esse dois exemplo podemos ver situações distintas, assim com a partir desses exemplos vamos abordar as estratégias mais comum de cache.

Cache only

Nesse caso todos as requisições serão direcionadas para o cache.

  1. O service worker recebe a requisição
  2. Consulta se o conteúdo se encontra no cache
  3. Retorna o conteúdo requisitado para o usuário

Se não encontrado no cache a requisição irá falhar. Mas esse pattern assume que os conteúdos serão armazenados no cache durante a instalação do service worker.

Casos recomendados: esse padrão é ideal para assets que raramente são atualizados, por exemplo, logos, ícones de redes sociais e estilos. Mas isso não significa que eles nunca serão alterados, esse controle será feito pela versão do seu service worker.

Código:

self.addEventListener('fetch', event => {
  // todos os arquivos serão servidos pelo cache 
  event.respondWith(caches.match(event.request));
})

Cache first

Parecida com a estratégia anterior, mas com uma diferença, caso não ache o arquivo no cache ele irá realizar uma requisição na rede como podemos ver no código a seguir:

self.addEventListener('fetch', event => {
   
  event.respondWith(
    caches.match(event.request).then(response => {
      return response || fetch(event.request);
    })
  );
});

Network only

  1. O service worker irá analisar a requisição
  2. Irá requisitar na rede os arquivos requisitados
  3. O conteúdo requisitado é enviado para o usuário

Neste caso se a requisição a rede falhar não retornará nada.

Casos recomendados: Esse útil para requisições exemplo pings no servidor para análise de tráfego ou estatísticas.

Network first

Nessa situação primeiramente fazemos o request para a rede, caso a requisição falhe procuramos o arquivo no cache. Problema nessa requisição que perdemos muito tempo esperando um retorno de uma falha na requisição.

Casos recomendados Trabalhamos com essa estratégia quando temos a prioridade dos dados recentes. Ideal para áreas que tem atualizações constantes.

Código:

self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request).catch(() => {
      return caches.match(event.request);
    })
  );
});

Cache, then network

Essa estratégia carrega os dados imediatamente do cache enquanto verifica na rede se o conteúdo sofre alguma alteração. No momento que receber o retorno das informações da redes, o conteúdo será verificado caso precisa será atualizado.

Temos o benéfico de exibir o conteúdo imediatamente mas sempre fazemos duas requisições precisando ou não da informação. Por que nesse caso só sabemos se o conteúdo foi alterado se requisitamos a informação na rede, se nada mudou, fazemos uma requisição em vão. Outro desafio desse padrão é desenvolver uma interface que não pareça estranho a atualização do conteúdo.

Casos recomendados: Quando priorizamos a performance mas temos uma frequência constante de updates do conteúdo, aplicações com timeline de e game leader board.

Código (sw.js)

self.addEventListener('fetch', event => {
   event.respondWith(
     caches.open('mysite-dynamic').then(cache => {
        return fetch(event.request).then(response => {
          cache.put(event.request, response.clone());
          return response;
        })
     })
   );
 });

Código(main.js)

let networkDataReceived = false;
startSpinner()
const networkUpdate = fetch('/data.json').then(response => {
  if(!response) throw Error('no data');
  return response.json();
}).then(data => {
  if(!networkDataReceived);
  updatePage(data);
}).catch(() => {
  return networkUpdate;
}).catch(showErrorMessage).then(stopSpinner);

Stale while revalidate

Utilizamos essa técnica quando não temos prioridade do conteúdo mais recente mas queremos fazer atualizações periódicas. Essa estratégia é parecida com a cache first, mas com uma diferença os dados mais recentes não serão atualizados imediatamente, o cache será atualizado e a informação será exibida quando o usuário recarregar a página.

Casos recomendados: Logos, imagens do perfil do usuário.

Código

self.addEventListener('fetch', event => {
   event.respondWith(
     caches.open('mysite-dynamic').then(cache => {
        return cache.match(event.request).then(response => {
         const fetchPromise = fetch(event.request)
          .then(networkResponse => {
           cache.put(event.request, networkResponse.clone());
           return networkResponse;
          });
          return response || fetchPromise;
        })
     })
   );
 });

Generic fallback

Quando o usuário usuário não achar o conteúdo requisitado na rede ou no cache retomamos um conteúdo genérico. Por exemplo, quando não conseguimos encontrar uma imagem específica como um avatar, para não prejudicar nossa interface retornamos um avatar genérico, por exemplo, uma ilustração. Esse padrão pode ser combinado com as estratégias anteriores.

Código

self.addEventListener('fetch', event => {  
  event.respondWith(
    caches.match(event.request).then(response => {
     return response || fetch(event.request);
    }).catch(() => {
      return caches.match('/offline.html');
    })
  );
});

Esse são as principais estratégias de cache, além delas podemos combinar estratégias de cache, mas para esse post vamos abordar os mais populares nos próximos posts iremos abordar uma ferramenta que irá facilitar nossa vida: Workbox, mas isso é assunto para um novo post.

Caso tenha alguma dúvida deixe um comentário e até o próximo post.

Categorias
JavaScript Tutoriais Web

Introdução a Service Worker

Nesse posts vamos falar sobre service worker é um dos recursos chaves dentro das Progressive web Apps vamos entender como ele funciona e o seu ciclo de vida. Para quem ainda não viu, estou gravando uma série sobre PWA em meu canal do youtube, até o momento tenho mais de 12 aulas gravadas também estou adicionando conteúdo complementar no blog.

O que é um service worker?

Nada mais é que o coração das PWAs, não é nenhuma tecnologia especial e sim um arquivo JavaScript que roda em segundo plano em nossa aplicação o que isso significa? Ele não é executado na thread principal da aplicação junto com execução do HTML e CSS, ele não tem acesso ao DOM por exemplo. Isso abre uma porta para recursos rodarem independente do browser por exemplo push notifications e execução de código em segundo plano. Outro recurso extremamente importante é o suporte a experiência offline, dando ao usuários controle sobre a aplicação independente da conectividade.

Pontos importantes sobre Service Worker

  • Precisa estar rodando em HTTPS
  • Ele é uma JavaScript Worker, ele não tem acesso ao DOM
  • Permite controlar como serão feitos os requests a rede
  • Faz o uso intensivo de promises
  • Precisa ser instalado por outro JavaScript
  • Possui um escopo e esse escopo é baseado onde o arquivo do service worker se encontra.

Ciclo de vida

Quando registrado por outro JavaScript, o service worker passa a ter um ciclo de vida independente do conteúdo web em que foi registrado. Ele será movido para outra Thread como mencionamos anteriormente, quando registrado ele irá chamar o evento Install event, se durante o processo de instalação ocorrer um erro na transferência de algum arquivo o processo de instalação irá falhar. mas se tudo ocorrer bem ele irá disparar um segundo evento Active event.

Depois que o Active event é disparado o service worker está pronto para disparar funções em segundo plano e acompanhar os dados que estão sendo transferidos entre aplicação e a rede. Neste momento conseguimos definir estratégia de cache e suporte offline. A imagem abaixo resume os passos que acabamos de comentar.

Ciclo de vida de um service worker

Na imagem acima temos uma definição completa do ciclo de vida de um service worker, com adição a um ponto importante quando adicionamos uma nova versão ela fica em estado de espera, ela só será instalada quando todas as instâncias da nossa aplicação forem finalizadas.

Registrando um Service worker

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/sw.js').then(function(registration) {
      // service worker registrado com sucesso
      console.log('ServiceWorker registrado no seguinte escopo: ', registration.scope);
    }, function(err) {
      // falha no registro:(
      console.log('Falha no registro do ServiceWorker: ', err);
    });
  });
}

O código acima será implementado pelo o JavaScript responsável por registrar o nosso Service Worker, na primeira linha verificamos se o nosso browser possui suporte a tecnologia, caso tenha, o registramos com a função com navigator.serviceWorker.register e através de uma promise verificamos se o service worker foi instalado com sucesso. E dentro do nosso sw.js podemos adicionar listener para acompanhar o seu ciclo de vida:

self.addEventListener('install', function(event) {
  // acompanha a instalação do service worker
});

self.addEventListener('activate', function(event) {
  // acompanha quando o service worker está ativo
});

self.addEventListener('fetch', function(event) {
  // acompanha quando a aplicação faz transferência de arquivos
});

Os listeners serão importante para criar um cache, acompanha mensagens e definir estratégias de cache. Para esse post, vamos fechando por aqui, se ainda não segue o meu canal no Youtube, lá estou sempre postando conteúdo sobre PWA: https://www.youtube.com/user/fdangellys

Veja os posts sobre PWA

Veja também o mini curso sobre PWA

Categorias
JavaScript Tutoriais

Badging API

A Badging API é uma das novas APIs criadas para fechar o gap entre aplicações nativas, a badging API foi incluída na versão 73 do Chrome em versão de teste, permite adicionar contador de notificações nos ícones de nossa PWA na barra de tarefas, diferente de push notification badging api é menos intrusiva apenas exibe um balão de notificação sobre o ícone de nossa aplicação, atualmente Window 7+ e MacOS possuem suporte a essa funcionalidade através de token especial para o recurso.

Google iniciou um projeto com foco na inclusão de novas funcionalidades e o mais legal que esse projeto será baseado em requisições feitas pela comunidade para saber mais sobre o projeto acesse o link:
https://developers.google.com/web/updates/capabilities

Casos sugeridos para utilizar a badging API

  • Aplicações de Chat, email e social apps que precisam notificar que o usuário recebeu novas mensagens
  • Aplicações precisa sinalizar que processos que estavam rodando em background foram concluídas
  • Jogos que estão aguardando uma ação do usuário.

Requisitos

  • Chrome 73 ou superior
  • Aplicação precisa estar instalada como PWA

Como utilizar

A partir da versão 73 a Badging API está disponível através de um recurso chamado Origin trials(Versões de avaliação) ele permite testar novas features e dar feedback de usabilidade, praticidade e eficiência. Caso queira saber mais sobre o projeto acesse o link.

Registrando para Versões de avaliações

  1. Requiste um token para sua origin
  2. Adicione o token em sua página, temos dois modos para prover esse recurso em qualquer página de sua versão de teste.
    1. Adicionando uma meta tag origin-trial no cabeçalho de sua aplicação
    2. Se você tiver acesso a configuração do seu servidor, você também pode prover um token em sua página adicionando a propriedade Origin-Trial em seu HTTP header.
    3. Se você quiser testar localmente também pode fazer o uso habilitando a flag #enable-experimental-web-platform-features acessando o endereço chrome://flags
Caso queira utilizar o token você pode essa será a página de requisição

Para esse tutorial vamos utilizar a flag do chrome, atualmente(maio 2019) estamos na versão 74 a previsão do uso definitivo desse recursos será na versão 78. Caso esteja lendo este post com a versão do Chrome 78 ou superior esse passo não será necessário. Mas para quem utiliza versão inferior a 78 vamos habilitar o recurso acessando o endereço chrome://flags:

Para facilitar nossa vida podemos pesquisar por “experimental web” para ir diretamente a flag. Após nossa flag habilitada precisamos reiniciar nosso Chrome para o recurso funcionar em nosso browser.

Agora que habilitamos a flag hora de testar o recurso, a badging API tem duas funções window.ExperimentalBadge.set() para definir o contador e window.ExperimentalBadge.clear() para limpar nosso contador.

Para os nossos testes vamos utilizar como base o projeto que estou desenvolvendo no mini curso de PWA que estou rodando no Youtube.

Inicialmente vamos adicionar dois botões em nossa página:

<button class="badingAPI__add">Add</button>
<button class="badingAPI__clean">Clean</button>

Nosso JavaScript ficará da seguinte forma:

const addBadge = document.querySelector('.badingAPI__add');
const cleanBadge = document.querySelector('.badingAPI__clean');
let counterBadge = 0;
let bagdeTimer;

if (addBadge) {
  addBadge.addEventListener('click', () => {
    if (counterBadge === 0) {
      bagdeTimer = window.setInterval(() => {
        counterBadge += 1;
        window.ExperimentalBadge.set(counterBadge);
        console.log('counter');
      }, 1000);
    }
    console.log('triggered');
  });

  if (cleanBadge) {
    cleanBadge.addEventListener('click', () => {
      counterBadge = 0;
      window.ExperimentalBadge.clear();
      clearInterval(bagdeTimer);
    });
  }
}

No Código acima realizamos uma simulação da atualização das notificações com um setInterval(), quando o usuário clica no botão “add” inicializamos o contador, passamos como parâmetro um número dentro da função set, caso queiramos apenas exibir o balão sem um número, chamamos a função set sem passar nenhum parâmetro. Numa aplicação real atualizamos o contador quando temos uma mensagem não lida ou precisamos completar alguma tarefa.

No macOS podemos ver o contador de notificações funcionando

Para o botão clean, quando o usuário clicar no botão, zeramos o contador e removemos a execução do nosso timer com clearInterval, e para remover a badge do ícone chamamos a função: window.ExperimentalBadge.clear().

Esse recurso está em modo de teste mas em breve será incorporado sem o uso de flag no Chrome para acompanhar o status e conferir mais informações acesse: https://developers.google.com/web/updates/2018/12/badging-api

Esse material faz parte do curso de PWA que estou rodando em meu canal do Youtube, para acompanhar as aulas sigam meu canal ou acessem a página do curso: https://blog.fellyph.com.br/curso-online-progressive-web-apps/

Qualquer dúvida só deixar um comentário e até o próximo post!