A site that loads fast isn't left to chance.

Because below that, there's almost always a real problem: an image that's too heavy, a useless script, a slow request. 95/100 is the level where the site is good for SEO, for conversion and for the visitor. We chose a threshold we can hold on all our sites, and we stick to it: no 95 announced and 82 in production.

Yes, because it's native in our EaaS stack. We don't build a site then optimize it: performance is a design constraint from the first line. Every store that goes into production on the stack starts at 95/100 minimum, with no catch-up phase afterwards.

It needs to be maintained, and that's precisely the role of the EaaS subscription. Each new feature, each payment module, each added integration can degrade the scores. Since the system is maintained and continuously improved, performance tests are part of the production cycle: 95/100 is not a given, it's a standard we defend for all the stores on the stack.

TTFB, FCP, LCP and CLS: these are the metrics Google uses to evaluate the real experience of visitors. We measure them under real conditions, not just in the lab: that's what counts for ranking and for your visitors. A site that scores 90 in a lab test but is slow in the field doesn't convert, and we know it.

Yes, provided it's set up well. That's exactly the point: we don't cache just anything. Storefront, category and product pages are served from the cache, and invalidation is precise: when a price or stock changes, the pages concerned regenerate, not the whole site. The customer always sees the right data, without paying the price of a page generated on the fly.

No, and that's a deliberate choice. Performance isn't added after the fact on an existing platform: it comes from the architecture, the rendering, the cache and the way the frontend loads its assets. That's why our clients arrive on the stack through a re-platforming, not through optimizing their existing site. Once on the stack, the performance is there from launch.

Not primarily. A more powerful server doesn't compensate for poorly thought-out architecture: many slow sites run on performant infrastructure that's simply misconfigured. What counts is the way content is generated, cached and served. In the EaaS subscription, the infrastructure is included and sized by us, you have nothing to configure.

That's true, some third-party scripts are what they are. Since they're integrated into the stack, we know them and we frame them: deferred loading, a lighter alternative when one exists, or limiting them to the moment the script is actually useful. What we can't improve, we tell you clearly with its quantified impact.