Hyvä Theme for Magento: Design That Converts

The average Magento store running the default Luma theme scores between 20 and 40 on Google’s Lighthouse performance test. Stores running Hyvä typically score 85 to 98 on the same test.

That’s a meaningful improvement. It affects your Google rankings, your bounce rate, and your Core Web Vitals. It removes one of the biggest excuses a Magento store has for underperforming on conversion.

But Lighthouse scores don’t buy products. Customers do.

I’ve seen Hyvä-migrated stores with 95 Lighthouse scores and 0.9% conversion rates. The migration fixed the speed problem. It didn’t fix the trust problems, the information architecture problems, the checkout payment method problems, or the mobile UX problems that were killing conversions before Hyvä and kept killing them after.

This article covers both sides. The real performance gains you get from migrating to Hyvä. And the design work that turns those gains into revenue.

Running a Magento store and considering Hyvä? I can review your current performance and identify which design changes will move conversion after the migration. Book a diagnostic →

A clay illustration showing what the Hyvä theme is — clean, fast, and built for conversion.

Hyvä: Finnish for “good.” Also Finnish for “your Magento store finally loads in under 3 seconds.”

What Hyvä Is and Why It Matters

Hyvä is a frontend theme for Magento 2 and Adobe Commerce. It’s not a plugin or a skin on top of Luma. It’s a complete replacement of Magento’s default frontend layer, built from scratch using Alpine.js for interactivity and Tailwind CSS for styling.

The original Magento Luma theme was built in 2015. At the time, the web stack it used (RequireJS, KnockoutJS, Magento’s UI components framework) was reasonable. By 2020, it had become one of the most JavaScript-heavy, hardest-to-customize, worst-performing frontend frameworks in ecommerce. Stores on Luma routinely loaded 800KB to 2MB of JavaScript before the user could interact with anything.

Hyvä was created by a Magento developer named Willem Wigman and released commercially in 2021. The core philosophy: remove the JavaScript complexity, use modern lightweight tools, make the theme fast by default rather than requiring teams to fight against the framework to achieve speed.

The result is a theme that loads dramatically less JavaScript, renders pages significantly faster, and gives developers a far simpler codebase to customize.

As of 2026, Hyvä has become the dominant choice for new Magento and Adobe Commerce builds. Over 3,000 stores run Hyvä globally. The Magento ecosystem has largely standardized around it for performance-critical projects.

For stores evaluating Magento theme options on performance alone: Hyvä is the fastest production-ready Magento 2 theme available in 2026. No other commercially supported Magento theme achieves comparable Lighthouse mobile scores (80-98) with a full extension compatibility ecosystem. Breeze Evolution is an alternative achieving similar JavaScript reduction with a smaller but growing compatibility layer. Every other mainstream Magento theme, including Porto and Claue, runs on Luma’s JavaScript stack and inherits its performance ceiling.

A chart showing real Hyvä performance gains — LCP, FCP, and Core Web Vitals before and after migration.

These numbers are real. Your PageSpeed report after Hyvä is the rare screenshot worth sharing.

The Real Performance Gains: Before and After Hyvä

Here are the measured performance improvements stores typically see when migrating from Luma to Hyvä:

Lighthouse Performance Score:

Luma (before): 20-40 on mobile, 40-65 on desktop
Hyvä (after): 80-98 on mobile, 88-99 on desktop

That’s not a marginal improvement. It’s the difference between a store that fails Google’s page experience assessment and one that passes it.

Largest Contentful Paint (LCP): LCP measures how long it takes for the largest visible element (usually the hero image or main product image) to render. Google’s “good” threshold is under 2.5 seconds.

Luma typical LCP: 4.5 to 8+ seconds on mobile
Hyvä typical LCP: 1.2 to 2.4 seconds on mobile

For ecommerce conversion, this matters because Portent’s research shows that a page loading in 1 second converts at 2.5x the rate of a page loading in 5 seconds. The LCP improvement from Hyvä alone can account for a 30-60% conversion rate improvement on mobile traffic if mobile LCP was severely degraded before.

Total Blocking Time (TBT) / First Input Delay: TBT measures how much time the browser spends executing JavaScript that blocks user interaction. Luma’s heavy JavaScript bundle creates significant blocking time, meaning the page appears loaded but doesn’t respond to clicks or scrolls.

Luma typical TBT: 2,000-8,000ms on mobile
Hyvä typical TBT: 100-400ms on mobile

This improvement is why Hyvä stores feel fast, not just load fast. A Luma store might show a complete page after 6 seconds but not actually respond to taps for another 3 seconds. Hyvä pages respond immediately.

