Start by confirming where the 4.5s goes

Before changing anything, break LCP into its four parts. The fix depends on which part is largest.

• Time to first byte: server and CDN response.
• Resource load delay: the gap between TTFB and when the browser starts fetching the hero image.
• Resource load duration: how long the image takes to download.
• Element render delay: the gap between the image finishing and it actually painting, usually because the main thread is busy with JavaScript.

Chrome DevTools' Performance panel shows this breakdown. Run it with 4x CPU throttling and "Fast 4G" to approximate a mid-range Android phone. The web-vitals library's attribution build gives you the same breakdown from real users.

Also confirm the LCP element really is the hero. On listing pages it is sometimes the first product tile, which changes what you optimize.

On mid-range Android, the usual pattern is a large load delay (image discovered late) plus a large render delay (scripts hogging the CPU). Both are fixable without touching analytics logic.

Fix 1: Make the hero image discoverable and prioritized

This is usually the biggest, safest win, and it has zero analytics risk.

• Remove `loading="lazy"` from the hero. Lazy-loading the LCP image is a very common cause of slow LCP.
• Add `fetchpriority="high"` to the hero `<img>`.
• Make sure the image is in the server-rendered HTML as a real `<img>`. If it is injected by client-side JavaScript or set as a CSS background, the browser can't find it until late. If you can't change that quickly, add `<link rel="preload" as="image" fetchpriority="high">` with matching `imagesrcset` and `imagesizes`.
• If images come from a separate CDN domain, add a `preconnect` to that origin.

Fix 2: Shrink the hero image

• Serve AVIF or WebP with a JPEG fallback.
• Use `srcset` and `sizes` so a 400px-wide phone doesn't download a 2000px desktop image. This alone often cuts hundreds of kilobytes.
• Aim for roughly 100KB or less for the mobile hero where quality allows.
• Set explicit `width` and `height` to avoid layout shift.

Fix 3: Get the tracking scripts out of the critical path

This is where analytics breakage can happen, so do it deliberately.

• Audit each script. Is it render-blocking (a plain `<script>` in the head)? Is it synchronous? How much main-thread time does it take? The DevTools "Third-party" grouping or a Lighthouse "Reduce the impact of third-party code" audit shows this.
• Switch blocking scripts to `async` or `defer`. Most analytics tools (GA4/gtag, Segment, Meta Pixel and similar) use a queue stub. Events pushed before the library loads are buffered and sent once it arrives, so deferring rarely loses data.
• For non-essential tags such as heatmaps, session replay, retargeting pixels and A/B tools that don't affect above-the-fold content, delay them until after the load event or first user interaction.
• If tags go through a tag manager, change their triggers rather than rewriting code. For example, fire marketing pixels on "Window Loaded" instead of "Page View".
• Treat client-side A/B testing scripts carefully. They often deliberately hide the page (anti-flicker snippets) and can add seconds to LCP. If one of your three is this type, it may be the single biggest culprit.

Longer-term options include server-side tagging, which moves vendor fan-out off the device, or running third-party scripts in a web worker with something like Partytown. Test the latter thoroughly, because some tags misbehave there.

Protecting your analytics while you change things

• Keep the core pageview tag loading early but non-blocking (async). Only the heavy extras get delayed.
• Before and after each change, verify events in each vendor's debug view (GA4 DebugView, Meta Pixel Helper and so on).
• Ship script changes separately from image changes so you can attribute any data shifts.
• Compare pageview and conversion counts for a week against the previous baseline, and against a holdout if you can. A small rise in recorded sessions is normal and often means you were previously losing bounces that left before slow tags fired.
• Watch for bounce-tracking and attribution tags that depend on firing before the user leaves. Those are the ones to delay least aggressively.

Suggested order

• Measure the LCP breakdown on throttled mobile and in field data.
• Fix hero discovery and priority: no lazy-load, `fetchpriority`, preload if needed.
• Right-size and modernize the hero image format.
• Make all three scripts async, then delay the non-essential ones, validating analytics after each.
• Re-measure with field data (CrUX or your RUM) over a couple of weeks, since lab improvements don't always translate one-to-one.

Teams in this situation commonly get from around 4.5s to under 2.5s with just the image fixes plus deferring third-party scripts, before any deeper architectural work.