Initpc Core Web Vitals: desktop passed, mobile work in progress

An e-commerce store with over 280,000 products is never made fast once and for all: it is made fast layer by layer, measured, and then the work resumes from wherever the numbers say it is not finished. On Initpc.it, the e-commerce we have supported as technical partner since 2006, performance work has proceeded exactly this way: desktop first, where the Core Web Vitals are now passed, then mobile, where the work is ongoing — and we say so.

This page shows the real Google PageSpeed Insights tests run on 27 August 2026, unfiltered: the desktop report and the mobile report, with field data from real users (Chrome UX Report, last 28 days) and lab data (Lighthouse). We prefer a declared work in progress to a convenient number.

It is one chapter of the Initpc case study: performance depends on everything underneath — the multi-level cache of the infrastructure and the search moved to Elasticsearch — and this page covers the last layer, the one the visitor sees.

How we measure: field data and lab data

PageSpeed Insights combines two different things. Field data comes from the Chrome UX Report: real user visits over the last 28 days, on real devices and connections, and this is what Google uses to assess the Core Web Vitals — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Lab data is a single load simulated by Lighthouse on an emulated device with a throttled network: useful for diagnosis, not for judgement.

For an e-commerce store the former is what counts. Field data decides whether the Core Web Vitals assessment is "passed" or "failed", and that is where we look to decide where to intervene. Lab scores help us find the causes.

Desktop: Core Web Vitals passed

Desktop came first, because for an office-supplies store it is still the channel through which a good share of businesses buy. The report of 27 August 2026 gives this result.

Desktop — 27/08/2026	Value	Google threshold
Core Web Vitals assessment (field, 28 days)	passed	—
Field LCP	1.5 s	≤ 2.5 s
Field INP	77 ms	≤ 200 ms
Field CLS	0.01	≤ 0.1
Field FCP	1.3 s	—
Field TTFB	0.9 s	—
Performance score (lab)	95	—
Accessibility / Best practices / SEO	92 / 92 / 100	—

In the lab, on an emulated desktop, the first content appears at 0.4 s, LCP at 1.5 s, Total Blocking Time is 40 ms and CLS 0.003. That is not a result you get from a caching plugin: it is the sum of Varnish serving already-generated pages, Redis saving database queries, optimised catalogue images and a search that no longer weighs on MariaDB.

The same report lists what could still improve on desktop — images (estimated saving 1,174 KiB), render-blocking requests (450 ms), cache lifetimes (270 KiB) — and we take it as a to-do list, not as a dispute of the result.

Mobile: work in progress, declared

On mobile the picture is different, and we write it as it is. Same day, same page.

Mobile — 27/08/2026	Value	Google threshold
Core Web Vitals assessment (field, 28 days)	failed	—
Field LCP	2.4 s	≤ 2.5 s
Field INP	289 ms	≤ 200 ms
Field CLS	0.07	≤ 0.1
Field FCP	1.8 s	—
Field TTFB	1.2 s	—
Performance score (lab, emulated Moto G Power, slow 4G)	53	—
Accessibility / Best practices / SEO	95 / 92 / 100	—

Field data says where the problem lies: LCP at 2.4 s is within the threshold by a hair, CLS is fine, while INP at 289 ms — the time between a tap and the visible response of the page — exceeds 200 ms and is what fails the assessment. In the lab, on an emulated mid-range phone with a slow 4G network, the picture is amplified: first content at 4.4 s, LCP at 12.4 s, Speed Index 7.1 s, 310 ms of main-thread blocking.

What the mobile diagnostics say and what we are working on

The mobile report pinpoints the causes, and they match the work plan in progress:

Lighthouse finding (mobile)	Google's estimate	What we are doing
Render-blocking requests	2,070 ms	Reduce CSS and JavaScript loaded before first paint: inline critical CSS for header and hero, defer the rest
Unused JavaScript	565 KiB	Remove, or load on demand, plugin scripts not needed on the current page
Long main-thread tasks	8	The direct cause of INP: split long tasks, postpone third-party scripts until after interaction
Non-composited animations	8 elements	Move animations to compositor-handled properties (transform, opacity)
Image delivery	207 KiB	Mobile-specific sizes and formats, lazy loading for off-screen images
Cache lifetimes	270 KiB	Longer cache times for static assets at the HAProxy/Varnish layer
Legacy JavaScript	47 KiB	Stop serving polyfills to browsers that do not need them

We work on desktop and mobile with the same method: one change at a time, measured with Lighthouse and Chrome DevTools on the real page, kept only if the numbers improve. The declared goal for mobile is to pass the field Core Web Vitals assessment — INP under 200 ms, LCP comfortably under 2.5 s — and we will update this page with the subsequent reports, with the same screenshots and the same dates.

Why mobile is harder on a large catalogue

Not an excuse, a technical observation. A category page with dozens of products, filters, prices and stock carries more HTML, more images and more scripts than a brochure page. On desktop, CPU and network absorb the weight; on a mid-range phone with a slow network every kilobyte of JavaScript becomes blocking time, and every third-party script — reviews, payments, analytics — competes with the response to the user's tap.

That is why mobile work is largely a work of subtraction: fewer scripts before first paint, less main-thread work, images at the right size. It is the same approach we followed on our own site, described in the case study from WordPress to a proprietary CMS.

What to expect if you run a similar e-commerce

That a Google test is not a final grade but a snapshot with a date. That field data matters more than the lab score. And that, on a large catalogue, speed comes from the architecture before the theme: cache at the right level, search outside the database, images governed upstream. That is the work we do in our business server support and e-commerce development services, and the full picture is in the full architecture of the Initpc project.