Author - Pradip Shah

Magento and WordPress site performance can improve with proxysql

proxysql is a small infrastructure change that can bring about a huge performance difference in large traffic Magento and WordPress websites.

What is proxysql?

Proxysql is a high performance mysql proxy. As a proxy it sits between the application and mysql. mysql requests from the application are routed to the proxy, which in turn routes the request to mysql.

Since it sits between the application and mysql, it can intercept the query and do many things – like routing select queries to a read-only replica, or load balance between a set of write replicas (such as a galeria cluster). It also collects a lot of interesting statistics that can help optimize the application.

Unexpected performance gain from an issue with mysql threading model

But, the a huge gain is achieved by increasing performance of mysql in a high traffic environment. This is achieved due to a drawback in the mysql threading model.

Mysql follows a “one thread per connection” threading model. Moreover, a single mysql thread corresponds to a operating system thread. A high traffic php application does not share mysql connections and as a result can have a large number of threads.

Some of the drawbacks of this model :

  • Mysql consumes memory per connection used and once consumed, this memory is never given back. As a result, mysql performance can deteriorate over time.
  • A CPUs performance is very heavily dependent on hardware level caches. These are dependent on the “principle of locality“. With too many threads executing simultaneously, the cache hit ratios go down, reducing CPU performance.
  • With too many threads executing in parallel, context switching overhead is high. Context switch is when the operating system decides to switch execution from one thread to another. A single CPU core can only execute on thread at a time.
  • Too many transactions executing in parallel increases resource contention in mysql. In InnoDB, this increases the time spent holding central mutexes. This results in queries running slow for no obvious reason.

Proxysql solves this problem by not opening a new connection for each client request. It reuses connection it may already have open with mysql.

Reference : MySQL Enterprise Documentation

Effect of context switching due to high number of mysql threads

The figure alongside shows the effect of context switching.

Upto 3rd May 2024, there is high CPU usage. The green bars are for CPU used by the operating system in context switching between threads. The DB server consuming almost 100% CPU and at the same time not responding to queries.

3rd May saw the introduction of proxysql. The CPU usage is now stable, with not much used by system in context switching.

Towards the leftThe green bars are CPU spent by the system in context switching between threads. Adding proxysql immediately dropped CPU usage.

The image alongside is the number of mysql threads for the same period. The correlation between the system CPU and the number of threads makes it obvious cause and effect.

Upto 3rd May, mysql has a surge in threads – caused by a spiral of slow insert or select queries adding more threads and slowing down the db. 3rd May saw the introduction of proxysql – and mysql now uses a small number of threads.

We will explore Mariadb Thread Pool shortly to see how it compares with the proxysql approach.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

Enterprise Class Hosting that does not hurt your bank!
With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

luroConnect Image Optimization Support : Watchimage

Image Optimization is a basic requirement to have a faster website. Photo images used in websites are generated with too large a size to be served over the internet on a web page. Also browser support for different, more modern and efficient (by storage) formats vary, requiring an image optimizer to be used on a website.

Generating images in different formats may be required in websites to support different browsers. This is part of image optimization.

luroConnect WatchImage service, “watches” a set of directories where images may be generated or saved and automatically generates different formats for the same image – keeping the base file the same and renaming the extension appropriately.

For example for Magento, if one wants to generate avif and webp images, the following settings work :

luroConnect WatchImage Configuration

How does it work?

A watch is setup for the folder mentioned and when a new image is saved in any folder or subfolder, the image conversion will automatically be launched and the formats specified will be generated, with the same base name and corresponding extension.

For example If we are watching

pub/catalog/product/cache folder and an image with the name 3af406316384c53a5f29d3772fa411e5_2.jpg is saved the following images will be generated

pub/catalog/product/cache/3/a/3af406316384c53a5f29d3772fa411e5_2.webp

pub/catalog/product/cache/3/a/3af406316384c53a5f29d3772fa411e5_2.avif

The developer can generate the picture element with srcset for mime types image/webp and image/avif with the same base file name but with the corresponding file extensions.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like Image Optimization, ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Use of luroConnect WatchImage Service

This is best suited when the HTML code uses <picture> element with fine tuned image sizes (and mime types).

Information about <picture> element is found here.

HTML supports the picture element which allows a developer to define various image sizes and formats and specify conditions – much like css media query – for the browser to decide what is the closest match.

