Core Web Vitals PrestaShop: CrUX monitoring and per-module diagnostics (dfcoreweb)

DataFirefly Core Web Vitals brings into your back office the performance measurements actually experienced by your Chrome visitors (Google’s CrUX report), separately for each page type: home page, category, product page, cart, CMS page and whole domain. It keeps the history, sends an e-mail when a metric degrades, compares your shop with your competitors and, with a PageSpeed Insights diagnosis, tells you which module, theme file or third-party service slows a page down.

Prerequisite: the Google API key

The module uses two free Google APIs with the same key: Chrome UX Report (real-user measurements) and PageSpeed Insights (Diagnostics tab).

1. Open the Google Cloud Console and create a project, or pick an existing one.
2. Under APIs & Services > Library, enable Chrome UX Report API.
3. Still in the library, enable PageSpeed Insights API.
4. Under APIs & Services > Credentials, click Create credentials > API key and copy the key (it starts with AIzaSy).

Installation and upgrade

1. Open Modules > Module Manager and click Upload a module.
2. Drop the dfcoreweb.zip file.
3. Click Configure: you land on the module dashboard.

Installation creates 5 tables and a Core Web Vitals menu under Improve, with 5 pages: Dashboard, Recommendations, History, Diagnostics and Settings.

Upgrading from version 1.0.0

Install the new ZIP over the old one, without uninstalling. The upgrade reorganizes the menu, repairs the measurements recorded by 1.0.0 (missing metrics were stored as 0), adds the new tables and removes the old files.

Settings

API key

Paste the key and click Save and test. The module queries CrUX for the shop domain and shows one of these results:

• Valid key, CrUX returns data: everything is ready.
• Valid key, not enough Chrome traffic yet for the domain: the key works, some highly visited pages may still return measurements, and Diagnostics remains available.
• Key rejected: check the key and that Chrome UX Report API is enabled on the project.
• The server cannot reach Google: see the troubleshooting section at the end of this page.

Tracked devices

• Mobile: enabled by default, this is the one Google uses for the page experience assessment.
• Desktop: enabled by default.
• Tablet: disabled by default, CrUX rarely has enough data on this segment.

At least one device always stays active: if you untick everything, Mobile is re-enabled.

Measured pages

The home page, the cart and the whole domain are always measured. For the other types, leave the field empty for automatic selection or enter comma-separated IDs:

• Product IDs: empty = the 3 best sellers of the last 90 days (valid orders of the shop), or failing that the 3 most recent products.
• Category IDs: empty = the 3 categories holding the most active products, excluding the root and home categories.
• CMS page IDs: empty = no CMS page measured.

Competitors

