logo company

Contact us:
+(48) 572 970 235 or Book a call
Magento Magento theme Website Performance

Magento 2 Hyvä Performance Optimization Case Study: How We Reduced Frontend Load and Stabilized Algolia Search

0%
Magento 2 Hyvä Performance Optimization Case Study: How We Reduced Frontend Load and Stabilized Algolia Search

A Magento 2 store running on Hyvä had frontend performance issues caused by scripts, API requests, widgets, and interactive components that started too early across multiple page types. This created unnecessary load during the first page render and affected the consistency of customer-facing interactions.

We at Transform Agency handled this as a Magento 2 Hyvä performance optimization case study focused on frontend load reduction, Algolia search stability, and Hyvä-compatible architecture refinement. Our team worked on deferred script execution, Amasty Magento 2 extension compatibility, product gallery logic, font asset cleanup, Page Builder components, and frontend-only improvements without vendor code changes.

As a result, the storefront achieved faster initial rendering, fewer unnecessary network requests, more stable search and interactive components, and a cleaner frontend architecture aligned with Hyvä best practices.

Project Snapshot

  • Platform: Magento 2
  • Theme: Hyvä Themes
  • Project type: Magento 2 frontend performance optimization
  • Main issue: Non-critical scripts, widgets, API requests, and interactive components started too early
  • Key integrations: Algolia, Amasty Custom Form, Amasty GDPR Cookie, Magento Quick Checkout, Magento Page Builder
  • Main constraint: No vendor modifications
  • Result: Faster initial storefront render, fewer unnecessary requests, and more stable search and interactive flows

Business Challenge

The client’s Magento 2 Hyvä storefront loaded too many frontend scripts, API requests, and interactive components immediately, even when they were not required for the current page or customer action.

This caused several issues:

  • Unnecessary frontend load during the initial page render.
  • Extra network activity from scripts and API requests.
  • Inconsistent behavior across different page layouts.
  • Compatibility issues between Hyvä and extensions originally designed for Luma / RequireJS.
  • Instability in Algolia search, autocomplete, and preview flows.
  • Extra frontend overhead from Amasty modules, Magento Quick Checkout, product gallery logic, fonts, and Page Builder components.

The main business risk was that the store could lose the performance benefits of Hyvä if Luma-oriented frontend behavior, early script execution, and unnecessary requests stayed in the first render path.

Our key challenge was to improve Magento 2 storefront performance without reducing search usability, customer interaction quality, or future maintainability.

Scope and Deliverables

We delivered:

  • Hyvä storefront performance optimization.
  • Magento 2 frontend architecture refinement.
  • Deferred load logic for third-party scripts, widgets, and customer-facing interactive components.
  • Stabilized Algolia search, autocomplete, and preview flows.
  • Magento 2 extension frontend optimization.
  • Product gallery optimization.
  • Font and Page Builder component improvements.
  • Frontend-only architecture improvements without vendor modifications.

Solution Approach

We approached the project as a frontend performance and architecture refinement initiative. The goal was to reduce unnecessary load during the first render, stabilize key interactive flows, and keep the solution clean, maintainable, and fully frontend-focused.

1. Hyvä Storefront Initialization Review

We began with a detailed review of the Hyvä storefront initialization flow. This helped us understand which frontend dependencies loaded on each page type and which scripts affected the first render.

The review covered search, forms, cookie consent, product gallery logic, carousels, third-party widgets, Page Builder components, and extension-related scripts. We identified components that loaded globally, even though the storefront only needed them on specific pages or after a customer action.

Result: We created a clear dependency map and separated critical frontend logic from scripts that could safely start later.

2. Deferred Load Strategy

We built a consistent deferred load strategy around Hyvä’s init-external-scripts event.

Instead of allowing non-critical JavaScript, API requests, widgets, and interactive components to start during the first render, we moved them out of the initial load path. These elements now start only when the storefront requires them.

Result: The storefront reduced unnecessary frontend overhead while keeping customer-facing functionality intact.

3. Algolia Search Stabilization

Algolia search was one of the main focus areas of the project because its behavior affected category pages, search pages, autocomplete, and preview flows.

We restructured the initialization logic for Instant Search and autocomplete. The updated logic now considers page type and viewport width, so search components load only where they are relevant. We also corrected DOM timing issues that had caused empty container scenarios.

Result: Algolia search became more stable, and the preview-to-full-search transition became more reliable across the Magento 2 Hyvä storefront.

4. Magento 2 Extension Frontend Optimization

We optimized several frontend extension flows to reduce unnecessary load and improve storefront behavior.

The work covered custom forms, GDPR cookie logic, carousel components, and other customer-facing frontend elements. Instead of allowing these components to start too early, we adjusted their frontend initialization and moved non-critical logic into the deferred load flow.

Result: The storefront became lighter, more stable, and easier to maintain, while extension functionality remained intact.

5. Product Gallery Optimization

We revised the product gallery logic to improve the initial product page experience.

