LCP and INP work often stalls because teams begin with a generic performance checklist: compress some images, defer some scripts, then look at a Lighthouse score. That does not establish which visitor-facing problem was fixed. Core Web Vitals cover loading, responsiveness, and visual stability, and Google recommends LCP within 2.5 seconds, INP below 200 ms, and CLS below 0.1 for a good user experience Google for Developers.
The practical problem is attribution. You need to identify the LCP element or the slow interaction on an affected page, make a change that has a clear mechanism, and verify it first in a controlled diagnostic and then in field reporting. The workflow below is designed to make that sequence repeatable.
1. Establish a field-data baseline before changing the page
Start in the Core Web Vitals report in Search Console. Google explicitly recommends checking this report to assess page performance Google for Developers. Record the affected URL or URL group, the metric under review, the device segment shown in your reporting, and the date.
Do not use a single lab run as the baseline for whether the site passes Core Web Vitals. Field data represents actual visitors under different device capability, network, geography, and browsing conditions; lab tests use a controlled simulated environment. The supplied measurement guidance distinguishes these uses: field data measures Core Web Vitals, while Lighthouse is useful for diagnosing specific performance issues corewebvitals.io.
- Write down the page template, not only an individual URL. For example: product detail, article, category, or landing page.
- Record whether LCP, INP, or both are the current issue. Do not combine them into one ticket without separate acceptance checks.
- Save the field-data status and date in the ticket or release note.
- Use one representative URL for controlled diagnosis, while retaining the affected URL group for field monitoring.
This record prevents a common mistake: declaring success because an unrelated page or a faster developer device looks better.
2. Find and document the actual LCP element
LCP measures the time for the largest image or text block to render relative to the beginning of the page load marfeel.com. The LCP candidate is a visible, contentful element; examples include images, text blocks, and videos in the viewport corewebvitals.io. Therefore, do not assume the hero image is the LCP element. On a page with a large heading, promotional block, or video, the candidate may be different.
Use a lab diagnostic to identify the element on the representative URL. Put its selector or a clear description in the ticket: “main product image,” “article headline,” or “hero video poster,” for example. Also record whether the element is an image, text block, or video. This creates a direct test: after the release, the same element should still be the subject of the investigation unless the design intentionally changed.
Choose one LCP intervention that matches the element
If the confirmed element is an image, two source-supported interventions are to preload the LCP image with fetchpriority="high" and to optimise image file size using modern formats such as WebP and AVIF corewebvitals.io. Treat these as separate changes where possible. If you make both at once, you will not know which change affected the diagnostic.
Before release, check the implementation rather than relying on intent:
- Confirm the preload, if used, points to the same asset that is actually rendered as the LCP image.
- Confirm the page still renders the expected primary image rather than a different responsive or script-selected asset.
- Compare the delivered image file and format with the pre-change version.
- Run the same lab diagnostic again and confirm the identified LCP element and timing have been recorded.
If the LCP candidate is text or video, do not blindly apply an image preload. The supplied sources establish that these can be LCP candidates, but they do not provide a universal optimisation recipe for every text or video implementation. Keep the diagnosis specific and test only changes your team can inspect on the page.
3. Split INP work into during-load and post-load cases
INP measures the time from a click or typing action until the page can next update, and it captures the slowest interaction on the page marfeel.com. It covers discrete clicks, taps, and key presses, not continuous actions such as scrolling or hovering corewebvitals.io. That distinction matters when someone reports that a page “feels slow”: first verify that the complaint maps to a qualifying interaction.
Classify the problematic interaction by timing. Marfeel separates suboptimal INP into interactions initiated while browser processes are still running during load, and interactions that occur after the page has fully loaded marfeel.com. Record the interaction itself: opening navigation, submitting a form, choosing a variant, expanding a filter, or another named action.
During-load INP: reduce non-critical competition
For an interaction delayed during load, inspect which non-critical JavaScript is being loaded or processed around that action. Deferring non-critical JavaScript is identified as a strategy to avoid blocking the main thread during interactions corewebvitals.io. Make the decision concrete: name the script or feature, state why it is not required for the initial interaction, and verify that the deferred feature still works after it becomes available.
Total Blocking Time is not a Core Web Vital, but it measures periods after First Contentful Paint when long tasks block the main thread; a task longer than 50 ms contributes blocking time marfeel.com. Use it as a lab diagnostic for main-thread blocking, not as a substitute for the field INP result.
Post-load INP: inspect the triggered component
When the interaction happens after load, inspect the JavaScript and visual update initiated by that component. The INP timing spans user input, JavaScript processing, and the final visual update corewebvitals.io. Your release note should say exactly which interaction was tested and what code or component changed. Re-test that interaction after deployment; do not infer improvement from a faster initial page load.
4. Use lab tests for diagnosis and field reporting for confirmation
A controlled run is useful because it is repeatable. Use it to compare the same URL, the same target LCP element, or the same interaction before and after a narrow change. But do not confuse a successful lab run with field confirmation. INP is based on real-user input and real-user variability; Marfeel notes that a page can perform well on a high-end device while visitors use lower-end hardware or interact differently marfeel.com.
After release, return to Search Console’s Core Web Vitals report as the monitoring record. Google lists that report among the resources for measuring, monitoring, and optimising LCP, INP, and CLS Google for Developers. Compare the same template or affected group with the baseline you saved. If the report does not yet provide enough URL-specific detail, mark the result as unverified rather than filling the gap with a Lighthouse score.
5. Keep an optimisation log that can survive the next release
Performance regressions are easier to investigate when every change has a stated target and a check. Maintain one entry per change, even if several changes are part of a wider redesign.
- Metric: LCP or INP.
- Scope: URL, page template, and device segment used for monitoring.
- Observed target: named LCP element or named user interaction.
- Change: one implementation change, such as image preload, image-format change, or deferred non-critical JavaScript.
- Lab verification: what was re-tested and what you observed.
- Field verification: Search Console report date and status.
- Regression check: key page function confirmed after the change.
This method keeps LCP work tied to the element visitors wait to see and INP work tied to the interaction visitors perform. It also keeps the evidence in the right order: diagnose in a controlled environment, then monitor the real-user metric that Core Web Vitals represent.