Works fine locally but fires early on production

[tyssen]

I know this is probably a long-shot, but I have a site where imagesloaded works fine on the local development version, but on production, it fires while images are still being loaded.

Are there any server-specific environmental settings which would affect the way the script works?

[ErwanGuillon]

I just tried it and got the same result, it fires it before all images are loaded

[nessup]

I occasionally have this issue, regardless of whether on production or locally.

[heytricia]

I'm having the same issue - but only in Firefox for Mac. Could it be there is a timeout in place in case an image won't load? If so, can it be set for a longer period of time?

[0xadri]

1. Are you guys all sure to consistently test on the same browser version (& same OS) when testing locally & then on prod?

2. Have you isolated the core of the problematic code in a jsfiddle or jsbin to test if it works in isolation from the complexity of the rest of your web page?

I guess it already seems like too many people having the same issue for a coincidence... but hey, only "heytricia" mentioned her setup, which seems like a pretty basic requirement when asking for help.

[jayenashar]

Are any of you using rails with asset minification (or something else that rewrites js)?

[HenryGau]

+1
I'm having the same issue, the "always" event fires early before all images are loaded.
I'm using Chrome on Mac OS. I use this inside a AngularJS modal http://angular-ui.github.io/bootstrap/, not sure if it could be the cause...

[ghost]

I'm running this in a PhantomJS environment to render images. imagesLoaded fires early and the images do not yet have their width/height properties set.

Works fine on Chrome 40 on Mac OSX 10.9.5

[verde-io]

Having the same issue in Chrome (both on OSX and iOS). Trying to get the naturalWidth and naturalHeight properties on load and they are both 0 if I just use imagesLoaded().done(). I need to use an extra setTimeout to be able to get the dimensions correctly.

I've using the minified version from GitHub without any other modifications.

[dcorb]

Same here. Fires early in Chrome OsX

[ktruckenmiller]

I grabbed his 'no-cache' branch - this should fix the issue. I think it just has to do with the file size of the image, and loading them from cache.

[rs3d]

@ktruckenmiller I'm not really sure, but imo Chrome has to load all styles, calculate the layout with the current viewport to finally decide which image sizes should be shown. This could take some time, so this information is not instantly available. Moreover image sizes can also change over time when the viewport size is updated.

[desandro]

imagesLoaded v3.2.0 has been released, with the internal cache removed. Try out the new version and let me know if this issue persists.

[bennybobw]

I can still replicate this behavior with v3.2.0, see far down on this (heavy) page. Search for "imagesLoaded" in the page, I've added a little note there.

https://tplrebrand.clientrabbit.com/node/95996

[note: updated link]

I put a some logging statements in, you can see that the height of image is not set when imagesLoaded is firing.

This is on Chrome 47.0.2526.73 (64-bit), Linux, but I have someone else on Chrome that is running into the problem on Mac.

I can also replicate this on my local machine by turning on throttling in the devtools network tab.

[danyj]

@desandro I think I am on to to something here , same thing Chrome Version 48.0.2564.116, imagesloaded 3.2.0

inside my isotope 16 items , I have 1 vimeo ,1 youtube video and 1 soundcloud, if I remove those,
always, or donefires correctly , if I leave them in , it fires late ,

[j0hj0h]

I had this problem in Firefox and apparently it was caused by deactivating the browser cache via Firebugs network tab: the images are actually loaded from server, but imagesLoaded fires when they are loaded from cache – something like this.

[PandaWood]

I'm just browsing the issues before starting to use imagesloaded...

I hope it doesn't sound rude but doesn't this issue make the library pretty close to useless?

There's so many cases here and so many browsers, all with the same issue, that the library basically doesn't work.

My use case is to have a way of waiting until all images have loaded and only then, taking a snapshot image. So it's crucial it doesn't fire too early, while too late is fine.

[j0hj0h]

@PandaWood: In my tests I got the impression, that this issue is only caused by developer tools, that modify the caching behaviour. But no warranty ...

[PandaWood]

@j0hj0h right thanks. I can use it then since I can guarantee that Developer tools will never be open, as I'm using an embedded Chrome browser.

[pacu]

I'm having this issue on production 100% of the times and 10% of the times on development. ImagesLoaded fires a lot before the images are loaded. I can reproduce the issue by using the network profiling tools from chrome developer tools accurately.

I'm working with Chrome for mac, Version 54.0.2840.98 (64-bit), but I have seen it on safari too.

[j0hj0h]

@pacu, I'm working mostly in Chrome for mac as well and for me it seems like it is caused by the option Disable cache in the Network tab. Did you try without this option enabled?

[ionflow]

I had the same issue where production had the images in the grid stacked on top of each other when local looked as expected. Was able to solve it by moving the call to imagesLoaded from:

document.addEventListener('DOMContentLoaded', setupGrid);

to:

window.addEventListener('load', setupGrid);

[pa-w]

Still seeing this behavior but now on mobile browsers.

[petko]

Just to confirm that it happens with Chromium Embedded too..

[jordanboston]

I'm working mostly in Chrome for mac as well and for me it seems like it is caused by the option Disable cache in the Network tab. Did you try without this option enabled?

I'm seeing this without Dev tools open, and in Chrome, Firefox, Opera, and Safari. Basically if the cache is cleared, ie --first time visit to the page, then everything is jumbled and stacked on top etc...

Once a resize takes place, or on subsequent visits without the cache clear or dev tools open with said settings, it works just fine. Not sure what the deal is.

I am using this in Vue.js, but everything works, except it seems like ImagesLoaded is not firing correctly that first time. Anyone have any thoughts?

[zhangchi]

tried different environments, so far, desktop browsers and ios safari are ok. Only happens on android chrome. Debugged and found there is an issue in masonry when using imagesLoaded:
in function resizeMasonryItem(item)
here is what i get
item.querySelector('.masonry-content').getBoundingClientRect() with width:1 and height: 1
when switched to desktop chrome, the same image's width/height are correct.
my suspect is android recently enable image lazyLoading by default.

As to the solution, looks like very simple: when populating your image tag, make sure the width and height are included, so even through android is using place holder, it can still pass along the right width/height, so masonry can do the right math for the layout.

[andimg93]

it occurs rarely on my site and is therefore not easily reproducible, but in any case I have also noticed that the images loaded callback is fired too early. Based on the layout adjustments that are then not made at the right time, my layout is completely screwed up. I have solved this by an additional very low timeout, but that is really not a nice solution since that is exactly why I have the imagesLoaded functionality.