Core Web Vitals PrestaShop — CrUX tracking per template (dfcoreweb)

DataFirefly Core Web Vitals queries Google’s Chrome UX Report (CrUX) API and brings into your back office the performance metrics actually measured on your visitors’ devices, separately for each page type: home, category, product page, cart, CMS page and aggregated origin. The module keeps the full history, detects regressions and turns every degraded metric into concrete PrestaShop-side actions.

Prerequisite: the Chrome UX Report API key

The module needs a Google API key to query CrUX. It is free and takes four steps to obtain:

1. Open the Google Cloud Console and create a project (or select an existing one).
2. Under APIs & Services > Library, search for Chrome UX Report API and click Enable.
3. Under APIs & Services > Credentials, click Create credentials then API key.
4. Copy the generated key (it starts with AIzaSy) and paste it into the module configuration.

Installation

1. In your back office, open Modules > Module Manager.
2. Click Upload a module and drop the dfcoreweb.zip file.
3. Click Configure once installation completes.

Installation creates three tables (tracked URLs, historical snapshots, dismissed-recommendation log) and adds a DataFirefly Core Web Vitals menu under Improve, with four tabs: Dashboard, Configuration, History and Recommendations.

Configuration

API key

Paste your Chrome UX Report key into the dedicated field and save. While this field is empty, the dashboard displays a warning and no synchronization is possible.

Tracked form factors

CrUX publishes its metrics separately per device type. Three checkboxes let you pick the ones you track:

• Mobile — enabled by default; this is the form factor Google uses for page experience evaluation.
• Desktop — enabled by default, useful when your desktop traffic is significant.
• Tablet — disabled by default; CrUX rarely has enough data on this segment.

Each additional form factor multiplies the number of daily calls, with no risk of exceeding the quota given the volumes involved.

Tracked URLs

By default the module picks a representative URL per page type on its own: the home page, the category holding the most products, the best-selling product, the cart page and the first active CMS page. It also queries the origin, meaning the aggregation of the entire domain.

Three fields let you take control by entering comma-separated IDs:

• Product IDs — to track a specific page rather than the current best-seller.
• Category IDs — to track a strategic category.
• CMS page IDs — to track a landing page or a high-traffic content page.

Data retention

The Retention period field (365 days by default) sets the age beyond which snapshots are purged. The purge runs on every synchronization, and a dashboard button lets you trigger it manually.

Regression alerts

• Notify on regression — enables email sending.
• Email address — alert recipient; leave empty to use the shop address.
• Regression threshold — degradation percentage that triggers the alert, 15% by default.

After every sync, each metric’s new value is compared to the seven-day average. If the gap exceeds the threshold, an HTML and text email is sent with the delta details and a direct link to the dashboard.

Automatic synchronization

The configuration page displays a synchronization URL protected by a token derived from your shop’s security key. Call it once a day from your task scheduler:

0 6 * * * curl -s "https://your-shop.com/index.php?fc=module&module=dfcoreweb&controller=cron&token=YOUR_TOKEN" > /dev/null

On Windows, use Task Scheduler; on shared hosting, PrestaShop’s Crontab Manager module or your hosting panel’s scheduler work equally well.

The Run synchronization button on the dashboard triggers an immediate collection, useful to validate the configuration right after installation.

Reading the dashboard

The dashboard shows one tile per page type, with the latest known value of each metric and a colour code following Google’s official thresholds:

• LCP (Largest Contentful Paint) — good up to 2.5 s, needs improvement up to 4 s, poor beyond.
• INP (Interaction to Next Paint) — good up to 200 ms, needs improvement up to 500 ms, poor beyond.
• CLS (Cumulative Layout Shift) — good up to 0.1, needs improvement up to 0.25, poor beyond.
• FCP (First Contentful Paint) — good up to 1.8 s, needs improvement up to 3 s.
• TTFB (Time To First Byte) — good up to 0.8 s, needs improvement up to 1.8 s.

All values are expressed at the 75th percentile: they represent the experience of the 25% least well served visitors, in line with Google’s methodology. A shop is considered to “pass” the assessment when LCP, INP and CLS are simultaneously in the green.

History

The History tab overlays each metric’s evolution over 30, 90, 180 or 365 days, for a given page type and form factor. Charts show Google’s thresholds as dashed lines, making the move from one band to another immediately readable. An extra curve tracks the percentage of visits rated “good” across the three main metrics.

This is the view to check after a deployment, a theme migration or the addition of a third-party script: an LCP degradation usually shows up over the following days, offset by the 28-day rolling window.

Recommendations

Every out-of-threshold metric generates one or more recommendations attached to the relevant page type, sorted by severity:

• Critical — metric in the red band, direct impact on ranking and conversion.
• Warning — metric in the amber band, significant room for improvement.
• Info — good practice applicable even in the green band.

Advice is phrased in PrestaShop vocabulary: format and preloading of the cover image on a product page, explicit dimensions for category grid thumbnails, number of modules hooked onto header hooks, compression and server cache for TTFB, deferring third-party scripts for INP. Each recommendation carries a business impact estimate calibrated on Deloitte’s “Milliseconds Make Millions” study.

The Dismiss button removes a recommendation from the list for 30 days, long enough to handle the topic or decide it is not a priority.

The “not enough data” status

CrUX only publishes a metric once enough Chrome visitors have loaded the URL over the period. Below that threshold, the API answers that the record does not exist: the module then records a “not enough data” status, with no error and no interruption to the collection.

If this applies to most of your pages, rely on the Origin row: the aggregation of the whole domain reaches the threshold far more easily and remains representative of your shop’s average experience.

Privacy and data hosting

No customer data is sent to Google. Only the public URLs you chose to track are sent to the CrUX API, and the returned metrics are already anonymized and aggregated by Google. All readings are stored in your own PrestaShop database. The charting library is bundled inside the module: no external CDN call, no telemetry, no visitor-side analytics script.

Troubleshooting

• Authentication error during sync — the API key is missing, mistyped, or the Chrome UX Report API was not enabled on the Google Cloud project. Also check that no IP address or HTTP referrer restriction is applied to the key.
• Every row shows “not enough data” — Chrome traffic on those URLs is too low. Track the origin, and manually pick high-traffic pages.
• The cron call returns an authorization error — the URL token no longer matches. It depends on the shop name and the installation’s security key: copy the URL shown in the configuration again after any shop name change.
• The menu does not appear after installation — clear the cache under Advanced Parameters > Performance, then check your employee profile permissions on the new tabs.
• Charts stay empty — at least two syncs on different dates are needed to draw a curve. Wait 24 hours after the first collection.

Uninstallation

Uninstalling removes the module’s three tables, all configuration keys and the back-office tabs. Measurement history is permanently lost: export your data beforehand if you want to keep it. An explicit confirmation is requested before the operation.