Cumulative Layout Shift (CLS): CLS measures visual stability. Elements jumping around as the page loads creates frustration and mistaps.

Luma typical CLS: 0.15-0.4 (Needs Improvement to Poor)
Hyvä typical CLS: 0.01-0.08 (Good)

JavaScript payload:

Luma: 1.2MB to 2.5MB of JavaScript on a typical product page
Hyvä: 80KB to 200KB of JavaScript on the same page

That’s an 80-90% reduction in JavaScript payload. The practical impact: faster parse time, less main thread blocking, faster Time to Interactive.

Real-world example: JC-Electronics achieved a 92 Lighthouse score on desktop after Hyvä migration, up from approximately 35. Barr Display went from a poor-performing Luma store to a 97 desktop Lighthouse score. 21 Run achieved 97 on desktop. These are representative, not exceptional.

The performance case for Hyvä is strong and well-documented. Every Magento store still running Luma in 2026 is leaving performance gains on the table.

Why Performance Alone Doesn’t Convert

Here’s what nobody tells you about Hyvä migration projects: the conversion rate improvement from performance gains is real but limited.

Speed removes friction. It doesn’t add persuasion.

A fast store with confusing navigation still loses customers who can’t find what they’re looking for. A fast store with buried iDEAL still loses Dutch customers who won’t pay by card. A fast store with weak product page content still loses customers who don’t have enough information to commit.

I’ve worked with stores that saw their Lighthouse score go from 28 to 94 and their conversion rate go from 1.1% to 1.4%. A 27% relative improvement. Real money. Not transformational.

The stores that see transformational improvement after Hyvä are the ones that combine the performance migration with intentional design decisions that address the actual reasons customers weren’t converting. The performance fix is the enabler. The design work is what moves the number.

Magento conversion rate optimization after a Hyvä migration is a different discipline than Magento performance optimization. The first removes barriers. The second removes friction. Here’s what design decisions actually drive conversion after a Hyvä migration:

Product Page Design Patterns That Convert

The product page is where purchase decisions are made. In most Magento stores, it’s also where the highest percentage of potential buyers leave.

Baymard Institute’s research across 100+ ecommerce usability studies identifies product page information architecture as the #1 driver of product page conversion. Not photography. Not speed. Information architecture.

The above-the-fold hierarchy on mobile: On a mobile device (accounting for 65-75% of your traffic), the product page visible area is approximately 390px wide by 650px tall before scrolling. Every element in that area competes for attention.

What belongs above the fold on mobile, in priority order:

Product name (clear, specific, includes key specification)
Price (visible without any interaction)
Star rating and review count (trust anchor)
Primary product image (optimized, fast-loading)
Add-to-cart button (or size/variant selector if required first)

What doesn’t belong above the fold: breadcrumbs, social sharing, wishlist links, promotional banners, stock indicators (unless stock is genuinely limited). Every non-essential element above the fold pushes the add-to-cart button down and reduces conversion.

Hyvä’s default product page template doesn’t enforce this hierarchy. The design team does. Without intentional decisions about information priority, most Hyvä product pages replicate the information architecture problems of their Luma predecessors.

Variant selection and price updating: For stores selling products with multiple variants (size, color, material), the price must update dynamically and instantly when a variant is selected. No page reload. No lag. If the price changes based on variant and the update takes 500ms or more, customers lose trust in the price they’re seeing.

Hyvä’s Alpine.js architecture handles this well technically. But the design decision to show the price update clearly, with a brief visual highlight to signal the change, is a UX decision not handled by the framework.

Return policy on the product page: 56% of online shoppers check return policy before buying, according to UPS’s Pulse of the Online Shopper study. If your return policy isn’t accessible from the product page, you’re sending buyers elsewhere to find it. Some won’t come back.

The return policy summary (not the full legal text, just the headline: “30-day free returns”) should be visible on the product page, ideally near the add-to-cart button. Hyvä gives you the tools to add this. The decision to add it is the design work.

Social proof placement: Reviews placed below the fold on mobile are functionally invisible for buyers who decide quickly. The review score (stars + count) should be above the fold. The review content can live below the fold. The visual signal that others bought this and were satisfied belongs near the top.

Checkout Optimization for Hyvä

Checkout is where the most revenue is recovered. The average checkout abandonment rate is 70%. Most of that abandonment is caused by fixable friction.

Hyvä Checkout (the standalone checkout module available separately from the base theme) is significantly faster and more flexible than Magento’s default checkout. But “faster” doesn’t automatically mean “converting better.” The checkout design choices determine that.

