Os Progressive Web Apps (PWAs) são criados e aprimorados com APIs modernas para oferecer recursos, confiabilidade e facilidade de instalação aprimorados, alcançando qualquer pessoa, em qualquer lugar e em qualquer dispositivo com uma única base de código. Para ajudar você a criar a melhor experiência possível, use as listas de verificação e recomendações principais e ideais.
Lista de verificação principal de Progressive Web App
A lista de verificação de Progressive Web Apps descreve o que torna um app instalável e usável por todos os usuários, independente do tamanho ou do tipo de entrada.
Começa rápido, continua rápido
O desempenho tem um papel significativo no sucesso de qualquer experiência on-line, porque sites de alta performance engajam e retêm usuários melhor do que sites de baixo desempenho. Concentre-se em otimizar métricas de performance centradas no usuário.
Por quê?
A velocidade é fundamental para que os usuários usem seu app. Na verdade, à medida que o tempo de carregamento da página aumenta de um segundo para dez segundos, a probabilidade de rejeição de um usuário aumenta em 123%. O desempenho não para com o evento load. Os usuários nunca devem se perguntar se a interação deles, como
clicar em um botão, foi registrada ou não. A rolagem e a animação precisam ser suaves. O desempenho afeta toda a experiência, tanto no comportamento do app quanto na percepção dos usuários.
Embora todos os aplicativos tenham necessidades diferentes, as auditorias de desempenho no Lighthouse são baseadas nas Core Web Vitals, e uma pontuação alta nessas auditorias aumenta a probabilidade de os usuários terem uma experiência agradável. Você também pode usar o PageSpeed Insights ou o Chrome User Experience Report para receber dados de desempenho reais do seu web app.
Como
Siga nosso guia sobre tempos de carregamento rápidos para saber como fazer seu PWA iniciar e permanecer rápido.
Funciona em qualquer navegador
Os usuários podem usar qualquer navegador para acessar seu web app antes da instalação.
Por quê?
Os Progressive Web Apps são apps da Web primeiro, o que significa que eles precisam funcionar em vários navegadores.
Uma maneira eficaz de fazer isso é, de acordo com Jeremy Keith em Resilient Web Design, identificar os recursos principais, disponibilizar esses recursos usando a tecnologia mais simples possível e, em seguida, melhorar a experiência sempre que possível. Em muitos casos, isso significa começar apenas com HTML para criar os recursos principais e melhorar a experiência do usuário com CSS e JavaScript para criar uma experiência mais envolvente.
Considere o envio de formulários, por exemplo. A maneira mais simples de fazer isso é com um formulário HTML que envia uma solicitação POST. Depois de criar isso, você pode melhorar a
experiência com JavaScript para fazer a validação e o envio do formulário por
AJAX, melhorando a experiência para usuários que podem usar esse recurso.
Os usuários acessam seu site em vários dispositivos e navegadores. Não é possível segmentar apenas a extremidade superior desse espectro. Use a detecção de recursos para oferecer uma experiência utilizável para a maior variedade possível de usuários em potencial, incluindo aqueles que usam navegadores e dispositivos que ainda não existem.
Como
O Resilient Web Design de Jeremy Keith é um excelente recurso que descreve como pensar no design da Web nessa metodologia progressiva e entre navegadores.
Mais informações
- Understanding Progressive Enhancement (em inglês) do A List Apart é uma boa introdução ao assunto.
- O artigo Progressive Enhancement: What It Is, And How To Use It? (em inglês) da Smashing Magazine oferece uma introdução prática e links para tópicos mais avançados.
- O artigo Implementando a detecção de recursos (link em inglês) da MDN discute como detectar um recurso consultando-o diretamente.
Adaptável a qualquer tamanho de tela
Os usuários podem usar seu PWA em qualquer tamanho de tela, e todo o conteúdo está disponível em qualquer tamanho de viewport.
Por quê?
Os dispositivos vêm em uma variedade de tamanhos, e os usuários podem usar seu aplicativo em uma variedade de tamanhos, mesmo no mesmo dispositivo. Portanto, é fundamental garantir que o conteúdo se ajuste à janela de visualização e que todos os recursos e o conteúdo do site possam ser usados em todos os tamanhos de janela.
As tarefas que os usuários querem concluir e o conteúdo que querem acessar não mudam com o tamanho da janela de visualização. Você pode reorganizar o conteúdo para diferentes tamanhos de viewport, e ele vai estar lá, de um jeito ou de outro. Na verdade, como Luke Wroblewski afirma no livro Mobile First, começar pequeno e ajustar o design para telas maiores pode melhorar o design de um site:
"Os dispositivos móveis exigem que as equipes de desenvolvimento de software se concentrem apenas nos dados e ações mais importantes de um aplicativo. Não há espaço em uma tela de 320 por 480 pixels para elementos desnecessários. Você precisa priorizar."
Como
Há muitos recursos sobre design responsivo, incluindo: o artigo original de Ethan Marcotte e uma coleção de conceitos importantes relacionados a ele, além de vários livros e palestras.
Para restringir essa discussão aos aspectos de conteúdo do design responsivo, consulte:
- Design com foco no conteúdo
- Layouts responsivos de conteúdo externo.
- Sete mitos mortais sobre dispositivos móveis, que é tão relevante para visualizações pequenas de sites responsivos quanto para todos os dispositivos móveis.
Fornece uma página off-line personalizada
Quando os usuários estão off-line, mantê-los no PWA oferece uma experiência mais integrada do que voltar para a página off-line do navegador padrão.
Por quê?
Os usuários esperam que os apps instalados funcionem independente do status da conexão. Um app específico da plataforma nunca mostra uma página em branco quando está off-line, e um PWA nunca deve mostrar a página off-line padrão do navegador. Oferecer uma experiência off-line personalizada, tanto quando um usuário navega até um URL que não foi armazenado em cache quanto quando ele tenta usar um recurso que exige uma conexão, ajuda a fazer com que a experiência na Web pareça parte do dispositivo em que está sendo executada.
Como
Durante um evento install de service worker, é possível pré-armazenar em cache uma página off-line personalizada para mostrar quando um usuário fica off-line. Leia
Criar uma página de substituição off-line para saber como
implementá-la. O Chrome continua mostrando uma página off-line básica se nenhuma for fornecida.
Pode ser instalado
Os usuários que instalam ou adicionam apps aos dispositivos tendem a interagir mais com eles.
Por quê?
Ao instalar um App Web Progressivo, ele tem a mesma aparência, sensação e comportamento de todos os outros apps instalados. Ele é iniciado no mesmo lugar em que os usuários iniciam os outros apps. Ele é executado em uma janela separada do navegador e aparece na lista de tarefas, assim como outros apps.
Assim como nos apps específicos para dispositivos, os usuários que instalam seus apps são seu público mais engajado e geralmente têm métricas de engajamento equivalentes aos usuários de apps em dispositivos móveis. Essas métricas incluem mais visitas recorrentes, mais tempo no seu site e taxas de conversão mais altas do que os visitantes típicos.
Como
Siga nosso guia de instalação.
Lista de verificação ideal para Progressive Web Apps
Para criar um PWA realmente incrível, que pareça um app de primeira classe, você precisa de mais do que apenas a lista de verificação principal. A lista de verificação ideal do PWA é sobre fazer com que o PWA pareça fazer parte do dispositivo em que está sendo executado, aproveitando o que torna a Web poderosa.
Oferece uma experiência off-line
Quando a conectividade não é estritamente necessária, o app funciona off-line da mesma forma que on-line.
Por quê?
Além de fornecer uma página off-line personalizada, os usuários esperam que os PWAs sejam utilizáveis off-line. Por exemplo, os apps de viagens e companhias aéreas precisam ter detalhes da viagem e cartões de embarque disponíveis off-line. Os apps de música, vídeo e podcast precisam permitir a reprodução off-line. Os apps de redes sociais e notícias precisam armazenar em cache o conteúdo recente para que os usuários possam ler off-line. Os usuários também esperam permanecer autenticados quando estão off-line. Portanto, crie um design para autenticação off-line.
Um PWA off-line oferece aos usuários uma experiência semelhante a um app.
Como
Depois de determinar quais recursos seus usuários esperam que funcionem off-line, você precisa disponibilizar e adaptar seu conteúdo para contextos off-line. Você pode usar o IndexedDB, um sistema de armazenamento NoSQL no navegador, para armazenar e recuperar dados, e a sincronização em segundo plano para permitir que os usuários realizem ações off-line e adiem as comunicações com o servidor até que o usuário tenha uma conexão estável novamente. É possível usar service workers para armazenar outros tipos de conteúdo, como imagens, arquivos de vídeo e arquivos de áudio, para uso off-line, e para implementar sessões seguras e de longa duração para manter os usuários autenticados.
Do ponto de vista da experiência do usuário, você pode usar telas esqueleto que dão aos usuários uma percepção de velocidade e conteúdo durante o carregamento, que pode então voltar ao conteúdo armazenado em cache ou a um indicador off-line, conforme necessário.
Totalmente acessível
Todas as interações do usuário atendem ao mais recente padrão internacional das Diretrizes de Acessibilidade para Conteúdo Web (WCAG).
Por quê?
A maioria dos usuários, em algum momento da vida, quer usar seu PWA de uma forma coberta pela WCAG. A capacidade dos humanos de interagir e entender seu PWA existe em um espectro, e as necessidades podem ser temporárias ou permanentes. Ao tornar seu PWA acessível, você o torna utilizável para todos.
Como
A Introdução à acessibilidade na Web do W3C (link em inglês) é um bom ponto de partida. A maioria dos testes de acessibilidade precisa ser feita manualmente. A auditoria de acessibilidade no Lighthouse, o axe e o Accessibility Insights podem ajudar você a automatizar alguns testes de acessibilidade. Também é importante usar elementos semanticamente
corretos em vez de recriar esses elementos por conta própria, como <a>
e <button>. Isso garante que, quando você precisar criar recursos mais
avançados, as expectativas de acessibilidade sejam atendidas, como quando usar
setas em vez de guias.
O A11Y Nutrition Cards tem excelentes conselhos sobre isso para alguns componentes comuns.
Ser encontrado na pesquisa
Seu PWA pode ser descoberto facilmente por meio da pesquisa.
Por quê?
Uma das maiores vantagens da Web é a capacidade de descobrir sites e apps por meio da pesquisa. Na verdade, mais da metade de todo o tráfego do site vem da pesquisa orgânica. É fundamental garantir que os URLs canônicos existam para o conteúdo e que os mecanismos de pesquisa possam indexar seu site para que os usuários em potencial encontrem seu PWA. Isso é especialmente verdadeiro ao adotar a renderização do lado do cliente.
Como
Comece garantindo que cada URL tenha um título e uma metadescrição exclusivos e descritivos. Em seguida, use o Google Search Console e as auditorias de otimização para mecanismos de pesquisa no Lighthouse para depurar e corrigir problemas de capacidade de descoberta com seu PWA.
Você também pode usar as ferramentas para proprietários de sites do Bing ou do Yandex e incluir dados estruturados usando esquemas do Schema.org no seu PWA.
Funciona com qualquer tipo de entrada
Seu PWA pode ser usado com um mouse, um teclado, uma stylus ou toque.
Por quê?
Os dispositivos oferecem vários métodos de entrada, e os usuários precisam conseguir alternar entre eles sem problemas ao usar seu aplicativo. Da mesma forma, os métodos de entrada não devem depender do tamanho da tela. Isso significa que janelas de visualização grandes precisam oferecer suporte a toque, e janelas pequenas precisam oferecer suporte a teclados e mouses. Na medida do possível, verifique se o aplicativo e todos os recursos dele oferecem suporte ao uso de qualquer método de entrada que o usuário possa escolher. Quando apropriado, melhore as experiências para permitir controles específicos de entrada também (como puxar para atualizar).
Como
A API Pointer Events oferece uma interface unificada para trabalhar com várias opções de entrada e é especialmente útil para adicionar suporte a stylus. Para oferecer suporte a toque e teclado, use os elementos semânticos corretos (âncoras, botões, controles de formulário etc.) e não os recrie com HTML não semântico. Ao incluir interações que são ativadas ao passar o cursor do mouse, verifique se elas também podem ser ativadas com um clique ou toque.
Fornece contexto para solicitações de permissão
Ao pedir permissão para usar APIs avançadas, forneça contexto e peça apenas quando a API for necessária.
Por quê?
As APIs que acionam uma solicitação de permissão, como notificações, geolocalização e credenciais, são projetadas intencionalmente para interromper o usuário porque tendem a estar relacionadas a recursos avançados que exigem ativação. Acionar essas solicitações sem contexto adicional, como no carregamento da página, faz com que os usuários tenham menos probabilidade de aceitar essas permissões e mais probabilidade de desconfiar delas no futuro.
Em vez disso, acione esses prompts somente depois de fornecer ao usuário uma justificativa no contexto de por que você precisa dessa permissão.
Como
O artigo UX de permissão e As maneiras certas de pedir permissões aos usuários do UX Planet são bons recursos para entender como criar solicitações de permissão que, embora focadas em dispositivos móveis, se aplicam a todos os PWAs.
Segue as práticas recomendadas para um código saudável
Manter a integridade da base de código facilita o alcance das metas e a entrega de novos recursos.
Por quê?
Há muito trabalho envolvido na criação de um aplicativo da Web moderno. Manter seu aplicativo atualizado e a base de código íntegra facilita a entrega de novos recursos que atendam às outras metas estabelecidas nesta lista de verificação.
Como
Há várias verificações de alta prioridade para garantir um codebase íntegro:
- Evite usar bibliotecas com vulnerabilidades conhecidas.
- Verifique se você não está usando APIs descontinuadas.
- Remova práticas de programação não seguras da sua base de código, como
document.write()ou ter listeners de eventos de rolagem não passivos. - Você pode até mesmo programar de forma defensiva para garantir que seu PWA não falhe se o Google Analytics ou outras bibliotecas de terceiros não forem carregadas.
- Considere exigir análise de código estático, como linting, além de testes automatizados em vários navegadores e canais de lançamento. Essas técnicas podem ajudar a detectar erros antes que eles cheguem à produção.