Update: please note that since I originally wrote this story in 2019, there are much better solutions for creating a Magento storefront than using the default Luma/Blank theme extensions. This article is for you if you still need to support the above instead of using a more performant solution such as the Hyvä or Breeze themes.

I’ve recently been asked to investigate if I could improve the score for a client as they were not entirely happy with a mobile score of 14 they got for their shiny, new M2 store’s homepage. While I was aware that Magento is extremely resource heavy, considering they advertise Magento 2 as a massive improvement in terms of performance compared to Magento 1, this didn’t seem very good indeed.

This article is not about the importance of your site’s page speed score. Obviously a higher page speed score doesn’t equal a higher conversion rate. It can however give you a very good insight about things you can improve on your site and I find it an an important resource to check from time to time.

First things first, I double checked that all the recommended settings were applied:

— enabled all the caches
— switched on js and css minification
— enabled flat categories and products
— use Varnish
— use http2 instead of 1

All seemed to be fine.

As usual, before I get started fixing any bugs, or adding improvements to a Magento site, I visit a few demo sites that simply load the Blank or Luma themes and do a little comparison between those sites and the site I’m about to work on. On a lot of occasions, bugs and decreased performance can be attributed to customisations done to the store via custom or third party modules or custom theme modifications so it’s good to get a good idea of what can be expected before you even write another line of code.

Using Google’s Pagespeed insights tool at https://developers.google.com/speed/pagespeed/insights/ I took a look at the following M2 sites and got similarly low scores as the store I was working on ( https://swisseme.com ):

http://demo-acm-2.bird.eu/ Score: 30
http://magento2demo.firebearstudio.com/index.php Score: 33 (however it’s mainly text only)

Then a few live M2 sites:
https://www.coxandcox.co.uk Score: 21
https://www.sigmabeauty.com/ Score: 19
https://www.drakes.com/ . Score: 16
https://www.mrp.com/en_uk/ Score : 13

Can also recommend Pingdom, GTMetrix and the Lighthouse Audit tool in Google Chrome’s developers tool tab to use to help identifying areas that pull down the score.

Here are a few things you can do to quickly improve these scores.

Optimise media

1. Videos
Most sites tend to use a large video on their homepage. In some cases, I’ve seen these at 12mb. Now for their mobile site, these blocks containing videos tend to be hidden, however that doesn’t mean that the video doesn’t play in the background. What can you do? Remove the autoplay tag then add a few lines of script that checks if based on the window width the video should be visible or not and target the video accordingly. Something like this should do the trick:

if(window.matchMedia(‘(min-width: 768px)’).matches){
$(‘.your-video video’)[0].play();
}

or in the case of Vimeo videos, I found it worked better to replace the src tag with data-src then adding this script:

if(window.matchMedia(‘(min-width: 768px)’).matches && $(desktopVideo).length){
$(desktopVideo).attr(‘src’, $(desktopVideo).attr(‘data-src’));
}

If the video doesn’t play, the video doesn’t load.

2. Reduce image size
Load the page and using the network tab of your browser’s developer tool, check image sizes. You can be sure to find some images that are just simply way too large. From experience this tend to be the case because content creators are in love with their work and tend to export the assets from the image editor of their choice at full size and at 100% optimised state. Exporting images at 90% instead of 100% using Photoshop can save hundreds of kb off the original size. (I’ve also seen some people exporting images at 300dpi rather than using the exporting for the Web options which is 72…)

The other issue can also be that the images are much larger than they need to be. For example an image that only needs to show below 768px at a max-width of 400px doesn’t need to be exported at 900px width, does it?

For Swisseme.com, I used https://compressor.io/ to reduce the size of the images from the homepage and can highly recommend for others to use as it’s free and does a perfect job. Just as an example a 725kb image was thus reduced to 98kb.

3. Mobile and desktop images
Magento 2 comes with PageBuilder as its cms editor which is a massive improvement over M1’s standard wysiwyg editor tool. Its simple and intuitive drag and drop interface makes creating content a breeze.

