Skip to main content
← Resources

Field notePerformance field note

How we diagnosed a site-wide LCP regression across 36 URLs

Search Console reported one poor desktop LCP group across 36 commercial URLs. This is the exact reasoning path we used to move from an aggregated field signal to bounded changes — and why we are not calling it resolved before the field window confirms it.

Performance field note illustrating a site-wide LCP investigation

Updated July 2026 · 12 min read

We typically work with Shopify and Shopify Plus stores doing $500k+ in annual revenue.

Samuel Noriega
By

Published

ShareXLinkedIn

The signal: 36 desktop URLs failed as one group

Google Search Console grouped 36 desktop URLs under the same poor Core Web Vitals issue: Largest Contentful Paint above four seconds. The affected set included several commercial routes, not one isolated landing page.

That grouping changed the investigation. When many URLs share the same failure pattern, the first question is not which page has the largest image. It is which rendering, delivery or third-party behavior those routes have in common.

What the report did not prove

Search Console did not identify one root cause, and it did not prove that every affected visit had the same LCP element. Field reports aggregate real users over a rolling window. They are strong evidence of a population-level problem, not a line-level debugger.

Turn a URL group into a small test matrix

Testing all 36 URLs independently would create a large report without necessarily increasing certainty. We selected representative route families and states that exercised the shared layout, asset loading and server response paths.

  • Homepage and one high-value service page.
  • A commercial page using the shared service-page layout.
  • A resource hub and a long-form resource.
  • English and Spanish equivalents where the same template was reused.
  • Cold and warm cache requests.

The goal was not to find the fastest page. It was to reproduce the common delay and separate server response, resource discovery, rendering and third-party work.

The shared causes we investigated first

Cache coverage

The edge-cache rules covered the homepage, resources and a limited set of generic routes, but several commercial route families were outside the public cache path. Those pages repeated server rendering and data work instead of benefiting from the same shared delivery policy.

Work competing inside the LCP window

Accessibility tooling, analytics and session-replay code were useful, but they did not need to start while the first meaningful content was still settling. A third party can be asynchronous and still create main-thread or network contention at the wrong moment.

LCP candidates hidden until hydration

Animation wrappers that begin at opacity zero can delay when a headline or hero is considered painted. The likely LCP text and image should be visible in the server-rendered HTML instead of waiting for client hydration and an IntersectionObserver.

Measurement without element context

A route-level score is more useful when it also records the element that produced LCP and the interaction associated with INP. Without that context, a regression alert says that something changed but makes the next investigation slower.

Use the same evidence discipline

Get a performance scope tied to affected templates and comparable tests

Send the store URL, the templates that matter and any Search Console or PageSpeed evidence you already have. We will define the baseline and validation method before recommending code changes.

Request a performance scope

The bounded changes we shipped

  • Expanded shared public edge caching to the commercial route families while keeping admin, portal, checkout, API and user-specific pages private.
  • Added CDN cache headers intended for the Cloudflare delivery path used by the application.
  • Deferred non-critical accessibility and session-replay tooling until after load and idle time.
  • Loaded Google Analytics only after analytics consent, then scheduled it outside the initial render path.
  • Kept the primary headline and hero image outside opacity-before-hydration animation wrappers.
  • Added route, rating, element and connection context to the existing LCP, INP and CLS events.

Each change corresponded to a named failure mode. We did not combine the performance work with a redesign, copy rewrite or broad dependency upgrade, because that would make the before-and-after harder to interpret.

Why deployment is not the same as a resolved field issue

The changes are deployed, but Search Console field data does not refresh like a Lighthouse run. Its Core Web Vitals reporting uses a rolling population window, so older slow visits remain part of the aggregate while new visits arrive.

We therefore separate three statements that are often collapsed into one:

  • The code and delivery changes shipped successfully.
  • Lab and first-party measurements can show whether the targeted causes improved.
  • Search Console can later confirm whether the affected population moved out of the poor group.

At publication time, the first statement is confirmed and the third remains under validation. Calling the issue resolved before the field window supports it would turn a useful case study into a marketing claim.

What transfers to a Shopify performance investigation

Shugert.com.mx runs on TanStack Start and Lovable rather than Shopify. The exact cache middleware and rendering implementation do not copy into Liquid, Hydrogen or a Shopify app stack.

The diagnostic sequence does transfer:

  • Start from field data and affected route groups.
  • Choose representative templates and customer states.
  • Identify the actual LCP element and critical request path.
  • Separate theme code, images, apps, consent tools and analytics.
  • Make bounded changes in staging.
  • Repeat comparable lab tests and wait for the field window before making population-level claims.

For Shopify, the shared cause is often global theme JavaScript, app embeds, consent tooling, hero discovery or a script loaded on templates where it contributes nothing. The implementation differs; the evidence discipline should not.

A practical review checklist for a multi-URL LCP regression

Baseline

  • Export the affected URL group and record the date range.
  • Identify route or template families instead of treating every URL as unrelated.
  • Record cold-cache and warm-cache server response behavior.
  • Capture the LCP element, request chain, consent state and active third parties.

Change control

  • Tie each code change to a named suspected cause.
  • Keep redesign, dependency and unrelated content changes out of the same release.
  • Preserve a rollback path and a known production baseline.

Validation

  • Repeat the same route, viewport, connection and state.
  • Confirm the improvement did not create CLS, INP or functionality regressions.
  • Monitor route-level real-user data after deployment.
  • Wait for the field-data window before declaring the grouped issue resolved.

Frequently asked

Why can 36 different URLs have the same LCP issue?

They may share the same layout, cache policy, hero-loading pattern, global scripts or third-party tooling. Search Console groups similar field behavior, so a shared failure often points to a shared delivery or template cause.

Does a better Lighthouse score mean the Search Console issue is fixed?

No. Lighthouse is a controlled lab run and Search Console reflects aggregated real-user field data over time. A lab improvement is useful diagnostic evidence, but the field group needs its own validation window.

Should analytics and accessibility scripts be removed for performance?

Not automatically. The first question is whether they can load after consent, load or idle time without losing their intended function. Removal should follow evidence and business approval, not a generic performance rule.

Can the same method be used on Shopify?

Yes. The method of grouping templates, identifying the LCP element, isolating global apps and scripts, staging bounded changes and validating equivalent states applies to Shopify. The code-level implementation depends on the theme, apps and storefront architecture.

Related reading in this cluster

Shopify performance

Fix the shared cause, not 36 URLs one at a time

A senior engineer maps the field issue to the theme, apps, assets and delivery path, then returns a bounded implementation plan with staging and before/after validation.

See the performance service
ShareXLinkedIn
On this page