Magento Core Web Vitals agencies, ranked on field data rather than lab scores

scandiweb ranks first of nine on this weighting and it does not win the criterion the page is named after. Its performance optimization services page states the right standard more plainly than any other page read in this run: "every result is confirmed in Core Web Vitals field data, the numbers Google records from real shoppers", and, separately, "Lab data comes from a simulated test, like a Lighthouse or PageSpeed run. Field data is what your visitors record, collected by Chrome and reported against Core Web Vitals thresholds. A store can score well in the lab and still fail real users, which is why a Core Web Vitals optimization service is judged on field data, the standard scandiweb signs results off against." That is a statement about method. The score turns on what the method is applied to.

The strongest applied evidence is Zumiez, named on the support and maintenance portfolio with the site given as zumiez.com and the measurement source named: "Green Core Web Vitals on New Relic and CWV assessment passed on the category page, homepage, PLP, and PDP". New Relic is a real user monitoring product, so this is field derived, and the figures run template by template: category page LCP down 56.67 percent, INP down 78.25 percent, CLS down 76.47 percent; homepage down 38.46, 65.74 and 33.33 percent; PLP and PDP down 44.12, 58.06 and 28.57 percent each, with absolutes of 1.3 seconds LCP and 0.04 CLS and a note that average page rendering time fell 34 percent after the category page LCP work. No collection window is stated anywhere in that entry, which is the whole 5 point gap to the top of the first criterion and the reason ParadoxLabs and ZERO-1 both beat scandiweb on it.

Template coverage is where scandiweb takes full marks and nobody else gets close. Alongside Zumiez, the Granit Luma to Hyva rebuild publishes mobile total blocking time for four template types separately, CMS 760 to 70 milliseconds, PLP 760 to 120, PDP 420 to 70 and homepage 530 to 240, and then prints all three current metrics beside all three of Google's good thresholds: "LCP: 1.1 to 1.8s (good threshold: under 2.5s), CLS: 0 to 0.06 (good threshold: under 0.1), INP: 52 to 168ms (good threshold: under 200ms)". The Magento performance audit page commits to the same shape before the work starts: "The Core Web Vitals audit scores LCP, INP, and CLS on your homepage, category, product, and checkout templates, on mobile and desktop."

The metric to mechanism material is the best in the set and it is why the second heaviest pair of criteria falls this way. The Magento Core Web Vitals guide, dated 22 April 2026, maps each metric to a named lever: "lower LCP by serving WebP images, preloading the hero asset, and enabling Varnish for fast HTML delivery, reduce INP by trimming and bundling JavaScript or moving to Hyva, and eliminate CLS by setting explicit image and ad dimensions so nothing shifts as the page loads." It names the module, MagePack, for the bundling, puts the Varnish TTFB saving at roughly 0.3 to 0.8 seconds on Adobe's guidance, and prints the limit with it: "The honest limitation is that Varnish caches anonymous traffic. Logged in customers, cart pages, and checkout bypass it by design." The same guide states, in words, that Interaction to Next Paint is "the responsiveness metric that replaced first input delay".

Where it loses, and it loses this badly. Three scandiweb pages still present First Input Delay as a Core Web Vital, a metric Google retired on 12 March 2024 and removed from its tools on 9 September 2024. The Laderach Core Web Vitals case study, whose own structured data shows it was modified on 22 April 2025, names its three "main indicators" under "Core Web Vitals Assessment: Passed" as CLS, FID and LCP, carries a full FID threshold explainer, reports 3 milliseconds desktop and 20 mobile, and never mentions INP at all. The portfolio page prints "6 ms first input delay (FID)" for Zumiez and "350% First Input Delay (FID)" for Classic Football Shirts, and the performance optimization service page carries the same 350 percent figure beside a separate "45% Interaction to Next Paint gain", presenting the retired metric and its replacement side by side as though both were current. Five of the eight competitors here score higher on that line. Separately, the JYSK Hyva case study is titled after Core Web Vitals and reports total blocking time, First Contentful Paint, Speed Index and PageSpeed score, which are all lab metrics, with no INP and no CLS.

One open question rather than a verdict, because each page is internally true and no page reconciles them. Hyva theme development publishes "Guaranteed results for every client we work with" above a 98 PageSpeed figure, a separate "99 PageSpeed score guaranteed", and "We guarantee faster load times, better Core Web Vitals, and improved PageSpeed scores". Magento performance optimization headlines "Magento performance optimization to a 90+ PageSpeed score" and carries no Core Web Vitals metric anywhere. The performance services page lists, under who the work is not for, "You want a guaranteed PageSpeed number, which no honest audit promises before seeing your store." PageSpeed is a lab score and Core Web Vitals is a field assessment, so a buyer reading all three cannot tell which unit the deliverable is measured in. Ask for it in writing.