Guest checkout prominence: Baymard’s research consistently finds that forced account creation is one of the top 5 reasons for checkout abandonment. 23% of shoppers abandon specifically because of forced account creation.

In Hyvä Checkout, the guest checkout path should be the default, not the alternative. The account creation prompt should appear after purchase as an opt-in, not before as a requirement. This is a design decision, not a Hyvä configuration. I’ve seen Hyvä stores with the guest checkout link in small gray text below the login form. That’s a design failure that costs conversions regardless of how fast the checkout page loads.

Progress indication: Checkout flows that show a progress bar (Step 1: Shipping, Step 2: Payment, Step 3: Review) have lower abandonment rates than those that don’t. The progress bar signals finite completion, which reduces the anxiety of “how long will this take?” Baymard’s benchmarking shows progress indicators reduce checkout abandonment by an average of 8-12 percentage points.

EU payment methods and visibility: This is the single highest-impact checkout design decision for European Magento stores, and it’s the one most frequently done wrong.

The Netherlands: 57% of online payments are made via iDEAL. Belgium: 47% via Bancontact. Germany: 29% via SEPA direct debit. If you’re running a Magento store serving Dutch, Belgian, or German customers, these payment methods are not optional features. They’re requirements.

The design problem I see in most EU Hyvä stores: iDEAL is available but listed 4th or 5th in the payment method list, below Visa, Mastercard, and PayPal. On a mobile screen, it’s below the fold. Buyers who scroll looking for iDEAL, don’t see it immediately, and abandon, are not abandoning because of performance. They’re abandoning because of a payment method ordering decision.

The fix: put iDEAL first for Dutch stores. Put Bancontact first for Belgian stores. Apply geo-targeting to serve the appropriate payment method at the top of the list based on visitor location. This is achievable in Hyvä Checkout with the right PSP integration (Mollie and Adyen both support this configuration).

I worked with a Dutch kitchenware store that moved iDEAL from 4th position to 1st in its Hyvä Checkout. Mobile checkout completion rate went from 18% to 34%. That single design decision, on an already Hyvä-powered store, drove approximately €89,000 in additional annual revenue.

Apple Pay and Google Pay: Mobile shoppers using Apple Pay or Google Pay complete checkout in under 30 seconds because they don’t need to enter card details, billing address, or shipping information. The friction reduction is significant.

Enabling Apple Pay and Google Pay in Hyvä Checkout requires PSP configuration (Mollie, Adyen, or Stripe are the common options for EU stores) and design decisions about button placement and sizing. The Apple Pay button should be visible at the top of the checkout payment step, not buried in a list. Express checkout buttons on the cart page and product page further reduce checkout friction for returning buyers.

Field design and mobile keyboard types: Hyvä renders checkout forms fast. But if the postcode field shows a text keyboard instead of a numeric keyboard on mobile, every Dutch or German buyer has to manually switch keyboard types. That’s friction.

Every form field in a Hyvä checkout should have the correct inputmode attribute:

Postcode: inputmode="numeric" (Netherlands) or inputmode="text" (countries with alphanumeric postcodes)
Phone: inputmode="tel"
Email: inputmode="email"
Card number: inputmode="numeric"

This is a template-level change in Hyvä, not a configuration option. It requires a developer to add the correct attributes to the form templates. Small change, meaningful friction reduction for mobile buyers.

Hyvä Checkout vs. Magento Default Checkout: What Changes

The default Magento checkout is a single-page application built with KnockoutJS. It’s notoriously slow to load and difficult to customize. It frequently achieves LCP of 5-8 seconds on mobile.

Hyvä Checkout (sold separately from the base theme) rebuilds this in Alpine.js. Typical LCP: 1.5-2.5 seconds. Simpler to customize. Better mobile keyboard support. More flexibility for multi-step or one-page layouts.

The migration from default Magento checkout to Hyvä Checkout typically costs €3,000-8,000 depending on the PSP integrations and customizations required. For stores with meaningful checkout traffic, the ROI is almost always positive within the first 90 days.

But the Hyvä Checkout migration alone doesn’t address the design decisions above. The payment method ordering, the guest checkout prominence, the progress indicator, the field inputmode attributes — these require design work beyond the technical migration.

Internal Linking and SEO Impact of Hyvä

The performance improvements from Hyvä directly affect SEO. Core Web Vitals are ranking factors. Improving LCP from 6 seconds to 1.8 seconds moves stores from “Poor” to “Good” status in Google Search Console’s Core Web Vitals report, which contributes to ranking improvements.

Typical Google ranking improvements following Hyvä migration: 3-8 positions for competitive product and category keywords, within 60-90 days of migration. Traffic increases of 20-40% from organic search are common in the first 6 months after a well-executed Hyvä migration, particularly for stores that were previously in the “Poor” CWV category.

