Eu entro na sua equipe e nós deixamos o seu site rápido

Isso depende de quanto dinheiro passa pelo seu site. A Loop Earplugs ficou cerca de 800ms mais rápida no mobile e a conversão do checkout subiu 7%. Eu não posso te prometer 7%, mas o RUM mostra o que cada correção fez com a métrica e o seu analytics mostra o que ela fez com a 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 desempata as páginas que estão próximas. O ganho maior está depois do clique. Um site mais rápido perde menos visitantes e converte mais daqueles que ficam. Isso aparece na sua receita independentemente do Google te subir de posição ou não.

Empresas com os seus próprios desenvolvedores, tráfego real e um site onde a velocidade aparece na receita. Principalmente e-commerce, apps SaaS onde os cliques parecem lentos, e publishers com muitos anúncios. Você não tem desenvolvedores próprios e não tem uma agência construindo para você? Então uma auditoria ou uma correção rápida é um começo melhor.

Não. Qualquer um que garanta uma pontuação antes de olhar para o seu site está adivinhando. O meu objetivo é passar nos Core Web Vitals no percentil 75 nas páginas que te dão dinheiro. É isso que o Google mede, e é isso que os seus visitantes sentem.

A maioria das agências faz um pouco de tudo, e performance é um item na lista. É só isso que eu faço. Os problemas difíceis raramente estão em um checklist: hydration no Next.js, dezenas de scripts de terceiros em um site de mídia, anúncios que causam layout shift quando carregam. Todos nós temos a nossa especialidade. Esta é a minha.

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

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 liga para o que construiu a página, e o navegador é onde eu trabalho. Em uma plataforma hospedada como o Shopify, você não pode mudar a plataforma em si. Mas o tema, os apps e os scripts que eles adicionam são seus, e a maioria dos problemas está ali.

Essa pontuação é do Lighthouse: um teste de lab em um celular lento simulado. O Google olha para os field data, o que os seus visitantes reais experienciam no percentil 75, e é nisso que eu trabalho. A pontuação do Lighthouse geralmente sobe ao longo do caminho, mas eu não a persigo. Um site pode pontuar 95 e ainda falhar nos Core Web Vitals, e vice-versa.

Eu descubro o que roda na main thread quando alguém clica. A API de Long Animation Frames (LoAF) me diz qual script e qual função. Depois nós dividimos esse trabalho, tiramos do caminho, ou nos livramos dele.

Quase nunca. Geralmente são alguns componentes pesados, a ordem em que os scripts carregam, ou como a página faz o hydrate. Mudar isso custa muito menos do que uma reescrita, e você vê o resultado muito mais cedo.

Ainda não tem RUM, ou o seu não consegue mostrar qual elemento ou script é lento? Então eu adiciono o CoreDash. Ele é construído exatamente para esse trabalho. Para cada evento de LCP, INP e CLS, ele mostra qual elemento, script ou recurso o causou. Você vê o que uma correção fez pelos visitantes reais em 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ê rastreia ou por quanto tempo você guarda os dados.

Sim. Eu gosto de trabalhar com agências, e com todo mundo envolvido. A agência constrói, eu encontro os problemas, coloco em ordem e verifico cada correção, igual com a sua própria equipe. Você é a agência? Então é assim que eu trabalho com agências.

Descobertas como tickets no seu próprio sistema, correções no ar, orçamentos de performance no seu pipeline de CI/CD, monitoramento e alertas nos seus dados de RUM, e desenvolvedores que sabem por que tudo isso funciona.

De duas formas. Orçamentos de performance no seu pipeline de deploy marcam uma build que adiciona layout shifts ou bloqueia a main thread antes de ir ao ar. E alertas nos seus dados de RUM te avisam quando algo piora. O CoreDash verifica a cada hora. Ele só dispara um alerta quando há dados suficientes para ter certeza, para que você não persiga falsos positivos. Você ainda fica sabendo semanas antes do Search Console.

Uma auditoria te diz o que está errado e em qual ordem corrigir. A consultoria fica até que seja corrigido.

A sua equipe assume. Há também uma retenção, a partir de €1.500 por mês por cerca de um dia do meu tempo: eu observo os seus dados de RUM, te aviso quando algo fica mais lento, e a cada trimestre nós decidimos o que fazer em seguida.

Acesso ao seu repositório (GitHub, GitLab, o que você usar), um ambiente de staging e o seu analytics. Sem semanas de reuniões de onboarding. Uma vez que eu estou dentro, eu começo, e você geralmente recebe as primeiras descobertas em até 5 dias úteis.

De uma semana a seis meses. Depende do quanto está errado e do quão rápido a sua equipe faz o deploy. A maioria leva menos tempo do que as pessoas esperam: 60% dos meus engajamentos terminam em menos de um mês. A duração exata fica no escopo, antes de começarmos.

Você vê mudanças nos seus dados de RUM um dia depois do deploy. Os números precisam de visitas suficientes antes de significarem algo, então páginas movimentadas mostram mais cedo do que as paradas. De qualquer forma, você sabe semanas antes do relatório CrUX do Google atualizar.

Sim. Nós não removemos as suas tags, nós mudamos como e quando elas carregam. Anúncios ainda podem atender aos requisitos de viewability sem bloquear a main thread ou empurrar o layout. DPG Media, Aleteia e Who What Wear mantiveram a sua receita de anúncios e passaram nos Core Web Vitals.