Briefly, using <picture> as the parent tag and <srcset> to specify conditions and alternatives.

<picture>
<source srcset="catalog/product/cache/xxx_for_600_width/m/y/myimage.jpg" media="(min-width: 600px)" />
<source srcset=" catalog/product/cache/xxx_for_600_width/m/y/myimage.webp" type="image/webp" media="(min-width: 600px)" />
<img src="myimage.jpg"/>
</picture>

luroConnect Magento CI/CD adds meta information to builds

luroConnect CI/CD

luroConnect managed hosting platform includes CI/CD from any git source.

luroConnect CI/CD is an opinionated, platform specific CI/CD. It currently supports Magento (luma, Hyva, ScandiPWA themes), PWAStudio, Angular, nodejs applications. Nodejs builds include yarn and npm based installation.

Builds are done in docker with environment variables. (Note : Our Magento CI/CD also builds in docker without a database).

Builds once made, are ready to be deployed.

Advantage of opinionated CI/CD

  • Built for the target application stack with options.
  • Improved over time in a platform specific way
  • Magento CI/CD builds support features like magepack bundling, css and js minification, luma, Hyva and ScandiPWA themes.
  • Magento CI/CD support multi website and multi store builds
  • PWAStudio supports multi website and mutli store builds with different default currencies.
  • Is built using resources on your AWS account and created to deploy on your AWS account.

Meta Data information

Builds are identified with git commnit-id (shortened). Meta information includes the branch, the build number (generated from git as a serial count of commits in the branch upto this commit-id), and the git comment for this release.

luroConnect dashboard now displays meta data with the current deployed version.

When deciding which version to deploy, meta data information is displayed as well.

Build counts are useful as they are serial numbers – a larger number indicates a later commit serially. Commit comments are useful to know the PR or merge comment used so one is sure of the deployment.

luroConnect build and deploy dashboard

Magento CI/CD metadata

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Improving Headless load times – Server Side Rendering Update

PWA / Headless with Magento.

PWA and Headless started with a lot of hype and promises. Many websites have benefited from successful implementations that proves many promises were fulfilled.

However, one of the biggest drawbacks of a headless / PWA implementation of a Magento website is the page load times – especially as reported by tools and metrics not tuned for the benefits.

A key benefit headless offers is improved navigation experience, but that is not measured, even by some Real User Monitoring (RUM) tools.

Headless makes sense – almost imperative – in many cases such as a large changing catalog (we have a customer with 700k products with 1k new product uploads and additional 1k product updates daily).

While navigating, a graphql is responsible for updating the page with content and it returns only the data asked for, which can be cached across all users. For uncached catalog graphqls, the Elastic Search is most crucial part of the system for performance, but a lot of php formatting such a the menu, that went along with it is now eliminated.

This has to be a better system. So, where does it go wrong?

Issues with headless that causes speed problems

  • Large js (the application) that needs to be loaded before any content can be painted
  • Too many graphql fragments. A framework has to decide what graphql is too small that the number of graphql calls will increase. PWAStudio is a prime negative example.
  • Session locks in Magento graphqls
  • Use of POST graphqls which are not easily cacheble in varnish. Traditionally graphqls are served in POST to avoid hitting url size limits. URL are limited by the browser with 2048 considered a limit at the lower end. But, most Magento frontends generate URLs much smaller than the 2k limit and can easily use GET for queries and

These reasons and SEO requires a good implementation of SSR – Server Side Rendering

What is Server Side Rendering (SSR)

  • A headless implementation is written with a browser in mind – one that can load javascript and render the content. This is Client Side Rendering.
  • A Server Side Rendering will render the page on the server side – much like a regular Magento theme might do – and return HTML

SSR has 2 flavors

  • SSR that serves HTML without the javascript. This HTML will have no interactivity. Usable only for SEO purposes.
  • SSR that “hydrates” the HTML on the browser – by adding the events to the html and also perhaps bootstraps the application itself so it is interactive

React 18 and SSR

Headless technologies written with React have an opportunity to leapfrog the site performance by upgrading to React 18 and using the SSR features

  1. Suspense component. This allows specifying a part of the UI to be in loading state. Through this react knows the page is yet being loaded.
  2. renderToPipeableStream API. Allows HTML to be sent as a nodejs stream.
  3. hydrateRoot API. Allows the react application to be attached to the rendered HTML.

These 2 features basically allow the server side to keep rendering the application as the HTML is being returned, allowing for asynchronous rendering of components. The 3rd feature is useful when the destination is a browser – the rendered HTML is now made useful.

Current state of some popular Magento PWA technologies

  1. PWAStudio : Currently is on react 16 and does not include any SSR component.
  2. ScandiPWA : Version 6.2 and above are on react 18. Out of the box ScandiPWA does not support SSR, but it should not be very difficult to add the ssr route.
  3. VSF1 : Is based on vue and supports an inbuilt SSR
  4. VSF2 : Has an inbuilt SSR

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Using AWS Autoscale “warm pools” to reduce costs

AWS Autoscale added a new feature “Warm Pool”.  Let us explore this feature and see how luroConnect uses this to reduce hosting costs.

The autoscale latency problem

Usually, AWS Autoscale will launch a new server with the given AMI image based on the launch configuration or launch template configured. Launching a new server takes about 4 minutes or more. So let us say a scale-out event is configured for launching a server when the CPU across all autoscale instances exceeds 70% for 1 minute. Now, let us say a sale promotion on facebook causes a surge in traffic causes this event to trigger. It takes AWS 4+ minutes to respond and add a new server. If during this 4 minute period, the surge goes past 70% and say reaches 90-100%, it is likely that visitors will see a slowdown or even errors. The 4+ minute period is called the autoscale latency and in designing the scale-out and scale-in parameters, it plays a crucial role.

For a website that sees frequent surge in traffic in short spurts, one would be prompted to use a lower threshold for a scale-out event. A lower threshold will result in frequent triggering of scale-out events.

At the same time the scale-in threshold will also have to be reduced to ensure enough spread between scale-out and scale-in events. A lower spread will result in an unhealthy sequence of a scale-out event adding a resource for it to be immediately removed.

Autoscale designers then tend to add higher number of minimum instances, possibly of larger sizes. That reduces the effectiveness of autoscale – and increases AWS costs.

Lowering the autoscale latency results in a better autoscale system. As the latency reduces, the need for larger number of minimum instances or larger size instances reduces. This results in savings in the AWS bill.

Introducing the warm pool

AWS now introduces the concept of a warm pool. The costs saving of a warm pools come from AWS policy for not charging for instances in stopped state – except for the disks. A warm pool is a set of autoscale instances that are launched but kept in stopped state. When a scale-out event happens, the latency Is now reduced to the boot time of an instance and any initialization needed – we measured adding 3 instances took about 35 seconds to start serving traffic for Magento.

A scale-in policy simply stops the selected instance and add it back to the warm pool.

Warm Pool For Autoscale

How to use a warm pool?

If you are using launch template for your autoscale, creating a warm pool is easy and documented here. If using lifecycle events, newer events have been introudced.

If using a launch configuration, we suggest upgrading to a launch template before using a warm pool. While upgrading to a launch template is easy, it is advisable to read about launch templates as they are a different and a larger concept.

Changing your instance image when in a warm pool

AWS has support for “instance refresh” – a term used by AWS to indicate an update in AMI image for all running and warm pool instances in a single command. However, this update has a crucial flaw – it can keep your website inaccessible for a short time. This is due to AWS terminating an instance before adding one. If an image has to be updated – such as a new code deploy – a custom strategy has to be deployed to ensure the website does not go down.

luroConnect support for warm pool

luroConnect now supports warm pools across all its autoscale plans, with a scripted image update policy that ensures 0 downtime during image change as well as a code deploy strategy that ensures 0 downtime on code deploy.

Issues with AWS Reference architecture and tools for a Magento application

At luroConnect we implemented our autoscaling system after addressing flaws in many implementations we had seen.

As AWS autoscale by default is integrated into AWS load balancers – ELB or ALB. Using AWS reference implementation will put the code in a autoscale instance with nginx or apache with php and the code. Traffic can be routed through the ELB/ALB which will handle SSL and route the traffic to each autoscale instance.

When code has to be updated, a new AMI will be created and AWS instance refresh can be run to update the instances.

You could use AWS CodeDeploy as described here but you need to set it up to make sure Magento setup upgrade can be run when required.

