Categorias
Geral

Estilizando temas Frontity com CSS-in-JS

Nesse post vamos falar sobre como estilizar nossos temas Frontity, o framework trabalha com emotion uma biblioteca css que nos ajuda a escrever CSS-in-JS. Essa é a primeira vez eu acho que falamos em CSS-in-JS no blog. Esse post faz parte de uma série sobre Frontity:

CSS-in-JS

Antes de entrar no assunto de estilização com Frontity vamos falar sobre CSS-in-JS é um assunto que tomou o hype a dois anos atrás com Styled Components, emotion e outros frameworks ele permite a escrita de CSS dentro de arquivos JavaScript, assim adicionamos super poderes em nosso estilo, com emotion temos várias formas de escrever CSS-in-JS, como por exemplo:

import styled from '@emotion/styled' const Button = styled.button` padding: 32px; background-color: hotpink; font-size: 24px; border-radius: 4px; color: black; font-weight: bold; &:hover { color: white; } ` render(<Button>This my button component.</Button>)

Como podemos ver utilizando string literals para escrever CSS atualmente os principais editores de texto reconhecem essa sintaxe, por exemplo, VS Code. Para simples mas temos uma série de conceitos que podemos ver nesse código e também parte de compilação.

  • nesting: algo comum com LESS e SASS é o uso de nesting onde podemos agrupar seletores.
  • CSS + Javascript: podemos definir regras e concatenar variáveis como JavaScript.
  • Compilação: muita gente pensa que CSS-in-JS é inline CSS mas esse código é compilado gerado uma style tag para esse elemento, como podemos ver o código a seguir:
<button class="css-txevan ezh9olb0">This my button component.</button> <style> .css-txevan { padding: 32px; background-color: hotpink; font-size: 24px; border-radius: 4px; color: black; font-weight: bold; } </style>
  • CSS modular: temos a possibilidade de criar um CSS modular criando seletores únicos dinamicamente e só carregando o CSS quando necessário.
  • Cross-browsing: Além disso bibliotecas como styled components e emotion cuidam de fazer todo o trabalho de cross-browsig.

Emotion é a biblioteca adotada por Frontity para trabalhar como ela você não precisa fazer nenhuma instalação uma vez que você instala Frontity já pode fazer uso dos recursos, para isso importamos classes e funções dentro do Frontity.

Nosso projeto

Alguns desses conceitos vamos abordar quando começamos a estilizar nosso tema. Agora vamos voltar para o nosso projeto, para definir o estilo da nossa aplicação vamos utilizar o Starter Theme da Alessandra Stalanto como base:

Demo do Stater Theme

No último post criamos o seguinte componente principal:

import React from 'react'; import { connect } from 'frontity'; const Theme = ({state}) => { const data = state.source.get(state.router.link); return ( <> <h1>Nosso Primeiro tema com Frontity</h1> <p>URL Atual: {state.router.link}</p> <p>Autor: {state.source.author[1].name}</p> { data.items.map( item => { const post = state.source.post[item.id] return ( <article key={post.id}> <h2>{post.title.rendered}</h2> </article> ) }) } </> ); }; export default connect(Theme);

Estilo Global

Como vimos no exemplo anterior o estilo criado com emotion fica vinculado ao componente criando uma estrutura mais modular. Caso queiramos adicionar um estilo de forma global precisamos adicionar o componente Global esse componente recebe como parâmetro um estilo que será o seguinte:

import { css } from "frontity"; export default css` body { margin: 0 font-size: 1.25rem; color: #0d405b; background-color: #FBEED9; } html, body { max-width: 100%; overflow-x: hidden; } a, a:visited { color: inherit; text-decoration: none; } `;

Vamos adicionar esse estilo dentro da pasta tutorial-fellyph > src > styles criamos o arquivo globalStyles.js. Um ponto importante desse código que importamos uma função css ela nos ajudará a manipular o conteúdo como CSS e não uma simples string literal. Agora o próximo passo será adicionar nosso estilo global.

