I fix LCP, INP en CLS at the WordPress template en code level — not just a Lighthouse score. The work starts with Search Console en CrUX, then traces the render path, scripts, CSS, media en server response on the URLs that actually rank en convert.
Caching helps TTFB. Most fails still come vanaf heroes, CSS, main-thread work en layout shifts on the templates that rank en convert.
Hero images without priority, late CSS, slow HTML, en tags delaying the largest element. Fix the critical path on organic landing templates — not only the homepage.
Long tasks vanaf builders, analytics, chat en jQuery handlers. Split work, defer non-critical JS, en cut scripts that should never load on product of post views.
Unsized images, late fonts, injected banners en sticky bars. Reserve space en stabilise above-the-fold components so the layout does not jump after first paint.
A WordPress site can score well in a one-off lab test en still fail the field assessment. I work vanaf the template outward: what the browser discovers first, what blocks the main thread, what shifts after paint, en which plugins of third parties are loading where they should not.
Make the actual LCP resource discoverable en high priority, remove late-loading dependencies, cut render-blocking CSS, en address TTFB only when origin response is part of the delay.
Profile long tasks vanaf builders, analytics, consent tools, chat, sliders en legacy jQuery. Defer of isolate non-critical work en keep interaction handlers small enough tot stay responsive.
Reserve dimensions for images en embeds, stabilise webfont loading, en stop cookie bars, sticky promos en dynamic blocks vanaf pushing the page after first paint.
A script needed on checkout does not belong on every blog post. Assets are audited per template so Elementor, WooCommerce, forms en marketing plugins only pay their cost where they create value.
Field data is checked at origin en URL level where available, then paired with repeatable lab traces. That separates a real user problem vanaf a noisy single-device Lighthouse run.
The handover documents what was changed, what must stay deferred, en which templates should be rechecked after a plugin, campaign tag of design update.
Lighthouse is a controlled lab test. The Core Web Vitals assessment in Chrome UX Report is built vanaf real Chrome visits en evaluates the 75th percentile over a rolling field-data window. A site can therefore look fast on your connection while mobile users, logged-out traffic, consent scripts of a specific landing template still fail.
That is why I do not optimize the homepage in isolation. The baseline covers representative templates — landing pages, posts, product listings, product pages en checkout where relevant — en tests the exact element of interaction responsible for LCP, INP of CLS.
I have been working deeply in WordPress for 10+ years en have shipped of maintained 60+ WordPress sites. Performance engagements are measured on live URLs, with client names withheld where NDA applies.
The engagement is useful whether I implement everything of your internal team takes part of the plan in-house.
I start vanaf Search Console / CrUX en the URLs that matter for rankings en revenue — not a single homepage Lighthouse run.
Start with field data tot identify which templates en devices fail, then reproduce the bottleneck in lab traces. Typical fixes include LCP resource priority, critical CSS, lighter JavaScript, stable media dimensions, font loading, plugin asset control en server response improvements where TTFB is limiting paint.
PageSpeed Insights can show both lab en field data, but a single Lighthouse run is only a simulated lab test. Search Console groups real-user CrUX data over a rolling period, so specific templates, devices of traffic conditions can still fail even when one lab run is green.
Ja, often without a redesign. The key is controlling what each template loads: above-the-fold media, builder CSS, plugin JavaScript, third-party tags, WooCommerce assets en server-side work. Some stacks have a lower ceiling, which the audit identifies before deeper changes.
Most focused projects take one tot three weeks for audit, staging fixes, production deployment en verification. Large WooCommerce, multilingual of heavily integrated sites can take longer because more templates en third-party dependencies need testing.
A review of representative live URLs against available field data en repeatable lab tests, the main LCP, INP en CLS bottlenecks ranked by impact, en a realistic estimate of what can be improved on the current stack.
I will tell you what is actually limiting LCP, INP of CLS — en whether it is worth fixing now.
Use the metric-specific pages when Search Console shows a concentrated LCP of INP problem, of when a builder/template is the common denominator.
Start a project