Credentials, for scale rather than for the score, since none of them is scored on this page. 23 years, founded 2003, 600+ certified specialists, a workforce across 36 countries serving clients in 45, 700+ clients, 2,100+ projects, 894+ Adobe certifications, NPS 95, $4B+ processed a year, Adobe Commerce Gold Solution Partner, Hyva Platinum Partner, and 600+ performance optimization projects stated on the performance services page, which also states ISO 27001 and 27017 certified practices. A Core Web Vitals engagement here runs through a global delivery team rather than a single timezone.

ParadoxLabs takes the heaviest criterion outright and it is the only agency in this set that names the percentile Google actually uses. Its performance page, read 2026-09-29, states the provenance in one sentence under a heading reading "Measured, in public field data": "All these numbers are from Google's Chrome UX Report, public field data from real visitors, not lab tests." Three figures sit under it, each with its own caption: "52% to 88% Page loads with good LCP the month a Luma store went Hyva (CrUX, Jul to Aug 2023)"; "800ms cut from page load times in one quarter of audit driven fixes, same legacy themes, no replatform (CrUX, Dec 2023)"; and "4.1s to 1.4s mobile performance (LCP p75) at launch of a greenfield Mage-OS and Hyva build (CrUX, spring 2026)".

The proof page names the clients behind two of those. Half Time Beverage carries the 52 to 88 percent good LCP share and a full page load figure of 6.5 to 1.9 seconds. Denver Wholesale Foods carries "4.1s to 1.4s mobile p75 LCP" with "(CrUX field data, spring 2026)" beside it and a greenfield Mage-OS and Hyva build with a from scratch OData ERP connector live in five months. A third card, an Adobe Commerce to Mage-OS move over a weekend, reports "1.7s to 1.3s mobile p75 LCP" and "Core Web Vitals stayed green through the cutover (CrUX field data)" without naming the client.

It publishes its terms and a document you can take elsewhere. The performance page states "Fixed scope, fixed price ($899), delivered as a document your next agency could execute, even if that's not us", and offers a redacted sample audit as a PDF. The proof page publishes a section headed "How to verify any Magento agency, including us", a checklist it says takes an hour and "filters out most of the field", closing "Run it on us. Then run it on everyone else you're evaluating." It also labels its own third party figures as third party: on Composer installs, "Public API, third-party numbers, not ours." Its site states US Eastern weekday hours of 8am to 5pm and "0 outsourced, ever", and describes itself as building and maintaining open source Magento commerce for US businesses since 2002.

Where it falls short is coverage, not honesty. Only LCP is published as a value. No INP figure and no CLS figure were found on the pages read, and "green on every Core Web Vital since" is the qualitative substitute. Every figure is whole store or origin level, so a buyer cannot see which template moved. And the work is described by layer rather than by metric, "TTFB, database, indexing, full page cache discipline, frontend (usually Hyva)", with no page found connecting a mechanism to the metric it moves, which is the one line where it scores near the bottom of the table.

ZERO-1 publishes the cleanest captions in the set and shares the top of the first criterion with ParadoxLabs. Three named clients each carry a Core Web Vitals panel that names the origin and the form factor, is marked Passed, and is footed with the dataset and the collection period: BigK Products at bigkproducts.co.uk mobile, LCP 1.1 seconds, INP 87 milliseconds, CLS 0, with FCP 0.7 seconds and TTFB 0.4 seconds, footed "Real-user data, Chrome UX Report, 28-day period, Jun 2026"; iBottles at ibottles.co.uk mobile, LCP 1.2 seconds, INP 138 milliseconds, CLS 0, same caption; Paddock Spares at paddockspares.com mobile, LCP 1.4 seconds, INP 118 milliseconds, same caption. All three read 2026-09-29.

What earns it the honesty criterion outright is the discipline on the other side. On a fourth case, 5 A Day Box, the same panel layout is headed "5adaybox.co.uk / desktop Lighthouse", reports total blocking time and Speed Index instead of INP, and is footed "Lighthouse 13.3.0, emulated desktop, single page session, Jun 2026". That is the only place in this entire set where an agency tells a reader which numbers came from a simulation and which came from real visitors, on the same template, in the same month. A fifth named client, Barr Display, is measured in Google's own report: "Within 48 hours the Core Web Vitals data reporting in Google Search Console was immediately lifting to provide a steady improvement in Good URLs from 19% to 85% in little over 2 weeks."

