Quarta-feira, 9 de novembro de 2016
Os Apps Web Progressivos (PWAs) estão aproveitando novas tecnologias para levar o melhor de sites móveis e aplicativos nativos aos usuários e representam uma das novidades mais empolgantes na Web. No entanto, para causar um impacto real, é importante que eles sejam indexáveis e vinculáveis. Cada recomendação apresentada neste artigo é uma prática recomendada de indexação, independentemente de você estar criando um App Web Progressivo ou um site estático simples. No entanto, reunimos essas práticas recomendadas para fornecer uma lista de verificação para orientar você:
Deixar o conteúdo rastreável
Por quê? Historicamente, os websites sempre geraram ou renderizaram o próprio HTML no servidor, que é a maneira mais fácil de assegurar que seu conteúdo possa ser vinculado diretamente. Os aplicativos para Web popularizaram o conceito de renderização pelo cliente, no qual o conteúdo é atualizado dinamicamente na página à medida que os usuários navegam por ela, sem exigir que ela seja atualizada.
A abordagem mais moderna é a renderização híbrida, na qual a renderização pelo servidor é usada quando um usuário acessa diretamente um URL, e a renderização pelo cliente é usada após o carregamento inicial da página, para a navegação posterior e para solicitações assíncronas.
Nossa amostra de PWA renderizado pelo servidor demonstra uma renderização pura no servidor, enquanto a amostra de PWA com renderização híbrida demonstra a abordagem combinada.
Se você não estiver familiarizado com a terminologia "renderização pelo servidor" e"renderização pelo cliente", confira estes artigos sobre renderização do lado do cliente e do servidor e renderização do lado do servidor em react e node.js.
Práticas recomendadas:
Use a renderização híbrida ou pelo servidor para que os usuários recebam a carga inicial da solicitação da Web.
Sempre assegure que os URLs possam ser acessados de forma independente:
https://www.example.com/product/25/
O endereço acima deve oferecer um link direto para esse recurso específico.
Se não for possível oferecer compatibilidade com a renderização híbrida ou do lado do servidor no seu Progressive Web App e você decidir usar a renderização do lado do cliente, recomendamos usar a ferramenta Fetch as Google do Google Search Console para verificar se o conteúdo é renderizado corretamente para o rastreador da Pesquisa.
Não redirecione os usuários que acessam links profundos de volta para a página inicial do seu aplicativo da Web.
Evite também mostrar aos usuários uma página de erro em vez de oferecer um link direto.
Fornecer URLs limpos
Por quê? Os identificadores de fragmento (#user/24601/ ou #!user/24601/) eram uma
solução alternativa eficaz para os navegadores buscassem com AJAX novos conteúdos de um servidor sem atualizar a página.
Esse design é conhecido como renderização pelo cliente.
No entanto, a sintaxe do identificador de fragmentos não é compatível com algumas ferramentas, estruturas e protocolos da Web, como o protocolo Open Graph do Facebook.
A API History permite
atualizar o URL sem identificadores de fragmentos, enquanto busca recursos de forma assíncrona
e, portanto, evita atualizações da página. É o melhor dos dois mundos. O esquema de rastreamento AJAX
(com os URLs de fragmento com escape / #!) fazia sentido no momento, mas agora não é mais
recomendado.
Nossas amostras de PWA com renderização híbrida e pelo cliente demonstram a History API.
Práticas recomendadas:
Forneça URLs limpos sem identificadores de fragmentos (# ou #!), como:
https://www.example.com/product/25/
Se for utilizar a renderização pelo cliente ou a renderização híbrida, ofereça suporte ao uso de navegadores com a History API.
Evite:
Não é recomendável usar a estrutura de URL #! para gerar URLs exclusivos:
https://www.example.com/#!product/25/
Foi apresentada como uma solução alternativa antes do advento da History API. É considerada um
padrão diferente da estrutura de URL exclusivamente #.
O uso da estrutura de URL # sem o símbolo ! é
incompatível:
https://www.example.com/#product/25/
Essa estrutura de URL já se tornou um conceito na Web e está relacionada ao fornecimento de links profundos para um conteúdo em uma página específica.
Especificar URLs canônicos
Por quê? A melhor maneira de eliminar qualquer dúvida sobre a indexação quando o mesmo conteúdo está disponível em diversos URLs (seja no mesmo domínio ou em domínios diferentes) é marcar uma página como canônica enquanto as outras páginas que duplicam esse conteúdo fazem referência a ela.
Práticas recomendadas:
Inclua a tag a seguir em todas as páginas que espelham um conteúdo específico:
<link rel="canonical" href="https://www.example.com/your-url/" />
Se você oferecer compatibilidade com Accelerated Mobile Pages,
também use corretamente a instrução rel="amphtml".
Evite:
Evite duplicar de propósito conteúdos em diversos URLs sem usar o elemento de
link rel="canonical".
Por exemplo, o elemento de link rel="canonical" pode reduzir a ambiguidade de URLs com
parâmetros de rastreamento.
Evite criar referências canônicas conflitantes entre suas páginas.
Projetar para vários dispositivos
Por quê? É importante que todos os seus usuários tenham a melhor experiência possível ao visualizar seu website, independentemente do dispositivo usado.
Crie seu site com design responsivo: fontes, margens, preenchimentos, botões e o visual do seu site devem ser redimensionados dinamicamente com base nas resoluções de tela e nas janelas de visualização dos dispositivos.
Imagens pequenas que são redimensionadas para computadores ou tablets oferecem experiências negativas. Por outro lado, o download de imagens com resolução superalta leva muito tempo em smartphones e pode afetar o desempenho de rolagem em dispositivos móveis.
Leia mais sobre a UX para PWAs.
Práticas recomendadas:
Use o
atributo srcset
para buscar imagens de resoluções diferentes para telas de densidades diferentes a fim de evitar o download de imagens
maiores do que a capacidade de exibição da tela do dispositivo.
Redimensione o tamanho da fonte e a altura da linha para garantir um texto legível, independentemente do tamanho do dispositivo. Da mesma forma, verifique se o padding e as margens dos elementos também estão dimensionados corretamente.
Teste várias resoluções de tela usando o recurso Modo dispositivo das Ferramentas para desenvolvedores do Chrome e a Ferramenta de teste de compatibilidade com dispositivos móveis.
Não mostre aos usuários conteúdo diferente do mostrado ao Google. Se você usa redirecionamentos ou detecção de user agent (também conhecido como detecção de navegador ou exibição dinâmica) para alterar o design do seu site para diferentes dispositivos, é importante que o conteúdo permaneça o mesmo.
Use a ferramenta Fetch as Google do Search Console para verificar se o conteúdo buscado pelo Google corresponde ao conteúdo que um usuário vê.
Por motivos de usabilidade, evite usar fontes de tamanho fixo.
Desenvolver repetidamente
Por quê? Uma das estratégias mais seguras ao adicionar recursos a um aplicativo da Web é fazer alterações continuamente. Se você adicionar recursos individualmente, poderá observar o impacto de cada alteração individual.
Como alternativa, muitos desenvolvedores preferem visualizar seus aplicativos da Web progressivos como uma oportunidade de reformular todo o site para dispositivos móveis em uma tacada, desenvolvendo o novo aplicativo da Web em um ambiente isolado e, depois de pronto, usando-o para substituir o site para dispositivos móveis existente.
Ao desenvolver recursos repetidamente, tente dividir as alterações em blocos. Por exemplo, se você pretende mudar da renderização pelo servidor para a renderização híbrida, trabalhe nesse aspecto isoladamente em vez de misturar com outros recursos.
As duas abordagens têm aspectos positivos e negativos. A repetição reduz a complexidade de lidar com a indexabilidade da pesquisa, já que a transição é contínua. No entanto, a repetição pode causar um processo de desenvolvimento mais lento e, possivelmente, uma reformulação menos inovadora se o desenvolvimento não estiver começando do zero.
De qualquer jeito, as áreas mais sensíveis que devem ser observadas com cuidado são os URLs canônicos e a configuração do robots.txt do site.
Práticas recomendadas:
Trabalhe no website de forma repetida e gradual, adicionando os novos recursos individualmente.
Por exemplo, se não houver suporte para HTTPS, comece a realizar a migração para um site seguro.
Evite:
Se você desenvolveu seu app da Web progressivo em um ambiente isolado, evite inicializá-lo sem verificar se os links rel-canonical e o arquivo robots.txt foram configurados adequadamente.
Verifique se os links rel-canonical levam ao site real e se a configuração do robots.txt permite o rastreamento do novo site.
É recomendável impedir que os rastreadores façam a indexação do site que ainda estiver em desenvolvimento, mas não se esqueça de desbloquear os rastreadores e permitir que eles acessem o novo site após o lançamento.
Usar aprimoramento progressivo
Por quê? Sempre que possível, é importante detectar os recursos do navegador antes de usá-los. A detecção de recursos também é melhor do que realizar testes para navegadores que você acredita serem compatíveis com um determinado recurso.
Anteriormente, era prática comum ativar ou desativar recursos testando o navegador que o usuário tinha. No entanto, como os navegadores estão sempre evoluindo com recursos, essa técnica é fortemente desencorajada.
O Service Worker é uma tecnologia relativamente nova e é importante não interromper a compatibilidade em busca do progresso. É um exemplo perfeito de quando usar o aprimoramento progressivo.
Práticas recomendadas:
Antes de registrar uma verificação da disponibilidade da API do Service Worker:
if ('serviceWorker' in navigator) {
...
Use conforme o método de detecção de API em todos os recursos do seu website.
Nunca use o user agent do navegador para ativar ou desativar recursos no seu app da Web. Sempre verifique se a API do recurso está disponível. Se não estiver, faça uma degradação suave.
Evite atualizar ou lançar seu site sem testá-lo em diversos navegadores. Verifique os dados analíticos do seu site para saber quais navegadores são mais utilizados entre sua base de usuários.
Realizar testes usando o Search Console
Por quê? É importante entender como a Pesquisa Google visualiza o conteúdo do seu site. Use o Search Console para buscar URLs individuais do site e veja como a Pesquisa Google os visualiza usando o recurso "Rastrear > Fetch as Google". O Search Console processará o JavaScript e renderizará a página quando essa opção for selecionada. Caso contrário, somente a resposta do HTML bruto será mostrada.
O Search Console do Google também analisa o conteúdo da página de diferentes formas, inclusive com a detecção da presença de dados estruturados, Rich Cards, sitelinks e páginas aceleradas para dispositivos móveis.
Práticas recomendadas:
Monitore seu site usando o Search Console e explore os recursos com o "Fetch as Google".
Forneça um sitemap pelo recurso do Search Console Rastrear > Sitemaps. Pode ser um método eficaz de garantir que a Pesquisa Google tenha conhecimento de todas as páginas do seu site.
Fazer anotações com os dados estruturados do Schema.org
Por quê? Os dados estruturados do Schema.org são
um vocabulário flexível para resumir as partes mais importantes da sua página enquanto dados processáveis
automaticamente. Pode ser uma descrição mais generalizada, como dizer que uma página é um NewsArticle,
ou mais específica, como os detalhes de localização, nome, local e empresa que vende os ingressos da turnê de uma banda, ou
ainda o resumo dos ingredientes e das instruções de uma receita.
O uso desses metadados pode não ser indicado para todas as páginas no seu aplicativo da Web, mas é recomendado sempre que os dados forem sensíveis. O Google os extrai depois que a página é renderizada.
Há diversos tipos de dados, incluindo NewsArticle, Recipe e Product,
para citar alguns. Conheça também todos os
tipos de dados compatíveis.
Práticas recomendadas:
Verifique se os metadados do Schema.org estão corretos usando a Ferramenta de teste de dados estruturados do Google.
Verifique se os dados fornecidos estão aparecendo e se não existem erros.
Evite usar um tipo de dado que não corresponde ao conteúdo real da sua página. Por exemplo, não use
Recipe para uma camiseta que você está vendendo. Use Product.
Fazer anotações com Open Graph e Twitter Cards
Por quê? Além dos metadados do Schema.org, talvez seja útil adicionar suporte para o protocolo Open Graph do Facebook e para os Rich Cards do Twitter.
Esses formatos de metadados melhoram a experiência do usuário quando seu conteúdo é compartilhado nas redes sociais correspondentes.
Caso seu site existente ou seu aplicativo da Web use esses formatos, é importante assegurar que eles também sejam incluídos no seu aplicativo da Web progressivo para otimizar a capacidade de viralizar.
Práticas recomendadas:
Teste sua marcação do Open Graph com a ferramenta de depuração de objetos do Facebook.
Familiarize-se com o formato de metadados do Twitter.
Não se esqueça de incluir esses formatos se o site existente oferecer suporte a eles.
Realizar testes em diversos navegadores
Por quê? Do ponto de vista do usuário, é importante que um website se comporte da mesma maneira em todos os navegadores. Embora a experiência possa ser adaptada para diferentes tamanhos de tela, todos nós esperamos que um site para dispositivos móveis funcione da mesma maneira em dispositivos com tamanhos similares, seja um iPhone ou um smartphone Android.
Mesmo que a Web possa ser considerada fragmentada por causa do número de navegadores em uso em todo o mundo, essa variedade e concorrência ajudam a tornar a Web uma plataforma tão inovadora. Os padrões da Web nunca estiveram tão maduros quanto agora, e ferramentas modernas permitem que os desenvolvedores criem com segurança websites compatíveis com diversos navegadores.
Práticas recomendadas:
Use ferramentas de testes para vários navegadores, como BrowserStack.com, Browserling.com ou BrowserShots.org, para garantir que seu PWA seja compatível com vários navegadores.
Medir o desempenho do carregamento de página
Por quê? Quanto mais rápido um website carrega para um usuário, melhor será a experiência que ele terá. Otimizar sites para aumentar a velocidade das páginas já é uma das prioridades no desenvolvimento para a Web, mas às vezes, ao desenvolver a nova versão de um site, as otimizações necessárias não são consideradas uma alta prioridade.
Ao desenvolver um aplicativo da Web progressivo, recomendamos medir e otimizar o desempenho da velocidade de carregamento das páginas antes de lançar o site, o que permitirá melhores resultados.
Práticas recomendadas:
Use ferramentas como o PageSpeed Insights e o Teste da página da Web para medir o desempenho de carregamento de páginas do seu site. Embora o Googlebot tenha um pouco mais de paciência com a renderização, pesquisas mostram que 40% dos consumidores saem de uma página que leva mais de três segundos para carregar.
Leia mais sobre nossas recomendações de desempenho para as páginas da Web e o caminho crítico da renderização aqui.
Evite deixar para trabalhar na otimização após o lançamento. Se o conteúdo do seu website carrega rapidamente antes da migração para um novo aplicativo da Web progressivo, é importante não provocar retrocessos com as otimizações.
Esperamos que a lista de verificação acima seja útil e forneça as orientações adequadas para ajudar você a desenvolver seus aplicativos da Web progressivos voltados para a indexabilidade.
Enquanto você dá seus primeiros passos, consulte nossas amostras de indexabilidade de Apps Web Progressivos que demonstram as renderizações pelo cliente, pelo servidor e de forma híbrida. Como sempre, se você tiver dúvidas, acesse os fóruns para webmasters.