Even a fast Magento store can have an average Page Speed Insights score. You should understand, though, these metrics are not 100% accurate. After all, Google doesn't see your site the same way as your customers do. It doesn't take into account the subtleties of the eCommerce user experience and the many Magento quirks we have to deal with every day.
Nevertheless, Google PageSpeed Insights tries its best to analyze the store and generate actionable recommendations for any web page. Our task as is to correctly understand what it tries to communicate and create effective solutions to fix everything wrong with the store.
To get the best score, you are guaranteed to invest quite a bit of your time into analyzing, fixing, and debugging every Google PageSpeed Insights opportunity, and our guide is here to help. Also, in this article, we'll explain the difference between actual and perceived performance, as well as reveal secrets that make your store look lightning-fast even if your Google Insight score is far from being high.
Table of Content
Why this Optimization Guide is Mobile-first?
Our Google PageSpeed Insights services audit will focus on the mobile-first experience. To explain our mindset, we want to hammer home 3 points:
- First, mobile purchases are on the rise.
- Second, Google mobile user experience higher than desktop.
- And third, because it's harder to optimize for slower mobile devices. But when you do that, your desktop score will also rise. We've covered this in detail in our extensive guide.
Take a look at the discrepancy between the desktop versus mobile score of this Magento store.
The gap is huge. This is what we are talking about. Your desktop score might be fine. Your mobile score is probably not, and few PageSpeed Insights services stress that enough. You can do many things to change that.
How Google PageSpeed Insights Ranks Sites
Only about 2% of all websites have a 100% PageScore score. This is the ideal score. Most of the time, 100 is an attainable but not entirely justifiable goal.
As with all things in life, there's an unspoken industry standard for store performance. The higher you go after that, the more costly it becomes. We often have to explain to our customers why they want to balance store performance, development costs, and customer satisfaction instead of going for the best score no matter what.
In order to avoid overpaying for further marginal improvements (the law of diminishing returns), we suggest you need to find the point where the performance score offers the best return on investment. The point where your store runs at optimal performance. With our experienced Magento developers, you'll overcome technical complexity and lack of optimization experience without overpaying for unnecessary improvements.
Field & Lab Data Metrics in Magento 2 PageSpeed Insights
Before diving into the PSI tips and tricks, let's refresh what metric the performance score comprises and what they mean. The PSI report has several parts:
- The Core Web Vitals assessment, which relies more on field data. It reflects real-world user experience: collects many data samples from multiple sessions, evaluates the monthly time period, and considers various mobile/desktop devices, network connections, and browser versions.
- The Performance score, which is mostly determined by lab data. There are measurements made by Lighthouse in a controlled environment: a single load on a predefined device and with particular network settings.
- Opportunities, diagnostics, and passed audits.
The Core Web Vitals Assessment
At the top of the Google PageSpeed Insights report, we see the Core Web Vitals (CWV) and a couple of other Web Vitals estimating the UX your website delivers to visitors. There are three CWVs:
- Largest Contentful Paint (LCP) measures loading performance. It's about how much time is needed for the biggest above-the-fold pic/text block to appear on the screen.
- First Input Delay (FID) measures the responsiveness of a web page. It's the time between the very first user interaction with a site (like a click, tap, swipe, or typing) and the start of processing the response.
- Cumulative Layout Shift (CLS) measures visual stability. It reports unexpected layout shifts when elements suddenly change their positions.
- Interaction to Next Paint (INP) measures the interactivity of a web page. It's a pending page interactivity metric which is due to replace FID in March 2024. It measures the input and presentation delay as well as the processing time for a scope of interactions taking place on the page during a user session.
Core Web Vitals are crucial in providing the best user experience for your Magento store and contribute much to the final Page Speed Score. Browse our detailed guide on to make these metrics optimized to perfection.
There are two more Web Vitals worth paying attention to because some CWV scores partly depend on them:
- First Contentful Paint (FCP) measures perceived page load speed. It's the time between the start of page loading and the very first element (text, image, etc.) appearing on the device's screen.
- Time to First Byte (TTFB), or server response time, measures the loading experience. It's the time between a call to a server and the first byte of response arriving to a client.
The Performance Score
Google Page Insights performance score contains some of the metrics discussed above (Largest Contentful Paint and Cumulative Layout Shift). Let's define the rest:
- First Contentful Paint (FCP) measures for how long a browser renders the first image or text after a user opened the page.
- Total Blocking Time (TBT) measures the overall amount of time when a page is blocked from responding to user interactions (clicks, taps, or keyboard presses) between FCP and TTI (Time to Interactive, which is the time for a page to become fully interactive)
- Speed Index measures the speed at which the page is actually filled with content as it loads.
The metrics results are not weighted equally. Currently, :
- Total Blocking Time - 30%
- Largest Contentful Paint - 25%
- Cumulative Layout Shift - 25%
- First Contentful Paint - 10%
- Speed Index - 10%
Why Opportunities Matter
Opportunities is a series of Google PageSpeed audits that help structure your website issues and fix them one by one. Each audit will improve one or more Lab Data metrics. Some audits are not really that important and get included as a recommendation. Others are true roadblocks, and eliminating them offers significant boosts to your page performance.
40 Hours of Magento Services. FOR FREE
Try our custom development, optimization, support, and design services. One week, free of charge, no strings attached.
22 Magento Performance Issues & How to Fix Them
No matter the importance and whether you use , we'll go through the entire list of 22 issues so you know how to deal with any of them.
1. Eliminate Render-Blocking Resources
Render-blocking resources refer to JS and CSS files. This one can be a real show-stopper for your First Contentful Paint and Largest Contentful Paint metrics.
Most of the time, your JS files are located at the very top of the document. This is not OK because this means the browser cannot proceed with page rendering before it can execute all this JS code first. But you can move all JS code to the bottom of the <body> with the help of the following module you can create on the Magento server:
public function aroundsendContent(\Zend\Http\PhpEnvironment\Response $response, callable $proceed)
{
ini_set('pcre.backtrack_limit',10000000);
$content = $response->getContent();
preg_match_all('#(<script.*?</script>)#is', $content, $matches);
$js = '';
foreach ($matches[0] as $value){
$js .= $value;
}
$content = preg_replace('#<script.*?</script>#is', '', $content);
$content = str_replace('</body>', $js . '</body>', $content);
$response->setContent($content);
return $proceed();
}di.xml
<?xml version="1.0"?>
<config xmlns:xsi="//www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
<type name="Zend\Http\PhpEnvironment\Response">
<plugin name="Onilab_DeferJs_Response" type="Onilab\DeferJs\Plugin\ResponsePlugin" />
</type>
</config>Pro tip: don’t include script tags in the <head> section. Nothing good will come of it.
You can do the same with CSS. Divide the CSS styles into two uneven parts. The smaller part will remain higher in the document. It will only contain stuff you can't move to the bottom of the page. This is the stuff that's crucial to web page design, what the user sees immediately upon entering your site.
The bigger part will go to the very bottom of the page. The lower CSS file will contain styles that don't affect user experience because these styles don't affect content on the first screen of the web page. This whole file shifting will unload most of the clutter from the critical render path and increase the page load speed.
Remote elements can also become render blockers. There are no ready-to-use solutions on how to deal with them, but we can outline your options. You can either move them to your server (if you can), delete them entirely (and probably get rid of a few fancy features they offered), or use preloads.
2. Serve Images in Next-Gen Formats
Unoptimized images become the biggest roadblock to a fast store. Instead of indiscriminately uploading media to your store, Google PageSpeed Insights services recommend you switch to new image formats.
Among its suggestions are WebP and AVIF, which are more recent and offer better image compression than JPEG. Alongside the switch to new standards, we can recommend tinifying PNG files.
But it's not enough. One of the best practices here is to use a Content Delivery Network with built-in image optimization features. Cloudflare is an obvious example with its Polish feature that can optimize and serve users the lightest version of the file without losing too much quality. AWS users can choose Amazon CloudFront, which works well for image optimization purposes.
In addition to using built-in CDN features, you can take an alternative route and integrate a module inside your server that can compress images for you. It's a bit redundant, in our opinion, since you'll still need a good CDN service for other optimizations, but if that's your call, go for it. We've covered in a detailed guide if you need more information.
3. Efficiently Encode Images
Much as with the next-gen image format audit, this one focuses on image delivery. PageSpeed Insights services suggest you automate your image optimization so that instead of manually making content managers, developers, and site owners compress media every time they need to upload a thing, users would just seamlessly apply compression from inside the platform.
As mentioned before, in the next-gen audit, good CDNs will have an image compression feature at the ready. Alternatively, you can use , , , , , or any other tools you like to integrate image compression inside your store.
Bear in mind that Google PageSpeed only checks JPEG and BMP images in this audit. Your score is unaffected by PNG. You'll have to account for large PNG files still slowing you down.
4. Minify JavaScript
There are a ton of JS files in Magento. In contrast to other websites, JS minification in Magento can have a significant impact on performance basically compressing files to 80-20% of their initial size.
Minify JS is fully available from the Magento Admin Panel. Go to Stores > Configuration > Advanced > Developer. After you set Minify Javascript Files to YES, flush the Magento cache. That's it. This optimization is so easy that 95% of Magento stores pass the audit by default. We are writing this tip for the other 5% who haven't got the memo.
5. Reduce Unused CSS Files
This one is tricky. Unused CSS files comprise a relatively small part of what could be wrong with your store speed. For example, a general CSS file will load everything it has when your browser requests a homepage.
This file might contain styles for Checkout or Catalog. It doesn't matter. Even if they are never used on the homepage, you'll have to download them. By the way, you may browse our guide on how to boost too.
Even though this guide lists solutions to every issue, it might be too labor-intensive to improve unused CSS files. You basically need to separate CSS styles by page type instead of clumping them all together. It's kind of hard to do, to be honest. We would need to review a few hundred individual rules in order to gain 160 ms time savings. Hence, the return on investment for this one is questionable. Clearly not a priority, that's for sure.
When enhancing Magento store's performance, pay attention to various parts of the shopping experience. For example, the speed of responding to the act of adding products to the cart may also impact user satisfaction. Is your ? If it creates any friction, check our guide for targeted strategies for optimizing this essential feature.
6. Properly Size Images
In order to pass this Google PageSpeed Insights audit, the difference between the image size in your browser and the actual size of the image must not exceed 25KB. The tool compares the actual size of the image and will penalize you if you upload a 2048x2048 monster to show a 256x256 pixel photo.
Most mainstream CDNs know how to handle image sizes really well, so if you use one, you are already a step ahead. Magento needs to resize the image to the right size before the browser downloads it. We will use the ImageFactory image adapter in order to enable this feature: \Magento\Framework\Image\AdapterFactory $imageFactory
$image = $imageFactory->create();
$image->open($pathToImg); //this is your actual server path to the image
$image->keepAspectRatio(true);
$image->resize($width,$height);
$image->save($dest);This code works well for random pictures. For product images, we will need a different approach. Find view.xml in the folder /etc/ located at app/design/<area>/<vendor>/<theme>/etc/view.xml.
If you can't find one, just create it. We need to add a new image size for the image we want to use. So, for example, if we need to use somewhere a 30x30 pixel photo, we create a new image and describe it as follows:
<image id="cart_cross_sell_products" type="thumbnail">
<width>30</width>
<height>30</height>
</image>imageID is a unique value needed for correct association with our new image. Magento requires type="thumbnail" to be able to use the image as a thumbnail for this type of product.
This is how we can use it on a page (code example):
\Magento\Catalog\Helper\Image $imageHelper //turn on imageHelper
$imageHelper->init($product, $imageId); //initialize imageHelperHere we give Magento product type and image ID. In order to get a link to the image, we need to write:
$imageHelper->getUrl(); // get a link to the image of the desired sizeMagento will resize the image and return a valid URL that you can give to the user. Images make up, on average, 70% of all data downloaded by a browser. So, if you properly size images, it boosts your PageSpeedInsights score dramatically. If you don't have enough expertise to resize or encode your store's visuals, are a way out here.
7. Ensure Text Remains Visible During Webfont Load
You can't make your store significantly faster with webfont load. Most often, time savings will be 10-20 ms per font load. Font-display is something you should do for perceived optimization, though. Users expect to see content within 1 second of loading time. Turning on the swap in CSS font-display settings can help speed up text rendering.
By default, your CSS either doesn't have any font-display config or uses something like a block which is slower. If there's nothing in the CSS config, this setting defaults back to auto (in fact, auto means block). Swap is a superior setting in terms of speed (read more about different font-display settings ).
OK, so for Magento, we want to change font-display from "auto" to "swap", the fastest possible option for text rendering. Find lib/web/css/source/lib/_typography.less and add font-display into the existing code, e.g.:
@font-face {
font-family: @family-name;
font-display: swap; //swap is speed!
src: url('@{font-path}.woff2') format('woff2'),
url('@{font-path}.woff') format('woff');
font-weight: @font-weight;
font-style: @font-style;
}Using swap, the browser will display the second font until the first font is loaded. For example, (Monaco, Monaco Regular). Monaco Regular will be displayed until Monaco gets loaded. Since you are now using zero blocks and an infinite swap period, you'll need to make sure that the two fonts look more or less the same.
8. Avoid an Excessive DOM Size
A brand-new Magento 2 store will have 481 DOM (document object model) elements which are way less than the recommended 1,400 DOM limit. The thing is, no one uses a default Magento store. Once you start customizing your store with better themes and more capable feature extensions, the number of DOM nodes will begin to climb into thousands of pieces.
The number of DOM elements doesn't really impact store performance, but they hit page rendering speed pretty hard. This is the realm of perceived performance vs. actual Magento load time. This issue is hard to fix. The only real fix to the problem is rebuilding the store to cut down on all this clutter. It's labor- and time-intensive. The more DOM elements you have, the better results you'll get in the end.
For example, a 1,500+ DOM-sized store took 950 ms to render and 500 ms to be parsed. According to our measurements, by lowering the DOM size to 827 elements, we manage to shave off 300 ms from the combined load (parsing+rendering). That's not a lot. And according to UX research, improvements of less than 500 ms are not even noticeable for average users.
Compared to the complexity of the task, it's easier to focus on more rewarding optimizations first before you tackle this beast of a problem.
9. Serve Static Assets With an Efficient Cache Policy
Cache expiration should be set to something big. If you set rarely changing files to expire frequently, the browser won't be able to take advantage of its local cache. This is another audit where a strong CDN will help you pass easily.
The setting may look different on different platforms. This is how Cloudflare handles it:
If you, for some reason, don't want to use a CDN to handle cache, make sure your Magento server is set to:
Cache-Control: max-age=3153600010. Minimize Main-Thread Work
Lots of factors here. Let's go over each one of them and how you can make each position faster.
Script Evaluation. This is the amount of time it takes to execute JS scripts. Consider reducing the number of files that execute at the very beginning of the document load. Push as many files as you can to the end of the HTML document. Use defer functionality to delay script execution that doesn't make any difference for the user. See if you can also make the code lighter through refactoring.
Style & Layout. The rendering process consists of multiple steps, and for each step, there are different things you can do to make it shorter and faster:
- Optimize and defer CSS files. Divide CSS into two files. Put the styles that don't get used on the first screen to the bottom of the page. This way, they won't block the initial render process, and your store will look faster.
- To speed up HTML parsing and DOM tree creation, reduce the amount of HTML code, the depth of the DOM tree elements, and the maximum child elements in each DOM element.
- To improve render tree construction, work with CSS attributes, and reduce the number of styles.
- To boost the performance of the layout process, make HTML files smaller. The same goes for painting.
Rendering. Webpage rendering is a non-trivial process. You can speed it up by reducing the number of CSS styles and HTML code amount.
Garbage Collection. All web browsers need to do housekeeping during regular work. This can take up a lot of time; it all depends on the store. One of the solutions is to reduce the amount of code your browser needs to execute. Our goal here is to shave off memory use. Anything goes, e.g., use fewer variables, or refactor the code.
Script Parsing & Compilation. Common sense rules apply here. Delete unused JavaScript files, don't load files that aren't necessary for a specific page, and minify JS.
Parse HTML & CSS files. The more CSS and HTML you have, the slower parsing works. Reduce CSS and HTML amount (which basically means you need to rewrite it).
11. Reduce JavaScript Execution Time
Find JS files that execute at the very beginning of the page but don't necessarily contribute to a better user experience. You can safely defer their execution for a few seconds (the more code you have, the larger defer time you need to account for). Use trial and error in estimating optimal delay time.
Another approach to reducing JS execution time is to just toughen up and rewrite questionable code that slows you down.
12. Avoid Chaining Critical Requests
Critical Render Chain demonstrates how your resources get loaded in the hierarchy regarding one another. Top-priority files create the critical request chain that will influence the length of loading procedures before the full document is rendered.
Nesting. The more resources you have to load within one another, the bigger latency you get. Defer as many JS scripts as you can. Reduce the size of every file wherever it's possible. Add preload. You can get a lot done by combining these methods with one another.
13. Keep Request Counts Low and Transfer Sizes Small
The number of requests. This data doesn't directly affect the final score but will improve other metrics if you follow the recommendations. For Magento, setting a detailed budget might not be the best idea. Let's just reiterate how you can reduce the number of requests and total file sizes.
| Resource Type | How to Reduce Requests | How to Reduce Transfer Size |
| Scripts | Merge JS | You should minify JS, delete unused scripts, defer all JS files that you can. |
| Images | Defer image load through lazy loading to alleviate the initial flood of requests to the server. | Don’t upload oversized images where smaller resolutions can do the trick. |
| Fonts | There is such a thing as too many fonts. Get rid of some if you have too many. | |
| Stylesheets | Merge CSS files. | Minify CSS, cut out unused styles. Your goal is to only load the code that will run on this page. |
| Documents | This section only counts barebones HTML. It’s already quite light. Not much else you can do about it. | |
| Third-party | Limit the number of third-party services. Defer third-party file load where possible. | Review your code and delete unused third-party files or pieces. |
14. Reduce the Impact of Third-party Code
The best defense is an offense. Google PageSpeed Insights will show you the slowest third-party files in your store. Defer or kill these scripts. And never let new files clutter your Magento store that bad ever again.
15. Defer Offscreen Images
Every store should use lazy loading, and Google unanimously announces the same approach. Lazy loading slows down the loading offscreen images because users can't see them when they enter the store. Everything they see is a few banners at the top and probably some text.
This is the type of content you need to load first. You can find media that need lazy loading by hand or using a custom JS script. It's common to just manually assign lazy loading to all media except the images on the first screen of the device.
Take into account that we are optimizing here for both mobile and desktop stores. Check how your store works in the most common mobile and desktop resolutions, and make sure that you include lazy loading while keeping in mind how the store functions on different devices.
While lazy loading usually refers to images, it's possible to use it to reprioritize the load order of JS scripts, CSS, and HTML files, too. Deferring offscreen images has the biggest impact on Time to Interactive (TTI).
16. Minify CSS
Similar to Minify JS, Minify CSS opportunity is great for Magento users to easily pass another Google Pagespeed audit.
To conduct CSS minification, find CSS Settings in Magento 2 Admin Panel at Stores > Settings > Configuration > Advanced > Developer.
17. Enable Text Compression
There are three main tools to make text smaller: Deflate, Gzip, and Brotli.
- Deflate is basically Gzip with some features missing (so we won't mention it too much). Let's focus on the other two, then.
- Gzip can archive text with a 71% compress ratio. While there are more efficient solutions on the market with up to 89% compression ratios, gzip is still a great tool to save data and speed up delivery.
- Brotli is another text compression alternative built into Cloudflare CDN. It offers a better compression ratio and – crucially – better compression and decompression speeds. Operational speed will help pack and unpack content faster. This is a big deal for mobile devices where browsers depend on weaker mobile CPUs to process archived data.
18. Preconnect to Required Origins
Add DNS-prefetch for all remote resources. We wouldn't expect a significant performance gain, but it's a nice little boost to speed up your third-party assets. Magento doesn't offer anything different here from any other platform. DNS-prefetch is easy to use and easy to implement; this is its greatest advantage.
You can also add preloading to fonts, the site's logo, critical CSS, and JS files to get even more out of prioritizing a specific load order. Read more about preloading in the dedicated audit below.
19. Avoid Multiple Page Redirects
Any new redirect will make your store a bit slower. Got a new design and now need to redirect all pages from one link to another? When you create custom redirects in Magento, use 301 moved permanently instead of 302 moved temporarily.
It's also a bad idea to change product or category URLs too much because Magento will create too many redirects inside the store. This clutter will slow down your store.
Good store management means maintaining a high housekeeping standard and eliminating links with redirects, most importantly on your critical rendering path. Google PageSpeed Insights will also penalize your score for “m.store.com”. The official guide wants you to use a responsive design instead of two versions of the store. So keep in mind that any page with two or more redirects will fail this audit.
20. Preload Key Requests
Besides the critical render path, there's also the critical request chain. Our goal is to make this chain as short as possible. And the main method of speeding it up is to remove a few links from it. This is where preloading comes into play.
Obviously, we do preloading inside the <body>, not the <head> of the document. The idea is to load different elements at different times, deprioritizing those elements that users don't interact with immediately after they see them.
For example, you can preload a number of things: fonts, styles, scripts, and images. Let's say there's a Login pop-up at your store. It's pretty huge. There is a login field, a Loyalty Program feature, and a large social media section.
You click the "Login" button, and the pop-up appears. Behind the scenes, the loading process prioritizes only one element of the entire pop-up: the "Sign Up" button. This is the UI element that most new users will click on as soon as they see it.
Everything else (login details, social media share buttons, integrated bells and whistles) can all wait. The "Sign Up" button can't. It needs to be available as soon as possible. And this is how preloading makes the entire window feel responsive and fast.
21. Use Video Formats for Animated Content
Some Magento stores like to use background videos on their pages. And all things considered, this is not a bad idea. Just make sure your video is actually a video and not an enormous gif.
In order to imitate gif behavior, your <video> content needs to loop continuously, have 0 volume, and play automatically without user input. Pretty simple to set up.
Videos have only one disadvantage: Chrome for Android offers a data-saving mode, and it won't allow the browser to load your video (but it will let the gif through). Take into account this limitation when you design for mobile user experience.
22. Avoid Enormous Network Payloads
Google PageSpeed Insights will write you a ticket if the overall size of your resources exceeds 1.6 MB. The number centers around a slow 3G mobile connection and 10 seconds max load time. If you think about it, that's a decent performance standard.
Ways to achieve in Magento:
- reduce the number of requests,
- defer file loading,
- configure compression and minification features,
- all the stuff we've already been talking about in the previous audits.
Perceived Performance vs. Actual Magento Load Time
Human brains are weird. Ten minutes in a checkout queue in a supermarket is long, and the same 10 minutes watching your favorite show is short. This is how our minds perceive time. It's our inherent ability to stretch 5 seconds of pain into eternity and 5 hours of fun into a single moment.
Working on performance optimization and decreasing Magento load time, we need this weirdness in our minds more than anything else. Our goal is to make the store look faster even when we can't actually push further on a technical level.
Three Thresholds of Store Performance
From a technical standpoint, 0.1 seconds or 100 ms is the holy grail of . This is the threshold that separates two distinct types of interaction with the application.
1. Between 0 and 0.1 seconds
If the store can render the page in 100 ms or less, sort the list of products within this timeframe, show a new page, add to the cart, or click a button in that timeframe, the user perceives it in a different way than a longer operation.
In their mind, this action happens instantaneously. Because of the speed of the action, the user is tricked into thinking they are the one doing the sorting, adding products to their shopping cart, or moving to a new page of the store. 100 ms or 1/10 of a second is the timeframe where users perceive actions as instantaneous.
The feedback from the computer is so fast that the user doesn't see the action as an order to a machine (which it actually is!) but as their own interaction.
2. Between 0.1s and 1s
This is not what happens when user actions take between 0.1s and 1s. This second threshold is where the user separates themselves from the computer. The lag between clicking the mouse and receiving the feedback is too long to ignore.
It's still a tolerable delay, and most users don't mind this interaction type at all. They view the delay as the PC/phone working at normal speed. Note that right now, Google advises websites to aim for 2-second max load times, which is well inside this interaction zone and became the industry standard for web applications. What is more, this is also important for .
3. 10 or more seconds
If it takes more than 10 seconds to do something, the interaction becomes unpleasant, and users get annoyed. They lose their patience, and you lose customers. This third threshold is not something we will discuss in this article because, in the eCommerce world, even a 3-second wait is too long.
What Is Perceived Performance and Why Is It Important?
As far as complex stores make the user load dozens of fonts, CSS and JS files, megabytes of media, and other content that further delays full-page rendering. In a situation where real gains are hard to achieve, the idea of perceived performance was born. Sometimes your store just can't go fast enough to feel instantaneous, but this is how you can fix it.
We trick the brain of the user to perceive something as quicker and more responsive than it really is. Even though it's a deception, it's also a win-win scenario: better user experience, less use of system resources, and more happy shoppers.
Four Main Magento Fixes to Boost Perceived Performance
Here we've collected four major Magento fixes that improve user experience without actually boosting real speed.
1. Use Lazy Loading to Make Media Appear Faster
Do you know how in video games, cards don't load objects that the player can't see? For example, there's no need to calculate and keep in memory any objects that don't fit inside the screen or are too far away to see all details. Web developers use this approach to visually boost loading speed for image-heavy pages such as Product Grids.
The installed script works differently with images that are located inside the visible area of the screen and outside of it. Lazy load functionality uses this selective approach to speed up image loading of closer media and substitute pictures that are further away with placeholders.
This way, the site feels faster and, at the same time, uses less bandwidth and system resources to load media instead of reworking the priority of image load. Users that have weak networks with lower speeds and older PCs that struggle with fast page rendering will notice a huge boost to their user experience. The same goes for mobile shoppers and users in rural areas with a spotty connection.
2. Prioritize Key Content on the Screen
On the screen, content can render in a number of ways. The normal, unoptimized approach of the browser is to “read” the document from top to bottom and process it in this order. What you can do to change this is to shift unimportant page elements to the bottom of the document to prioritize loading key content first.
Which content is that? It depends on what type of tasks your users want to accomplish on the page. On About Us, they need to see the text first. On a product grid, images and titles are more important. Understanding the needs of your customers is the key to optimizing the pages in the right way.
3. Clear up Your Customer's Path to Content
Large media has long been the biggest problem for web developers. But over time, we've managed to deal with heavy images using a number of clever solutions: by introducing Content Delivery Networks, priority loading mechanisms, more capable network connections, and specialized image formats.
But removing one bottleneck revealed a new one. The community found out that complex data processing and third-party extensions put a vast amount of pressure on processing power. Eventually, it came up with some efficient steps to improve perceived performance:
- define desired critical rendering path and make it as short as possible,
- create a proper loading state (setup placeholders) and a fallback for the pages,
- move unimportant JS/CSS code to the bottom,
- prioritize loading the text before you load the fonts for it.
4. Emphasize UI Feedback Where Delays Happen
Using button states is a smart way of masking delays and shortening waiting time in user interfaces. Consider this: there's a small delay every time you click a button and wait for the server to respond. Let's say the waiting time is 200 ms. This is the necessary interval the server uses to receive the command, process it, and send out the result. It also includes in-browser calculations and whatnot.
There's always an option to leave the user waiting. After all, the interaction is fairly short and doesn't interfere with the user's attention span. But as a caring store owner, you want users to feel as comfortable while shopping as you can.
So we implement the pseudo selector :active: button state to indicate button presses and convey that the user request is being processed. Instead of leaving the user empty-handed, we give them minimal feedback to look at while our server is doing the hard work of fetching and sending the right data their way.
This improvement might seem low-key, but the cumulative effect of a responsive interface is hard to overestimate. The upgrade is relatively easy to introduce and makes your customers a little bit happier.
These actions can boost your conversion rates considerably, and you can find more ideas in our .
Summing Up
At the end of the day, everything we design, we design for humans. And humans are prejudiced. They see the world using their senses and not scientifically proven data. So if something seems to work slowly, it is kind of slow. Our task is to make it appear fast. If using a sleight of hand results in shorter perceived latencies in key tasks, we have achieved our goal. Perceived performance leads to very real results: more conversions, better user engagement, and increased sales.
However, we don't have to forget about the actual Magento site loading speed, which is a no less important benchmark. Google PageSpeed concentrates on frontend optimization. Just keep in mind that a fast store has a lot more going under the hood than a slow frontend.
Look into slow Magento backend & , and work out . Investigate how you can improve your store speed without actually raising real-life numbers (perceived performance is a thing!). These are all areas where speed matters as much as anywhere else.
If you want an expert team to run a quick and practical audit of your store and eliminate code bottlenecks, get in touch with us, and we'll be happy to provide you with and our help.