It also publishes the limit of the thing it sells, as its own article. "Is Hyva a guarantee for passing Core Web Vitals?", dated 24 January 2024 by Sean Watson, answers no and names the mechanisms: "Hyva can still be butchered. It's solely down to the implementation"; an agency that built on Hyva and "decided to include various JavaScript libraries, a completely new CSS library, and countless bad practices in the theme files. This resulted in a Hyva site that was performing poorly on Core Web Vitals"; third party scripts that "are just dumped onto a Hyva website"; and merchant added media, "a category page that loads by default in 1.5s. Then someone comes along and adds a new content block at the top of the category page. This content block includes a video and 30 images at 0.5MB each." A separate article, dated 11 February 2025, reports declining to bill a £50,000 Hyva budget for Epic Militaria because its own product delivered the build in three days out of existing retainer hours.

Where it loses is interpretation and granularity. Every panel is origin level, domain and form factor, so no template level figure was found on the pages read. And no threshold appears anywhere: the panels say Passed and the body says the store passes Google's assessment, but 2.5 seconds, 200 milliseconds, 0.1 and the 75th percentile are not printed, so a reader has to already know the rule to read the number. The metric to mechanism material is thin too, one mapping of image attributes to CLS in the Page Builder article, and no INP mechanism found. ZERO-1 Ltd is registered in England, company number 03837629, with a head office in Buxton.

JaJuMa is the only agency in this set that publishes the metric change with its date. Its LCP optimization guide states, in a parenthesis a reader can check: "(Note: INP replaced First Input Delay (FID) as a Core Web Vital in March 2024)", and prints all three thresholds correctly, "Google recommends an LCP of 2.5 seconds or less", "A good INP is considered 200 milliseconds or less", "A good CLS score is 0.1 or less". No page read carried FID as a Core Web Vital. That takes full marks on the second criterion and nobody else does.

Its Hyva performance page makes field measurement the first layer of the service rather than a proof format bolted on afterwards: "Layer 1: Beyond Lab Data: Real User Monitoring (RUM). We start where others stop: with your actual customers." And: "While many agencies chase a green PageSpeed score (outdated lab data), we focus on field data, the real world performance your visitors experience. We capture your visitors perceived performance and your site's health with our proprietary Real User Monitoring (RUM) tool, providing the only true path to passing Core Web Vitals." The RUM product is sold separately at EUR 349. The same page carries a guarantee, and it is the only one in this set expressed in the metrics Google actually assesses rather than in a lab score: "We guarantee your store will pass all Core Web Vitals (LCP, INP, CLS)."

It publishes a limit that works against the thing it sells. On the same page: "Hyva provides a lightning fast foundation, but nearly half of all Hyva sites still fail Google's Core Web Vitals", and "About half of all websites using Hyva still struggle to pass Google's Core Web Vitals assessment, which is based on this real user data." The mechanisms are named: admin added media without AVIF or WebP, compression or strategic lazy loading; render blocking third party scripts, handled "using advanced facade loading"; and legacy dependencies.

The applied evidence is one named client and it is captioned loosely. A showcase last updated 27 July 2025 names Rosemarie Schulz and reports, after 60 days of post launch monitoring, CLS from 0.3 to 0.0, LCP from 1.6 to 0.8 seconds, FCP from 1.3 to 0.7 and TTFB from 0.9 to 0.4. The diagnosis is metric specific and useful: "the Cumulative Layout Shift (CLS), which had never received specific attention or optimization, was causing the store to fail its Core Web Vitals test." But no measurement tool is named beside those numbers, the caption is "diligently monitoring the store's performance" and nothing more, and no INP figure appears in the result set. There is no template breakdown and no percentile anywhere.

Hatimeria publishes the most complete single set of before and after values in this ranking. Its DeeZee case study, read 2026-09-29, names the client and the source in a panel reading "Core Web Vitals passed, source: RUMvision", then reports, under "Our results after 6 months of cooperation": LCP improved 34 percent, from 2.42 seconds to 1.6; INP down 53 percent, from 423 milliseconds to 200; CLS improved up to 96 percent, from 0.46 down to 0.02 flat. RUMvision is a real user monitoring product, so those are field derived, the client is named, and all three current metrics carry absolutes on both sides. Its CEO repeats the INP figure in an attributed quote on the same page.

