Magento2: Fotorama product picture script is extremely slow on mobile devices

[andidhouse]

1. Magento 2.1 via download / nginx / php7 / redis / varnish / mariadb

   Steps to reproduce

2. Go to a product page with a smartphone (even if no product picture is uploaded and the default backup picture is there)

3. look at the load time of the product page

   Expected result

4. The product site loads very quick on smartphones and tablets too

   Actual result

5. The fotorama script is extremely slow on smartphones and causes the whole product site to load several seconds without showing a picture.
   You will realize that that all parts of the product page load extreme fast but not the fotorama picture script.
   Also if there is no picture uploaded and the default backup picture is loaded (with just a view kbs) the script needs seconds to render the default backup picture with just a view kbs.

I think this is not exactable on mobile devices at all. There are other ways to load the product pictures first before calling a complex script which blocks the load of the first picture and just shows a spinner for several seconds.

[andidhouse]

We also checked this on multi servers and installations - it is not the server power or anything else.
It is the fotorama script or the implementation of it.

You can for example check out this magento2 site and you will see that the product sites need several seconds to load the pictures on mobile devices:

https://www.ninewest.co.uk

[LucScu]

@piotrekkaminski How could you move huge bugs (it's incredible that you release a so slower carousel builder for mobile) to "Feature Requests and Improvements"?
How could a user waits 5 seconds before see product's image? And in the meantime see the ugliest loader ever?

[choukalos]

Reopening; changing to bug. Internal ticket - MAGETWO-58628

Hi @andidhouse & @LucScu ; sorry our script that runs under Piotr's name auto-moved this. Looks like it was incorrectly tagged with the label improvement.

I did notice that JS on the site hasn't been bundled & minified. That should help performance some.

[piotrekkaminski]

@LucScu we have automated process that moves every ticket markes as improvement or feature request to forums. I agree this should be fixed so we have reopened it. Thanks!

[LucScu]

@choukalos On my env all js and css are bundled & minified, but product's pages are very bad user experience due to slowness of fotorama js.
Are you agree?
Do you have a fix to correct it or we have to install a 3rd part extension?

[andidhouse]

@choukalos The bundling and minify is another topic here. As far as i know this does not work correctly and is reported several times here.

As @LucScu states here - also if we bundle and minify js and css this has no huge effect. The loading time of the script is simply inacceptable for a mobile or tablet user.

[ignaciomella]

I cannot stand this. Product images loads too slow.

There's a temporary solution posted in StackExchange

http://magento.stackexchange.com/questions/134834/how-can-we-load-product-image-gallery-instantly-without-the-delay-in-magento

From what I read there, this problem lies with Magento's implemenation of the fotorama script.

[guz-anton]

@andidhouse ,
You pointed that Fotorama (and so Magento's Gallery.js build on top of Fotorama) works slow. It is wrong opinion. Gallery itself work fast enough (as any other image gallery widget could).

Why not a Fotorama?

I've made some changes to PDP to leave just Gallery with dependencies and compare page speed:

| Instance | Total requests | Total data | Time of page processing | Time of page processing on low connection |
| --- | --- | --- | --- | --- |
| Default | 179 | 882Kb | 2sek | 46sek |
| Gallery only | 15 | 218Kb | 0.12sek | 1sek |

Instance with cut PDP could be set up from my test branch.

Who is if not a Fotorama?

Main admonitions are

• Visual appearance of images is too late (like User feeling of "fast")
• Magento JS app on storefront has too long intializization (it's too huge)

First point could be solved. Example by Aaron Allen from previous comment. Yes, adding the image on stage could do such trick.

Second point is a subject of set of improvements. I don't think that we should track them under this Github issue. So I'm going to close an issue like _Won't fix_.

Please leave notes here if you have additional insights.

[andidhouse]

@guz-anton can you pls point out a live magento2 website where we can test and confirm this. As far as i know the script is the problem and really slow on mobile - a killer.

I am happy if you prove me wrong here but pls point out a m2 site where we can test this.

Not shure about your point here:
Default 179 882Kb 2sek 46sek
Gallery only 15 218Kb 0.12sek 1sek

To be honest i do not believe that a default call of a site with pictures should last 46 seconds on a low internet connection. Pls also have a look at the quality. 218kb is not 882kb so the question is really how photorama is compressing the images. Do you have any infos here?

Many thanks!

[andidhouse]

@guz-anton can you pls read my post carefully:

--> IT IS ABOUT smartphones and tablets

The normal website view is ok. But try to use a smartphone to view the pictures. It loads not in 1-2 seconds but takes 3-6 seconds on a very fast server and internet connection.

[guz-anton]

@andidhouse
I understand that original issue reported for mobile devices. I have no comments that mobile performance is worse than desktop (but in nowadays it could be an opposite). Sorry, that screenshots show picture only for the desktop.

I have concerns about _Fotorama_ word in the issue description. We cannot fix just _Fotorama_ 's performance. Whole picture with JavaScript app on storefront should be improved. We will continue work in this direction.

[andidhouse]

@guz-anton many thanks for your reply.
It is possible that your send me some links of M2 live sites where you think the performance ist ok. My team will then check this.

For example we did a test using magic zoom extension instead of fotorama - speed was more then 5 times faster on mobile devices with magic zoom.

[guz-anton]

Thanks for point about comparison _magic zoom_ vs _fotorama_ . I'll check. As about instance - ping me on [email protected] .

[LucScu]

@andidhouse How do you implement magic zoom? Do you install a 3rd part extension or manually?

[ghost]

@LucScu whatever works for your budget.

[LucScu]

@jupiter01 do you have a magic zoom deployed on a demo site?

[ghost]

No, a quick google will bring up the magic zoom website, they have live demos there.

[andidhouse]

You can download the M2 demo of magic zoom on the website - install it in 2 minutes and test it.
Can you pls share your results on mobile here?

[LucScu]

@jupiter01 ok
@andidhouse for now i'll continue with default fotorama, but when i'll test magic zoom i'll give here a feedback

[andidhouse]

@choukalos really don´t know why this is closed without a solution... it is also reported in the forum:

http://magento.stackexchange.com/questions/134834/how-can-we-load-product-image-gallery-instantly-without-the-delay-in-magento

[LucScu]

@andidhouse try to use magic zoom, it is easy to install (2 minutes and free demo) and it works like a charm!

[andidhouse]

@LucScu many thanks. yes we tried this and it works great.
But we try to use as less extensions for normal functions as possible due to update problems and conflicts. I think it is a very poor implementation of the magento gallery script at the moment causing so much trouble.... i am not shure they fix it the next time so we maybe give magic zoom a try... :-/

[andidhouse]

we give it up on the native photorama implementation due to:

• problem with mobile devices and scrolling issue
• extreme long load times of the script compared to for example magic zoom
• some other small bugs and in general poor implementation of the script at this moment

Magic zoom works like a charm and has a great support fixing bugs in minute not years.

[andidhouse]

just tested in 2.1.3 against magic zoom.

Problem is present - on other magento2 live sites as well.
Problem with implementation of fotorama in m2 at this stage:

The first product picture is shown AFTER all pictures are downloaded meaning if you have 2-5 pictures on one product this takes about 3-10 seconds on mobile devices and about 1-2 seconds more on desktop.

This behaviour is very bad for user experience as well as for google. I am not shure why this problem is not taken into account here!

[Crossmotion]

I have the same isseu on version 2.1.3. desktop version load under 1 sec. mobile version shows a loading icon for about 11 seconds before showing image ( there is only one image in this product)

Update: I first tested it on a 2 year old HTC M8. But it seems to work better on newer phones (tested on Iphone 7 and Nexus 6P). So it looks like its mostly an performance issue on older phones. but also on new phones you can see a delay.

[andidhouse]

@Crossmotion exactly - it is a poor implementation of the fotorama script performance wise. On newer and faster systems you can hardly see a delay. if you turn to some older devices there is a big delay in loading the page. If you use for example magic zoom extension there is no delay at all so this is clearly a bad implementation of the fotorama script.

[twistedatrocity]

@andidhouse I"m having the same problem. There is a noticeable delay using a desktop, like a good 2-3 seconds if images are in the cache, longer if not, and this is on a beastly modern gaming laptop. However on a mobile, Galaxy S4 with chrome, the delay is a solid 10 seconds at times, more if images not cached. The phone is dated but isn't THAT old. The phone still works well on other ecommerce sites, like amazon for example.

The performance is also poor once the images are loaded. Tapping and zooming on mobile is noticeable twitchy/lagginess. The close button when zooming is also right over the cart icon (in luma theme), when tapping close, the tap bleeds through the element and also activates the cart link.

This is way too long of delays for E commerce, customers will go elsewhere. All we have are images to sell a product. Product descriptions mean nothing without a picture.

Did you ever find a solution? I hate to buy yet another extension to address core functionality.

[andidhouse]

@twistedatrocity no solution at all - magento team just does "part fixing" like the picture scroll bug. I suggest two ways:

• install magic zoom plus which works lightning fast and solid
• get rid of magento2 and change to another system ;-)

You can not trust magento to at this stage to implement bugfixes as fast as needed and also as solid as needed.

[andidhouse]

@piotrekkaminski are you really shure it is a good idea to close such a major not solved mug here at all? No words on this...

[ignaciomella]

I'm back on magento1 ... Current Magneto 2 commitment falls short of many of us who expected great things. To date.. I don't see the point of upgrading to M2... lots of problems (like this thread) and not any major benefits. Sad.

[GuiltyNL]

@guz-anton You say:

'I have concerns about Fotorama word in the issue description. We cannot fix just Fotorama 's performance. Whole picture with JavaScript app on storefront should be improved. We will continue work in this direction.'

I doubt this is because of the performance of Fotorama. When I look at the waterfall of a product page of our staging server, I can see the following:

1. Total requests: 187
2. Cross sell and up sell product images loaded in request 9 to 13
3. Fotorama.js loaded in request 166
4. Actual image of the product loaded in request 184

This has nothing to do with the performance of Fotorama itself. As I can see dozens of examples of fast fotorama implementations. This has something to do with incorrect implementation of the fotorama software in Magento 2 and nothing else.

It worries me that several people complain about it, that the issue is very easy to reproduce and that Magento developers just seem to ignore this issue. While it is a very big performance issue.

Also on fast desktops the delay is noticable and a very annoying thing in user experience. It is horrible on mobile phones.

Look at this example, this is a very fast Magento 2 demoserver with PHP7, Redis and Varnish:

https://varnish.m2.magehost.pro/stellar-solar-jacket

You must agree this performance is just a bit sad, annoying and incomprehensible, even on a desktop!

I really don't care if this should be considered as a bug, missing feature, misimplementation, optimization or whatever. The fact is that Magento 2 store owners are having severe performance issues with displaying product images for crying out loud and Magento just doesn't fix this issue.

What is wrong with this picture? (Well this is a nice word joke...)

[andidhouse]

@andimov pls have a look on this again... i really do not know why magento is ignoring a major bug like this since month!

[GuiltyNL]

I really think that the main issue is that the Fotorama and the Gallery parts are loaded way too late!

I mean, loading the actual product photo as request 184 while there are 187 requests in total? It is almost the latest request to be loaded. On a product page a product photo should be loaded in the top 10 of requests.

It even comes after the 'Document Complete', Webpagetest.org tells met 'Document Complete' after request 101.

You can see my example here:

http://www.webpagetest.org/result/170320_AW_aa44cf01d093e195a188d8d5d263cae8/

[GuiltyNL]

It is disappointing that there is no response or solution whatsoever. 22 days ago I tried to comment on this topic and I'm just being ignored.

The question is: why does Magento does not take this issue seriously? I think it is a severe issue that must have been solved a year ago. Instead this is being ignored .

Tim

[ngz82]

+1 for fixing this. It is a terrible user experience on mobile.

[ghost]

I can't believe this is still an issue.

[ngz82]

I've just noticed this same delay of the product images, seems to impact the loading of configurable product "options" in the drop down menu on the product page. The configurable options only show up once the images load so that could be linked.
This effectively means a customer cannot add these products to their shopping cart until it all loads, and in some cases this is many seconds - a very poor experience.

[johnny-longneck]

I had the same problem and found out it was Paypal Express that blocked the loading of the images and other things on the page.
In the backend there is a setting for the PayPal Express Button. Don't set it to "dynamic" -> Use "static".
Otherwise it makes a request to paypal and this is causing the problem.

At least it solved the problem for me.

[GuiltyNL]

Hmm I tried this immediately, but no effect for my site unfortunately.

I timed it and it is as slow as ever. I also don't use that Paypal plugin at all, but still changed it do static, without any effect :(

My site has about 200 requests on one page. And the actual product image is still somewhere down the row, request 174.

[yumicom]

I"m having the same problem

[qrider]

We are experiencing very similar issues on our site for the products that have youtube videos. I am using a Macbook air and seeing extremely long load times.

[tomekjordan]

Hi. tested M211 and this is still the main problem from UX perspective. Maybe automated tests shows it load fast, but what users sees is different. From my perspective M1 merchant. This is top prio issue to fix. I cannot move to M2 until this slow image + ugly loader will not be improved.

The common problem is that even 3rd party themes comes with THIS "feature" :)
If user want to see product page or open cart page - it takes too much time to load, even on fast server. Because images and ajaxed blocks defer loading is breaking UX for customers, I expect conversion on M2 site will be lower than on M1.
Since this is ecommerce - conversion & UX for user is TOP1 factor for any business

Hope somebody will find solution and fix the core with it :)

