Core Web Vitals & site speed

Executive summary

Searchflex's mobile Core Web Vitals are failing at a speed score of 52, creating direct Google ranking risk across all 100 audited URLs; the single biggest revenue-adjacent issue is that GTM, Facebook Pixel, and Hotjar are collectively blocking the main thread for over 57 seconds in aggregate on mobile alone, meaning visitors — especially those on paid campaigns driven by that very Facebook Pixel — are waiting several seconds before they can interact with the page. Fixing just the tag-loading strategy is projected to lift desktop scores by up to 7 points and cut Total Blocking Time nearly in half, with mobile gains expected to be at least equivalent.

At a glance

Top 3 fixes

The highest-impact actions from the full recommendation list. Start here — these three alone are projected to move the needle most.

Core Web Vitals distribution

How the sample splits across Google's Good / Needs Improvement / Poor bands for each metric. A passing site needs ≥75% of URLs in Good for every metric. Hover each segment for exact counts.

CrUX field trend — last 6 months

Real-user data from Google's Chrome User Experience Report. Each sparkline spans ~25 weekly periods ending now. Background bands show Good (green) / Needs Improvement (yellow) / Poor (red). A diverging field vs lab story is a signal — lab tests reveal the bad page-load path, but field data is what Google ranks on.

LCP anti-patterns

A correctly-tuned LCP element loads eagerly, has fetchpriority="high", and is discoverable in the initial HTML. Any of these missing will delay paint.

Worst pages

Lowest-scoring URLs per strategy — prioritise these for manual investigation in addition to sitewide fixes.

mobile

desktop

Sitewide third-party impact

How each vendor compounds across every audited page. Fixing a script on 1% of pages nudges the score. Fixing a script on 90% of pages moves it.

Sitewide heavy files

Specific files that either render-block or ship large amounts of unused code on many pages at once. One-file fixes that propagate everywhere.

What-if: projected score lift per fix

Directional estimates — each scenario assumes an 80% reduction in the named script's blocking contribution. Actual lift varies based on what Lighthouse then sees as the next bottleneck.

Template rollup

Median performance per template. Each template can be expanded to show the exact URLs audited — useful for tracing why a template is underperforming.

mobile

desktop

Deep script inspection

Top scripts fetched directly and inspected for minification, compression, cache TTL, and stale library versions.

All recommendations

1. PRIORITY 1 — Consent-gate GTM-loaded tags (GTM, Facebook Pixel, Hotjar): In GTM, open each tag and change its firing trigger from 'All Pages' or 'DOM Ready' to the built-in 'Consent Initialization' trigger; pair it with a condition that checks analytics_storage=granted (for GA/Hotjar) or ad_storage=granted (for Facebook). This alone targets ~57,600ms of mobile blocking time and is the highest-leverage single change available.
2. PRIORITY 2 — Audit and prune GTM tag bloat: Open GTM Preview mode, load your highest-traffic pages, and export the list of tags firing on page load. Any tag firing on every page that could instead fire on a specific URL path, element click, or custom event should be re-scoped immediately. The goal is to reduce the number of synchronous execution contexts GTM spawns on initialisation — this is what drives the 1,283–1,687ms GTM-own-script blocking cost reported above.
3. PRIORITY 3 — Lazy-load Calendly on interaction: Calendly is costing 1,314ms of blocking time on mobile. If it is injected via GTM, add an 'Element Visibility' trigger scoped to the booking section rather than firing on page load. If it is hard-coded in the template, replace the inline script tag with a dynamically injected script that fires only on the first click or scroll into the booking widget — use an IntersectionObserver with a rootMargin of '200px' to pre-load just before the user reaches it.
4. PRIORITY 4 — Move the GTM container snippet to deferred initialisation: If GTM is hard-coded in the <head> (the Google-default placement), move the <script> tag to the bottom of <body> and add async defer attributes. Then initialise your consent SDK before the GTM dataLayer.push so consent state is available the moment GTM fires. This prevents GTM from being a parser-blocking resource during the critical rendering path.
5. PRIORITY 5 — Investigate and scope the Cloudflare CDN blocking entries (~3,200ms mobile): The audit flagged Cloudflare-origin scripts adding ~3,200ms of aggregate blocking on mobile. Identify which specific Cloudflare Worker scripts or Rocket Loader assets these are (check the Network waterfall in Chrome DevTools filtered to 'cdnjs.cloudflare.com' or 'static.cloudflareinsights.com') and either defer them with async, remove unused ones, or migrate any self-hosted assets to direct CDN delivery without the Rocket Loader rewrite layer.
6. PRIORITY 6 — Set a tag performance budget in GTM to prevent regression: After implementing fixes, create a GTM custom HTML tag that runs on 'All Pages' in a low-priority firing sequence and logs window.performance.getEntriesByType('resource') to the dataLayer. Alert via a Slack webhook or GA4 custom event if total third-party script transfer size exceeds 150KB — this creates an ongoing guardrail so future tag additions don't silently re-introduce the blocking pattern.

Findings

80 distinct finding types across 794 occurrences. Numeric variants of the same finding (e.g. "costs 867ms" vs "costs 698ms") are collapsed into one row with a range in the title.