Online stores are increasingly evolving through the use of new technologies and the integration of innovative functionalities. However, this also leads to a growing trend of slow performance. When randomly testing 10 stores, I noticed that all of them take more than 3 seconds to load on mobile devices. What's particularly concerning is that for most, loading times approach ten seconds.
Why is loading a web store over 3 seconds problematic?
Various analyses have shown that anything above this time significantly reduces the number of visited pages and shortens the time visitors spend on the site. Consequently, this also affects conversion rates or the number of purchases.
Why do slow loading issues occur?
Merchants always want to add additional modules and services to their stores to improve sales, ranging from services for visitor traffic statistics to advertising optimization, as well as modules for displaying user reviews, benefits, etc. These additional services often add code to the page obtained from an external source, causing the page to always wait for a response from this external source when loading. This can cause delays or a large volume of additional code, prolonging the time it takes to display the page. The more code there is, the longer it will take to display the page.
While some modules that display basic benefits on the page do not consider the impact on page speed, the images they add may be large and unoptimized. For example, in one case, a benefit image was nearly 3 MB, which increased execution time by a whole second just because of that image. Most merchants don't care about controlling each individual image, which is almost impossible with a large amount of content. The problem also lies in the fact that most merchants, when adding functionalities, view the page on a fast connection or already cached page in the browser.
How can we ensure that additional functionalities do not negatively affect store performance?
For example, regarding images, the only smart solution is well-optimized functionality. For instance, automatic image resizing and conversion to a modern format, such as WebP, can be applied when displaying images. Images can also be loaded only when they are in the visible area. If we have benefits below the product description, this part of the page is often not immediately visible when the page is opened, so we could trigger loading only when the visitor scrolls down to where this part is visible.
This means that in the development of functionalities, we must always check how they affect the operation of the site, even if it's just a simple thing like displaying benefits.
Many might think it's better not to engage in functionality development but to buy a module that already has everything done and thousands of users with excellent ratings. However, this often presents an even bigger problem.
Pre-made functionalities usually come with lots of additional features to meet various needs and allow for flexibility. The problem with this is that many functionalities need to be developed to cover numerous needs, which can result in additional code volume, prolonging page load times. The issue lies not only in the backend code being executed but also in the styles and libraries being included. Sometimes, instead of a few lines of styles, thousands of lines of code are loaded. If we have a subscription to functionalities in a store, it can be difficult to change anything to improve performance. A developer might not change the entire module just for one client.
What if we buy a module that improves the speed of the online store?
If the store is poorly made from the start, such a module will certainly help, but the improvement is often temporary. The module can improve one part of the site but may worsen another. Improving the speed of the store may not be perfect. It may only alleviate the problem.
Ideal performance is only possible if we focus on each basic functionality and organize it separately to work as it should. If you want to save costs on your store, carefully check the performance with each change so you won't be disappointed later.
For the past month, I've dedicated most of my time to optimizing store speed, and I managed to achieve a perfect mobile score of 100/100 through Google Page Speed for both systems I work on: Magento 2 and OpenMage (Magento 1.9). For this purpose, I will soon release affordable store packages and some additional modules. Some will certainly be free and almost necessary for use by customers.
Speed tests are conducted via Google PageSpeed site: https://pagespeed.web.dev/
