Os Progressive Web Apps (PWA) foram criados e aprimorados com APIs modernas para oferecer recursos, confiabilidade e instalação aprimorados, além de alcançar qualquer pessoa, em qualquer lugar e em qualquer dispositivo com uma única base de código. Para criar a melhor experiência possível, use as recomendações e as listas de verificação principais e ideais.
Lista de verificação principal de App Web Progressivo
A lista de verificação de Progressive Web App descreve o que torna um app instalável e utilizável para todos os usuários, independentemente do tamanho ou do tipo de entrada.
O desempenho desempenha um papel significativo no sucesso de qualquer experiência on-line, porque sites de alto desempenho engajam e retêm usuários melhor do que sites de baixo desempenho. Concentre-se na otimização de métricas de desempenho centradas no usuário.
Por que o
A velocidade é fundamental para fazer com que os usuários usem seu app. Na verdade, à medida que o tempo de carregamento da página aumenta de um para dez segundos, a probabilidade de um usuário desistir aumenta em 123%. O desempenho também não é interrompido com o evento load
. Os usuários nunca devem se perguntar
se a interação deles (por exemplo, clicar em um botão) foi
registrada ou não. A rolagem e a animação devem ser suaves.
O desempenho afeta toda a sua 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 se baseiam nas Core Web Vitals. Uma pontuação alta nessas auditorias aumenta as chances de uma experiência agradável aos usuários. Também é possível usar o PageSpeed Insights ou o Chrome User Experience Report para coletar dados de desempenho real do seu app da Web.
Como?
Siga nosso guia sobre tempos de carregamento rápidos para saber como fazer seu PWA ser iniciado rapidamente e permanecer rápido.
Os usuários podem usar qualquer navegador para acessar seu app da Web antes da instalação.
Por que o
Progressive Web Apps são apps da Web primeiro, e isso significa que eles precisam funcionar em vários navegadores.
Uma maneira eficaz de fazer isso é, segundo Jeremy Keith, no curso Resilient Web Design (link em inglês), identificando os principais recursos, disponibilizando-os com a tecnologia mais simples possível e melhorando 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.
Por exemplo, considere o envio de formulários. A maneira mais simples de implementar é usando 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 de formulários e enviá-los por AJAX, melhorando a experiência dos usuários compatíveis.
Os usuários acessam seu site em uma variedade de 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 o maior número possível de usuários em potencial, incluindo aqueles que utilizam navegadores e dispositivos que ainda não existem.
Como?
O Resilient Web Design (link em inglês) de Jeremy Keith é um excelente recurso que descreve como pensar o Web design nessa metodologia progressiva e entre navegadores.
Mais informações
- A seção Noções básicas sobre aprimoramento progressivo, de "List Apart", é uma boa introdução ao tópico.
- Aprimoramento progressivo: o que é e como usar? (em inglês) da Smashing Magazine? fornece uma introdução prática e links para tópicos mais avançados.
- O artigo Como implementar a detecção de recursos da MDN discute como detectar um recurso consultando-o diretamente.
Os usuários podem usar seu PWA em qualquer tamanho de tela, e todo o conteúdo dele está disponível em qualquer tamanho de janela de visualização.
Por que o
Existem dispositivos de vários tamanhos, e os usuários podem usar seu aplicativo em diversos tamanhos, até mesmo no mesmo dispositivo. Portanto, é fundamental garantir não apenas que seu conteúdo se encaixe na janela de visualização, mas que todos os recursos e conteúdos do seu site possam ser usados em todos os tamanhos.
As tarefas que os usuários querem concluir e o conteúdo que eles querem acessar não mudam de acordo com o tamanho da janela de visualização. Você pode reorganizar seu conteúdo para diferentes tamanhos de janela de visualização, e todos eles precisam estar lá, de uma forma ou de outra. 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 nas ações mais importantes de um aplicativo. Simplesmente não há espaço para elementos irrelevantes e desnecessários em uma tela de 320 x 480 pixels. Você precisa priorizar.
Como?
Existem muitos recursos sobre design responsivo, incluindo o artigo original de Ethan Marcotte, uma coleção de conceitos importantes relacionados a ele, além de livros e palestras. Para restringir essa discussão aos aspectos de conteúdo do design responsivo, consulte design que prioriza o conteúdo e layouts responsivos para a saída de conteúdo. Por fim, embora o foco seja dispositivos móveis, as lições do livro Seven Deadly Mobile Myths de Josh Clark são tão relevantes para visualizações pequenas de sites responsivos quanto para dispositivos móveis em geral.
Quando os usuários estão off-line, mantê-los no PWA proporciona uma experiência mais integrada do que retornar à página off-line do navegador padrão.
Por que o
Os usuários esperam que os apps instalados funcionem independentemente 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 o usuário acessa um URL que não foi armazenado em cache quanto quando tenta usar um recurso que exige uma conexão, faz com que sua experiência na Web pareça parte do dispositivo em que está sendo executada.
Como?
Durante o evento install
de um service worker, é possível pré-armazenar em cache
uma página off-line personalizada para uso posterior. Se um usuário ficar off-line, você poderá
responder com a página off-line personalizada pré-armazenada em cache. Siga nosso
exemplo personalizado de página off-line
para conferir um exemplo disso em ação e aprender a implementar por conta própria.
Os usuários que instalam ou adicionam apps aos dispositivos tendem a se engajar mais com esses apps.
Por que o
A instalação de um Progressive Web App permite que ele tenha a aparência e o comportamento dos outros apps instalados. Ele é lançado no mesmo local em que os usuários iniciam os outros apps. Ele é executado na própria janela do app, separada do navegador e aparece na lista de tarefas, assim como outros apps.
Assim como acontece com apps específicos a dispositivos, os usuários que instalam seus apps são o público mais engajado e geralmente têm métricas de engajamento em paridade com os usuários do app em dispositivos móveis. Essas métricas incluem mais visitas repetidas, mais tempo no site e taxas de conversão mais altas do que os visitantes típicos.
Como?
Siga nosso guia de instalação para saber como tornar seu PWA instalável.
Lista de verificação ideal de Progressive Web App
Para criar um PWA realmente incrível, que pareça o melhor app da categoria, você precisa de mais do que apenas a lista de verificação principal. A lista de verificação ideal para PWAs faz com que seu PWA pareça fazer parte do dispositivo em que está sendo executado, aproveitando o que torna a Web poderosa.
Quando a conectividade não é estritamente necessária, seu app funciona off-line da mesma forma que on-line.
Por que o
Além de fornecer uma página off-line personalizada, os usuários esperam que os PWAs possam ser usados off-line. Por exemplo, os apps de viagens e companhias aéreas precisam ter acesso fácil aos detalhes da viagem e aos cartões de embarque quando estiverem off-line. Apps de música, vídeo e podcast precisam permitir a reprodução off-line. Os apps sociais e de 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 se manter autenticados quando estão off-line. Por isso, crie um design para autenticação off-line. Um PWA off-line oferece uma verdadeira experiência semelhante a um app para os usuários.
Como?
Depois de determinar quais recursos os usuários esperam que funcionem off-line, você precisará disponibilizar seu conteúdo e se adaptar a contextos off-line. Use 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 adie as comunicações do servidor até que o usuário tenha uma conexão estável novamente. Também é 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 implementar sessões seguras e de longa duração para manter os usuários autenticados. Da perspectiva da experiência do usuário, você pode usar telas esqueleto que dão aos usuários uma percepção de velocidade e de conteúdo durante o carregamento que pode retornar ao conteúdo armazenado em cache ou a um indicador off-line, conforme necessário.
Todas as interações do usuário atendem aos requisitos de acessibilidade das WCAG 2.0.
Por que o
Em algum momento da vida, a maioria dos usuários quer usar seu PWA de forma coberta pelos requisitos de acessibilidade das WCAG 2.0. A capacidade dos humanos de interagir e entender seu PWA existe em diversas áreas, e as necessidades podem ser temporárias ou permanentes. Ao tornar seu PWA acessível, você pode usá-lo para todos.
Como?
A
Introdução à acessibilidade na Web (link em inglês) do W3C é um bom ponto de partida. A maioria dos testes de acessibilidade precisa ser feita manualmente. Ferramentas como as auditorias de Acessibilidade
no Lighthouse, axe
e Insights de acessibilidade
podem ajudar a automatizar alguns testes de acessibilidade. Também é importante usar elementos semanticamente corretos em vez de recriar esses elementos por conta própria, por exemplo, elementos a
e button
. Isso garante que, quando você precisar criar recursos mais avançados, as expectativas de acessibilidade sejam atendidas (por exemplo, quando usar setas em vez de guias).
A página A11Y Nutrition Cards tem
conselhos excelentes sobre isso para alguns componentes comuns.
Seu PWA pode ser facilmente descoberto por meio de pesquisa.
Por que o
Uma das maiores vantagens da Web é a capacidade de descobrir sites e apps pela pesquisa. Na verdade, mais da metade de todo o tráfego do site vem da pesquisa orgânica. Garantir que os URLs canônicos existam para o conteúdo e que os mecanismos de pesquisa possam indexar seu site é fundamental para permitir que 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 descritivo e exclusivo, além de uma metadescrição. Depois, é possível usar o Google Search Console e as auditorias de Otimização de mecanismos de pesquisa no Lighthouse para depurar e corrigir problemas de detecção no PWA. Também é possível usar as ferramentas de proprietário de site do Bing ou do Yandex (links em inglês) e incluir dados estruturados usando esquemas do Schema.org no PWA.
O PWA pode ser usado igualmente com mouse, teclado, stylus ou toque.
Por que o
Os dispositivos oferecem uma variedade de métodos de entrada, e os usuários precisam ser capazes de alternar entre eles facilmente enquanto usam o app. Da mesma forma, os métodos de entrada não podem depender do tamanho da tela, o que significa que janelas de visualização grandes precisam ser compatíveis com toque e janelas de visualização pequenas precisam oferecer suporte a teclados e mouses. Da melhor maneira possível, verifique se o aplicativo e todos os recursos dele são compatíveis com o uso de qualquer método de entrada escolhido pelo usuário. Quando apropriado, melhore as experiências para permitir também controles específicos de entrada (como puxar para atualizar).
Como?
A API Pointer Events oferece uma interface unificada para trabalhar com várias opções de entrada e é especialmente boa para adicionar suporte à stylus. Para oferecer suporte a toque e teclado, verifique se você está usando 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, verifique se elas também podem ser ativadas com um clique ou toque.
Ao pedir permissão para usar APIs avançadas, forneça contexto e pergunte apenas quando a API for necessária.
Por que o
As APIs que acionam solicitações de permissão, como notificações, geolocalização e credenciais, são projetadas intencionalmente para causar interrupções ao 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, diminui as chances de que os usuários aceitem essas permissões e as chances de não confiar nelas no futuro. Em vez disso, acione essas solicitações somente depois de fornecer uma justificativa contextualizada ao usuário sobre o motivo da necessidade dessa permissão.
Como?
O artigo UX de permissão e o artigo As maneiras certas de pedir permissões aos usuários da UX Planet são bons recursos para entender como projetar solicitações de permissão que, embora com foco em dispositivos móveis, se aplicam a todos os PWAs.
Manter a integridade da sua base de código facilita o cumprimento das suas metas e o fornecimento de novos recursos.
Por que o
Há muito o que fazer na criação de um aplicativo da Web moderno. Manter o aplicativo atualizado e a base de código íntegra facilita o fornecimento de novos recursos que atendam às outras metas estabelecidas nesta lista de verificação.
Como?
Há uma série de verificações de alta prioridade para garantir uma base de código saudável:
- 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 usar
document.write()
ou ter listeners de eventos de rolagem não passivos). - Você pode até mesmo codificar de maneira defensiva para garantir que seu PWA não seja corrompido se análises ou outras bibliotecas de terceiros não forem carregadas.
- Considere exigir análise de código estático, como lint, 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.