Real-User Speed Analysis

LCP (blue) — the biggest image or headline on the page. Sits at 3.3–4.0 s every single day. Never crosses below 2.5 s into the "good" zone. Crossed above 4 s (into "poor") on Apr 7 and Apr 14.

FCP (green) — first visible paint of anything at all. Sits at 2.5–3.0 s. Google's "good" is < 1.8 s — we're well above. Users stare at a blank browser window for about 3 seconds before any content appears.

INP (purple) — responsiveness after the page loads. Around 150–200 ms at p75, which is fine-ish. (It gets worse at p90 — see below.)

CLS×1000 (pink) — layout shift. Mostly < 0.10 (good), with occasional spikes toward 0.20. Elements jump around as images load late.

INP 664 ms at p90 — one in ten clicks/taps takes over half a second to respond. That's not "slow," that's broken-feeling. Visitors tap a button, nothing happens, they tap again. Trending up over the week.

LCP 6.43 s at p90 — 10% of visits wait more than 6 seconds for the main content. On mobile that's the point where people hit back.

FCP 3.98 s at p90 — 10% of visits see a blank page for almost 4 seconds.

CLS 0.32 at p90 — flagged "poor." Content shifts noticeably during load for a meaningful slice of visits.

At p75 (majority experience) speed is "bad." At p90 (the slow tail) it's broken. The tail is where you lose the most revenue — patient users finish the purchase anyway; fed-up users quit.

The fast column (< 200 ms) is mostly order detail and saved-basket pages — low-interaction, already-rendered content.

The "poor" column (> 500 ms) is almost all /CF/DynamicProduct/Editor/* — the Infigo designer tool where users customize prayer cards, programs, memorials. That's the page users spend the most time on, and every interaction there feels laggy.

This is the highest-leverage finding on this page. Product pages and checkout are merely slow. The designer — the step right before purchase — is the step that feels broken.

The site loads 3.4 MB of third-party JavaScript across 21 services before the browser can even paint the main content. Total main-thread JS execution time is ~5.5 seconds.

• Render-blocking stack: Google Tag Manager (1,258 ms of CPU, loads 3 separate gtag copies), PostHog session replay (1,298 ms — ironically the tool measuring this), Zendesk widget (422 ms), Infigo platform scripts (373 ms), FOU Analytics (368 ms on only 8 KB of code). All fire on every page.
• Duplicate Font Awesome: loaded twice — once via the FA Kit, once via the Infigo CDN pulling three full font files (regular, light, solid). 1.6 MB combined.
• Ad pixels on every page: Google Ads (via GTM), Facebook Pixel, AdRoll, Bing UET, Amazon Ads, xAd/GroundTruth, SecureAdDisplay, ConversionLP. Each adds requests and CPU.
• Designer tool is heavier still: the Infigo MegaEdit editor runs on top of all of the above, plus its own canvas-rendering runtime. That's why INP is worst on /CF/DynamicProduct/Editor/* — the main thread is already saturated before the editor even boots.

Devia flagged most of this in March 2024 (2 years ago). The duplicate Font Awesome, the render-blocking GTM, and the sitewide widgets that didn't need to be sitewide were all called out. Since then the site has gained services, not lost them.

Bottom line for John/JC: speed is an accumulation problem, not a broken-feature problem. Every marketing tool, analytics tool, and ad pixel added over the years is still firing on every page. The fix is subtraction, starting with the duplicates and the sitewide-that-could-be-pagewide (Zendesk, TrustPilot, Klaviyo popup).