> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Slowest LCP URLs, Website Performance (PageSpeed + CrUX) > Slowest LCP URLs for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act ... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## At a glance > **Per-URL ranking of the slowest-loading pages by Largest Contentful Paint**, sorted descending. The card surfaces individual URLs (not just templates), with their LCP value, traffic share, and the LCP element that's responsible. **The most actionable per-URL view in the website\_performance set**: instead of "your site is slow on average", it gives you specific URLs ranked by impact, so optimisation effort concentrates on the right pages first. URLs with low LCP × high traffic share are the highest-leverage fixes; URLs with low LCP × low traffic are tail and can be deferred. | | | | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | List of URLs from the audited site, each with: URL, mobile LCP value (lab), desktop LCP value, traffic share (from GA4 if connected, else equal-weighted), LCP element type (image, video, text, etc.), and recommended optimisation. Sorted by LCP descending. | | **Sample type** | **Lab data** (per-URL Lighthouse audits). Field data per-URL is available in CrUX URL-level dataset for high-traffic URLs only. | | **Audit scope** | Vortex IQ schedules per-URL audits for the merchant's configured URL list (typically homepage + top product/category pages from the integration setup). Default depth: 30-50 URLs covering homepage, top-by-traffic product pages, top-by-traffic categories, and key checkout pages. | | **Why per-URL matters** | Origin-level metrics average across URLs, hiding which specific pages are dragging the average. The same site can have a healthy homepage and a broken product detail page; origin-level shows "needs improvement" without indicating where to fix. Per-URL ranking surfaces the dragging pages directly. | | **Traffic-weighted decision making** | The right optimisation priority is **LCP × traffic share**, not LCP alone. A URL with 8s LCP but 0.5 percent traffic share affects fewer customers than a URL with 4s LCP and 25 percent traffic share. The card surfaces both dimensions; the merchant decides priority. | | **Common patterns** | (1) **Homepage typically slowest by absolute LCP**: heavy media. (2) **Top-traffic PDPs second**: hero product image LCP. (3) **Top categories third**: 12-image grid. (4) **Tail PDPs and tail categories**: variable, often inherit theme issues. | | **Currency** | n/a, list with millisecond annotations. | | **Time window** | `T` (current state from latest audit). Per-URL trends available via [`crux_lcp_trend`](/nerve-centre/kpi-cards/website-performance/load-speed-over-time) when CrUX URL-level data is available. | | **Alert trigger** | `top URL > 4000ms LCP` (any single URL in the poor band). | | **Sentiment key** | `null` | | **Roles** | owner, operations | ## Calculation Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A UK-based BigCommerce fashion store, 30-URL audit, mobile, Wednesday 15 May 26. | Rank | URL | Mobile LCP | Traffic share | LCP element | LCP × traffic | | ---: | ------------------------------------ | ---------: | ------------: | -------------------------------------------- | ------------: | | 1 | `/products/spring-floral-maxi-dress` | 5,820ms | 8.4% | Hero JPEG (1.4MB) | 489 | | 2 | `/` (homepage) | 4,820ms | 22.0% | Hero PNG carousel (slide 1, 2.8MB) | **1,060** | | 3 | `/collections/new-arrivals` | 4,610ms | 12.0% | First product image in 12-image grid (380KB) | 553 | | 4 | `/products/leather-tote-bag` | 4,480ms | 6.8% | Hero JPEG (1.2MB) | 305 | | 5 | `/products/gold-statement-earrings` | 4,320ms | 5.2% | Hero JPEG (980KB) | 225 | | 6 | `/collections/sale` | 4,180ms | 7.8% | First product image (340KB) | 326 | | 7 | `/products/silk-scarf-print` | 3,940ms | 4.1% | Hero JPEG (920KB) | 162 | | 8 | `/collections/dresses` | 3,820ms | 9.2% | First product image (320KB) | 351 | | 9 | `/products/casual-cotton-tshirt` | 3,650ms | 3.8% | Hero JPEG (840KB) | 139 | | 10 | `/about` | 3,420ms | 0.8% | Banner image (520KB) | 27 | | ... | (20 more URLs) | | | | | What the per-URL view is telling us: 1. **The homepage tops the LCP × traffic ranking despite not having the slowest LCP.** Spring floral maxi dress page has 5,820ms LCP (slowest), but its 8.4 percent traffic share produces a lower commercial impact than the homepage's 4,820ms × 22 percent = 1,060 weighted score. **The homepage should be optimised first** despite not being the absolute-slowest URL. 2. **Pattern: every page over 4 seconds has a hero image as the LCP element.** The fix-pattern is uniform: image format conversion (WebP/AVIF), responsive variants via `srcset`, preload directive on the LCP image, possibly lazy-loading downstream images. **One coordinated optimisation cycle handles 6 of the top 10 URLs.** 3. **PDPs (product detail pages) cluster in the LCP 4,000-5,800ms range.** The Stencil theme's PDP template uses a single large hero image; 7 of the top-10 URLs are PDPs. The fix is structural to the PDP template rather than per-page; one template fix improves all 78 PDPs simultaneously. 4. **Collection pages cluster at 3,800-4,600ms LCP.** The first image in the 12-image grid is the LCP element (it's the largest above-the-fold element). **Adding `loading="lazy"` to images 5-12** plus image format conversion drops collection LCP by 800-1,200ms typically. 5. **Tail pages (about, contact, terms, etc.) below rank 10** have low traffic share and slower LCP than ideal but lower priority. **Defer** until the high-traffic pages are fixed. 6. **Recommended optimisation sequence by LCP × traffic ranking**: * **Week 1**: Homepage hero carousel optimisation. Single biggest commercial impact. * **Week 2**: PDP template hero image optimisation. Affects 78 PDPs simultaneously via template change. * **Week 3**: Collection page first-image optimisation + lazy-load below-fold. * **Week 4+**: Re-audit; address any URLs still in poor band; tail cleanup. 7. **Commercial impact estimation**: Bringing the homepage and top-3 PDPs from 5-6 seconds to 2.5 seconds typically lifts mobile conversion rate 2-5 percent on those pages. For a brand with 30 percent of mobile traffic on homepage and 25 percent on PDPs at 2 percent baseline conversion at £42 AOV, a 3 percent conversion lift on those pages translates to £8,000-£12,000/month in incremental revenue. Diagnostic flow: 1. **Sort by LCP × traffic.** Don't optimise the absolute-slowest URL if it has low traffic; commercial impact follows the weighted score. 2. **Identify the LCP element pattern.** When the LCP element is the same type across many URLs (hero JPEG on PDPs), a template-level fix is more efficient than per-URL fixes. 3. **Confirm the fix on one representative URL first.** Implement on one, audit, measure; only then propagate to similar URLs. 4. **Re-rank after each ship.** Removing the homepage from the top usually reveals a different priority for the next round. Rapid-response playbook: | Time horizon | Action | | -------------- | ----------------------------------------------------------- | | First 1 hour | Identify top 3 by LCP × traffic. | | First 24 hours | Implement fix on the highest-leverage URL. | | First 7 days | Field LCP movement on that URL (per-URL CrUX if available). | | First 30 days | Cumulative ranking shift; second-priority URL becomes top. | ## Sibling cards merchants should reference together | Card | Why merchants reach for it | | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed) | Origin-level LCP; this card decomposes by URL. | | [`psi_lcp_by_template`](/nerve-centre/kpi-cards/website-performance/lcp-by-template) | LCP by template type (homepage, PDP, collection); coarser grouping than per-URL. | | [`psi_worst_cls_urls`](/nerve-centre/kpi-cards/website-performance/worst-cls-urls) | Same per-URL view for CLS. | | [`psi_worst_inp_urls`](/nerve-centre/kpi-cards/website-performance/worst-inp-urls) | Same per-URL view for INP. | | [`psi_image_optimisation`](/nerve-centre/kpi-cards/website-performance/image-optimisation) | Per-image opportunities; pairs with this card to identify which images on which URLs need work. | | [`psi_biggest_regression`](/nerve-centre/kpi-cards/website-performance/biggest-regression) | URLs with biggest LCP regression vs prior period. | | [`psi_all_cwv_pass`](/nerve-centre/kpi-cards/website-performance/all-cwv-pass) | Per-URL all-three CWV pass status. | | [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) | Composite score; URLs with worst LCP often drag the composite. | | [GA4 `ga_pageviews_per_session`](/nerve-centre/kpi-cards/google-analytics/pageviews-per-session) | Traffic share input for the LCP × traffic weighting. | ## Reconciling against the vendor's own dashboard **Where to look:** * **[PageSpeed Insights](https://pagespeed.web.dev)**, paste each URL individually for per-URL LCP measurement. * **[Google Search Console → Core Web Vitals](https://search.google.com/search-console)**, surfaces URL groups failing CWV; group-level rather than individual URL. * **[CrUX URL-level dataset](https://github.com/GoogleChrome/CrUX#crux-on-bigquery)**, for the highest-traffic URLs, CrUX provides per-URL p75 measurements. **Why the Vortex IQ ranking may differ from a fresh PSI run:** | Reason | Direction | What to do | | --------------------------------------------------------------------------------------------------------------------- | --------------------------- | ----------------------------------------------------- | | **Run-to-run variance.** Lighthouse LCP fluctuates ±10-20 percent between runs. | Either direction | Use 7-day rolling per-URL average. | | **URL set differences.** Vortex IQ audits the configured URL list; PSI runs whatever URL is pasted. | Different scope | Confirm same URL for direct comparison. | | **Traffic share weighting.** Vortex IQ weights by GA4 traffic share when GA4 is connected; PSI doesn't weight at all. | Different ranking criterion | The weighted ranking is more commercially actionable. | **Cross-connector reconciliation:** primarily internal cross-references with [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed), [`psi_image_optimisation`](/nerve-centre/kpi-cards/website-performance/image-optimisation), and traffic share data from [GA4](/nerve-centre/kpi-cards/google-analytics). **Quick rule for support tickets:** if a merchant says *"PSI says my homepage LCP is 3.2s but your card shows 4.8s"*, the most common cause is run-to-run variance. Re-run PSI 3 times, average the results; should match Vortex IQ within 300-500ms. ## Known limitations / merchant FAQs **My slowest URL has 0.5 percent traffic share. Should I still fix it?** Probably not first. The LCP × traffic weighting concentrates effort where commercial impact is largest. **Fix high-traffic URLs first**; tail URLs often share the same root cause (template-level fix) and improve as a side effect of fixing high-traffic pages. **Why does my homepage LCP differ between this card and the headline LCP card?** The headline [`crux_lcp_p75`](/nerve-centre/kpi-cards/website-performance/page-load-speed) shows origin-level field data (real users, 28-day rolling); this card shows lab-measured per-URL data (synthetic single run). Lab and field can differ for many reasons (run-to-run variance, real-user device mix). **Both are correct for their purpose**: lab for engineering iteration, field for ranking truth. **Should I audit every URL on my site?** No. Vortex IQ defaults to \~30-50 representative URLs (homepage, top PDPs, top categories, key checkout pages). Auditing 1,000+ URLs adds API rate-limit pressure and rarely surfaces issues different from the representative set. **Add specific URLs to the audit list** if they're high-traffic and not in the default set. **Some URLs in the list have no LCP element identified. Why?** A few possibilities. (1) **The URL didn't load successfully** during the audit (404, 500, redirect to login). (2) **The page has no above-the-fold visible element** large enough to qualify (rare). (3) **The audit timed out** before the LCP element finished rendering. Verify the URL loads correctly in a fresh browser before treating the LCP value as valid. **Can Vortex IQ run audits on every PDP individually?** Technically yes; commercially marginal value. The PageSpeed API rate-limit (4 req/sec, 25k/day) caps practical audit volume. **Recommended audit scope**: top 30-50 URLs by traffic. The pattern across the top set typically reveals template-level issues that apply to the long tail. **Is the traffic share from GA4 or from BC's analytics?** GA4 if connected; BC's session count if GA4 is unavailable. **GA4 is more accurate** for true visitor behaviour because it tracks across sessions and devices; BC's session count is closer to raw page-loads. The card uses whichever is available; the ranking is reasonable either way. *** ### Tracked live in Vortex IQ Nerve Centre *Slowest LCP URLs* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.