I join your team and we make your site fast

That depends on how much money goes through your site. Loop Earplugs got about 800ms faster on mobile and checkout conversion went up 7%. I can't promise you 7%, but your field data shows you what every fix did for your real visitors, so you're not guessing.

A little. Core Web Vitals are a ranking factor, but a small one: relevant content comes first, and speed breaks the tie between pages that are close. The bigger win is after the click. A faster site loses fewer visitors and converts more of the ones who stay, and that shows up in your revenue whether Google moves you up or not.

Companies with their own developers, real traffic and a site where speed shows up in revenue. Mostly e-commerce, SaaS apps where clicks feel slow, and publishers with a lot of ads. No developers of your own and no agency building for you? Then an audit or a quick fix is a better start.

No. Anyone who guarantees a score before looking at your site is guessing. What I aim for is passing Core Web Vitals at the 75th percentile on the pages that make you money. That's what Google measures, and it's what your visitors feel.

Most agencies do a bit of everything, and performance is one item on the list. It's all I do. The hard problems are rarely on a checklist: hydration in Next.js, dozens of third-party scripts on a media site, ads that shift the layout when they load. I have forgotten more about PageSpeed than most SEO agencies will ever learn. We all have our specialty. This is mine.

Yes, it's included in the consultancy. If your own RUM already shows which element or script is slow, we can use that instead.

Pretty much all of them. Next.js, Nuxt, Magento, Salesforce Commerce Cloud, Shopify, WordPress, or a PHP site somebody built in 2012. The browser doesn't care what built the page, and the browser is where I work. In 17 years I've seen almost every platform and backend there is. On a hosted platform like Shopify you can't change the platform itself, but the theme, the apps and the scripts they add are yours, and most of the problems are in there.

That score is Lighthouse: a lab test on one simulated slow phone. Google looks at field data, what your real visitors experience at the 75th percentile, and that's what I work on. The Lighthouse score usually goes up along the way, but I don't chase it. A site can score 95 and still fail Core Web Vitals, and the other way around.

I find out what runs on the main thread when someone clicks. The Long Animation Frames (LoAF) API tells me which script and which function. Then we break that work up, move it out of the way, or get rid of it.

Almost never. Usually it's a few heavy components, the order scripts load in, or how the page hydrates. Changing those costs a lot less than a rewrite, and you see the result much sooner.

No RUM yet, or yours can't show which element or script is slow? Then I add CoreDash. It's built for exactly this work. For every LCP, INP and CLS event it shows which element, script or resource caused it. You see what a fix did for real visitors within a day, instead of waiting 28 days for Google's CrUX report. And there's no limit on how many URLs you track or how long you keep the data.

Yes. I like working with agencies, and with everyone else involved. The agency builds, I find the problems, put them in order and check every fix, the same as with your own team. Are you the agency? Then this is how I work with agencies.

Findings as tickets in your own system, fixes that are live, performance budgets in your CI/CD pipeline, monitoring and alerts on your RUM data, and developers who know why it all works. No big PDF at the end.

Two ways. Performance budgets in your deployment pipeline flag a build that adds layout shifts or blocks the main thread before it goes live. And alerts on your RUM data tell you when something gets worse. CoreDash checks every hour, but it only raises an alert once there's enough data to be sure, so you're not chasing false positives. You still know long before Search Console shows it, 28 days later.

An audit tells you what's wrong and in what order to fix it. Consultancy stays until it's fixed: I write the tickets, your developers build them, and I check every fix in your field data until the numbers are green.

Your team takes over, and most teams can. If you'd rather keep an expert around, there's the retainer: about a day of my time a month. I watch your RUM data, tell you when something gets slower, and every quarter we sit down with the field data and decide what's next.

Access to your repository (GitHub, GitLab, whatever you use), a staging environment and your analytics. No weeks of onboarding meetings. Once I'm in, I start, and you usually get the first findings within 5 working days.

Anywhere from a week to six months. It depends on how much is wrong and how fast your team ships. Most take less time than people expect: 60% of my engagements are done within a month. The exact length is in the scope, before we start.

You see changes in your RUM data within a day of deploying. The numbers need enough visits before they mean anything, so busy pages show it sooner than quiet ones. Either way you know weeks before Google's CrUX report catches up.

Yes. We don't remove your tags, we change how and when they load. Ads can still meet viewability requirements without blocking the main thread or pushing the layout around. My publisher clients kept their ad revenue and passed Core Web Vitals.