What could be tweaked is its image component element that allows you to inject an image block to the page where you can specify different images per block for desktop and mobile views. They are then automatically shown/hidden depending if you are below or above Pagebuilder’s default 768px breakpoint.

This is quite handy however it also means that two image tags are injected in the page per block, and while a desktop image is automatically hidden via a Pagebuilder “pagebuilder-mobile-hidden” css class, that still means that the desktop image is downloaded in mobile view.

So, what can we do? We can use tag instead of image tags like so:

If you do this, you can both reduce the http requests on the page and reduce the page size also. Win-win.

Pay attention, that if you don’t specify a mobile image, Pagebuilder will assume that you want to use the desktop image in mobile also. So, in case you have a block that you only want to show in desktop, I simply specify a spacer image that’s about 1kb to be used as a mobile image, then hide the mobile block. Bit of a hack but works. Same thing is true the other way around, if I want to have a block that’s only visible in mobile, and hidden in desktop.

Main takeaway is that using the pagebuilder-mobile-hidden/pagebuilder-mobile-only classes simply hides sections, but they will still be downloaded unless you follow the steps above.

4. Image sprites
What’s better? Downloading 60 icons or downloading one? If you don’t use a font icon but rather individual custom icons (which you can still upload to icomoon for example to create your own stack) across the site, that means one http request per icon. Move all those into an svg sprite (which you can also export as a png for fallback), and use background position to make them appear instead.

5. Lazy loading
If you see the “Defer offscren images” notice in page speed insights, add a lazyloading snippet to only load images which are visible in the viewport.
Why would you want to download images below the fold if the user might not even scroll to them? This is especially helpful on content heavy pages or category pages with a lot of product images.

Otherwise, just simply google for a lazyload js snippet or you can even write it yourself to do the same thing. The idea is quite simple, rename the src=”” tag to a data-src=”” and add a class for the js to target, so it can replace the src tag with the value of what’s in the data-src.

You can use this to expand what I wrote about picture tags above. Lazyloading is definitely more fiddly and needs more testing than the relatively safe picture tag — just think of sliders/rollover menus which need to be synched with lazyloading unlike picture tags.

However you could use a syntax like this in the Pagebuilder master.html:
data-src=”desktop-image:desktopimage.png; mobile-image: mobile-image.png”. These can be also conditional so will save you from having to upload spacer.gif images for a block that’s only visible in a one breakpoint but not the other.

Split the task into two, first, overwrite the master.html template of the Magento Pagebuilder’s image component to cover content sections and two, then copy Magento’s default image template to either your theme or a full fledged module so you can turn it off and on via settings also/per store for example.

(vendor/module-catalog/view/frontend/templates/product/image.phtml)

6. Favicon and logo
Again, using the network tab I’ve noticed that these were much larger than needed to be so simple re-saved them at the correct dimensions

7. Fonts
If you only use web safe fonts, move to the next section otherwise read on.

To quote Andy Davis at https://andydavies.me/blog/2019/02/12/preloading-fonts-and-the-puzzle-of-priorities/ :
“As most browsers delay rendering text until the relevant font is available, loading fonts sooner has become one of commonly suggested use cases for preload.

By default fonts are loaded late as the browser only discovers them when it’s building the render tree i.e. after the styles have been downloaded and any blocking scripts in the head have been downloaded and executed too.

Ideally we want the fonts downloaded much sooner, most likely after the render blocking elements in the head — this is the point where the browser starts adding the body contents to the DOM and where the fonts will be needed.”

For Swisseme.com, there were a few custom fonts being used, however the page score only complained about the Pagebuilder icon font. Could have been because it lives in a different folder in the theme or because it didn’t have woff2 format specified, not sure. However adding this to the head, fixed that issues also:

You also might want to quick scan if the fonts are even used. Many times especially when quick fixes are added to sites, or multiple teams/agencies/developers work on the codebase over time, previously added and redundant code is not removed, just expanded, that contributes to unnecessary bloat. Nuke what’s not needed, if any problems, don’t panic, Git is your best friend. :)