import React from 'react'; import { Global, connect } from 'frontity'; import globalStyles from "../styles/globalStyles"; const Theme = ({state}) => { const data = state.source.get(state.router.link); return ( <> <Global styles={globalStyles} /> <h1>Nosso Primeiro tema com Frontity</h1> <p>URL Atual: {state.router.link}</p> <p>Autor: {state.source.author[1].name}</p> { data.items.map( item => { const post = state.source.post[item.id] return ( <article key={post.id}> <h2>{post.title.rendered}</h2> </article> ) }) } </> ); }; export default connect(Theme);

O arquivo global tem algumas regras básicas. Podemos criar algo um pouco mais complexo para utilizar o Componente Global para adicionar nossas fontes, para isso vamos criar um arquivo fontFace.js dentro da mesma pasta que globalStyles:

import React from "react"; import { Global, css } from "frontity"; import baumansWOFF2 from "../fonts/baumans_regular-webfont.woff2"; import khandmediumWOFF2 from "../fonts/khand_500-webfont.woff2"; const FontFace = () => ( <Global styles={css` @font-face { font-family: "khandmedium"; src: url(${khandmediumWOFF2}) format("woff2"); font-weight: normal; font-style: normal; font-display: swap; } @font-face { font-family: "baumansregular"; src: url(${baumansWOFF2}) format("woff2"); font-weight: normal; font-style: normal; font-display: swap; } `} /> ); export default FontFace;

Como podemos ver o component FontFace por se só acessa diretamente o componente Global, além carregar as fontes que iremos trabalhar baumas e khand mas para vincular as fontes precisamos adicionar em nosso componente principal.

Antes de mostrar o Theme componente vamos mover a estrutura de nosso post para um componente Post:

import React from 'react'; import { styled } from 'frontity'; export const Post = ({ post }) => { return ( <Box> <h2>{post.title.rendered}</h2> </Box> ) } const Box = styled.article` box-sizing: border-box; margin: 0; min-width: 0; width: 100%; max-width: 1200px; margin-left: auto; margin-right: auto; padding: 20px; max-width: 900px; margin-bottom: 48px; box-shadow: 0px 1px 10px rgba(0,0,0,0.05); background-color: #fdf6eb; color: #0d405b; h2 { font-family: baumansregular, sans-serif; line-height: 1.1; color:#0d405b; font-size: 2rem; margin-top: 8px; } `;

Também vamos criar um componente para nosso cabeçalho com o component header:

import React from 'react' import { styled } from 'frontity'; export const Header = ({ title }) => { return ( <HeaderContainer> <h1>{title}</h1> </HeaderContainer> ) } const HeaderContainer = styled.header` background-color: #082737; color: #FBEED9; font-weight: bold; margin: 0 0 20px 0; padding: 1em; box-shadow: 0px 1px 10px rgba(0,0,0,0.05); h1 { font-size: 2rem; text-transform: uppercase; font-family: baumansregular,sans-serif; text-align: center; letter-spacing: 4px; line-height: 1.5; color: #FCB458; margin: 0; } `;

Agora como esses dois componentes vamos finalizar nosso Theme componente para esse tutorial:

import React from 'react'; import { Global, connect } from 'frontity'; import globalStyles from '../styles/globalStyles'; import FontFace from '../styles/fontFace'; import { Post } from './post/post.js'; import { Header } from './header/header'; const Theme = ({state}) => { const data = state.source.get(state.router.link); return ( <> <FontFace /> <Global styles={globalStyles} /> <Header title="Nosso Primeiro tema com Frontity" /> { data.items.map( item => { const post = state.source.post[item.id] return ( <Post key={post.id} post={post} /> ) }) } </> ); }; export default connect(Theme);

Assim o resultado será o seguinte:

Tema carregando os estilos

Vamos fechando esse post por aqui, para conferir o código completo você pode conferir o a branch que criei em meu github: https://github.com/fellyph/frontity-tutorial/tree/videos/04-css-in-js-final para mais posts sobre WordPress acesse a página da categoria.

Categorias
AMP Accelerated mobile pages Geral WordPress

Plugin Web Stories do Google versão 1.0

