Web Performance Engineering
Core Web Vitals Optimization
Pass Core Web Vitals on real users, not just on PageSpeed. I diagnose LCP, INP, and CLS at the network, browser, and framework layers and ship the changes that move CrUX field data — for WordPress, Shopify, Next.js, Laravel, and custom stacks.
What's Included
Comprehensive solutions tailored to your specific needs
LCP engineering
Hero image, web font, CSS, and server-render diagnosis with fetchpriority, preload, and critical CSS implementation.
INP engineering
Long-task breakdown, main-thread profiling, scheduler.yield rollout, and third-party deferral for interaction-heavy pages.
CLS engineering
Dimension reservation, font swap stabilisation, and elimination of above-the-fold injected content.
Field-data tracking
CrUX, RUM, and weekly dashboards measuring real-user metrics, not synthetic lab scores.
Third-party governance
Audit, defer, server-side, or remove the tags that are silently destroying your Vitals.
CI performance budgets
Lighthouse CI on every PR with budgets that block regressions before they reach production.
Problems I Solve
Symptoms this engagement is built to fix
A green PageSpeed score in the lab but Needs Improvement on real user data in CrUX.
INP regressions since Google replaced FID, especially on interaction-heavy product or filter pages.
LCP dominated by a hero image, web font, or render-blocking script your team cannot remove.
CLS spikes from late-loading ads, fonts, embeds, or third-party widgets.
Performance budgets that hold for one week then drift back the moment a marketing tag ships.
Plugin-based optimisation that broke the site, the analytics, or the checkout.
Why lab scores are not the same as Core Web Vitals
PageSpeed Insights gives you two numbers: a lab score from a simulated mobile run, and a field score aggregated from real Chrome users over the previous 28 days. Google ranks on the field number. The lab number exists to help you debug. Most teams optimise the lab number, watch it climb to 95+, and then wonder why the field number is stuck in orange. The reason is that real users have slower devices, slower networks, and they actually interact with the page — which surfaces INP problems that lab tests will never reproduce. My engagements optimise against CrUX field data first, with lab numbers as a debugging tool. That is the only definition of pass that matters for rankings.
How LCP, INP, and CLS are actually fixed
LCP is almost always a network or render problem: the largest visible element is either a hero image that loads too late, a web font that blocks the title, or a server-rendered block that waits behind hydration. Real fixes include preloading the LCP image with the correct fetchpriority, eliminating render-blocking CSS via critical-path extraction, moving to SSR or ISR where hydration is the bottleneck, and using a properly configured CDN at the edge. INP is an interaction problem: long JavaScript tasks block the main thread between a user input and the next paint. Real fixes include breaking long tasks into yieldable chunks, moving non-critical work into requestIdleCallback or web workers, deferring third-party scripts that run on every interaction, and replacing heavy React patterns with cheaper ones. CLS is a layout problem: elements shift after they paint. Real fixes include reserving dimensions for media, ads, and embeds; pre-loading critical fonts with size-adjust; and stabilising any client-side content that injects above the fold.
Stack-specific bottlenecks I see most often
WordPress sites usually hit LCP problems from oversized hero images, render-blocking page builders, and uncached database queries on the first byte. Shopify stores almost always need theme-level surgery around image rendering, third-party app scripts, and the cart drawer's hydration cost — caching plugins do not exist on Shopify. Next.js apps regress on INP when client components do too much work in useEffect, and on LCP when the App Router is misconfigured for streaming. Laravel applications usually need Octane, opcache tuning, and a CDN edge cache before any front-end work pays off. Custom React SPAs typically need code splitting, route-level lazy loading, and a serious look at whether they should be a SPA at all. I diagnose against your specific stack rather than running the same five plugin recommendations on every site.
How third-party scripts quietly destroy your Vitals
Most field-data CWV failures are not your code. They are GTM, Meta Pixel, HubSpot, Intercom, a chat widget, a heatmap tool, a personalisation script, and three A/B tests all loading on the critical path. Each one adds main-thread work that pushes INP and TBT into the red, plus network contention that delays LCP. Removing them is not always politically possible, so the engagement includes a script governance plan: which tools are essential, which can be deferred, which can be moved server-side via GTM Server Container or Stape, and which simply need to be killed. I do this work with marketing in the room so the conversation is constructive rather than adversarial.
How the work is measured and protected over time
Every engagement defines a target field metric (typically all three CWV in the green for 75 percent of mobile sessions) and a measurement window (the next CrUX update cycle). You receive a weekly dashboard tracking field LCP, INP, CLS, and the underlying lab metrics, plus alerts when any metric regresses by more than 10 percent. After the initial optimisation, most clients move to a small monthly retainer that includes a performance budget enforced in CI, automated Lighthouse runs on PRs, and a monthly review of new third-party scripts before they ship. This is what prevents the gains from quietly evaporating once your team starts shipping again.
What You Receive
Deliverables & expected outcomes
- Field-data baseline report with all three CWV per template
- Engineering diagnosis document with root causes per metric
- Implementation (or co-implementation with your team)
- Third-party script governance plan
- Weekly performance dashboard for 30 days post-launch
- CI performance budget configuration to prevent regressions
Illustrative Engagement
A representative scenario
The problem
A multi-brand e-commerce group passed PageSpeed in the lab on every template but failed CWV on field data, blocking organic visibility on the product pages that drove most revenue. INP was the worst metric at 410ms p75.
The approach
Main-thread profiling traced 78 percent of input delay to a personalisation script and the cart drawer's React tree. We deferred the personalisation script behind first interaction, moved analytics to a server-side container, and refactored the cart drawer to lazy-hydrate only when opened.
The outcome
INP dropped to 168ms p75, LCP improved from 3.1s to 1.9s, and all three Vitals moved into the green within two CrUX cycles. Mobile organic clicks rose 34 percent over the following quarter.
Composite scenario based on typical engagements. Replace with a real, attributed case study once published.
My Process
A proven methodology for delivering exceptional results
Field-data baseline
We pull CrUX and (where available) RUM data per template, identify the templates that account for most traffic, and define numeric pass targets.
Root-cause diagnosis
Profiling, log analysis, and trace inspection to find the actual bottlenecks per metric — not surface symptoms.
Implementation
I ship the changes directly, or co-implement with your engineering team. High-risk changes are gated behind feature flags or staged rollout.
Measure & protect
Weekly dashboard for 30 days post-launch, plus CI performance budgets so future PRs cannot quietly regress the work.
Why Choose Me?
With 7+ years of experience and a track record of delivering results, I bring expertise, reliability, and a results-driven approach to every project.
- Optimise against the field data Google ranks on — not lab scores
- Stack-specific diagnosis instead of one-size-fits-all plugin advice
- Measurable INP wins, including the hard interaction cases
- Third-party tag governance with marketing in the room
- CI budgets that protect the gains long-term
- Senior engineering delivered directly, no junior handoff
Starting at
€397
Field-data baseline, engineering diagnosis, implementation, third-party governance, and 30 days of post-launch monitoring with CI performance budgets.
Frequently Asked Questions
Related Services
Further Reading
Related articles from the blog
Ready to Get Started?
Let's discuss your project and create a custom strategy for success.