Enter up to 5 domains, one per line (competitor.com or https://www.competitor.com). Since CrUX data is public, the module measures each competitor’s whole domain without installing anything on their side. Competitors are not included in alerts or recommendations.

Automatic synchronization

• Allow the synchronization URL below: enables the scheduled task described further down.
• Import the weekly CrUX history: retrieves up to 40 weeks of past measurements for each page, then refreshes them once a week.
• Automatic lab analysis: the scheduled task analyzes one page per day with PageSpeed Insights (mobile), so each page is reviewed about once a week.
• History retention (days): 365 days by default, from 30 to 3650. Older measurements, analyses and events are deleted at each synchronization.

Regression alerts

• Send an e-mail when a metric degrades: enables alerts.
• Recipient: empty = shop e-mail address.
• Degradation threshold (%): 15% by default, from 5 to 100%.

At each synchronization, the LCP, INP, CLS and TTFB of each page and device are compared with their average over the previous 7 days (at least 3 measurements). An alert is sent when the increase exceeds the threshold and the value is no longer in Google’s green zone. All the regressions of one synchronization fit in a single e-mail, and the same page does not trigger an alert for the same metric again within 7 days. The Send a test e-mail button checks the address and the shop’s e-mail configuration.

PrestaShop dashboard

The Show a mobile summary option adds a block to the back-office home page with mobile LCP, INP and CLS per page type and their status.

The scheduled task

The Settings tab shows the URL to call once a day and a crontab line ready to copy:

17 6 * * * curl -fsS "https://your-shop.com/module/dfcoreweb/cron?token=YOUR_TOKEN" > /dev/null

On shared hosting, use the scheduler in your hosting control panel or a service such as cron-job.org. Each call:

1. updates the list of tracked pages (best sellers, categories);
2. queries CrUX for each page, device and competitor;
3. sends the alert e-mail if needed;
4. imports the weekly history when it is due;
5. runs the day’s lab analysis;
6. deletes data older than the retention period.

The URL responds in JSON with a 200 code when everything went well and 502 on failure, so that your cron service can warn you. A wrong token gets a 403 code. The task runs even when the shop is in maintenance mode and refuses to run twice at the same time for a given shop (15-minute lock).

The dashboard warns you if the task has never been called, or if no synchronization has taken place for more than 3 days. The Synchronize now button starts an immediate collection, useful right after installation.

The dashboard

One tile per page type shows, for each device, the five metrics at the 75th percentile over a rolling 28 days, with the colors of Google’s thresholds:

• LCP (main content display): good up to 2.5 s, poor above 4 s.
• INP (responsiveness to interactions): good up to 200 ms, poor above 500 ms.
• CLS (visual stability): good up to 0.1, poor above 0.25.
• FCP (first display): good up to 1.8 s, poor above 3 s.
• TTFB (server response time): good up to 0.8 s, poor above 1.8 s.

The Passed or Failed badge follows Google’s rule: LCP, INP and CLS in the green zone (INP is ignored when CrUX does not publish it, which is common on the cart). Under each value, an arrow shows the change compared with 4 weeks ago: red when the metric is getting worse, green when it is improving. When a page type groups several URLs, the tile shows their average.

Further down, the Comparison with your competitors ranks your domain and your competitors’ domains by LCP, for each device. The Tracked URLs table details each page with its measurements, its latest PageSpeed score (Lab column) and two shortcuts: its history and its diagnostics.

Recommendations

Each metric outside the green zone produces a recommendation. Recommendations that share the same cause are grouped into a single card, which lists the affected pages with their values (for example TTFB on the home page, categories and product pages). Each card shows:

• the severity: Critical (red zone), To fix (orange zone) or Tip;
• the likely cause on this type of PrestaShop page and the steps to fix it;
• an order of magnitude of the impact, taken from public studies and presented as an estimate;
• links to the relevant screens (Performance, Image settings, Module positions, Cart rules) and to Diagnostics.

Dismiss for 30 days hides the card for all its pages. It comes back if a new page is affected, and a link at the top of the page lists the dismissed recommendations so you can show them again.

History

Choose the page type, the URL (or the average of all URLs of that type), the device and the period (30, 90, 180 or 365 days). Six charts are displayed: LCP, INP, CLS, TTFB, FCP and the share of URLs passing the assessment, with Google’s thresholds as dotted lines.

Before the first synchronization, each point is a week imported from the CrUX history; after that, one point per synchronization. Each point covers the 28 days before it: a change takes about 4 weeks to show in full.

Events

Module installs and uninstalls are recorded automatically and appear as dotted lines on the charts. Add your own markers with a date and a description (theme update, hosting change, campaign) to link a variation to its cause. Hovering over a point shows the nearby events.

The CSV export button downloads the displayed selection, with the source of each point (weekly or daily).

Page diagnostics

Choose a tracked page and the device (Mobile or Desktop), then click Run the analysis. Google loads the page from its servers and the result arrives within 20 to 60 seconds. It is kept: switching page or device shows the latest analysis without running a new one.

Score and screenshot

The performance score (out of 100), the LCP, TBT, CLS, FCP, Speed Index and TTFB values, the total weight, the number of requests and a screenshot of what Google displayed.

LCP element

The element that sets the LCP (image, banner, heading) with its HTML code, and its time split into four stages: server response, wait before download, resource download and render delay. A piece of advice matches the longest stage, for example preloading the image when it is discovered late, or removing loading="lazy" when the LCP image is lazy-loaded.

What weighs on the page

Each loaded file is attributed to its origin based on its path:

• Module: files under /modules/module_name/, shown with the module name;
• Theme: files under /themes/name/;
• Shop: PrestaShop core files, shop images, and the HTML page with the scripts written directly into it;
• Third party: any other domain, named by Google when it recognizes it (Google Tag Manager, Facebook, chat tools…).

For each origin: CPU time (JavaScript execution during loading, the main cause of a high INP), JS, CSS and other file weight, unused JavaScript and number of requests. The table is sorted by CPU time.

Render-blocking files and reported issues

The list of files that block rendering, each with its module or origin, and the issues reported by Google (cache, image format, unused JavaScript…), ranked by estimated savings, with a PrestaShop lead for each one. Google’s wording is shown in the back-office language.

Previous analyses

The table of the page’s latest analyses (score, LCP, TBT, CLS, weight, or the error encountered) lets you check the effect of a fix.

Automatic analysis

With the Automatic lab analysis option, the scheduled task analyzes each day the page whose latest mobile analysis is the oldest, if it is more than 7 days old. For a shop without per-page CrUX measurements, this is the only measurement that changes over time.

The “Not enough Chrome traffic” status

CrUX only publishes a measurement if enough Chrome visitors have loaded the URL over 28 days. Otherwise, the module records this status without an error and the synchronization carries on. In that case, rely on the whole domain, which reaches the threshold more easily, and on the Diagnostics tab for the pages concerned.

Privacy

Only the tracked public URLs, and the competitor domains you enter, are sent to Google. No customer data leaves the shop. All measurements, analyses and events stay in your PrestaShop database; each analysis keeps a summary and the page screenshot (about 50 KB) for the same retention period. Chart.js is bundled in the module: no CDN, no telemetry.

Troubleshooting

• “Google rejected the API key”: key copied incorrectly, Chrome UX Report API not enabled on the project, or an HTTP referrer restriction on the key.
• “The PageSpeed Insights API is not enabled” (Diagnostics tab): enable PageSpeed Insights API in the library of the same Google Cloud project.
• “The shop server cannot reach Google’s servers”: your host blocks outbound connections. Ask them to allow outbound HTTPS to googleapis.com. The synchronization stops after two failures instead of waiting on every page.
• “Quota exceeded”: the synchronization will resume at the next run of the task. For PageSpeed, try again a minute later.
• “A synchronization is already running”: a synchronization is already in progress for this shop; try again a few minutes later.
• The cron URL returns 403: the token is no longer valid (new token or upgrade from 1.0.0). Copy the URL from the Settings tab again.
• The test e-mail does not arrive: check the address and Advanced Parameters > E-mail.
• Diagnostics does not break down by module: disable CCC for one analysis (see above).
• The menu does not appear: clear the cache in Advanced Parameters > Performance and check the employee profile permissions on the module tabs.

Uninstallation

Uninstalling deletes the module’s 5 tables, its configuration and its tabs after confirmation. The history is permanently lost: export it to CSV from the History tab if you want to keep it.