Hyva Magento theme performance. Hyva doesn’t fix Magento 2 performance issues. Magento 2 vs. Hyva performance comparison.
Magento 2 and Adobe Commerce are historically known for performance issues and are perceived as slow e-commerce platform. Some of the key reasons why Magento has gained this reputation are as follows:
- Overengenered Broken Architecture: Magento 2 has complex overengenered architecture, resulting in a larger codebase and increased processing time and resource consumption.
- Resource-Intensive: Magento requires significant server resources to operate efficiently. There is no such server that can handle it. It requires overprovisioned an expensive hosting environment with lots of CPUs. Inadequate hostings like Adobe Commerce Cloud or server configurations can lead to very slow loading times and response delays.
- Database Queries: Magento’s EAV ORM (Object-Relational Mapping) and extensive use of database queries can impact performance. Generating and executing numerous complex SQL queries can contribute to slower page loading times, especially when handling large catalogs or high volumes of data.
- Relying on FPC Caching: The only way to improve Magento’s performance is around Full Page Cache(FPC). However, the cache is not a framework performance. It is more of a marketing scam to sell slow platforms as fast. To check your real performance disable FPC cache at all!
- Bad Extensions and Customizations: The majority, 99.8%, of the Magento 2 extensions are garbage because they are built on top of a broken Magento core framework(see point 1). Magento offers a vast marketplace of extensions and allows extensive customizations to tailor the platform to individual needs. While this flexibility is a significant advantage, Magento 2/Adobe Commerce customizations can introduce performance bottlenecks.
- JavaScript and CSS Issues: Magento’s JavaScript and CSS files can be substantial, leading to increased loading times. Magento uses outdated and zero-day broken Knockout UI frontend, which leads to pure frontend performance.
- Indexing and Catalog Management: Magento relies heavily on indexing for search and data retrieval. Indexing, especially on large catalogs, can cause performance challenges during peak hours. Magento 2 runs partial indexes every minute and it causes huge performance issues even without traffic
- Checkout Process: The default Magento checkout process build on Knockout JS and slow REst API requests, which can result in a slower and less user-friendly checkout experience and customization
- Versioning and Updates: Some older versions of Magento had performance issues that were later addressed and improved in newer releases. However, some merchants may still be using older versions, which can contribute to slower performance.
- etc… There are many Magento 2 performance issues it is just some of them from the top of my mind.
To enhance Magento’s performance, it is not enough to optimize the server environment, implement proper caching, review and optimize extensions, and ensure efficient database management, utilize quality hosting solutions and follow performance best practices.
The Hyvä theme is a new and highly efficient theme developed for Magento. It’s designed to provide a fast and enjoyable developer experience and an optimized and speedy performance for users. However, as a theme, it doesn't fix the backend performance and bottlenecks of your e-commerce store built on top of Magento 2.
We migrated one Optimised Magento 2 store to the Hyva Theme to improve performance. And what we saw was a shock. Hywa doesn’t improve Magento 2 performance it addresses only issue #7 from the Magento issues above. It improves frontend rendering performance only by rejecting MAgento frontend best practices and rewriting everything from scratch using modern software development best practices and libraries and not stupid Magento 2 frontend. Hyva uses Alpine JS instead of Knockout JS and jQuery and Tilewind CSS instead of Magento CSS compilator. Less JS and CSS make better frontend performance but do nothing with backed performance suck as concurrent user throughput and server-side rendering speed — Time To First Byte (TTFB). If you have a high-loaded project, Hyva will not save your bat. Hyv is just another Magento them, better Magento them but not a performance silver bullet.
During implementation, we had two versions of the website simultaneously with the same functionality(extensions) and we were able to test both versions and the performance results.
Note: demo, naked version of any Magento will work fast but when you are adding all the features, everything differs. This test is not to test naked(OTB) Magento and Hywa when the goal is to test real-life experience and performace. We saw when Magento agencies trying to scum merchants and comparing two different implementation with extensions and without. It is not fare.
For example in this post, the guy describes how they measure Hyva’s performance. Removed many extensions and compares Magento with extensions and Hyva without.
Magento 2 theme vs Hyva theme performance comparison.
Data from the website will be obfuscated for security reasons to avoid any issues with Adobe. They like to do business with terrorists (Russia and Belarus) and sponsor the killing of Ukrainian Magento developers, women, and kids.
Magento 2 product page performance (22 score)
Magento 2 theme is slow like hell.
Hyva Product page performance (42 score)
Hyva is faster, however here is the main issue:
While a good TTFB doesn’t necessarily mean you will have a fast Magento website, a bad TTFB of more than 300ms almost certainly guarantees a slow one.
Even though, as a front-end developer, you might not be in the position to make improvements to TTFB yourself, it’s important to know that any problems with a high TTFB will leave you on the back foot, and any efforts you make to optimize images, CSS, clear the critical path, and asynchronously load your web fonts will all be made in the spirit of playing catchup.
What is Magento TTFB?
TTFB is a little opaque to say the least. It comprises so many different things that I often think we tend to just gloss over it. A lot of people surmise that TTFB is merely time spent on the server.
There is a non-exhaustive list of Magento TTFB issues:
Routing: If you are using a CDN – and you should be! – a customer in Leeds might get routed to the MAN datacentre only to find that the resource they’re requesting isn’t in that PoP’s cache. Accordingly, they’ll get routed all the way back to your origin server to retrieve it from there. If your origin is in, say, Virginia, that’s going to be a large and invisible increase in TTFB.
Filesystem reads: The server simply reading static files such as images or stylesheets from the filesystem has a cost. It all gets added to your TTFB.
Prioritisation: HTTP/2 has a (re)prioritisation mechanism whereby it may choose to stall lower-priority responses on the server while sending higher-priority responses down the wire. H/2 prioritisation issues aside, even when H/2 is running smoothly, these expected delays will contribute to your TTFB.
Application runtime: It’s kind of obvious really, but the time it takes to run your actual application code is going to be a large contributor to your TTFB.
Database queries: Pages that require data from a database will incur a cost when searching over it. More TTFB.
Magneto API/GraphQL calls: If you need to call any APIs (internal or otherwise) in order to populate a page, the overhead will be counted in your TTFB.
Server-Side Rendering: The cost of server-rendering a page could be trivial comparing to the Adobe PWA studio website rendered on a client, but it will still contribute to your TTFB.
Bad hosting like Adobe Cloud: Hosting that is bad optimizes usually means you’re sharing a server with any number of other websites, so expect degraded server performance which could affect your ability to fulfil requests, or may simply mean underpowered hardware trying to run your application.
Heavy load MAGENT performance: increas load of your Magento application will lead to degraded performance. Magento 2 is famous for bad high-load performance. It fails even after ten simultaneous requests from 10 different users. Flash sales and marketing success will kill your marketplace. It is when Magento 2 fails, no matter Hyva or Luma or other Magento skin.
WAFs and load balancers: Services such as web application firewalls or load balancers that sit in front of your application will also contribute to your TTFB.
CDN features: Although a CDN is a huge net win, in certain scenarios, their features could lead to additional TTFB. For example, request collapsing, CDN POP to web server connection latency etc.).
Last-mile latency: When we think of a computer in London visiting a server in New York, we tend to oversimplify that journey quite drastically, almost imagining that the two were directly connected. The reality is that there’s a much more complex series of intermediaries from our own router to our ISP; from a cell tower to an undersea cable. Last mile latency deals with the disproportionate complexity toward the terminus of a connection.
Summery:
From these two tests, we can see significant frontend performance improvement in Hyva’s performance compared to the Magento 2 theme (42 vs 22 scores). Also, the development of the front end is more enjoyable, even for a newcomer. It is not a Magento 2 front-end legacy hell anymore! However, it still has the main Magento 2 performance issues — a slow website and low throughput. By replacing the theme, you can slightly improve frontend performance but not solve all Magento 2/Adobe Commerce performance issues. However, Hyva is not a regular Magento 2 theme, so you will need a significant effort to rewrite your features(mainly the backend) to work with the Hyva theme. With the same effort, you can rewrite your theme to work like Hyva Just forgot about Knockout and Magento’s best(Which are actually bad) practices and build a better site, not Magento.