Problems with autoscale implementations for Magento

  1. Issues configuring FPC (Full Page Cache) with this configuration : If varnish is configured on all autoscale instances (as we have seen many implementations do), each server will warm caches on its own. Clearing pages from cache will also be difficult. Using redis as a FPC increases per page latency for cached pages.
  2. Media and var folders are needed to be shared across all servers. NFS is typically used to share. However, the configuration of each autoscale instance has to be such that it can discover and mount the folders from the NFS server.
  3. When a code change has to be deployed, it is not clear how it can be done without causing a downtime of the website. Using AWS Code Deploy requires a complex setup to ensure setup upgrade is run before one of the 0 downtime strategies can be used.
  4. When a new server is launched, conditions to check the health of the website are not easy to write. This results in a few error responses before the server is ready to serve traffic.
  5. It is difficult to use a AWS ALB to route traffic for specific purposes – for example, routing traffic to a wordpress server for /blog urls.

luroConnect Autoscale on AWS : Smooth setup and running.

luroConnect Autoscale solves these problems.

luroConnect lets AWS monitor instances and decide when to add or remove (scale out or scale in) instances. luroConnect autoscale for AWS adds cloudwatch events and lifecycle management generated by AWS Autoscale to ensure a very smooth Autoscaling operation. luroConnect uses nginx as a load balancer and does not require a ALB/ELB to operate. luroConnect Autoscale supports AWS Autoscale with warm instances and has a mechanism to update the AMI when needed without any downtime.

  1. Using nginx as a load balancer allows high flexibility in deciding which urls go to varnish for full page cache and which should be directly served by php. varnish as a full page cache gives the maximum impact of full page caching.
  2. A nfs server holds shareable content of magento – specific media and var folders for example. Using NIS, autofs and NFS, each new app server is able to discover the NFS share.
  3. When a code change has to be deployed, php code using nfs is shared to each app server. A php reload and opcache configuration will ensure the new code is kept in the php opcache memory for all future operations. A php file from NFS share is loaded only once.
  4. Before a server is added to the nginx load balancer, extensive checks are done to ensure the new autoscale instance is ready to take traffic, including warming the opcache.
  5. nginx as a load balancer brings in a lot of flexibilty in routing traffic such as a /blog to a wordpress website, custom rewrites, etc.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Do you know what size server you want for your eCommerce site?

Leaving the toughest question unanswered

When signing up for your Magento hosting, the first question you see asked, before you place an order, is what size server you want. It has become so ubiquitous, that everyone just expects to answer it looking at the cost.

But this is much like Mathematics books leaving tough problems as exercise to the readers!

It should not be that way! The size and architecture of the server you need depends on many factors.

Factors to consider

  1. The traffic and pattern. We routinely ask for 2 google analytics graphs – one for a typical day and one for a high sale day. This drives the architecture and server size.
  2. Your hosting stack – are you vanilla magento? or do you use headless / PWA? or use some software for image optimisation on your server?
  3. If the live site is already hosted, current CPU and memory usage.
  4. The size of the magento database.

luroConnect always starts an engagement with a server sizing sheet that is filled on behalf of the merchant. This allows us to propose a hosting plan on the customers cloud account and an appopriate luroConnect support plan.

Take the guesswork out of server sizing with horizontal scaling

A classic 3-tier architecture.

  • The web layer (WAF, apache / nginx /varnish, cron, rabbitmq),
  • the application layer (php, nodejs) and
  • the database layer (mysql, elasticsearch, redis).

Horizontal Scaling :

  • app servers can scale independently – indeed they can be autoscaled.
  • Low traffic websites can fold either the app or the db layers or both into the web layer
  • The db layer can be extended to have master slave
  • A proxy layer can load balance read traffic between master and slave, giving scalability at the database level

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

luroConnect supports Hyva in its CI/CD pipeline

luroConnect CI/CD is an inbuilt feature of the luroConnect Managed Hosting Platform. Built from the ground up, it supports Magento and Mage-OS and dependent build options such as Magepack, baler and headless/PWA stacks such as ScanePWA, PWA Studio, vue-storefront.

luroConnect announces support for Hyva. To be configured as a build option, your Hyva website builds and deploys in ~0-downtime.

How does luroConnect CI/CD support Hyva?

luroConnect Ci/CD separates the build and deploy stages of your eCommerce store. The Hyva support is in the build. luroConnect builds in docker. Our Hyva docker build image contains the correct version of node and modules. The Hyva build, when enabled, takes 1 parameter

