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