Recentemente fiz um post testando a versão beta do plugin e na semana passada saiu a versão 1.0 do plugin. Com uma série de correções e melhorias. Nesse post iremos falar sobre as novidades do plugin em sua versão 1.o.

Plugin oficial do google para web stories

1 – Mudança dos endereços

Umas das mudanças da versão beta para a versão final foi a alteração do URL /stories/ para /web-stories/. O agora todos os seus stories ficarão na pasta web-stories mas isso será mais relevante caso tenha utilizado o plugin na versão beta.

2 -Salvar cores e fontes

Umas dos pontos que tinha até criado uma issue no github era a opção de criar opções pré-definidas para fontes e cores. Agora na versão 1.0 temos a opção de salvar cores estilos de texto.

Opções salvas no editor visual

3 – Melhorias em acessibilidade

Uma série de melhorias relacionadas a acessibilidade foram incluídas nessa versão sempre quando o elemento possui um contexto de acessibilidade uma aba de acessibilidade será exibida no menu de contexto, como podemos ver na imagem a seguir:

Images e vídeos possuem a opção de adicionar texto descritivo

Além de melhorias referentes a conteúdo o editor visual também possui melhorias, como teclas de atalhos e navegação e edição via teclado.

4 – Integração com imagens e vídeos do Unsplash

Imagens e vídeos tem um importante papel da criação do seu web stories ter uma imagem relativa ao seu conteúdo demanda tempo para seleção e upload desse conteúdo. Com o plugin de web stories possui uma integração com o repositório de imagens unsplash.

Integração com o repositório de imagens unsplash

5 – Canal Google Web Creators

Umas das novidades junto com o plugin foi o lançamento do canal Google Web Creators, uma iniciativa para apoiar criadores de conteúdo na Web.

Vídeo de introdução do Google Web Creators

Então essas são as novidades que eu gostaria de listar em breve estará saindo mais um vídeo no canal sobre Web Stories. Caso queira ler mais posts sobre o WordPress acesse a página da categoria.

Categorias
AMP Accelerated mobile pages Geral WordPress

Plugins WordPress não são tecnologias ou processos

Navegando pelo YouTube encontro muitos vídeos, plugin de performance WordPress, plugin de SEO WordPress e outros casos como AMP pode matar o seu projeto. Muitas vezes criam uma visão com dois cliques eu irei resolver todos os meus problemas, plugins WordPress ajudam na automatização de tarefas mas muitas vezes criamos essa visão que eles resolvem todos os nossos problemas ou representam uma tecnologia ou um processo.

Por exemplo SEO é um assunto muito complexo, temos ótimos plugins disponíveis, mas o fato de instalar um plugin de SEO não vai resolver todos os seus problemas referentes ao tema. Eles ajudam e otimizar a realização de tarefas, mas temos que implementar o SEO de nossa aplicação como, inclusão de meta informações, inclusão e otimização de palavra chave e manutenção.

Somente a inclusão do plugin sem o cadastro de nenhuma informação pode prejudicar o SEO de sua aplicação, mas nessa situação é um problema do plugin ou do seu mal uso?

Dai caímos num segundo problema, culpar toda uma tecnologia ou processo por conta plugin, isso é muito comum de achar, por exemplo, no canal do mestre SEO do Fabio Ricotta que eu admiro bastante eu vi o seguinte relato:

Fabio sempre aponta informações baseado em experiências próprias, falando que sua experiência não foi válida mas analisando o vídeo vou comentar certos pontos:

  • Começando pelo título “Como AMP pode matar o seu projeto” já temos o direcionamento de para a tecnologia.
  • Nenhum momento ele especifica qual plugin utilizou generaliza o problema para tecnologia
  • Falhas como esquecer de adicionar código de tracking não é um problema da tecnologia
  • Depois atribuiu o fato plugin remover o código de tracking, novamente não é uma falha da tecnologia. Quando esse tipo de problema acontecer recomendado é notificar o desenvolvedor do plugin para que o problema não se repita
  • Por fim atribui limitações de não ter caixa de comentários, eu utilizo o plugin oficial do AMP tenho todas as funcionalidades do core do WordPress rodando normalmente, mas isso pode ser a limitação do plugin a qual ele utilizou
  • “por padrão o plugin cria uma versão tosca” – Importante especificar qual plugin foi utilizado, por exemplo, novamente a tecnologia sendo resumida a um plugin do AMP oficial a versão reader não é recomendada pelo próprio Google, mas existem opções de customização. Mas temos opções de disponibilizar uma versão idêntica a versão não-AMP.