What holds it at the same rung as scandiweb rather than the top rung is the caption. Six months of cooperation is an engagement duration, not a collection period: a reader cannot tell what window either reading covers, and ZERO-1 and ParadoxLabs both state theirs. The same page also publishes competitor relative language, "the best score among competitors" on the UX score, LCP and INP and "second result among competitors" on CLS, without naming the tool that produced the comparison, so nothing was scored on it.

The metric to mechanism material is complete in general terms. Its Core Web Vitals article maps each metric to a lever under its own heading: LCP to image compression, WebP and lazy loading; INP to "Minimize JavaScript execution: Remove unused scripts and use async or defer attributes"; CLS to "Specify dimensions for images and media, reserve space for ads and embeds". The same article cites Vodafone at a 31 percent LCP improvement and redBus at an INP improvement, both correctly attributed to web.dev rather than presented as its own work. The delivery scope published on the DeeZee page is unusually specific for this set: user segmentation by device performance, A or B testing the performance cost of third party scripts, developer training to prioritise performance issues, and a monthly report carrying organic traffic, conversion on lower performance mobile devices, and the correlation between the two.

Where it scores nothing is the honesty criterion. No limit and no unsuccessful result was found on the pages read, and the work is presented without a condition: "Hatimeria takes full responsibility for the entire process, so you are guaranteed to achieve the desired results." Its Magento page goes further and attaches the guarantee to the platform: "By choosing Magento, we can guarantee that the site will comply with the Core Web Vitals Assessment." ZERO-1 publishes an article arguing the opposite case about Hyva, and a buyer should put both in front of whoever they hire. No percentile appears anywhere, and the DeeZee figures are site level with no template breakdown. Its head office is in Krakow, Poland, where it states the company started in 2011.

elgentos publishes a named client, a named real user monitoring product, dated movement and, alone in this set apart from ParadoxLabs, an explicit argument about which percentile the number is read at. Its article of 16 June 2026 by Peter Jaap Blaakmeer names Haibu, running Magento 2 with a Hyva frontend, and reports that until the end of September 2025 the p90 user experience score and the FUX score, which measures the first page load specifically, hovered around 70; that around 30 September 2025 the line jumps into the low 80s; and that it then climbs steadily to around 90 and has stayed there. The tool is RUMvision. In its own words, translated: no coincidence and no measurement error, that is the moment a series of performance optimizations went live.

The percentile argument is worth reading even though it is not Google's. The article's case is that an average load time is a comforting liar, that p90 answers how fast the shop is for the slowest tenth of visitors, and that "a PageSpeed score or a green tick on your Core Web Vitals is often correct for the average visitor, while a whole group of people has a slow experience without you noticing". Google classifies on the 75th percentile, which is not mentioned, so a reader learns exactly what elgentos measured and not how it maps to a pass. That is still six of twelve points on a line where most of this table scores two.

The mechanism list is the most specific in the set after scandiweb's, and it maps two of the three metrics. The Varnish configuration was rewritten using its own elgentos/magento2-varnish-extended module including Xkey for smarter cache invalidation and targeted caching of media and static files, and the chain is published end to end: a higher cache hit rate, a lower Time To First Byte and therefore a faster Largest Contentful Paint, described as by far the main reason for the September jump. A redundant database query and more than 60 lines of dead code came off the checkout success page. The Prismic content integration was constrained because it loaded more products than needed. And: "Snappier cart. We accelerated the cart interactions so changes give immediate feedback. Better for the Interaction to Next Paint (INP) and for the feel." No CLS mechanism was found on the pages read.

It also publishes the measurement discipline behind the result. "Had we measured these optimizations with PageSpeed Insights, we would have had a nice lab figure and a pat on the back. But we would not have known whether the visitor on that slower device noticed anything." A companion article of 21 April 2026 adds deploy annotations, so every release appears as a vertical line on the monitoring timeline and a metric movement can be tied to a specific release rather than reconstructed afterwards. What is missing is the metrics themselves: the published figure is a vendor composite score out of 100, not an LCP, INP or CLS value, there is no template breakdown, and no threshold is printed.

Vendic publishes more named clients with a field derived number than anyone else here and fewer metrics than anyone else here, and those two facts produce the score. Its Hyva page, read 2026-09-29, prints a results wall with the client named above each figure: Paco Verpakkingen at 96 out of 100 RUMvision UX score alongside 45+ custom modules; TopaShop at 99 out of 100 with 60 percent reduced technical debt on modules; and a further client at 93 out of 100 delivered in 12 weeks. RUMvision is a real user monitoring product and Vendic states on the same page that it is a RUMvision partner for performance and Core Web Vitals, so the scores are field derived and the tool is named.