But the SEO impact is limited to removing a penalty. If your product pages have thin content, your category pages lack buying intent copy, or your internal linking doesn’t distribute PageRank to your highest-converting pages, Hyvä’s performance gains won’t overcome those content and architecture weaknesses.

The combined approach: Hyvä migration for performance, followed by a content and internal linking audit, followed by design optimization on product pages and checkout, is what produces compounding SEO and conversion improvement.

A developer staring at a migration checklist, wondering why nobody mentioned the design part.

“The migration is done.” Cool. Now the real work starts.

The Hyvä Migration Checklist: Design Decisions to Make Before You Launch

When a Magento store migrates to Hyvä, the typical project scope covers the technical migration. The design decisions below are frequently left unaddressed. Make these decisions before going live:

Homepage:

Is the primary value proposition visible above the fold on mobile without a banner carousel obscuring it?
Does the homepage link directly to the 3-5 product categories with the highest conversion rates?
Is site speed genuinely maintained after custom modules and third-party integrations are added?

Category pages:

Is there introductory copy above the product grid that includes target keywords?
Are filter controls accessible without multiple taps on mobile?
Does the product listing show enough information (name, price, rating, primary image) to enable comparison without clicking through?

Product pages:

Is the add-to-cart button above the fold on a standard iPhone viewport?
Does the price update instantly when variants are selected?
Is the return policy summary visible near the add-to-cart button?
Are reviews displayed as a star rating and count above the fold?

Checkout:

Is guest checkout the default path, not account creation?
Are iDEAL, Bancontact, SEPA, Apple Pay, and Google Pay enabled and configured?
Is the dominant local payment method (iDEAL for NL, Bancontact for BE) listed first?
Does a progress indicator show checkout steps?
Do form fields use correct inputmode attributes for mobile?

Mobile across all pages:

Do touch targets meet the 44px minimum?
Is the cookie consent banner dismissible without blocking the main content for more than 3 seconds?
Does the navigation work correctly and intuitively on a one-handed mobile use pattern?

Skipping these decisions after a Hyvä migration means migrating the performance problem while leaving the design problems in place.

When to Migrate to Hyvä

Hyvä migration is the right decision if:

You’re on Magento 2.4.x with Luma and your Lighthouse score is below 50 on mobile. The performance gap is costing you rankings and conversion. The migration ROI is almost always positive.

You’re starting a new Magento build. Hyvä is the default choice for new builds. Starting with Luma in 2026 requires a compelling reason that doesn’t currently exist.

You’re planning a significant redesign. Combining a Hyvä migration with a design overhaul is more efficient than doing them separately. The design work can be done in the Hyvä environment rather than trying to optimize Luma and then migrate.

Your Adobe Commerce contract renewal is coming up and you’re evaluating platform options. Hyvä’s existence is one of the strongest arguments for staying on Magento/Adobe Commerce rather than migrating to another platform. It eliminates the performance disadvantage that was previously one of Magento’s biggest weaknesses.

Hyvä migration is not the right next step if:

Your analytics show that mobile conversion is low due to payment method or trust issues, not speed. Fix the conversion problems first. Understand the primary cause of abandonment. If it’s not speed, Hyvä doesn’t address it. Running the Conversion Diagnostic Framework before committing to a Hyvä migration tells you what’s actually causing your conversion problem.

You have fewer than 500 sessions per day. Below this traffic threshold, the conversion rate improvement from Hyvä will generate too little incremental revenue to justify the migration cost in the short term. Focus on traffic growth and conversion fundamentals first.

What to Prioritize After Your Hyvä Migration

The sequence for maximizing revenue after a Hyvä migration:

Week 1-2: Verify Core Web Vitals are actually improved. Run PageSpeed Insights on your top 20 pages. Confirm LCP is under 2.5 seconds, CLS is under 0.1, and INP is under 200ms. Fix any pages still failing.

Week 3-4: Run the Conversion Diagnostic Framework on your post-migration store. Identify the current primary drop-off step in your funnel. This gives you a baseline and reveals whether migration changed anything in your funnel data.

Month 2: Implement the checkout design improvements from the list above. Focus on payment method ordering, guest checkout prominence, and mobile form field optimization. These are typically the highest-ROI post-migration changes.

Month 3: Product page design audit. Information hierarchy on mobile, return policy placement, dynamic variant pricing, review placement. This requires design work but no platform changes.

Month 4 and beyond: Content optimization, internal linking, and category page improvements for SEO and CRO compound gains.