I make slow sites fast. Real measurable wins on Core Web Vitals — LCP, INP, CLS — not Lighthouse theater. I work on the bundle, the network, the rendering path, and the parts of your stack that are actually causing the hit.
Most performance work is grinding, not glamorous. The wins live in places that look boring — image format choices, font loading strategy, third-party script audits, render-blocking CSS, layout shift from late-loading content. I find them, fix them, and prove the win in Real User Monitoring data, not in synthetic lab numbers.
I have rebuilt this site from 800KB JS to under 50KB. I have cut LCP on a Shopify Plus storefront from 5.2s to 1.7s in two weeks. I have fixed INP on a SaaS dashboard that was scoring 600ms by tracking down the offending event handler in a third-party widget. The pattern is always the same: measure first, find the actual cause, fix the actual cause.
If your team has been chasing Lighthouse scores without RUM data improving, that is the engagement I usually take on.
WebPageTest, Lighthouse, real-device testing, CrUX field data, RUM if available. Output is a written report with prioritized fixes and expected impact.
LCP first, then INP, then CLS. Each fix shipped independently and measured before moving to the next.
Real User Monitoring set up. Performance budget enforced in CI so regressions get caught at the PR level, not in production.
I watch CrUX and RUM data for 30 days post-launch and surface anything that drifts.
$6,000+ for audit + implementation, $3,000+ for audit-only.
2–6 weeks depending on stack complexity and number of fixes.
FID was retired in March 2024. INP is the replacement — measures interaction responsiveness across the full page lifetime, not just the first interaction. INP is harder to fix than FID was, which is exactly why teams need help with it.
RUM. Lighthouse is a synthetic benchmark on a fixed device profile. CrUX and RUM are what your actual users experience. I optimize for the latter — Lighthouse usually goes up as a side effect, but the goal is real-user metrics.
Sometimes. Options range from delaying load with PartyTown, deferring until interaction, replacing the third party with a lighter equivalent, or — in the worst cases — building a server-side proxy. The right answer depends on what the script does.
I will identify it as the bottleneck and recommend the right specialist. I am not going to pretend a frontend tool fixes a slow database.
No, because Lighthouse is synthetic and your users do not experience Lighthouse. I guarantee a target on CrUX p75 LCP, INP, and CLS — the actual metrics Google uses for ranking.
30-minute call, fixed-price proposal in 48 hours. No commitment until you sign.