What the page does not contain is a Core Web Vitals metric. No LCP, no INP and no CLS value appears anywhere on the pages read, individually or as a set: the number is always the vendor's composite user experience score. That is why the second and third criteria score nothing here. It is not a judgement about the work, it is what the published surface contains.

The headline claim is an aggregate with no arithmetic behind it. The same page states "30+ Hyva projects, 100% Core Web Vitals" and "100% of our Hyva projects achieve Core Web Vitals", with no per project figure for the other twenty something stores and no window, threshold or percentile anywhere. It also prints a 90+ PageSpeed score for one build without labelling it as a lab figure, which is the only place on the page where the lab and field distinction it depends on is blurred. Vendic describes itself as the first Hyva Platinum Partner. The right question on a Vendic call is short: for one named store, send the LCP, INP and CLS values at the 75th percentile, and say over what period.

MGT-Commerce owns a lot of the written territory around this keyword and publishes no Core Web Vitals figure for any named client, which is the whole of its score on the heaviest criterion. Its Magento Core Web Vitals article, marked updated on 27 March 2025, is a competent explainer: it names the current three correctly in the body, "Loading performance (Largest Contentful Paint, LCP), Interactivity (Interaction to Next Paint, INP), Visual stability (Cumulative Layout Shift, CLS)", carries a section headed "INP Replaces FID", and states the thresholds, LCP within 2.5 seconds and INP at "200 milliseconds or less".

The same page lists the retired metric as one of the three in the summary a reader sees first. Its Key Takeaways block reads "3 key metrics, including LCP, FID, and CLS, and how they impact performance", eleven months after Chrome stopped guaranteeing FID in its tools, on a page whose body states the replacement. Its best practice table repeats the error in the one place it matters most, filing "Remove unnecessary scripts and extensions, break down large JavaScript bundles into smaller chunks" under "improve interactivity metrics like FID" rather than INP.

Its measurement literacy is better than average and its backend numbers are real. The same article tabulates ten tools and separates their data types correctly: PageSpeed Insights "offers both lab (simulated) and field (real user) data", Search Console "provides real world Chrome user data for core web vitals", Lighthouse, WebPageTest, GTmetrix and Pingdom as lab, and Sematext Experience as "a real user monitoring tool that collects field data across devices and locations worldwide". Its caching material states that cached pages serve in under 200 milliseconds while uncached Magento pages with extensions can take 3 to 8 seconds, that Magento 2.4.8 requires Varnish 7.6 and adds Valkey 8 alongside Redis 7.2, and a Varnish hit ratio target above 90 percent. The company states it has run since 2011, is registered in Berlin, and hosts 5,000+ stores, and its CLS mechanism list is specific: explicit width and height attributes, reserved space for ads and banners, font-display swap, and not injecting content above existing content. What none of that produces is a store you can go and look at.

Aureate Labs is in this ranking because it publishes a number for a named client and it is the clearest illustration on the page of the difference the ranking measures. Its Magento speed optimization service page, read 2026-09-29, carries a client testimonial attributed to Majd Al-Dmour, Digital Channels Supervisor at Umniah: "Our website lighthouse score has risen to 94 from 29 and also now our website loads in less than 2 sec." The figure is labelled as a Lighthouse score, so a reader knows exactly what it is, which is why it scores five rather than two. It is a lab score, and it is a testimonial rather than a measurement the agency reports, so it scores five rather than more.

The published outcome is in lab units and the page treats the two things as one. Its FAQ answers "What PageSpeed Insights scores will I get in the end?" with "you can expect your Google PageSpeed Insights score to reach the green zone. However, the final score depends on how many slow loading elements you remove. If we consider keeping the most important ones, our team can help you get a score of 60-70 on mobile devices and 90 on desktops." Another answer describes the work as boosting "performance of your Magento site and its Google PageSpeed Insights score (Core Web Vitals)", putting the lab score and the field assessment inside one parenthesis as if they were the same measurement. Google's own documentation is explicit that they are not.

It does publish terms, which most of this table does not: "It takes a minimum of one week to optimize your Magento store", with the caveat that it varies by size and complexity, and an affordable pricing claim with no figure. The mechanism list is real but unassigned, bundling image compression, browser cache management, HTML, CSS and JavaScript minification, advanced JavaScript bundling, lazy loading, critical CSS, CDN and AMP into one paragraph with no metric attached to any of it. No LCP, INP or CLS value appears anywhere on the pages read, no template breakdown, no percentile and no published limit. Aureate Labs states it was founded in 2012 with a team of more than 60 people.