Core Web Vitals Investigation & Optimization
Core Web Vitals Engineering
Core Web Vitals Investigation & Optimization
Core Web Vitals tell you where the user experience is breaking down. They do not tell you why. WebPerfLab traces the browser, network and application path behind poor LCP, INP and CLS, fixes the responsible layer and verifies the result.
Metric ≠ root cause
A Poor Core Web Vital Is the Result — Not the Root Cause
Core Web Vitals describe a user-experience problem. They do not automatically identify the resource, script, dependency, server layer or rendering work responsible for it.
Poor LCP
Important content appears too late. The cause may be server response, discovery, loading or rendering.
Poor INP
An interaction responds too late. The cause may be input delay, expensive event processing or delayed presentation.
Poor CLS
Visible content moves unexpectedly. The cause may be dynamic layout, fonts, media, ads or injected UI.
Three metrics, three different experiences
LCP, INP and CLS Need Different Investigation Paths
For definitions and thresholds, see Core Web Vitals. This service page focuses on diagnosis, scope and remediation.
Loading experience
What it tells you: important visible content appears too late.
What it does not tell you: whether the cause is TTFB, late discovery, load duration or render delay.
Good field target: LCP ≤ 2.5s at the 75th percentile.
Interaction responsiveness
What it tells you: the page responds too slowly to user interaction.
What it does not tell you: whether the delay comes from existing main-thread work, event processing or presentation.
Good field target: INP ≤ 200ms at the 75th percentile.
Visual stability
What it tells you: visible elements shift unexpectedly.
What it does not tell you: which element moved, which state change caused it or which component should be fixed.
Good field target: CLS ≤ 0.1 at the 75th percentile.
Metric-specific diagnosis
How We Diagnose Each Core Web Vital
Each metric is decomposed into a smaller timing or attribution problem before a fix is proposed.
LCP diagnostic model
Where did the loading delay occur?
INP diagnostic model
Where did the interaction delay occur?
CLS diagnostic model
What caused the geometry to change?
| Metric | Symptom | Possible root causes | Evidence |
|---|---|---|---|
| LCP | Important content appears late | TTFB, discovery, load duration, render delay, main-thread contention | Waterfall, Initiator, Performance Trace, server evidence |
| INP | Interaction responds late | Long tasks, event processing, component work, rendering, third-party CPU | Performance Trace, interaction events, task/source attribution |
| CLS | Content moves unexpectedly | Dynamic layout, media, fonts, ads, injected components, UI state | Layout shift attribution, DOM/component inspection, browser trace |
Real users vs controlled diagnosis
Field Data and Lab Data Serve Different Purposes
A single Lighthouse run cannot represent an entire user population. Field data shows what real users experienced over time; lab data gives us a controlled environment for diagnosis.
FIELD DATA
Real-user experience
- Real devices
- Real network conditions
- Real user states
- Distribution over time
- CrUX / Search Console / RUM where available
LAB DATA
Controlled diagnosis
- Repeatable scenarios
- Controlled device/network assumptions
- Waterfall and trace inspection
- Before/after testing
- Isolation of specific hypotheses
Service scope
What We Investigate
Scope is driven by the failing metric, affected templates, user states and the evidence needed to prove the responsible layer.
LCP Investigation
Loading path and render timing
- Actual LCP element
- TTFB and document response
- LCP resource start time
- Late resource discovery
- Request Initiator
- Preload usage
- Responsive candidate selection
- Lazy loading
- CSS background dependencies
- JavaScript-generated hero content
- Resource priority
- Render delay and main-thread contention
late LCP discovery · when LCP preload helps · resource loads but paint is late
INP Investigation
Interaction and main-thread timing
- Slow interactions
- Input delay
- Long tasks
- Event handlers
- Main-thread contention
- Third-party JavaScript
- Component updates
- DOM work
- Style/layout after interaction
- Presentation delay
Interaction to Next Paint · long tasks · browser Performance Trace
CLS Investigation
Layout-shift attribution
- Unexpected layout shifts
- Images and media dimensions
- Fonts
- Dynamic content
- Banners and ads
- Cookie notices
- Injected components
- Delayed UI state
- Animations or transitions when relevant
How we diagnose Core Web Vitals
Evidence Before Remediation
Not every investigation needs every evidence source. We collect the evidence required to answer the metric-specific question and distinguish confirmed findings from hypotheses.
Field
CrUX, Search Console CWV reporting and RUM when available.
Lab
Repeated Lighthouse tests and controlled scenarios for reproducible diagnosis.
Browser
Network waterfall, Request Initiator, Performance Trace, interaction events and layout-shift attribution.
Server
TTFB, cache state and origin response when the LCP/response path requires deeper investigation.
Application
WordPress, theme, plugins, framework behavior, dynamic components and third-party scripts.
Investigation process
From Failing Metric to Verified Change
Identify
Which metric is failing?
Segment
Which template, device or user state is affected?
Baseline
Measure current behavior under defined conditions.
Trace
Collect browser, network, field, server or application evidence.
Diagnose
Identify the responsible timing stage, dependency or component.
Fix
Apply the smallest responsible change first.
Verify
Repeat the same scenario and compare before/after evidence.
Monitor
Watch field trend and regression when data is available.
Finding format
Every Recommendation Should Explain the Cause
How fixes are prioritized
What you receive
Core Web Vitals Deliverables
Core deliverables are defined below. Implementation and monitoring outputs depend on the agreed scope.
Core Web Vitals Baseline
Current state under defined test conditions.
Field vs Lab Comparison
What real-user data says versus what controlled diagnosis reveals.
Affected Template Analysis
Which page types, states or devices show the issue.
Metric-Specific Findings
LCP, INP and CLS findings kept separate where the cause differs.
Browser / Network Evidence
Waterfall, trace, Initiator or shift attribution where relevant.
Root-Cause Findings
Evidence, responsible layer and confidence level.
Priority Matrix
What deserves engineering effort first.
Recommended Remediation
Targeted change direction tied to the diagnosed cause.
Risk Notes
Potential impact on design, interaction, tracking, checkout or dynamic behavior.
Implementation Guidance
Technical direction or scoped implementation where included.
Verification Criteria
What must change for the fix to be considered successful.
Before / After Comparison
Comparable evidence after implementation.
Regression Check
Confirm that adjacent metrics and business functionality still behave correctly.
Optional Monitoring Guidance
Recommended field follow-up when CrUX or RUM data is available.
Why generic fixes fail
The Same CWV Recipe Does Not Work for Every Site
Poor LCP
“Compress the hero image.”
But the actual bottleneck may be late LCP discovery, server response or render delay. A smaller image cannot remove a dependency that prevents the request from starting.
Poor INP
“Delay all JavaScript.”
But the actual bottleneck may be one event handler, one third-party task or a specific component update. Broad deferral can break dependencies without fixing the interaction.
Poor CLS
“Add image dimensions.”
But the actual shift may come from an injected banner, consent UI, font change or delayed component state. Attribution comes before remediation.
WordPress & WooCommerce
Core Web Vitals Problems Can Cross the Full Stack
On WordPress and WooCommerce, metric-specific bottlenecks may originate from theme/page-builder behavior, plugin assets, PHP/TTFB, third-party scripts, dynamic content, commerce widgets, cart/checkout scripts or tag managers.
This page does not replace a full WordPress performance diagnosis. See why WordPress is slow and high WordPress TTFB.
Third-party scripts
Required Scripts Still Need Performance Engineering
GTM, GA4, Ads, Meta Pixel, reCAPTCHA, chat, heatmaps, consent tools and embeds can affect loading or responsiveness.
We do not remove them by default. We evaluate:
- Timing
- Trigger
- Necessity
- Scope
- CPU impact
- Network impact
Access depends on the question
Public Investigation vs Deep Investigation
Server access is not always required. We go deeper only when the metric path requires internal evidence.
PUBLIC INVESTIGATION
Without internal access
- Public CWV data
- HTML and requests
- Browser traces
- Third-party scripts
- Frontend assets
- Layout-shift evidence
DEEP INVESTIGATION
When internal evidence is required
- Server and origin behavior
- WordPress / application internals
- Code
- Database
- Cache configuration
- GTM/configuration
Good fit
Who This Service Is For
- Search Console reports poor Core Web Vitals.
- CrUX field data is poor.
- LCP, INP or CLS problems persist after previous fixes.
- Lighthouse and field results disagree.
- CWV degraded after a redesign or deployment.
- WordPress or WooCommerce has metric-specific issues.
- Your development team needs browser-level evidence.
- The site has a complex third-party stack.
May not need full service
When a Full CWV Investigation May Be Overkill
- The root cause is already confirmed.
- The fix is trivial and isolated.
- You only need implementation of one known change.
- You only want a PageSpeed 100 score.
- The problem is unrelated to Core Web Vitals.
Why WebPerfLab
Core Web Vitals Engineering, Not PageSpeed Score Optimization
Metric-specific diagnosis
LCP, INP and CLS are investigated through different evidence paths.
Browser-level evidence
Waterfalls, Initiators, traces, interaction events and shift attribution where relevant.
Root-cause investigation
We separate the measured symptom from the responsible dependency or component.
Full-stack view
Browser, network, server, application and third parties are considered when they affect the metric.
Business functionality preserved
Tracking, consent, checkout and required functionality are not treated as disposable.
Reversible implementation
Scoped changes with rollback paths are preferred over broad rewrites.
Verification after changes
A code change is not proof of improvement until the same scenario is retested.
Risk-aware prioritization
Impact is balanced against evidence strength, cost, regression risk and business criticality.
Verification and regression safety
Improvement Must Be Measured — Not Assumed
After a fix, we repeat the same scenario, compare before/after evidence, inspect the relevant waterfall or trace, verify the metric component and check adjacent functionality.
Repeat the same scenario
Keep page state, device assumptions, network assumptions and cache context comparable.
Check the metric mechanism
Did resource discovery move earlier? Did interaction processing shorten? Did the shift source disappear?
Check regressions
Design, responsive images, sliders, forms, tracking, consent, checkout, interactions and animations may all be affected.
Commercial questions
Frequently Asked Questions
What is included in a Core Web Vitals audit?
The recommended scope includes baseline measurement, field-vs-lab comparison where data exists, affected-template analysis, metric-specific findings, browser/network evidence, root-cause findings, prioritized remediation, risk notes and verification criteria. Final deliverables depend on the agreed package.
Can you fix LCP?
Yes, when the responsible layer can be identified and the implementation is within scope. LCP remediation may involve server response, discovery timing, resource loading, priority or render delay rather than image compression alone.
Can you improve INP?
Yes, by tracing the slow interaction and identifying whether input delay, event processing, long tasks, third-party CPU work or presentation delay is responsible. We do not automatically delay all JavaScript.
Can you fix CLS?
Yes, after the layout shift is attributed to the element, state change or component responsible. Missing image dimensions are only one possible cause.
Why does Lighthouse pass while Search Console fails?
Lighthouse is a controlled synthetic test. Search Console Core Web Vitals reporting is based on field data from real-user experience aggregated over time. They answer different questions and can legitimately differ.
Do you guarantee Core Web Vitals will pass?
No guaranteed field pass or Lighthouse score is claimed. Real-user conditions vary, field data aggregates over time, business-critical functionality may constrain changes and external services may contribute. WebPerfLab provides a structured engineering process and evidence-based recommendations.
Do you need server access?
Not always. Public investigation can cover CWV field data, HTML, requests, browser traces, third parties and frontend assets. Server or application access is requested only when internal evidence is required to prove the responsible layer.
Can you work with WordPress and WooCommerce?
Yes. Metric-specific issues can be traced through theme/page-builder behavior, plugin assets, PHP/TTFB, dynamic content, commerce scripts, third parties and other WordPress/WooCommerce layers where relevant.
Can third-party scripts cause CWV problems?
They can contribute to network or CPU cost, but they are not removed by default. We assess timing, trigger, necessity, scope, CPU impact and network impact.
How do you verify improvements?
We repeat comparable scenarios, compare before/after evidence, inspect the relevant waterfall or trace, verify the specific metric mechanism, test adjacent functionality and monitor field trend when available.
Do you optimize for Lighthouse 100?
No. Lighthouse is useful for diagnosis, but score chasing is not the service objective. The goal is to remove meaningful user-experience bottlenecks without sacrificing business functionality.
Can you implement the fixes after the audit?
Implementation can be included in the agreed scope or handled as a separate remediation phase.
Scope and pricing
Investigation Scope Depends on the Problem
We do not invent a fixed price without a defined scope. Complexity depends on the number of representative templates, failing metrics, platform, required access, implementation scope and field-data availability.
Fix the cause, not the color
Your Core Web Vitals Are Failing. Find the Cause Before Changing More Code.
If LCP, INP or CLS remains poor despite previous optimization work, the next useful step is to identify the specific timing, dependency or rendering bottleneck responsible.
Recommended lead form
Website URL · Which metric is affected? (LCP / INP / CLS / Not sure) · CMS/platform · Main issue · PageSpeed/Search Console data if available · Contact details · Optional evidence upload
No guaranteed Lighthouse score or field pass. Expected impact depends on the diagnosed cause, implementation constraints and real-user conditions.