Opiniões de influenciadores como o Fabio tem um peso muito grande e quem não conhece a tecnologia cria resistência sem mesmo nunca ter utilizado. Por isso é importante antes de compartilhar experiências ser mais específico sobre plugins WordPress e cenários de sua experiência.

Perfomance, SEO ou AMP, por exemplo, não se resumem apenas a instalar um plugin. O plugin de AMP facilitam o seu uso, mas a instalação sem o mínimo de configuração prejudicam a experiência do usuário. Além disso podemos criar um tema totalmente com AMP.

Performance não se resume a adicionar cache tem outra série de recursos que ações que melhoram o desempenho de sua aplicação. Além disso, SEO e Performance são tarefas continuas que nunca acabam precisam de manutenção constante.

Qualquer pessoa tem o total direito de não gostar de uma tecnologia específica mas é importante validar certos pontos antes de compartilhar qualquer opinião. Sou totalmente aberto a tecnologias e contra a clubismo com tecnologia. AMP possui pontos a melhorar assim com WordPress, JavaScript, PHP e outras linguagens, frameworks e CMSs.

Que você acha sobre o assunto? deixe um comentário com sua opnião.

Categorias
Geral

Utilizando Dark Mode em sua aplicação web

Nesse post vamos ver como implementar Dark mode em sua aplicação web, lançado em sistemas operacionais tanto Mobile quanto para Desktop agora podemos controlar a estilização do nosso conteúdo de acordo com a preferência do usuário. Falando um pouco dessa trajetória no inicio da computação por questões de limitação utilizávamos “dark mode” com os famosos monitores de tela preta como o texto verde.

Com a evolução das telas tivemos uma mudança dos sistemas operacionais para representar elementos reais como documentos e images. Com o passar dos anos a comunidade de desenvolvimento passou a utilizar IDEs para codificação em dark, e agora nos últimos anos Dark Mode passou a ser uma opção para sistema operacionais mobile.

Preferências e vantagens

Particularmente por uma longa exposição durante o dia a diversas telas, no trabalho, celular e em casa. Eu utilizo modo como uma forma de descanso mas estudos realizados pelo time do android mostram que dark mode permite uma economia de até 60% em algumas aplicações, por exemplo, o Youtube app em dark mode.

Mas a web não fica para trás, nas últimas versões dos browsers passaram a reconhecer quando o usuário utiliza o modo, Conseguimos através de media queries monitorar a preferência do usuário.

Media Query CSS

@media (prefers-color-scheme: dark) { ... } @media (prefers-color-scheme: light) { ... } @media (prefers-color-scheme: no-preference) { ... }

Com essas três media queries conseguimos captar 3 estados: dark, light, no-preference. Assim conseguimos alterar propriedades quando o usuário utiliza um modo especifico, por exemplo:

