PRPL é um acrônimo que descreve um padrão usado para fazer com que as páginas da Web carreguem e se tornar interativo e mais rápido:
- Pré-carregue os recursos descobertos tardiamente.
- Renderize a rota inicial o mais rápido possível.
- Pré-armazenar em cache os recursos restantes.
- Carregar lentamente outras rotas e recursos não críticos.
Neste guia, você aprenderá como cada uma dessas técnicas se encaixa, mas ainda pode ser usados independentemente para alcançar resultados de desempenho.
Auditar sua página com o Lighthouse
Executar o Lighthouse para identificar oportunidades de melhoria alinhadas ao PRPL técnicas:
- Pressione "Control+Shift+J" (ou "Command+Option+J" no Mac) para abrir o DevTools.
- Clique na guia Lighthouse.
- Marque as caixas de seleção Desempenho e Progressive Web App.
- Clique em Executar auditorias para gerar um relatório.
Para mais informações, consulte Descobrir oportunidades de performance com o Lighthouse.
Pré-carregar recursos críticos
O Lighthouse mostra a seguinte auditoria com falha se um determinado recurso for analisado e buscado com atraso:
Pré-carregamento
é uma solicitação de busca declarativa que diz ao navegador para solicitar um recurso que não seria detectável pelo verificador de pré-carregamento do navegador, como uma imagem referenciada pela propriedade background-image. Pré-carregue recursos descobertos tardiamente adicionando uma tag <link> com rel="preload" ao cabeçalho do documento HTML:
<link rel="preload" as="image" href="hero-image.jpg">
Adicionar uma diretiva <link rel="preload"> iniciará uma solicitação para esse recurso e o armazenará no cache. O navegador poderá, então, recuperá-las quando necessário.
Para mais informações sobre o pré-carregamento de recursos críticos, consulte a Guia Pré-carregar recursos essenciais.
Renderizar a rota inicial o mais rápido possível
O Lighthouse gera um aviso quando há recursos que atrasam a First Paint, o momento em que o site renderiza pixels na tela:
Para melhorar a First Paint, o Lighthouse recomenda embutir elementos essenciais do JavaScript e
adiando o restante usando
async,
assim como a inserção in-line do CSS crítico usado acima da dobra. Isso melhora a performance
eliminando viagens de ida e volta ao servidor para buscar recursos que bloqueiam a renderização.
No entanto, é mais difícil manter o código embutido do ponto de vista do desenvolvimento e
não pode ser armazenado em cache separadamente pelo navegador.
Outra abordagem para melhorar a First Paint é renderizar pelo servidor o processo HTML da sua página. Isso exibe conteúdo imediatamente ao usuário enquanto os scripts ainda estão sendo buscados, analisados e executados. No entanto, isso pode aumentar do arquivo HTML significativamente, o que pode prejudicar o Time to Interactive, ou o tempo que leva para o aplicativo se tornar interativo e conseguir responder à entrada do usuário.
Não há uma única solução correta para reduzir a First Paint em e considere apenas estilos in-line e do lado do servidor a renderização se os benefícios superarem as compensações para o aplicativo. Você pode saiba mais sobre esses dois conceitos com os recursos a seguir.
Pré-armazenar recursos em cache
Ao atuar como proxy, os service workers podem buscar recursos diretamente do cache e não o servidor em visitas repetidas. Isso não só permite que os usuários usem seus aplicativo quando estiverem off-line, mas também resulta em tempos de carregamento de página mais rápidos em visitas repetidas.
Usar uma biblioteca de terceiros para simplificar o processo de geração de um service worker a menos que você tenha requisitos de armazenamento em cache mais complexos do que uma biblioteca que oferecem. Por exemplo: O Workbox oferece uma de ferramentas que permitem criar e manter um service worker para armazenar recursos em cache. Para mais informações sobre service workers e confiabilidade off-line, consulte o guia do service worker no programa de aprendizado sobre confiabilidade.
Carregamento lento
O Lighthouse exibe uma auditoria com falha se você enviar muitos dados pela rede.
Isso inclui todos os tipos de recursos, mas payloads grandes de JavaScript são especialmente devido ao tempo que o navegador leva para analisá-los e compilá-los. O Lighthouse também mostra um alerta quando apropriado.
Para enviar um payload menor de JavaScript que contenha apenas o código necessário quando um o usuário carrega inicialmente seu aplicativo, divida o pacote inteiro e faça o carregamento lento em blocos sob demanda.
Uma vez que você tiver conseguido dividir seu pacote, pré-carregue os blocos que são mais importante (consulte o guia Pré-carregar recursos críticos). O pré-carregamento garante que os recursos mais importantes sejam buscados e baixados mais rapidamente pelo navegador.
Além de dividir e carregar diferentes blocos JavaScript sob demanda, O Lighthouse também oferece auditorias de carregamento lento de imagens não críticas.
Se você carregar muitas imagens em sua página da Web, adie todas que estão abaixo da dobra ou fora da janela de visualização do dispositivo quando uma página é carregada. Consulte Usar Slowsizes para carregar imagens lentamente;
Próximas etapas
Agora que você entende alguns dos conceitos básicos por trás do padrão PRPL, acesse o próximo guia nesta seção para saber mais. É importante lembrar que nem todas as técnicas precisam ser aplicadas juntas. Todos os esforços feitos com qualquer um dos itens a seguir fornecerão melhorias de desempenho perceptíveis.
- Pré-carregue recursos críticos.
- Renderize a rota inicial o mais rápido possível.
- Pré-armazenar em cache os recursos restantes.
- Carregar lentamente outras rotas e recursos não críticos.
Leia mais sobre os padrões PRPL (em inglês).