[GuiltyNL]

Why is this issue marked as closed? It is a bit weird that such an issue is being ignored, isn't it?

[yumicom]

I closed this issue - was forced to buy a third-party program to speed up the opening of fotorama product pictures. Thank you, Magento team ((

[GuiltyNL]

Which one did you buy @yumicom ?

[yumicom]

I bought Magic Zoom (not Plus).

[GuiltyNL]

Ok, that one was on my list too. Thanks!

[royandre]

We are also writing our own image magnifier as the one bundled in Magento (even Magento Commerce) is simply useless due to this.

Need to cast a -1 to the Magento dev team on this one.

Also worth mentioning that fotorama has been deprecated (https://github.com/artpolikarpov/fotorama/issues/532)

[harrigo]

I'm having similar issues with this script just seems so slow however not just on mobiles. It can take 3 or 4 seconds to load on desktops especially chrome. This feels really slow as the rest of the page is up and running in 0.2 seconds. Am debating ripping it out for Magic Zoom if magic zoom works with all the swatches etc.

This however does seem intermittent on desktops as a cache flush seems to being the speed down however have seen computers taking minutes on some occasions to load images until I flushed cache. Not sure if this is a separate issue however.

[siliconalchemy]

Incredible that this is still a problem, and this issue remains closed. This is a major issue on all browsers including desktops. In my case the page loads <1-2sec, then it takes anything up to 3-10sec (depending on the speed of the device/browser) to display the main picture - just a spinner in the meantime. Terrible, terrible UX.

[tomekjordan]

100% agree. terrible UX

[ngz82]

Terrible UX indeed. We went ahead and installed magic zoom, problem solved.

[DrewML]

Related: https://github.com/magento/magento2/issues/14667

[DrewML]

For those still following this thread, we're discussing alternatives to address the performance issue https://github.com/magento/architecture/pull/33

[LiamKarlMitchell]

Still slow.