Os Progressive Web Apps (PWA) foram criados e aprimorados com APIs modernas para oferecer recursos aprimorados, confiabilidade e instalação, além de alcançar qualquer pessoa, em qualquer lugar, em qualquer dispositivo com uma única base de código. Para ajudar você a criar a melhor experiência possível, use os atributos principal e ideal checklists e recomendações para guiá-lo.
Lista de verificação de Progressive Web Apps principais
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.
O desempenho desempenha um papel significativo no sucesso de qualquer porque sites de alto desempenho engajam e retêm melhor os usuários do que os 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
para 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 precisam ser suaves.
O desempenho afeta toda a experiência, tanto na forma como seu app
se comporta e como os usuários o percebem.
Embora cada aplicativo tenha necessidades diferentes, o desempenho audita O Lighthouse tem como base as Core Web Vitals, e uma pontuação alta nessas auditorias tornará seus usuários mais propensos 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 com que seu PWA inicie e permaneça rápido.
Os usuários podem usar qualquer navegador para acessar seu aplicativo da Web antes que ele seja instalado.
Por quê?
Progressive Web Apps são aplicativos da Web primeiro, e isso 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, disponibilizá-los usando a tecnologia mais simples possível e, em seguida, aprimorar a experiência sempre que possível. Em muitos casos, isso significa começar com apenas 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, o envio de formulários. A maneira mais simples de implementar isso é
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
do formulário e enviar o formulário pelo AJAX, melhorando a experiência
para os usuários que podem oferecer suporte a ele.
Seus usuários utilizam seu site em uma variedade de dispositivos e navegadores padrão. 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 usam navegadores e dispositivos que ainda não existem.
Como
Web design resiliente de Jeremy Keith é um excelente recurso que descreve como pensar sobre o web design de essa metodologia progressiva e em vários navegadores.
Mais informações
- de Lista separada Noções básicas sobre o aprimoramento progressivo é uma boa introdução ao tópico.
- Smashing Magazine Aprimoramento progressivo: o que é e como usar? oferece uma introdução prática e links para tópicos mais avançados.
- MDNs Implementar a detecção de recursos o artigo 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ê?
Os dispositivos têm vários tamanhos, e os usuários podem usar seu aplicativo em vários tamanhos, mesmo no mesmo dispositivo. Portanto, é essencial garante não apenas que seu conteúdo se encaixe na janela de visualização, mas que todas os recursos e o conteúdo do seu site possam ser usados 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 tudo deve estar lá, de um jeito ou para outra. Na verdade, como Luke Wroblewski afirma no livro Mobile First, começar pequeno e ajustar seu design para telas maiores pode melhorar um no design do site:
Os dispositivos móveis exigem que as equipes de desenvolvimento de software se concentrem em apenas os dados e as ações mais importantes de um aplicativo. Simplesmente não há espaço em uma tela de 320 por 480 pixels para os elementos. Você precisa priorizar.
Como
Existem muitos recursos sobre design responsivo, incluindo original artigo de Ethan Marcotte, um(a) uma coleção de conceitos importantes relacionados, além de livros e palestras. Para restringir essa discussão aos aspectos de conteúdo do design responsivo, consulte design com foco no conteúdo e layouts responsivos de conteúdo externo. 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, mantê-los no PWA oferece uma experiência uma experiência perfeita do que voltar para o navegador padrão off-line página.
Por quê?
Os usuários esperam que os apps instalados funcionem independentemente da conexão o status atual da conta. 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. Proporcionar uma experiência off-line personalizada, tanto quando o usuário navega até uma URL que não foi armazenado em cache e quando um usuário tenta usar um recurso que requer uma conexão, faz com que sua experiência na web pareça parte do dispositivo em que está sendo executado.
Como
Durante o evento install de um service worker, é possível pré-armazenar em cache
uma página off-line personalizada que aparece quando um usuário fica off-line. Finalizar compra
Criar uma página substituta off-line
para aprender a implementar por conta própria. O Chrome
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 com eles mais apps.
Por quê?
A instalação de um Progressive Web App permite que ele tenha a aparência e o comportamento todos os outros apps instalados. É lançado no mesmo local onde os usuários acessam nos outros aplicativos. Ele é executado na própria janela do app, separada do navegador e ela aparece na lista de tarefas, assim como os outros aplicativos.
Assim como nos apps específicos do dispositivo, os usuários que instalam seus apps são os mais público-alvo engajado e geralmente têm métricas de engajamento em paridade com as do app 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 o normal visitantes.
Como
Siga nosso guia de instalação. para saber como tornar seu PWA instalável.
Lista de verificação de Progressive Web Apps ideais
Para criar um PWA realmente incrível, que pareça o melhor app da categoria, você precisa 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 da mesma forma off-line quanto on-line.
Por quê?
Além de fornecer uma página off-line personalizada, os usuários esperam que os PWAs sejam pode ser usado off-line. Por exemplo, os apps de viagens e companhias aéreas precisam ter uma versão detalhes e cartões de embarque disponíveis quando você estiver off-line. Música vídeos e podcasts precisam permitir a reprodução off-line. 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, projete para autenticação off-line. Um PWA off-line oferece uma 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. Você também pode usar workers de serviço para armazenar outros tipos de conteúdo, como imagens, arquivos de vídeo e á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 são aprovadas nas WCAG 2.0 requisitos de acessibilidade.
Por quê?
A maioria dos usuários, em algum momento, quer usar seu PWA de uma forma coberta pelos requisitos de acessibilidade do WCAG 2.0. A capacidade das pessoas de interagir e entender sua PWA existe em um espectro, e as necessidades podem ser temporárias ou permanentes. Ao tornar seu PWA acessível, você pode usá-lo para todos.
Como
do W3C
Introdução à acessibilidade na Web
é um bom ponto de partida. A maioria dos testes de acessibilidade precisa ser
feita manualmente. Ferramentas como a página de Acessibilidade
auditorias no Lighthouse, axe,
e Insights de acessibilidade
pode 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 aplicativos mais avançados
recursos, as expectativas de acessibilidade são atendidas (como o uso de setas
em comparação com as guias).
O A11Y Nutrition Cards tem
excelentes conselhos sobre isso para alguns componentes comuns.
Seu PWA pode ser facilmente descoberto usando a 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. Garantir que há URLs canônicos para o conteúdo e os mecanismos de pesquisa podem indexar é fundamental para permitir que usuários em potencial encontrem seu PWA. Isso é especialmente ao adotar a renderização do lado do cliente.
Como
Comece verificando se cada URL tem um título descritivo e uma metadescrição exclusivos. 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 visibilidade no seu PWA. Você também podem usar os recursos do Bing ou no site da Yandex do proprietário e considere incluir dados estruturados usando esquemas do Schema.org no PWA.
O PWA pode ser usado igualmente 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. 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, como puxar para atualizar.
Como
A API Pointer Events oferece uma interface unificada para trabalhar com várias opções de entrada e é especialmente bom 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 por clique ou toque.
Ao pedir permissão para usar APIs avançadas, forneça contexto e pergunte apenas quando a API é 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 a ativação. Acionar esses comandos sem contexto adicional, como no carregamento da página, torna os usuários menos propensos a aceitar essas permissões e mais propensos a deixar de confiar neles no futuro. Em vez disso, acione esses comandos somente depois fornecendo ao usuário uma justificativa contextualizada para o motivo de você precisar disso permissão.
Como
O artigo UX de permissões e o artigo da UX Planet As maneiras certas de pedir permissões aos usuários são bons recursos para entender como projetar solicitações de permissões que, embora se concentrem em dispositivos móveis, se aplicam a todos os PWAs.
Manter a integridade da sua base de código torna mais fácil atingir seus objetivos e entregar novos recursos.
Por quê?
Há muito o que fazer na criação de um aplicativo da Web moderno. Manter o aplicativo atualizado e a integridade da base de código para fornecer novos recursos que atendam às outras metas estabelecidas esta lista de verificação.
Como
Há diversas verificações de alta prioridade para garantir codebase:
- Evite usar bibliotecas com vulnerabilidades conhecidas.
- Verifique se você não está usando APIs descontinuadas.
- Remova práticas não seguras da sua base de código (como usar
document.write()ou com um evento de rolagem não passivo ouvintes), - 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 a possibilidade de exigir análise de código estático, como lint, além de testes automatizados em vários navegadores e canais de lançamento. Esses podem ajudar a detectar erros antes que cheguem à produção.