Entro na sua equipe e deixamos seu site rápido

Isso depende de quanto dinheiro passa pelo seu site. A Loop Earplugs ficou cerca de 800ms mais rápida no celular e a conversão do checkout subiu 7%. Não posso prometer 7%, mas o RUM mostra o que cada correção fez na métrica, e o seu analytics mostra o impacto na receita. Você terá os dois.

Um pouco. Os Core Web Vitals são um fator de ranqueamento, mas pequeno: conteúdo relevante vem primeiro, e a velocidade serve de desempate entre páginas parecidas. O maior ganho vem depois do clique. Um site mais rápido perde menos visitantes e converte mais daqueles que ficam — e isso aparece na sua receita, quer o Google suba seu posicionamento ou não.

Empresas com desenvolvedores próprios, tráfego real e um site onde a velocidade impacta a receita. Principalmente e-commerces, aplicações SaaS onde os cliques parecem lentos e portais de conteúdo com muitos anúncios. Não tem desenvolvedores próprios nem agência trabalhando no projeto? Então uma auditoria ou uma correção pontual é um começo melhor.

Não. Quem garante uma pontuação antes de olhar o site está apenas chutando. Meu objetivo é fazer o site passar nos Core Web Vitals no percentil 75 nas páginas que geram receita. É isso que o Google mede e é isso que seus visitantes sentem.

A maioria das agências faz um pouco de tudo, e a performance é só mais um item na lista. Eu só faço isso. Os problemas mais difíceis raramente estão em um checklist: hidratação no Next.js, dezenas de scripts de terceiros em um site de mídia, anúncios que deslocam o layout quando carregam. Cada um tem sua especialidade. Essa é a minha.

Sim, está incluído na consultoria. Se o seu próprio RUM já mostra qual elemento ou script é lento, podemos usar ele.

Praticamente todas. Next.js, Nuxt, Magento, Salesforce Commerce Cloud, Shopify, WordPress ou um site em PHP que alguém construiu em 2012. O navegador não se importa com o que gerou a página, e é no navegador que eu atuo. Em uma plataforma hospedada como a Shopify, você não pode alterar a plataforma em si, mas o tema, os aplicativos e os scripts adicionados são seus — e a maioria dos problemas está ali.

Essa nota é do Lighthouse: um teste de laboratório em um celular lento simulado. O Google analisa os field data, o que seus visitantes reais enfrentam no percentil 75 — e é nisso que eu trabalho. A nota do Lighthouse geralmente sobe junto, mas não fico correndo atrás dela. Um site pode tirar 95 e ainda assim reprovar nos Core Web Vitals, e vice-versa.

Descubro o que roda na main thread quando alguém clica. A API Long Animation Frames (LoAF) me diz qual script e qual função. Depois, dividimos esse trabalho, tiramos ele do caminho ou simplesmente o eliminamos.

Quase nunca. Geralmente o problema são alguns componentes pesados, a ordem de carregamento dos scripts ou como a página faz a hidratação. Ajustar isso custa muito menos do que uma reescrita, e o resultado aparece muito antes.

Ainda não tem RUM, ou a sua ferramenta não mostra qual elemento ou script está lento? Então eu adiciono o CoreDash. Ele foi feito exatamente para esse trabalho. Para cada evento de LCP, INP e CLS, ele mostra qual elemento, script ou recurso causou o problema. Você vê o impacto de uma correção em visitantes reais em até um dia, em vez de esperar a média móvel de 28 dias do Google atualizar. E não há limite de quantas URLs você monitora nem de quanto tempo os dados ficam guardados.

Sim. Gosto de trabalhar com agências e com todos os outros envolvidos. A agência desenvolve, eu encontro os problemas, organizo as prioridades e valido cada correção, exatamente como faria com a sua própria equipe. Você é a agência? Então veja como trabalho com agências.

Diagnósticos em formato de tickets no seu próprio sistema, correções no ar, performance budgets no pipeline de CI/CD, monitoramento e alertas nos dados de RUM, e desenvolvedores que entendem por que tudo funciona.

De duas formas. Performance budgets no seu pipeline de deploy sinalizam uma build que adiciona deslocamentos de layout ou bloqueia a main thread antes de ir para o ar. E alertas nos dados de RUM avisam quando algo piora. O CoreDash faz checagens a cada hora, mas só dispara um alerta quando há dados suficientes para ter certeza — assim você não perde tempo com falsos positivos. Mesmo assim, você descobre semanas antes do Search Console.

A auditoria mostra o que está errado e em que ordem corrigir. A consultoria fica até estar tudo corrigido.

Sua equipe assume. Também existe a opção de um retainer, a partir de € 1.500 por mês por cerca de um dia do meu tempo: acompanho seus dados de RUM, aviso quando algo fica mais lento e, a cada trimestre, decidimos os próximos passos.

Acesso ao repositório (GitHub, GitLab ou o que você usar), um ambiente de staging e seu analytics. Sem semanas de reuniões de alinhamento. Assim que tiver os acessos, começo o trabalho — e você geralmente recebe os primeiros diagnósticos em até 5 dias úteis.

De uma semana a seis meses. Depende do tamanho do problema e da velocidade de entrega da sua equipe. A maioria leva menos tempo do que se espera: 60% dos meus projetos terminam em até um mês. A duração exata fica no escopo, antes de começarmos.

Você vê mudanças nos dados de RUM em até um dia após o deploy. Os números precisam de acessos suficientes para se tornarem representativos, então páginas com muito tráfego mostram o resultado antes das mais calmas. De qualquer forma, você fica sabendo semanas antes do relatório do CrUX do Google atualizar.

Sim. Nós não removemos suas tags, mudamos como e quando elas carregam. Os anúncios ainda conseguem cumprir os requisitos de viewability sem bloquear a main thread nem deslocar o layout. DPG Media, Aleteia e Who What Wear mantiveram a receita de anúncios e passaram nos Core Web Vitals.