body { color: #000; background-color: #fff; } @media (prefers-color-scheme: dark) { body { color: #fff; background-color: #000; } }

Habilitando Dark mode

No MacOS definimos através de configurações > preferencias gerais:

Alterando para Dark Mode Mac OS

Para iOS vamos em Configurações > Tela e Brilho

Como definir dark mode no iOS

Essa é uma maneira que podemos modificar toda a configuração do sistema operacional. Mas quando estamos desenvolvendo ficar trocando todas as configurações do sistema operacional pode se tornar inconveniente. Nas novas versões do Chrome 79 podemos simular essa mudança como o Chrome DevTools. Para isso vamos no seguinte painel.

Com o DeTools aberto clicamos no menu mais opções(três pontos) e habilitamos a opção renderização(rendering), Lá na propriedade “Emulate CSS media feature prefers-color-scheme” conseguimos simular light mode e dark mode.

Tela do devtools do Chrome

Agora que sabemos como simular e qual media query utilizamos, vamos aplicar o código ao projeto utilizado no curso de PWA. Atualmente o tema principal utilizar um background preto com fontes branca, agora vamos criar uma tema light com as cores invertidas:

Resultado final Light vs Dark mode

Controlando as cores com variáveis CSS

Para isso vamos fazer algumas modificações. Atualmente o projeto utiliza SASS, vou levar em consideração o modo light como o modo padrão e para esse exercício vou utilizar as variáveis para CSS para modifica-las quando usuário muda o modo:

//cores com variáveis CSS :root { --primary-color: #fff; --secondary-color: #000; --ternary-color: #bae2fd; --gray-color: #333; } @media (prefers-color-scheme: dark) { :root { --primary-color: #000; --secondary-color: #fff; } }

No código acima á parte de nossa solução, temos as variáveis sendo modificadas quando o usuário muda entre modos, assim não precisamos modificar todos os seletores do nosso CSS apenas as variáveis.

Quando testamos nossa aplicação em Dark Mode deparamos com a seguinte situação:

SVGs e images precisa de ajustes

Para esse caso temos duas correções os icones das redes sociais estão como “embedados” em nosso HTML conseguimos controlar a propriedade fill do nosso SVGs para isso adicionamos o seguinte código:

.social__icon { width: 25px; height: 25px; fill: var(--secondary-color); } a:hover .social__icon { fill: var(--primary-color); }

Para a logo principal, por conta de ser uma image preto e branco conseguimos inverter sua cor através de filtros CSS:

@media (prefers-color-scheme: dark) { .header__picture { filter: invert(1); } }

Assim temos o fix para os dois items, lembrando que no caso da imagem funcionou por que eu utilizo uma image monocromática e temos o seguinte resultado:

Observações

Implementações do dark mode em sua aplicação web pode ser mais complexa que no exemplo acima, por conta da paleta de cores restritas temos uma simples implementação, caso de uma paleta mais complexa preste atenção nos níveis de contraste.

Em caso mais complexos o ideal é dividir o CSS e carregar o estilo para mode preterido pelo usuário, adicionando as seguintes tags em nosso html:

<link rel="stylesheet" href="/dark.css" media="(prefers-color-scheme: dark)"> <link rel="stylesheet" href="/light.css" media="(prefers-color-scheme: no-preference), (prefers-color-scheme: light)"> <!-- Estilo principal --> <link rel="stylesheet" href="/style.css">

No caso acima temos um estilo geral style.css e dark.css para os usuários que preferem dark mode e light.css para os usuários sem seleção ou light mode. Assim os usuários em dark mode so carregam o css relacionado.

Para browser antigos

Caso o browser não suporte prefers-color-scheme conseguimos adicionar um fallback em nosso código:

<script> // Se `prefers-color-scheme` não for suportado pelo browser, o fall back será light mode. if (window.matchMedia('(prefers-color-scheme: dark)').media === 'not all') { document.documentElement.style.display = 'none'; document.head.insertAdjacentHTML( 'beforeend', '<link rel="stylesheet" href="/light.css" onload="document.documentElement.style.display = \'\'">' ); } </script>

Após a inclusão da media query a validação do stylelint acusou a media query como desconhecida, isso por conta da versão do style lint caso passe o mesmo problema atualize o stylelint para versão 10 ou superior e a validação passará a reconhecer a media query

Falso alert de validação das versões antigas do stylelint

Suporte

Atualmente Novembro de 2019 o suporte para a media query prefers-color-scheme é de 74% dos browser do mercado:

Edge, firefox, chrome, safari, opera, iOS safari suas ultimas versões suportam dark mode.

O código completo de como implementar dark mode em sua aplicação web você encontra em meu github: https://github.com/fellyph/pwa-tutorial/tree/video/dark_mode_20_final

A base desse tutorial vem do projeto utilizado no curso de PWA que estou rodando no Youtube: https://blog.fellyph.com.br/curso-online-progressive-web-apps/

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

Esse post foi baseado no artigo “Hello darkness, my old friend” do @tomayac: https://web.dev/prefers-color-scheme/

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 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:

Curso online sobre aMP