forge.
DocssoonBlogContact
ManifestoDemo
← blogBenchmark · Jul 28, 2026

We tested 100 stores on Core Web Vitals. The result explains why Forge exists.

by Forge Team ·7 min read

Google measures your store's experience with three numbers: LCP, INP, and CLS. They decide part of your search ranking and, more importantly, whether the customer stays or leaves. Instead of talking about this in theory, we measured it: we took 100 real stores on other SaaS platforms, ran the same test Google runs, and put Forge on the other side. This post is the full methodology, the numbers unedited, and what they have to do with the platform we're building.

The three measures Google uses

LCP (Largest Contentful Paint) is the time until the main content appears, like the product photo or the campaign banner. INP (Interaction to Next Paint) is the response to touch: the button click that's slow to react. CLS (Cumulative Layout Shift) is visual stability: the page that jumps right as you were about to click.

Metric Good Needs improvement Poor
LCP · main content up to 2.5 s 2.5 s to 4.0 s above 4.0 s
INP · touch response up to 200 ms 200 to 500 ms above 500 ms
CLS · visual stability up to 0.1 0.1 to 0.25 above 0.25

These three make up the Core Web Vitals, defined and documented by Google itself. The official reference is at web.dev/vitals and their effect on search ranking is at Search Central. The thresholds above aren't our opinion: they're what Google uses to classify a visit as good, needs improvement, or poor.

The test: Forge against 100 real stores

The comparison group is 100 real stores on other SaaS platforms, in Latin America, with a catalog matched in size to one Forge store (in the 3,000-to-4,000-product range) — none individually identified.

The test itself runs in the lab: PageSpeed Insights (Google's own Lighthouse engine), standard mobile profile, one run per page, not a median of several, to keep the call volume viable across a test of more than 480 measurements. Each store was measured across five page types: home, category, product, search, and checkout (checkout measures the empty cart, same bundle and same tags as a real checkout, just with nothing inside). The group's value on each metric is the median, not the mean, so a single exceptionally bad store can't skew the number.

Performance score
95
forge. · 1 store
31 100 stores
LCP in the lab
2.8 s
forge. · 1 store
12.4 s 100 stores
Thread blocking
5 ms
forge. · 1 store
1.0 s 100 stores
Page weight
869 KB
forge. · 1 store
4.5 MB 100 stores
Measureforge.100 storesDifference
Performance score9531+64 pts
LCP (lab)2.8 s12.4 s−78%
CLS (lab)0.000.12−100%
Total Blocking Time5 ms1.0 s−99%
Page weight869 KB4.5 MB−81%
Third-party weight247 KB4.2 MB−94%
Requests79186−58%
JavaScript shipped144 KB2.7 MB−95%

LCP by page type

Lower is better. Checkout hurts the most: a 20.8-second median across the 100 stores, and that's with an empty cart, just the page shell. With a product inside, it tends to get worse, not better.

2.8
13.8
Home
1.8
10.5
Category
2.0
9.0
Product
2.4
10.4
Search
2.0
20.8
Checkout
forge. 100 stores (real, seconds)

A sample of the five worst

Each row is a real store from the comparison group. "Good visits" is the average across LCP, INP, and CLS, measured in the field (Chrome UX Report, real user data, not lab):

Sample LCP (p75) INP (p75) CLS (p75) Good visits
1 4.3 s 0.48 27%
2 4.6 s 0.28 33%
3 3.9 s 630 ms 0.42 42%
4 5.7 s 221 ms 0.27 42%
5 6.3 s 207 ms 0.47 42%

The dash under INP isn't an error: two of these stores don't have enough interaction volume for Chrome to publish the number, which already says something about the traffic that survives the first impression.

What's worst about these stores (and what it has to do with Forge)

Two field numbers sum up the size of the problem. Among the 142 stores in our larger set with real Chrome UX Report data, only 3% pass all three metrics at once, the very bar Google considers "good." Among the 100 worst that make up this benchmark, the field median for CLS is 0.32 and for LCP it's 3.95 seconds, already in "poor" territory before any lab test at all.

In the lab, the pattern repeats at a different level of detail: 94% of the average page weight is third-party. That happens from a lack of governance combined with a platform limitation that pushes everything to the front end when it could integrate on the back end.

That lines up with what we already see in practice about why stores fail these metrics: the problem is almost never the product being sold. It's structural, and it repeats in four forms:

JavaScript the platform forces you to load before your product. On SaaS, that code is decided for millions of stores at once, with a feature your store never uses, but that ships in the same bundle anyway. On Forge, the code is yours and auditable: you can see exactly what runs, because there's no hidden factory baseline.

Apps and pixels that pile up with no owner. Each small app, alone, looks cheap. The total (the 94% third-party we measured) isn't. On Forge that becomes the Friends model: every integration is a consented choice, with its own permissions and database, hand-picked by the Forge Team or by you, never a pre-installed bundle nobody remembers to review.

Shared cache, warmed for the average, never for your store. On a SaaS platform, thousands of stores split the same infrastructure, tuned for the average case. Forge runs on the cloud you choose (AWS, GCP, Azure, or the one you already use), dedicated to your operation, not to a long tail of other tenants.

Checkout loaded to the bone. Our test showed checkout as the worst page, by far, even empty. On SaaS platforms, it's common for checkout to accumulate years of conversion pixels that nobody audits anymore, because touching it feels risky or impossible. On Forge, every integration on checkout is also an app with explicit permission — visible, reviewable, removable, and not always on the front end.

Why owning your platform changes the game

Forge is not a SaaS. You don't rent space in a shared system: the store, the code, and the data are yours, running on your infrastructure, operated by the Forge Team. That structural difference is why the numbers above can become control, not just diagnosis:

  • Your own infrastructure. Your cloud, your choice (AWS, GCP, Azure), without sharing cache or capacity with tenants you don't know.
  • Your code, auditable. Source-available, no black box. What runs on your store is traceable: by you, if you have a technical team, or by the Forge Team, if you don't.
  • Friends model, not bloatware. ERP, CRM, invoicing, payments, and analytics come in as first-class apps, with their own permissions, never accumulated by default.
  • 0% on your sales. We charge for what we do, never for what you sell. Performance isn't a premium feature.
  • No lock-in. If you ever want to leave, you take it all: code, data, and infra are already yours.
  • LGPD and GDPR native. Running on your infra, in the country you choose, data residency comes free, and doesn't depend on a third-party contract.

Every item that showed up as a structural problem in this benchmark (factory JavaScript, accumulated apps, shared cache, an unowned checkout) is, on Forge, a decision you get to make by hand. That's the difference between renting a platform and owning yours.

Want to know your store's ceiling today?
We measure the Core Web Vitals of your current operation and hand back an honest assessment: what's a tweak and what's a limit of the platform you use today.
Request a free assessment → Talk to a specialist →
Forge Team · hi@forgecommerce.pro
← back to the blog
.Free assessment

What you gain, what you lose, and whether migrating is worth it.

That is what the assessment delivers, in writing, after you tell us what your operation looks like today. Free, no strings attached.

Request a free assessmentorTalk to a specialist
hi@forgecommerce.pro+55 (11) 93624-1034