PRPL é um acrônimo que descreve um padrão usado para fazer com que as páginas da Web sejam carregadas e tornadas interativas mais rapidamente:
- Carregue os recursos descobertos mais tarde.
- Renderize a rota inicial o mais rápido possível.
- Armazene em cache os recursos restantes.
- Carregar lentamente outras rotas e recursos não críticos.
Neste guia, aprenda como cada uma dessas técnicas se encaixa, mas ainda pode ser usada de forma independente para alcançar resultados de performance.
Auditar sua página com o Lighthouse
Execute o Lighthouse para identificar oportunidades de melhoria alinhadas às técnicas PRPL:
- Pressione "Control+Shift+J" (ou "Command+Option+J" no Mac) para abrir o DevTools.
- Clique na guia Lighthouse.
- Marque as caixas de seleção Performance e App Web Progressivo.
- Clique em Executar auditorias para gerar um relatório.
Para mais informações, consulte Descubra oportunidades de desempenho 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 informa ao navegador que ele precisa solicitar um recurso que não pode ser descoberto pelo scanner de pré-carregamento do navegador, como uma imagem referenciada pela propriedade background-image. Carregue os recursos descobertos mais tarde 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"> vai iniciar uma solicitação para esse recurso e armazená-lo no cache. O navegador pode extrair o arquivo quando necessário.
Para mais informações sobre o pré-carregamento de recursos críticos, consulte o guia Pré-carregar recursos críticos.
Renderizar a rota inicial o mais rápido possível
O Lighthouse mostra um aviso quando há recursos que atrasam a First Paint, no momento em que o site renderiza pixels na tela:
Para melhorar a first paint, o Lighthouse recomenda incluir o JavaScript crítico inline e
adiar o restante usando
async,
bem como incluir o CSS crítico inline usado acima da dobra. Isso melhora a performance,
eliminando idas e voltas ao servidor para buscar recursos que bloqueiam a renderização.
No entanto, o código inline é mais difícil de manter 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 no servidor o HTML inicial da sua página. Isso mostra o conteúdo imediatamente ao usuário enquanto os scripts ainda estão sendo buscados, analisados e executados. No entanto, isso pode aumentar significativamente o payload do arquivo HTML, o que pode prejudicar o Tempo para interação, ou seja, o tempo que leva para o aplicativo se tornar interativo e responder à entrada do usuário.
Não há uma única solução correta para reduzir a First Paint no seu aplicativo. Considere apenas a renderização in-line de estilos e a renderização do lado do servidor se os benefícios superarem as compensações para o aplicativo. Saiba mais sobre esses dois conceitos com os recursos a seguir.
Pré-cachear recursos
Agindo como um proxy, os service workers podem buscar recursos diretamente do cache, em vez de do servidor, em visitas repetidas. Isso permite que os usuários usem seu aplicativo quando estão off-line, além de resultar em tempos de carregamento de página mais rápidos em visitas repetidas.
Use 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 os que uma biblioteca pode oferecer. Por exemplo, o Workbox oferece um conjunto de ferramentas que permitem criar e manter um worker de serviço 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 mostra uma auditoria com falha se você enviar muitos dados pela rede.
Isso inclui todos os tipos de recursos, mas payloads JavaScript grandes são especialmente custosos devido ao tempo que o navegador leva para analisar e compilar. O Lighthouse também oferece um aviso para isso quando apropriado.
Para enviar um payload JavaScript menor que contém apenas o código necessário quando um usuário carrega o aplicativo pela primeira vez, divida o pacote inteiro e os fragmentos de carregamento lento sob demanda.
Depois de dividir o pacote, pré-carregue os blocos mais importantes (consulte o guia Pré-carregar recursos essenciais). O pré-carregamento garante que recursos mais importantes sejam buscados e transferidos mais rapidamente pelo navegador.
Além de dividir e carregar diferentes blocos de JavaScript sob demanda, o Lighthouse também oferece uma auditoria de carregamento lento de imagens não críticas.
Se você carregar muitas imagens na página da Web, adie todas as que estiverem abaixo da dobra ou fora da janela de visualização do dispositivo quando uma página for carregada (consulte Usar lazysizes para carregar imagens de forma lenta).
Próximas etapas
Agora que você entende alguns dos conceitos básicos por trás do padrão PRPL, continue para o próximo guia desta seção para saber mais. É importante lembrar que nem todas as técnicas precisam ser aplicadas juntas. Qualquer esforço feito com qualquer um dos seguintes itens vai proporcionar melhorias perceptíveis no desempenho.
- Pré-carregue recursos críticos.
- Renderize a rota inicial o mais rápido possível.
- Armazene em cache os recursos restantes.
- Carregar com atraso outras rotas e recursos não críticos.
Leia mais sobre os padrões PRPL (em inglês).