The storefront now shows lightweight product previews right away, while the full interactive gallery starts after deferred script execution. This keeps the product page responsive during the first render without removing the full image browsing experience.

Result: The product gallery no longer adds unnecessary weight to the initial page load, while customers still get the full interactive gallery experience.

6. Font and Asset Load Cleanup

We reviewed font asset paths and preload behavior to remove incorrect resource requests.

After we aligned font paths with actual resource locations, the storefront no longer requested missing font files. We also corrected preload behavior so the browser could handle key assets more reliably.

Result: The storefront reduced network noise and achieved more reliable asset delivery.

7. Magento Quick Checkout Adjustment

Magento Quick Checkout added Luma-specific assets to Hyvä page output.

We introduced a frontend-only adjustment that prevents unnecessary Luma-oriented assets from entering Hyvä pages. The adjustment did not require vendor code changes.

Result: Hyvä pages stayed cleaner and avoided extra frontend overhead from Luma-specific assets.

8. Frontend Architecture Refinement

We moved the main storefront logic into the Hyvä theme layer and limited core interception to narrowly scoped frontend-only add-ons.

This approach helped us avoid vendor file modifications and reduce long-term maintenance risk. It also gave the client a cleaner Magento 2 frontend architecture that is safer to extend.

Result: The final structure followed Hyvä development practices and created a stronger base for future frontend improvements.

How We Verified the Improvements

We validated the work through frontend review across key page types, including category pages, search pages, product pages, and pages with customer-facing interactive components.

Our checks focused on script behavior, network requests, DOM readiness, search container stability, font resource paths, and compatibility between Hyvä and Luma-oriented extension logic.

This helped us confirm that deferred scripts still worked correctly after user interaction and that key storefront flows remained stable.

Measurable Outcomes

The original project data did not include numeric performance benchmarks. Based on the completed work, the measurable technical outcomes were reduced unnecessary frontend requests, corrected font resource behavior, stabilized Algolia initialization, and cleaner Hyvä-compatible frontend architecture.

The Magento 2 Hyvä performance optimization project delivered the following results:

  • Faster initial storefront rendering.
  • Fewer unnecessary frontend network requests.
  • More stable Algolia search, autocomplete, and preview behavior.
  • Better consistency across category and search pages.
  • Improved Hyvä compatibility for Amasty modules.
  • Cleaner product gallery initialization.
  • Corrected font asset load behavior.
  • Reduced Luma-specific frontend overhead in Hyvä pages.
  • More maintainable frontend architecture without vendor modifications.

The result was a Magento 2 Hyvä storefront with a lighter first render, cleaner frontend logic, and more predictable customer-facing interactions.

Tech Stack

  • Magento 2
  • Hyvä Themes
  • Algolia Instant Search
  • Algolia Autocomplete
  • Amasty Custom Form
  • Amasty GDPR Cookie
  • Magento Quick Checkout
  • Magento Page Builder
  • Product gallery frontend logic
  • JavaScript
  • Hyvä-compatible template-based frontend implementation
  • Frontend-only Magento customization
  • Luma / RequireJS compatibility refinement

Business Impact

We helped the client improve the storefront experience by reducing unnecessary frontend load and stabilizing key interactive flows.

The client received a faster, cleaner Magento 2 Hyvä storefront with fewer compatibility issues between Hyvä and Luma-oriented extensions. Since we avoided vendor modifications and kept the main logic inside the Hyvä theme layer, the architecture became easier to maintain and better prepared for future Magento 2 improvements.

Key Learnings

Magento 2 stores on Hyvä need a different frontend optimization approach than Luma-based storefronts. Extensions built around RequireJS often require Hyvä-compatible patterns, and deferred script execution is critical for keeping scripts, widgets, API requests, search components, and product galleries out of the first render path.

Algolia search needs precise initialization timing, especially when autocomplete, preview containers, category pages, and full search pages depend on each other. Frontend-only Magento 2 optimization can improve performance and stability while avoiding vendor modifications and reducing long-term maintenance risk.

If your Magento 2 store has similar Hyvä performance issues, unstable Algolia search behavior, unnecessary frontend requests, or Luma-to-Hyvä extension compatibility problems, we at Transform Agency can support you through our Hyvä theme customization service, including a focused frontend audit and bottleneck analysis.

lera-kuksa-n

Written by Valeria Kuksa

Content Marketing Manager at TA

Expert in creating engaging written content. Skilled at analyzing audience behaviors and refining strategies to align business goals with customer interests. Proven ability to craft content that connects deeply with audiences. Passionate about staying current with trends to boost engagement.

lera-kuksa-n

Written by Valeria Kuksa

Content Marketing Manager at TA

Expert in creating engaging written content. Skilled at analyzing audience behaviors and refining strategies to align business goals with customer interests. Proven ability to craft content that connects deeply with audiences. Passionate about staying current with trends to boost engagement.

Next E-Commerce Inventory Management Guide: Best Practices, Tools & Strategies
0 Comment(s)
To Top