Performance & Core Web Vitals

XICTRAQ runs Lighthouse itself in a headless Chromium, in two runs: with Lighthouse's desktop preset and with its mobile default (mid-range phone, simulated throttling). Each run yields the four scores Performance, Accessibility, Best Practices and SEO (each 0–100). If Lighthouse fails, a faster approximation steps in that measures desktop only and without throttling; its scores are not equivalent to those of Lighthouse. Free plan every 24 h, Starter/Business/Agency every 12 h — the run is compute-heavy, hence no finer grading. For ad-hoc runs use the manual scan at /app/scan.

Each Lighthouse run stores a cwv object: lcp_ms (Largest Contentful Paint), cls (Cumulative Layout Shift), tbt_ms (Total Blocking Time), si_ms (Speed Index), fcp_ms (First Contentful Paint) and ttfb_ms (response time of the main document), for the desktop and the mobile run alike. INP requires an interaction that a lab run does not trigger; tti_ms (Time-to-Interactive) is recorded instead. These fields drive the Core Web Vitals card in the website overview and are the reference values for performance budgets.

With the XICTRAQ tracker installed, TTFB (server response time), FCP (first visible element), LCP, INP, CLS and the full page load time are additionally measured in your visitors' real browsers (via PerformanceObserver, cookieless) and sent on the engagement ping — millisecond-accurate. The aggregated evaluation follows the Google standard at the 75th percentile (p75), segmented by device, page and country — with a noise floor of at least 3 data points per segment. In addition the values appear per session directly in the visitor log and in the performance cards. So you see not only how XICTRAQ measures your site, but how your users experience it.

In addition — provided the origin has sufficient data — XICTRAQ pulls the public p75 field data from the Chrome UX Report: LCP, INP, CLS, FCP and TTFB. The split by phone, desktop and tablet (form_factor) is requested as well, but only appears when CrUX has enough traffic for that individual device class — a markedly higher threshold than for the origin total. If an origin has too little traffic for CrUX, this block stays empty and you rely on the synthetic run and your own RUM.

Per website you define a performance budget with any combination of these five fields: min_score (Lighthouse performance ≥ X), max_lcp_ms (LCP ≤ X ms), max_inp_ms (INP ≤ X ms), max_cls (CLS ≤ X) and max_ttfb_ms (TTFB ≤ X ms). max_inp_ms is stored but only checked when a run supplies an INP value; the synthetic run supplies none, so a budget with INP alone triggers neither an alert nor an all-clear. It is checked against the values of the synthetic run: with viewport “desktop” (default) against the desktop run (lighthouse_scores.cwv), with “mobile” against the mobile run (lighthouse_scores.mobil.cwv), with “both” against both. If a run breaches one or more thresholds, the budget cron creates an alert of type “performance_budget” — severity “critical” from three breached thresholds, otherwise “warning”. A 24-hour dedupe prevents a flood during a sustained breach: as long as an open performance alert younger than 24 h exists, no second one is created.

Even without a budget of your own, XICTRAQ reports a marked drop in the performance score: if two Lighthouse runs in a row are at least 15 points below the median of the up to five runs before, an alert of type lighthouse_drop is raised, separately for mobile and desktop. A single weak run triggers nothing, and runs are only compared within the same Lighthouse version. Once a run is back within 7 points of that median, the alert is resolved automatically. You can switch it off under Settings → Notifications → Performance and JS errors.

For every Lighthouse run the website view shows which scripts occupy the main thread: the 15 most expensive scripts above 50 ms, grouped by source and split into desktop and mobile. From the path of the URL XICTRAQ attributes plugins and themes of Shopware 5 and 6, WordPress, Magento, PrestaShop and Gambio, as well as the core of the shop system, own files, third parties and the inline scripts of the page. Third parties are also listed with their transfer size. Every group expands down to the single file.

By default the URL stored on the website is measured. Under Website → Settings → Subpage Monitoring you can add further key URLs (e.g. /product, /checkout, /category/shoes) — each then runs a separate uptime cycle. The maximum number depends on your plan: Free 1, Starter 5, Business 25, Agency 100. Beyond the limit the API rejects with status 422.