Os Progressive Web Apps (PWAs) são criados e aprimorados com APIs modernas para oferecer recursos, confiabilidade e facilidade de instalação aprimorados, enquanto alcançam 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 listas de verificação e recomendações core e optimal para se orientar.
Lista de verificação principal do App Web Progressivo
A lista de verificação de Progressive Web Apps descreve o que faz com que um app possa ser instalado e usado por todos os usuários, independentemente do tamanho ou do tipo de entrada.
A performance desempenha 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 as métricas de desempenho 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 também não é interrompido com o evento load. Os usuários nunca devem se perguntar
se a interação deles, por exemplo, o clique 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 são baseadas nas Core Web Vitals. Ter 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 conferir dados de desempenho reais 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 quê?
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.
Seus usuários interagem com seu site em uma variedade de dispositivos e navegadores. Não é possível segmentar apenas o extremo 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 usam 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 em vários navegadores.
Mais informações
- A seção Noções básicas sobre aprimoramento progressivo, de "List Apart", é uma boa introdução ao tópico.
- Smashing Magazine's Progressive Enhancement: What It Is, And How To Use It? 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 sua PWA em qualquer tamanho de tela, e todo o conteúdo dela está disponível em qualquer tamanho de janela de visualização.
Por quê?
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 que o conteúdo se ajuste à janela de visualização e que todos os recursos e o conteúdo do site sejam utilizáveis em todos os tamanhos de janela de visualização.
As tarefas que os usuários querem concluir e o conteúdo que eles querem acessar não mudam com o tamanho da viewport. 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
Há muitos recursos sobre design responsivo, incluindo o artigo original de Ethan Marcotte, uma coleção de conceitos importantes relacionados a ele, além de muitos 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 em dispositivos móveis, as lições em Seven Deadly Mobile Myths (em inglês) de Josh Clark são tão relevantes para visualizações de tamanho pequeno de sites responsivos quanto para dispositivos móveis de modo mais geral.
Quando os usuários estão off-line, manter eles no PWA oferece uma experiência mais simples do que voltar à página off-line padrão do navegador.
Por quê?
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 uma 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 para um URL que não foi armazenado em cache quanto quando ele tenta usar um recurso que requer uma conexão, ajuda a experiência da Web a parecer parte do dispositivo em que ela 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 mostrar quando um usuário ficar off-line. Confira
Criar uma página de substituto off-line
para aprender a implementá-la por conta própria. O Chrome vai
mostrar uma página off-line básica se nenhuma for fornecida.
Os usuários que instalam ou adicionam apps aos dispositivos tendem a se engajar mais com esses apps.
Por quê?
A instalação de um Progressive Web App permite que ele tenha a aparência, a sensação e o comportamento de todos os 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 nos apps específicos para dispositivos, os usuários que instalam seus apps são seu público mais engajado e costumam ter métricas de engajamento equivalentes às dos usuários em dispositivos móveis. Essas métricas incluem mais visitas repetidas, 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 para saber como tornar seu PWA instalável.
Lista de verificação ideal para 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 tem como objetivo fazer com que o app pareça 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 quê?
Além de oferecer uma página off-line personalizada, os usuários esperam que os PWAs sejam 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ê precisa disponibilizar e adaptar seu conteúdo a contextos off-line. Você pode usar o IndexedDB, um sistema de armazenamento NoSQL no navegador, para armazenar e recuperar dados e sincronização em segundo plano para permitir que os usuários realizem ações off-line e adiem 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. Do ponto de vista da experiência do usuário, é possível usar telas de esqueleto que dão aos usuários uma percepção de velocidade e conteúdo durante o carregamento, que podem 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 quê?
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
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 Accessibility Insights
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).
O A11Y Nutrition Cards tem
excelentes conselhos sobre isso para alguns componentes comuns.
Seu PWA pode ser detectado facilmente pela pesquisa.
Por quê?
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. É fundamental garantir que URLs canônicos existam para o conteúdo e que os mecanismos de pesquisa possam indexar seu site para que usuários em potencial encontrem sua 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 com mouse, teclado, stylus ou toque.
Por quê?
Os dispositivos oferecem vários métodos de entrada, e os usuários precisam poder alternar entre eles sem problemas ao usar seu aplicativo. Da mesma forma, os métodos de entrada não podem depender do tamanho da tela, ou seja, as viewports grandes precisam oferecer suporte ao toque, e as 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 controles específicos de entrada (como o "puxe 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 ao toque e ao teclado, use os elementos semânticos corretos (âncoras, botões, controles de formulário etc.) e não os reconstrua 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 poderosas, forneça contexto e peça apenas quando a API for necessária.
Por quê?
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, 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 essas solicitações somente depois de fornecer um motivo para o usuário entender por que você precisa 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 base de código saudável facilita o cumprimento das metas e a entrega de novos recursos.
Por quê?
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á várias 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 o uso de
document.write()ou a presença de listeners de eventos de rolagem não passivos. - Você pode até mesmo programar defensivamente para garantir que o PWA não falhe se a análise ou outras bibliotecas de terceiros não forem carregadas.
- Considere exigir a análise estática do código, como linting, e 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.