New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Product Page Product Images Slow to Load #14667

Open
chattertech opened this Issue Apr 12, 2018 · 72 comments

Comments

@chattertech

chattertech commented Apr 12, 2018

Preconditions

  1. Running on a very fast Magento centric server (MageMojo)
  2. Magento 2.2.3, PHP 7.026, MYSQL 5.6.35-80.0

Steps to reproduce

  1. Clean setup of Magento 2.2.3 via composer
  2. Imported products and created new products
  3. Used both Magento Luma and Ultimo Themes
  4. Images are 500x500 or similar jpegs and properly compressed
  5. Same behaviour in all modes
  6. Same behaviour with Magento cache and Varnish cache

Expected result

  1. Product image should open very quickly with page (same exact page and images open instantly on same server on Magento V1.9.3)

Actual result

  1. All pages are opening very fast however,
  2. Product image/images take 2-4s to load with spinning loader icon before image shows

magento-2-slow-image-load-screenshot

@AirmanAJK

This comment has been minimized.

AirmanAJK commented Apr 12, 2018

I've noticed this as well. I suspect it's because of Magento 2's heavy use of requireJS. All of the many "x-magento-init" and "data-mage-init" parts need to be executed, and the gallery.js code doesn't seem to be very quick anyway.

It would be nice if the primary image was shown instead of a spinner, since that could simply be an tag on the page.

@subbu-d

This comment has been minimized.

subbu-d commented Apr 18, 2018

Yes, I have noticed the same issue as it took more time to load the product's primary image.

@utklasad

This comment has been minimized.

utklasad commented Apr 25, 2018

Same issue here even if the source file of the picture is just 400kb. I've not noticed this before so it might be an issue with the latest version of Magento 2.2?

I will try to debug the code to find out where the bottleneck is.

@Ylmzef

This comment has been minimized.

Ylmzef commented May 18, 2018

Same here!

@utklasad

This comment has been minimized.

utklasad commented May 18, 2018

The issue is definitely related to Chrome.

@seanspcm

This comment has been minimized.

seanspcm commented May 23, 2018

did anyone find a solution to the product images loading slow on the product pages?

@dankoz51

This comment has been minimized.

dankoz51 commented Jun 11, 2018

I have been looking for a solution to this, let me know if anyone comes up with something otherwise its will be a few weeks before i get back to it

@harrigo

This comment has been minimized.

harrigo commented Jun 28, 2018

Has anyone noticed with this that if you flush the browser cache the problem goes away?

For me at least, flushing my cache in chrome leads to images loading in less than a second (rather than 4+ seconds) and am unsure how to get the problem to come back. It will however come back as it has the past few times.

@dankoz51

This comment has been minimized.

dankoz51 commented Jul 6, 2018

Ok so this issue is simply how the loader is designed, I have outlined why this is in the blog post. https://xumulus.com/kill-the-loader-how-to-improve-your-magento-2-product-page-load-time/

There is also a solution provided in a GitHub project

@uk28881785

This comment has been minimized.

uk28881785 commented Jul 6, 2018

Which Magento mode are you using? This could also have an effect....

@harrigo

This comment has been minimized.

harrigo commented Jul 6, 2018

Thanks Dankoz, I am halfway deciding to use Magic Zoom as after testing it seems a far bit better however that blog post looks interesting and may reconsider.

It's happening for me in production mostly with bundling and merging on however is not great in either mode. The problem seems to occur after a while of not flusing client cache tho and in dev i disable that most the time on browser so wouldn't notice it. When this goes slow on one occasion ive seen it take a few mins and eating all the ram until i flushed the cache. Think i have only seen this on chrome so far however.

@chattertech

This comment has been minimized.

chattertech commented Jul 6, 2018

Thanks Dankoz!

