Olá, sou o Arjen. Corrijo Core Web Vitals.
Fale comigo quando chegar a um impasse. Descubro o que está realmente a abrandar o site, resolvo o problema com os programadores e deixo a equipa com a monitorização e as competências para o manter rápido.
Correções certas, ordem errada
Já percorreu a lista de tickets, talvez durante meses, e o site continua lento. Vejo isto na maioria dos projetos. Cada ticket faz sentido isoladamente, mas a velocidade da página é um ecossistema: as correções dependem umas das outras. Uma hero image com preload não serve de nada enquanto houver 500ms de scripts a bloquear a main thread antes dela.
Por isso, começo por descobrir o que tem de acontecer primeiro no site e avançamos a partir daí.
Começo pelos visitantes reais
Qualquer projeto começa com field data: o p75 no telemóvel, que páginas falham e se o problema surgiu de um dia para o outro ou ao longo de meses. Uso o CoreDash, a ferramenta de RUM que criei, para ver que elemento ou script está a causar o atraso. É isso que corrigimos primeiro, porque é por isso que os visitantes estão à espera.
Decide quem implementa
Os seus próprios programadores com o meu plano, eu a escrever o código ou a trabalhar com a equipa durante alguns meses. Bloqueado numa questão? Muitas vezes, uma hora chega. Ver os serviços
Continua rápido depois de eu sair
Uma correção só está concluída quando os visitantes reais a notam. O CoreDash continua a monitorizar depois de tudo estar live, por isso qualquer novo plugin, app ou deploy que abrande o site é detetado no próprio dia.
Loop Earplugs
"No telemóvel, ficou cerca de 800ms mais rápido e a conversão no checkout subiu 7%. Pagou-se praticamente de imediato."
Nathan Ziarczyk
Resultados
Marktplaats, Subito, Fotocasa e Kijiji
A Adevinta gere alguns dos maiores marketplaces online do mundo. Entre 2022 e 2024, ajudei quatro deles a tornarem-se mais rápidos: nos Países Baixos, em Itália, em Espanha e no Canadá. No final de 2024, o LCP no telemóvel do Kijiji tinha descido de 3,7 para 1,9 segundos e o INP do Fotocasa de 600 para 200 ms. Nos quatro, o botão de retroceder passou a carregar as páginas diretamente da cache do browser. Os programadores implementaram as correções e a equipa do Fotocasa documentou o trabalho de INP num estudo de caso no web.dev. Ler o caso da Adevinta
em conjunto com outros trabalhos
Resolvido em duas sessões
A equipa deles andava a trabalhar em layout shifts e no LCP há meses. A causa era a galeria de produtos, construída inteiramente em JavaScript. Fizemos as imagens renderizar primeiro em HTML simples e deixámos o script adicionar o scroller e o zoom a seguir. Os field data mostraram o resultado numa semana.
Um novo plano a cada trimestre
Desde 2024 que me reúno com a equipa da Prijsvrij pelo menos quatro vezes por ano. Analisamos os field data em conjunto, decidimos o que é mais importante para os meses seguintes e planeamos a implementação. Os programadores deles fazem o trabalho. Eu garanto que é o trabalho certo, na ordem certa.
What clients say
Miro
"Our dashboards were doing way too much work on the main thread. CPU usage went down 25%, and our users noticed it right away."
Suzanne Beek
Rituals
"We used to break performance every other sprint. Arjen put performance budgets in our pipeline and we haven't had a regression since."
Laura Vogels
Voices.com
"Arjen played a key role in fixing our Core Web Vitals. He got our critical profile pages back into the green in PageSpeed. What I value most is his hands-on attitude: he doesn't just find the bottlenecks, he works directly with our development team until the fixes are actually live."
Jayme Cousins
DPG Media
"He found problems in our component library that we had been living with for two years. Within a few days you could see the difference."
Ashkan Malekloo
Zalando
"We've had audits before, and they all gave us a long list of problems. This one told us what to fix first, and why."
Swift
"The layout shift on our checkout is gone. CLS went from 0.4 to 0.02, on mobile and on desktop."
Louis Breton
Alza
"Arjen taught our team how he works. We now find and fix performance problems ourselves."
A ferramenta por trás do trabalho
CoreDash: Real User Monitoring para Core Web Vitals
Criei o CoreDash porque precisava dele. Em cada projeto, preciso de ver, no momento em que acontece, que elemento ou script está a tornar uma página lenta ou a atrasar um clique. Depois de anos a investigar isso à mão, criei uma ferramenta. Continua a funcionar depois de eu sair e já salvou a pele a vários clientes.
Tempo real, até à causa
Veja o que os visitantes estão a experienciar neste momento, e o elemento ou script exato por trás de cada página lenta.
Funciona com a sua IA
Pergunte ao seu assistente de IA porque é que o checkout ficou mais lento ontem. O CoreDash responde via MCP.
Os dados ficam na UE. Sem cookies, sem endereços IP e sem dados pessoais — logo, sem banner de consentimento. E sem limites ao número de páginas monitorizadas nem ao tempo de retenção dos dados.
Chegou a um impasse? Diga-me o que se passa.
Envie-me uma mensagem com o URL e o que se está a passar. Analiso a situação e digo-lhe o que me parece estar a falhar e o que é preciso para resolver. E se afinal não precisar de mim, também lhe digo.
O LCP no telemóvel não sai dos 3,8s. Seguimos a lista toda do Lighthouse e não vimos qualquer melhoria.
https://www.example.com/
Estive a ver. A ferramenta de testes A/B esconde a página inteira até o script carregar. No telemóvel, isso é a maior parte do LCP. Corrija isso primeiro. Até lá, o resto da lista importa muito menos.
Quer que explique aos programadores como resolver?