Critical css

Critical css is another option added by Magento in its latest versions (2.3 and up). If css keeps showing up in the PSI report as render blocking, enable this and a critical.css file your theme’s web/css/source/ folder.
When this setting is enabled, css is moved the from the document head to the closing body tag instead. The critical.css file should ideally just contain based styles which apply to the header/top part of the page which will be visible on page load until the deferred css is loaded as well.
Or you could just apply .page-wrapper {display: none; } or better yet, grab the output of .lib-visually-hidden() and apply to the the page-wrapper, then apply .lib-visually-hidden-reset() on the .page-wrapper in your less files which will be included in the deferred css, overwriting the critical.css style once the deferred css is loaded.

Scripts

Magento 2 comes with a whopping 500-600kb of javascript by default. On top of that if you have third-party or custom modules, this will only increase in size. You can use the built in merge javascript tool but this wouldn’t help much because of require.js. Ie scripts loaded by require js will not be merged at all so don’t really see the point of this to be honest.

These files are also loaded in the head and marked as render blocking pulling your page speed score down.

Solution for this is to move all the js files close to the closing body tag instead of loading it in the head.

Magento has now added a Defer Js option you can enabled in your config.php (option is only available in the admin in developer mode). If you have earlier versions, here are free plugins to do this for you. Here is an example (I would probably add some system.xml values also so it can be turned on/off in the admin):

https://github.com/goivvy/DJS/

Speak to a back end dev however to evaluate the plugin for you however.

Js Bundling

Javascript bundling is an option to create “bundles“ or packages of Javascript to reduce the amount of http lookups needed. In some of my tests, https requests for http files went from 300/page to only 30, and half of those 30 were third party scripts (hotjar, gtm, onetrust etc) so you might even have less depending on how much of those you have.

Rather than using Magento’s built in js bundling option which will just quadruple the size of js needed to be downloaded, try to use Magesuite’s Magepack bundling tool instead:

https://github.com/magesuite/magepack

I do have to mention that node and magepack needs to be installed on your server as the commands need to be run after the static-content:deploy has run so speak to your dev ops guys to make sure this won’t be a problem.

Magepack will need two commands, one for generating the config file for which you need to specify 3urls for it to crawl for js files on the page (cms/product/category), and once the config file is generated, you just run “magepack bundle” which will create a the bundles per theme/locale in your pub/static folder.

Third party scripts

Third party scripts loaded from other domains can also cause issues. They mean another dns lookup, another http request and can take a bit longer to download than other scripts on your site.

So, what can be done? First, evaluate whether you even need them. For example, I’ve noticed that for Swisseme.com, an addthis.com script has been added to every page, however only used on the product pages. After a code change so that the script would only be loaded on product pages, the page score went up by 12 points on the home and category pages.

If it’s a script you can’t remove, try adding a defer tag on the script or follow these useful tips:
https://web.dev/efficiently-load-third-party-javascript

Result

When I started working on the Swisseme.com site, the homepage’s mobile page speed score was around 18, by the time I’ve made all the changes above it went up to around 52.

Using Chrome’s Audit tool that uses Lighthouse, the score was even better, up from 24 to 70 on the homepage, and on category pages the score went to 77.

So keep this in mind when thinking about how much content you are planning to show on the homepage as content clearly influences page score.

On Pingdom and Gmetrix, the page went from Grade B to A, 80 => 89 (though they both measure desktop views), and the http request went from 68 to 37.

In terms of page size, the homepage’s page size went from 6.5 to 1.8mb in mobile view.

Obviously these can be further tweaked to get a higher score, ie get a better server, use a cdn delivery network for images, tweak the cache settings in your htaccess file, or switch on the Magento Profiler to see if there are any major problems, however the steps above are a very good start.

Hope you’ll find this guide helpful, and I’d be happy to hear about other solutions you’ve used to increase your site’s score.

Developer ramblings

How to speed up Adobe PWA for logged in customers

Improving your Magento 2 store’s page speed score