HYVA_THEMEDIR
the magento root relative themedir where the hyva build is done.
The pipeline will then do the following, before Magento static content deploy :
(cd $HYVA_THEMEDIR;
npm ci
npm run build-prod)

Kalkifashion.com uses Hyva on Magento Open Source 2.4.5. Kalkifashion.com is a premier independent Indian fashion store and has over 200 visitors on the site at any time 24×7. With such a busy website, the eCommerce manager should not be worried about code deploys giving a bad experience to visitors.

With luroConnect CI/CD offers that comfort.

Build and deploy on staging before deploying to production

luroConnect supports staging (also called pre production or UAT) and a production environment. The staging has same system component versions as production, but on a hardware that is not designed to scale. The production environment on the other hand is a multi-server 3-tier architecture possibly with autoscale.

The advantage is that code can be tested on staging before deploying to production – with confidence.

luroConnect CI/CD can deploy to staging or production.

The support for Hyva is included in both staging and production builds.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento, including a powerful written-for-Magento CI/CD

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Improving PDAStudio performance : Cache more

PWAStudio makes many “storeConfig” calls that – depending on the website – be made cacheable in varnish as they are unlikely to change. This will reduce cookie blocking – or reduce load on php if the authorization is used.

What is the session blocking problem?

When Magento (php) processes a request, the cookie passed is mapped to a session in Magento. Sessions are stored either in var/session or on production systems, in redis.

Magento will lock the session until the php code processes this request. At the end of the request the session is unlocked.

When the session is locked, any hit with the same cookie, is kept in wait state, waiting for the session lock to be released. If there are more than one hits, all hits wait. These are not kept in a ordered queue – instead they each check the state of the session every x seconds and the first one breaking in gets the session lock.

Session lock is important to process hits that update the session – login, cart operations, checkout operations can use sessions. But, the problem is that, not all hits need this lock, and Magento gives no way for a developer to hint that the hit being processed does not need a lock.

The problem with ajax calls – especially PWAStudio – is even more severe. To display a page, many calls for each component on the page are made. If all of these are to be processed by magento, they will all be queued and a single slow query can bring down the site performance.

A PWAStudio Example

As can be seen in the screen below, a page refresh of a PWAStudio website hosted on Magento Commerce Cloud, The arrows highlight the hits that are marked by Magento as non cacheable.

Analyzing the content returned by the getStoreConfig hit.
https://www.soch.com/graphql?query=query+GetStoreConfigForCarouselEE{storeConfig{store_code+product_url_suffix+magento_wishlist_general_is_enabled+enable_multiple_wishlists+__typename}}&operationName=GetStoreConfigForCarouselEE&variables={}

It is clear that these values are unlikely to be changed and can be cached by TTL alone – with a potential ability to clear varnish with a URL / regular expression to help clear the url if an occasion arises.

Improve caching

The hits marked in Blue on the right have been analyzed by luroConnect and we can suggest to cache in varnish on TTL of 1 day. Note : Varnish cache is already hashed with the store key. This is important as some of the data is store specific.

This requires a vcl change.

Yet recommending Magento Commerce Cloud for hosting?

Think again! Analysis like this is only available from luroConnect. Moreover, we will implement the vcl changes.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Meet Magento India 2023 – Speaker Talk – Improve PWA Performance

On Feb 3, 2023, our CEO Pradip Shah presented a talk titled “Improving Headless / PWA Performance” at Meet Magento India in Mumbai, India.

The premise of the talk was the observation that the Headless / PWA eCommerce world promised lightning fast websites but many have ended up with slow performance, especially as measured by Google’s metrics.

This talk discussed issues and solutions that have been implemented in real eCommerce websites to increase page speed.

There are 2 versions of this for you to download

  1. The pdf version (5MB)
  2. The powerpoint version (23MB) – it has a few videos, and hence recommended to download.

Summary

Section 1 : Legacy HTML page technology is not stagnant – with Hyva and on page optimization from technologies like Nitrogen, page speeed scores of Magento traditional HTML page has improved. However, many traditional websites suffer from slower response speeds with uncached pages. Example : www.kalkifashion.com is a Hyva theme with Nigrogen front end caching and optimizaion.

Section 2 : PWA is not magic – the promise of “lightning fast” website needs work. Basic page speed principles apply and so do some new ones.

Section 3 : It is possible to make websites using Magento REST and Graphql. Each one has different challenges. REST by default does not cache and Graphql uses sessions.