I read your blog and it is an excellent explanation of this behaviour. Surprised that this issue has not been addressed by Magento themselves yet. ( I haven't tried V2.2.5 yet )

I will try the fast page load module you suggest.

@Johan-Trp

This comment has been minimized.

Johan-Trp commented Jul 12, 2018

I can confirm this is also happening for us, M EE 2.2.4. Upon loading a product detail page, we see the fotorama spinning icon and for some people, it takes extremely long before the image is shown. According to the Chrome Network tab, banner/ajax/load/?sections hangs, I've seen myself for as much as 13 seconds, before the image displays. The header on the image says it's eventually fetched from browser cache with status 200. So that shouldn't be delayed at all.

As harrigo mentioned, as soon as you flush the browser cache, then reload the product detail page, you barely see the spinner, the image is there near instantly.

Dankoz51's solution may well make the first product image display faster, by removing the spinner, but I'm concerned this may not actually fix this degrading performance of the AJAX call. We might just not notice it as much anymore, but should still strive to find out why the performance of that AJAX call is negatively impacted by a filled up browser cache.

@snoroozi

This comment has been minimized.

snoroozi commented Jul 13, 2018

@chattertech I updated to 2.2.5 and I don't see any improvement in the image loading as advertised. This shouldn't still be a lingering issue since 2016. Pretty fucking ridiculous to be honest.

@chattertech

This comment has been minimized.

chattertech commented Jul 13, 2018

I tried Dankoz51's solution at https://github.com/xumulus/magento2-fast-product-images. It does indeed make the initial image load much faster. However the rest of the page is then delayed and stalls by the same amount that the image was spinning before.

Like Johan-Trp said there is a major issue delaying product page renders. There is no delay in category or CMS pages btw.

Also this is not just a Chrome issue as i see a delay in Safari and Firefox as well. They are a bit faster but still very noticeable.

@dankoz51

This comment has been minimized.

dankoz51 commented Jul 13, 2018

@snoroozi

This comment has been minimized.

snoroozi commented Jul 22, 2018

Any new updates to this issue. I tried @dankos51 solution but didn't seem to do anything in my case.

@dankoz51

This comment has been minimized.

dankoz51 commented Jul 23, 2018

@harrigo

This comment has been minimized.

harrigo commented Jul 23, 2018

Dankoz's module is an improvement it atleast looks like the page loads fast so thanks a lot for that. I will also keep using it even if fotorama does speed up as would rather see the image than a loading spinning wheel. With mine however scrolling and java script becomes jumpy while fotorama is still loading. Don't think it will be possible to hide this unless we actually fix it.

@dankoz51 the Redis locking idea sounds interesting but why would this be affected by a client cache flush? Is this the 'disable_locking' => '1' part of the redis config for sessions in env.php? I will test this but need the problem to resurface on a computer for me first and i wont flush the cache this time.

@snoroozi

This comment has been minimized.

snoroozi commented Jul 23, 2018

@dankoz51 Thanks, that was the issue. Appreciate the extension.

@engcom-backlog-nazar

This comment has been minimized.

Contributor

engcom-backlog-nazar commented Jul 30, 2018

Hi @chattertech I'm tested but, the image load fastly, see attachments,
frame- 43d

@harrigo

This comment has been minimized.

harrigo commented Jul 30, 2018

@engcom-backlog-nazar It doesn't always load slow and this is why this is going to be very difficult to debug. Once it does start loading slow it will load incredibly slow on that client PC until cache is flushed.

@siliconalchemy

This comment has been minimized.

siliconalchemy commented Aug 6, 2018

@engcom-backlog-nazar It's heavily dependent on browser CPU speed - on slower/older computers/devices it's very, very bad - up to 45 seconds on an older desktop in my case. Try using Chrome Developer tools to throttle your CPU (Developer Tools -> Performance -> CPU -> Throttle -> 6x or slowest setting).

@siliconalchemy

This comment has been minimized.

siliconalchemy commented Aug 6, 2018

This is the same issue that celebrated it's second birthday yesterday which was stupidly closed by @guz-anton and has thus languished ever since:
#6018
This is a terrible, terrible bug in Magento frontend, I'm sure a lot of people would really appreciate it if you took it seriously and looked into it. Thank you!

@DrewML

This comment has been minimized.

Member

DrewML commented Aug 24, 2018

Hey all. Your friendly neighborhood Magento JS dev here 👋. I'd love to get this issue addressed.

I did some performance profiling on a demo store to add some concrete data to this discussion.

Trace Details

  • Out of the box Luma installation in 2.2
  • HTTP2-enabled server
  • Product photos on a CDN
  • Warmed client-side cache from previous visit to PD page (no round-trip for photos during trace)
  • Emulated CPU slowdown of 4x to better simulate commodity hardware (because my Macbook Pro isn't representative of commodity hardware)

Full render without product photos - just over 1s
image

Product Photos rendered - around 6.4s
image.

Why the slowness
@dankoz51 is correct that this has to do with JavaScript execution and how the mage-init loader works in Magento 2. There are a few problems that add up to the problem we're seeing:

  1. data-mage-init and text/x-magento-init are not processed until the document is completely ready. There are places where the DOM needed for these operations is already ready, so we have an artificial slowdown

  2. mage-init scripts have no concept of priority or load order. After they're scraped from the DOM, a require call is made in a loop to fetch each dependency. The order of execution ends up becoming a race: whichever AMD module finishes loading the quickest, evaluates first. Because of the single-threaded nature of JS, some lower-priority mage-init scripts will end up hogging the thread and pushing out the time for Fotorama to begin its evaluation.

  3. The gallery.js and Fotorama evaluation happen to be the most expensive JS on the product page out of the box. In this trace, it takes half a second for all of it to evaluate
    image
    image

Possible Solutions

  1. Add a concept of priorities to the mage-init loader so a developer can add hints as to which widgets should get CPU time first (typically above the fold content). This is a decent chunk of work that would require design and planning to get right.

  2. Switch gallery.js and Fotorama from the declarative mage-init initialization to imperative initialization from a JS module, so there is better control over when execution happens during page load

  3. Server render the <img /> tag for the primary product photo, and upgrade the DOM to use Fotorama during page boot on the client-side.

I'm leaning towards a combination of 2 and 3 to address this issue, and then looking into 1 as a better long-term solution. Would love to hear input from those of you dealing with this issue in production, and then we'll decide on a plan of attack.

@pemann

This comment has been minimized.

pemann commented Aug 29, 2018

My 2 cents:

Browser: Chrome
Magento: 2.2.x

If I have a lot of data in localstorage then there is a browser freeze between initial page load and loading of gallery and recently viewed data. Chrome call tree timings show that most of the time is spent adding and updating items in localstorage. JS heap is constantly full and needs GC. CPU usage shows 100%.

If I clear the localstorage, then loading of gallery and recently viewed is fast.

chrome-call-tree-m2-product-page

chrome-call-tree-m2-product-page-2

@pemann

This comment has been minimized.

pemann commented Sep 8, 2018

Actually that storage problem I described is related to recently viewed products. If I have a lots of them, browser will freeze because of intensive storage writing and reading.

@pemann

This comment has been minimized.

pemann commented Sep 12, 2018

Might be related to #17813

@Johan-Trp

This comment has been minimized.

Johan-Trp commented Sep 12, 2018

Hey all. Your friendly neighborhood Magento JS dev here 👋. I'd love to get this issue addressed.

Thanks for the comprehensive front-end dev perspective analysis. As above pemann found out, this problem gets worse when the client side cache starts building up. To get this into the complete picture, can you please analyse this part as well? Why is it that the already poor performance degrades when the browser cache fills up? The answer might affect your otherwise sound proposals.

For me, the PDP main image is so important for all sorts of reasons and KPI's, I'd rather not leave it to client-side 'chance' how/when it's rendered. Getting the first one to sent from the server makes total sense. Any further images can then indeed be loaded through client-side logic. Solution 3 for me on the short term, pretty please kind people at Adobe/Magento/in this community.

@DrewML

This comment has been minimized.

Member

DrewML commented Sep 12, 2018

Thanks for the input @Johan-Trp. The local storage stuff is kind of related to this (it makes the problem worse). Any slow code that runs in the main thread before gallery.js initialization is going to push out the time to rendering of the first photo. re: #17813, I'd love to keep the discussion confined there, but I will confirm I've seen this be a serious bottleneck on some popular sites I've profiled. We're hammering localStorage in a loop, which isn't helping.

@DrewML

This comment has been minimized.

Member

DrewML commented Sep 12, 2018

For all 17 of you following along in this thread at the moment, an initial PR has been opened by @Igloczek, which implements suggestion 3 from my previous write-up.

If any of y'all are interested in seeing this PR land and can lend a hand with some PHP, we'll be able to keep this moving. See #17996 (comment)

@MartinAarts

This comment has been minimized.

MartinAarts commented Sep 20, 2018

The slow loading of images is fixable by installing the magic zoom extensions, although the images are still clickable after about ten seconds. Also products option remain unresponsive for about the same time.

For some reason the JS takes a very long time on a bit slower pc's.

@snoroozi

This comment has been minimized.

snoroozi commented Sep 20, 2018

@yamarco

This comment has been minimized.

yamarco commented Sep 23, 2018

I've heard so much about magento being a top notch solution for e-commerce. But frankly the more I use it the more I realize how 1980 this solution is. This kind of critical frontend bug that has a major impact on Conversion is the kind of thing that any reasonable business would jump to within seconds. Yet here we all are staring at a loader hoping one day we will see the product we would like to buy. This is beyond ridiculous.

@chattertech

This comment has been minimized.

chattertech commented Sep 25, 2018

I know there is a fix in the works for initial image speed and that is great but will there ever be a fix for the js problems in M2. This probably ties into why the Magento 2 checkout is so slow compared to other solutions as well.

So it looks like the following pages are nice and speedy..

Home page and other CMS pages
Category pages
Search pages
Account Pages

These are slow

Product pages
Checkout
and cart (somewhat)

There are some plugins that help somewhat but product and checkout are the most important part of an ecommerce site.

Hopefully a solution is on its way.

@MartinAarts

This comment has been minimized.

MartinAarts commented Sep 25, 2018

The fix in #17813 fixes this problem. Loading time of productpages goes from 30 seconds, down to loaded within a second.

@AirmanAJK

This comment has been minimized.

AirmanAJK commented Sep 25, 2018

Per https://devdocs.magento.com/guides/v2.2/javascript-dev-guide/javascript/product-frontend-storage.html:

The frontend product repository uses the product_data_storage section of the data storage cache as its data source. This section is responsible for holding all product data that come from the server when a customer visits a product page.

Pretty ironic that this mechanism was added to improve performance.

@tomekjordan

This comment has been minimized.

tomekjordan commented Sep 29, 2018

Total disaster. New versions released. 2.2.6 and still no improvement. I wonder if @magento team ever checked inspector and see how "fast" the images are loaded on product pages..... maybe they think we will start using PWA...

@snoroozi

This comment has been minimized.

snoroozi commented Sep 30, 2018

@oviliz

This comment has been minimized.

oviliz commented Oct 13, 2018

@tomekjordan they say the fix would only be included in 2.3.0, #17813 (comment)

@AirmanAJK I wonder if the Enterprise version is affected...

@DrewML

This comment has been minimized.

Member

DrewML commented Oct 16, 2018

Keeping the ball rolling on this: magento/architecture#33

@DrewML

This comment has been minimized.

Member

DrewML commented Oct 16, 2018

I wonder if @magento team ever checked inspector and see how "fast" the images are loaded on product pages

@tomekjordan I'm from the Magento team, and I posted actual traces from DevTools here 🙂. Definitely aware it's a problem, and we're working on it.

they say the fix would only be included in 2.3.0, #17813 (comment)

@oviliz this is a separate issue. That issue could slow down all things requiring JS execution on the page, but this issue (slow product photos) still requires separate work.

I know there is a fix in the works for initial image speed and that is great but will there ever be a fix for the js problems in M2. This probably ties into why the Magento 2 checkout is so slow compared to other solutions as well.

@chattertech stay tuned 🤐

@siliconalchemy

This comment has been minimized.

siliconalchemy commented Oct 18, 2018

@DrewML Thanks a lot for picking this problem up and doing such a good analysis. Hopefully there will be a bit of reflection within Magento to learn from why such a huge issue was ignored for so long, and how such impacting issues can be better prioritised in the future.

@snoroozi

This comment has been minimized.

snoroozi commented Oct 18, 2018

@wontroba666

This comment has been minimized.

wontroba666 commented Oct 20, 2018

This is a critical bug. Please do not make us wait until 2.3

@Rickertje

This comment has been minimized.

Rickertje commented Oct 29, 2018

Same here. Dev team please give us an update.

@DrewML

This comment has been minimized.

Member

DrewML commented Nov 1, 2018

The 2.3.0 release branch is already closed off and going through regression, so this will not be addressed in 2.3.0 unfortunately, but is tentatively planned for 2.3.1 (cannot give a 100% guarantee, but that's the current plan). The issue will be addressed when we swap out Fotorama.

For the time being, several folks in this thread have mentioned https://github.com/xumulus/magento2-fast-product-images as a temporary solution to the problem. I personally can't comment on the efficacy of it, though.

@snoroozi

This comment has been minimized.

snoroozi commented Nov 1, 2018

@CristiLodor

This comment has been minimized.

CristiLodor commented Nov 1, 2018

Because non of the solutions worked for me I installed https://www.magictoolbox.com/magiczoomplus/ (hope will not be interpreted as ad).
Now the product page image appears in about 1-2 seconds which is very much improvement.
Really can't understand why this was not fixed by now and isn't included in a strict plan.

Any way, thx for hard work @magento-team

@siliconalchemy

This comment has been minimized.

siliconalchemy commented Nov 1, 2018

@DrewML Honestly, Magento/Adobe is doing your flagship product a long-lasting harm in not addressing this in a major release. Any sane development/management team should see this as a critical UX bug. The fact it is not being addressed in the first major release in over a year is embarrassing.

@harrigo

This comment has been minimized.

harrigo commented Nov 1, 2018

Although i'm not a massive fan of fotorama the problem is not fotorama for a lot of people here i believe. I completely ripped it out and still had massive problems with my pages when product data storage overloaded. See the issue and fix here: #17813 modify the 2 files as suggested and drop them in a theme. Your product pages will drop to 1-2 seconds and everything will be fine and it wasn't any Fotorama code modied. Do that with the Xumulus Fast Gallery Load and you will have instant product pics i've done it a few times and it works a charm.

@sskharate

This comment has been minimized.

sskharate commented Nov 30, 2018

Thanks @dankoz51 your solution have worked for me on 2.2.5 and image loading is much faster.
I had to merge your logic in theme overridden gallery.phtml.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment