Gerir o desempenho de um website é fácil de gerir. Gerir o desempenho de dez websites, cinco apps móveis e vários microsserviços é complexo.
Um só site: o painel mostra LCP, CLS, INP. A equipa foca-se numa página de cada vez.
Empresa grande: o painel mostra centenas de páginas, vários produtos, várias plataformas. A equipa precisa de definir prioridades.
Escalar a análise de desempenho significa: escolher o que medir, escolher o que otimizar, distribuir a responsabilidade pelas equipas.
Exemplo: uma empresa tem cinco produtos (plataforma web, app móvel, painel, ferramenta de análise, API). Cada produto tem um perfil de desempenho diferente. Cada produto é mantido por uma equipa diferente. A equipa central de desempenho não consegue otimizar tudo. Solução: definir padrões de desempenho, cada equipa é responsável pelo desempenho do seu produto, a equipa central monitoriza o desempenho agregado.
Escolher o que medir à escala empresarial
Mede apenas os percursos críticos. Plataforma de loja online: página inicial, produto, pagamento (críticos). Blogue, página sobre nós (não críticas). Foca-te nos percursos críticos.
Mede por linha de produto. Plataforma SaaS: página de registo, painel, página de definições. Cada equipa é responsável pelas suas páginas. Cada equipa acompanha o seu desempenho.
Mede por impacto no negócio. As páginas que geram receita contam mais. As páginas com pouco tráfego contam menos. Foca-te nas páginas que geram receita.
Exemplo real: uma empresa com três linhas de produto:
- Produto A (loja online): página inicial, produto, pagamento, pesquisa
- Produto B (SaaS): registo, painel, definições, integração
- Produto C (conteúdo): página inicial do blogue, artigo, comentários, artigos relacionados
Prioridade de medição:
- Produto A (mais tráfego, mais receita): medir todas as páginas
- Produto B (muito tráfego, muita receita): medir as páginas críticas (registo, painel)
- Produto C (pouco tráfego, pouca receita): medir só a página inicial
Distribuir a responsabilidade pelo desempenho
A equipa central define os padrões. Cada equipa é responsável pelo desempenho do seu produto.
Padrões: todas as páginas devem ter LCP abaixo de dois vírgula cinco segundos, CLS abaixo de zero vírgula um, INP abaixo de duzentos milissegundos.
Modelo de responsabilidade:
- Equipa do produto A: responsável pelo desempenho da página inicial, produto, pagamento, pesquisa
- Equipa do produto B: responsável pelo desempenho do registo, painel, definições
- Equipa do produto C: responsável pelo desempenho da página inicial do blogue
- Equipa central de desempenho: monitoriza o cumprimento, dá alertas de regressão, fornece ferramentas
Exemplo real: uma empresa de SaaS com três equipas de engenharia.
Padrões (definidos pela equipa central de desempenho):
- Objetivo de LCP: dois segundos (os objetivos por produto podem variar, mas a base é de dois segundos)
- Objetivo de CLS: zero vírgula zero cinco
- Objetivo de INP: cento e cinquenta milissegundos
Responsabilidade das equipas de produto:
- Equipa da plataforma: o painel deve manter o LCP abaixo de dois segundos
- Equipa de integrações: a página de integrações deve manter o LCP abaixo de dois vírgula cinco segundos
- Equipa de análise: a página de análise deve manter o LCP abaixo de dois segundos
Cada equipa mede as suas páginas. O painel dá um alerta se as páginas de uma equipa excederem os padrões. A equipa é responsável.
Agregar o desempenho entre produtos
O painel agregado mostra: todos os produtos, todas as páginas, cumprimento dos padrões.
O painel mostra a percentagem de produtos que cumprem o padrão: noventa por cento das páginas têm LCP abaixo de dois vírgula cinco segundos. Zona verde.
O painel mostra que produtos não cumprem: o produto B tem oitenta por cento de cumprimento (duas páginas excedem o padrão). Zona amarela.
Relatório à direção: o desempenho agregado é forte (noventa por cento das páginas cumprem). Um produto precisa de atenção (produto B).
Ação: a equipa do produto B é alertada. A equipa investiga. A equipa otimiza as páginas que não cumprem.
Exemplo real: desempenho agregado de uma empresa com três produtos.
Produto A (loja online):
- Página inicial: LCP 1,2 s (cumpre)
- Página de produto: LCP 1,8 s (cumpre)
- Pagamento: LCP 2,1 s (cumpre)
- Pesquisa: LCP 2,4 s (cumpre)
- Cumprimento: 100 por cento
Produto B (SaaS):
- Registo: LCP 1,9 s (cumpre)
- Painel: LCP 2,6 s (não cumpre)
- Definições: LCP 2,5 s (não cumpre)
- Cumprimento: 66 por cento
Produto C (conteúdo):
- Página inicial do blogue: LCP 2,3 s (cumpre)
- Cumprimento: 100 por cento
Agregado: 88 por cento de cumprimento em todos os produtos.
Relatório à direção: dois dos três produtos cumprem na totalidade. O produto B precisa de atenção. A equipa está a trabalhar para melhorar o desempenho do painel e das definições.
Padrões de desempenho por tipo de dispositivo e zona geográfica
Os padrões podem variar com o contexto. Os padrões do computador são diferentes dos do telemóvel. Os padrões dos EUA são diferentes dos internacionais.
Objetivo de LCP no computador: dois segundos (internet rápida, CPU rápido).
Objetivo de LCP no telemóvel: três segundos (internet mais lenta, CPU mais lento).
Objetivo de LCP nos EUA: dois segundos (internet rápida em geral).
Objetivo de LCP internacional: três segundos (velocidades de internet variadas).
Exemplo real: uma empresa global de SaaS com implementação em várias regiões.
Padrão de LCP por zona geográfica:
- EUA: 1,8 segundos (objetivo)
- UE: 2,2 segundos (objetivo, internet mais lenta do que nos EUA)
- Ásia-Pacífico: 2,5 segundos (objetivo, internet mais variável)
Desempenho por região (estado atual):
- EUA: 1,5 segundos (bom, excede o objetivo)
- UE: 2,3 segundos (no objetivo, é preciso melhorar um pouco)
- Ásia-Pacífico: 3,0 segundos (abaixo do objetivo, precisa de melhorias)
Ação: a equipa da Ásia-Pacífico (ou a equipa central de desempenho, se não houver equipa regional) otimiza o desempenho na Ásia-Pacífico. Foco: otimização da CDN para as regiões da Ásia-Pacífico, otimização de imagens para menor largura de banda.
Perguntas frequentes
Como definimos padrões de desempenho diferentes para produtos diferentes?
Baseia-te na criticidade para o negócio e nas expectativas dos utilizadores. O produto que gera mais receita: o objetivo mais exigente. O produto que gera menos receita: um objetivo mais relaxado. Exemplo: o pagamento da loja online é o mais crítico (gera receita). Objetivo: 1,5 segundos. O conteúdo do blogue é menos crítico. Objetivo: 2,5 segundos. Com o criador de websites da WEMASY, podes configurar isto diretamente no teu website.
A equipa central de desempenho deve otimizar todos os produtos ou só definir padrões?
Definir padrões e monitorizar. Deixa as equipas de produto serem responsáveis pela otimização. A equipa central fornece ferramentas, acompanhamento e escalamento. Se uma equipa de produto não consegue cumprir o padrão, a equipa central ajuda. Mas a otimização do dia a dia é responsabilidade da equipa de produto.
Como lidamos com conflitos entre o desenvolvimento de produto e os requisitos de desempenho?
O desempenho faz parte dos requisitos do produto. Uma funcionalidade nova tem de cumprir os padrões de desempenho. Se a funcionalidade acrescenta código que piora o desempenho, não é aprovada até ser otimizada. O desempenho não é negociável (a não ser que a direção o despriorize de forma explícita por uma razão de negócio).
Devemos medir o desempenho de páginas com pouco tráfego?
Não. Foca-te em páginas com muito tráfego e muito impacto. Não vale a pena o esforço de otimização em páginas com pouco tráfego. O tráfego vezes o impacto no negócio determina a prioridade. Mede onde o impacto é maior.
Como tratamos as diferenças de velocidade de rede entre regiões?
Define objetivos diferentes por região. Os EUA têm redes rápidas. Define um objetivo exigente (1,5 segundos). As regiões internacionais têm redes variadas. Define objetivos realistas (2 a 3 segundos). Mede o desempenho por região. Cria um alerta se uma região ficar abaixo do seu objetivo (não do objetivo absoluto).
Devemos integrar orçamentos de desempenho no pipeline de publicação de todas as equipas?
Sim. Verificação do orçamento de desempenho antes da publicação. Se o código de uma equipa exceder o orçamento, a publicação é bloqueada. Previne regressões. Garante também responsabilidade (a equipa é forçada a otimizar antes de publicar).