Section 4 : When using graphql, avoid POST graphql for queries – use them only for mutations.

Section 5 : Study your application and you can add caching to Graphql’s that Magento may mark as not caceheable.

Section 6 : Custom graphql queries result in database queries that may need optimization. A step by step method to get the underlying mysql query generated is a useful process. We used that to achieve great results. www.mysoresareeudyog.com has a custom default filter for a listing page – latest.

Section 7 : Magento 2.4.5 allows method to prevent session locking using authentication. But by default, authenticated graphql calls are not cached – an approch similar to one presented earlier will be required to ensure optimal caching is achieved.

Section 8 : Go beyond. Add logic in frontend and cache GraphQL results in the browser. This is the ultimate power of headless / PWA. It may not help with page scores that are measured without browser cache, but user experience will improve.

Section 9 : Bulid can improve page loads. Appropriate sized chunks and using hashes instead of version. Another improvement build can give is use of cookie free domains. A static domain for example for js and css bundles allows the main domain to not go through a caching layer, improving page load speed.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs

Improve page speed with Hyvä Themes

Modern Page Speed Metrics

Modern Page Speed Metrics as defined by Google are called “Core Web Vitals“.
This measure focusses on 3 aspects of user experience.

Largest Contentful Paint or LCP that measures loading performance.
Content Layout Shift or CLS that measures visual stability.
First Input Delay or FID that measures interactivity.

This obsoletes previous measures such as First Contentful Paint (FCP) or even Page load time reported by many measuring tools.

Core Web Vitals

Site speed has evolved and needs an evolution in the technology stack

The change in metrics means the technology stack has to evolve.
Many storefronts have adopted a more agile approach moving to a headless architecture.

Deploying headless adds complexity – for Magento stores, you now are dealing with two or more builds – Magento and headless. (Some headless stacks may need more builds). As a result, a headless stack is not for all stores.

There is nothing wrong with a monolithic stack – however, the Magento theme uses rather old technology that has aged.

The frontend technology world has accepted Adam Wathan‘s tailwind css as a great solution for both easing frontend development and improve page speed.

Much like jquery was the javascript library of choice for older UI, alpine.js is the library of choice for user interfaces developed using tailwaindcss.

What is Hyvä?

Hyvä Themes is a Magento theme based on tailwaindcss and alipe.js. Much like the Adam Wathan with tailwindcss, Willem Wigman the pioneer of Hyvä, believes in simplicity and componentization – making it ready for the future.

Hyvä Themes is not based on Magento’s default Luma. It is completely rewritten with modern a UI framework. The results are astonishing UI with a better page score.

Moreover, moving to Hyvä Themes is a re-theming project. Most of your existing functionality will work as is – until a module was written to be dependent on the older theme. A large website was moved by our partners Aureate Labs in under 3 months.

luroConnect partners with Hyvä

luroConnect will support Hyvä build as part of our standard Magento build process.
The luroConnect build is generally done in a dockerized container without access to the database. This ensures our build does not consume resources of the live site while running composer, setup:di:compile and static:content:deploy commands. It also makes our build easy to deploy and rollback.

luroConnect is a Managed Hosting Platform for Magento – giving a development, staging and live environment on your cloud account. With infrastructure-as-code principle used in its stack and a CI/CD inbuilt into the platform, luroConnect gives unprecedented confidence of the hosting environment on any cloud – and now use our kubernetes stack option.

Limited Time Offer for Hyvä customers

Signup with us between Jan 1, 2023 and March 31, 2023, with a go-live date before May 1, 2023 with Hyvä and get
first 3 months free of luroConnect fees (US $900 – US $3000 value depending on the plan chosen), if customer signs up for a 1 yr contract with luroConnect.

Signup with the consultation link below and see how kalkifashion.com with Hyvä is hosted on luroConnect.

Would you like to switch to a modern hosting platform?

Schedule a call of a free evaluation!

With features like ~0 downtime code deploy and autoscale to reduce your hosting costs, luroConnect offers you unparalleled hosting environment for Magento. Now with out-of-the-box support for Hyva.

Schedule a call and we will show you how we can

  • Improve your hosting, possibly with autoscale
  • Have a managed dev, staging and production environment
  • Server performance measured every minute with alerts for a slowdown
  • A multi point health check every day
  • Optimized hosting costs