Skip to main content
Talk to an expert
ServiceHyvä performance optimisation

Hyvä performance optimisation, measured honestly.

Hyvä is a lighter frontend, but it does not guarantee good performance. The wider stack, third-party scripts, image handling, hosting and template weight all matter. We help set performance budgets, measure against real buying journeys, reduce frontend weight and prevent regressions over time.
600+
Commerce projects
40+
Engineers · on staff
31
Years · systems behind commerce
1995
Founded
01 · Where Hyvä performance work pays back

Where Hyvä performance work pays back

Hyvä does not guarantee performance
Hyvä can improve Core Web Vitals when the rest of the stack co-operates. It does not automatically fix a slow ERP, heavy third-party scripts or a misbehaving CDN.
Performance budgets up front
Page-weight, request-count, JavaScript and Core Web Vitals budgets agreed before tuning starts, so improvement is measured against a target rather than a feeling.
Real-journey Core Web Vitals
LCP, INP and CLS measured against the real buying journey (PLP, PDP, basket, checkout) on real devices, not a clean homepage on a fast laptop.
Template and component weight
Hyvä components reviewed for size, render cost and unnecessary work. Tailwind purged correctly; Alpine kept lean; over-eager hydration removed.
Image and media handling
Responsive images, modern formats, lazy loading and CDN behaviour audited end to end. Image weight is often the biggest single win.
JavaScript reduction
Bundle size, third-party libraries and unused code reduced where it pays back. Less JavaScript is usually more value than smarter JavaScript.
Third-party scripts under control
Tag manager, analytics, reviews, chat and recommenders audited for cost. Scripts moved server-side or deferred where they earn their place.
Hosting, CDN and edge
Origin, edge cache, asset delivery and cache headers reviewed. Performance gains at the server are wasted if the edge gives them back.
Measurement and monitoring
Real-user monitoring, lab tests and synthetic checks set up so regressions show up early, not as a Core Web Vitals scare report months later.
Regression prevention
CI checks, performance budgets in the build and a written change-review pattern so new features do not silently put the gain back.
Honest "what will and will not help" read
A written read on which fixes are real wins, which are cosmetic and which are not Hyvä's problem at all. No fake percentages.
03 · Platform fit and estate context

How this platform fits the wider commerce estate.

Fit against operational shape
Catalogue depth, trade complexity, branch logic and ERP integration named honestly before the platform decision is fixed, not assumed from a vendor demo.
Integration boundary with ERP
ERP owns commercial data, pricing and stock. The commerce platform reads the boundary through governed APIs; the boundary itself is the most important design decision in the estate.
PIM as the catalogue system of record
Deep catalogue governance lives in PIM (Akeneo, Salsify or similar). The commerce platform reads from PIM rather than re-modelling product data in the storefront.
OMS and fulfilment surface
Order management, partial dispatch, returns and customer-visible order state live in operational systems. The platform reads what operations actually did.
Search and merchandising
Native search plus specialist engines (Algolia, Constructor.io) assessed against the actual query mix, not a vendor benchmark. Relevance is a continuous activity.
B2B and trade behaviour
Account-only catalogues, customer-specific pricing, depot stock, quote-to-cart and partial dispatch modelled inside the platform rather than patched at the storefront.
Multi-store and multi-territory
Brand, market and territory storefronts modelled with shared catalogue, pricing and operations rather than parallel sites that drift apart.
Total cost over five years
Licence, hosting, engineering and support modelled honestly across the lifecycle, not just year one. The cheap year-one platform is often the expensive five-year one.
Headless and composable trade-offs
Headless or composable storefronts where they earn their place, not as a default. The trade-off between optionality and integration surface is named upfront.
Operational ownership and runbook
Long-term support, releases and integration ownership inside a UK agency that runs platforms day to day, with a written runbook the on-call team can act on.
Replatform sequencing
Where a platform move is on the table, sequencing by domain, traffic share or territory keeps trading live throughout. Big-bang relaunches are rarely the right shape.
Honest "do not move" advice
Where the existing platform is the right answer, iWeb says so on the record. A senior, written read on the brief is the deliverable, not a sales pitch.
04 · Questions we get asked

Questions we get asked.

Will Hyvä give us perfect Core Web Vitals?

No. Hyvä helps when the rest of the stack co-operates. We measure honestly against real buying journeys and do not promise specific scores.

What is a realistic gain from Hyvä performance work?

It depends on the starting point, third-party scripts and hosting. We measure before and after; we will not put a fixed number on it up front.

Where do most Hyvä performance problems come from?

Usually third-party scripts, image weight, hosting and over-eager JavaScript. The Hyvä framework itself is rarely the bottleneck once the basics are right.

Can iWeb monitor performance after launch?

Yes. Real-user monitoring, synthetic checks and CI performance budgets covered under the wider Hyvä support runbook.

Do we need to be on Hyvä to benefit from this work?

No, but this page is about Hyvä-specific tuning. Magento Luma performance work is a different conversation; we will say which fits the brief.

How does iWeb choose between platforms?

Against operational shape: catalogue depth, trade complexity, ERP integration, multi-territory rules and five-year cost. The decision is written down with trade-offs, not assumed from a vendor demo.

Where does ERP integration sit in the platform decision?

It is a primary input. Some platforms make ERP integration straightforward, some make it expensive. iWeb names the trade-off rather than hiding it.

Does iWeb deliver headless or composable storefronts?

Where they earn their place. The trade-off between optionality and integration surface is named upfront; composable is not a default.

How is search handled on this platform?

Native search where the query mix supports it; specialist engines (Algolia, Constructor.io) where the catalogue, volume or merchandising appetite justify them. Relevance is a continuous activity.

Where does PIM sit relative to the commerce platform?

PIM owns catalogue truth (attributes, variants, assets, channel readiness). The commerce platform reads from PIM rather than re-modelling deep product data in the storefront.

Can iWeb take over an existing build on this platform?

Yes, where the brief fits. iWeb will give a senior, written read on what is working, what needs remediation and what is honestly fixable, and the first month on support stays deliberately conservative on change.

How does iWeb size a five-year total cost picture?

Licence, hosting, engineering and support across the lifecycle, including the integration surface and operational ownership. The headline year-one number is rarely the honest comparison.

Accreditations & assurance
Gold Commerce Partner
Specialised in Commerce & AI
ISO certified
27001 · 9001 · 42001
Cyber Essentials Plus
Independently verified security
WCAG 2.2 AA
Accessibility embedded by design
Employee-owned
The same team, long term
Next step

Talk to a Hyvä developer

Send the brief. You'll get a written response from a senior expert on the platform, ERP and operational realities we'd look at first, not a pitch deck.
Talk to an expertor see hyvä support →