Loading GIF (Preloader) gets stuck only on Chrome
Asked Answered
A

6

9

I have a gallery in my website. The gallery contains 15 images, each one of them is approximately 500KB (total size is 7.5MB).

Because the gallery takes a while to load (25 seconds on my computer, tough it depends on the connection), I want the visitor to know the gallery is loading, hence the Ajax loading GIF.

I want the visitor to see the loading GIF as soon as he enters the gallery page, until the the gallery images have been downloaded and are ready to be viewed.


In order to achieve my goal, this is what I've done:

This is the beginning of the body of the gallery HTML page:

<body>
    <img src="images/ajax-loader.gif" alt="" class="hiddenPic" /> 
    <!-- loading Ajax loading GIF before all the other images -->

And this is the gallery CSS part:

#gallery {
  background: url(images/ajax-loader.gif);
  background-repeat:no-repeat;
  background-attachment: fixed;
  background-position: center; 

So basically, the loading GIF should be downloaded as soon as a visitor enters the gallery page, because it is the first object inside the <body> that is going to be downloaded. However, it's not visible due to the hiddenPic class.

This method should help making the loading GIF ready and visible as the gallery background as soon as possible, until all the gallery images have been downloaded and the gallery is ready.


However, the loading GIF doesn't work properly on Google Chrome; it works perfect fine on Firefox & IE (spinning flawlessly) - but gets stuck (doesn't spin properly) on Chrome, from the moment it appears until the gallery is ready.

Update: I know I can implement a better gallery (like the ones suggested in the comments) which would require less resources from the user when entering the gallery page - but I don't understand how this can be the cause for the problem when the GIF loader works perfectly on Firefox & IE.

Why doesn't the Ajax loading GIF work properly on Chrome?

Apollo answered 16/8, 2012 at 7:44 Comment(8)
Loading your website it seems to work as expected, even in Chrome (v21.0.1180.77 m). Certainly when I load the page I am presented with the GIF spinner, which later gets replaced by the gallery. I would say it's fairly slow, ie. I don't see the spinner "spin" I just see it in 3 or 4 various positions, but that's presumably down to loading the rest of the gallery and my PC being a tad slow. However, I'm loading the gallery in about 5-6 seconds not the 25 seconds you suggest so that may be affecting results.Scow
Also, while I think you should absolutely have a GIF spinner, I wonder if you should be loading the entire gallery straight away, for two reasons: 1) it's slows the whole page and 2) it wastes bandwidth as people may not view all the pictures. I would explore a process of either 1) loading each image when it's selected (so gif spinner for each image) or 2) load say the first 3. Then when they hit 'Next Image' (to show image 2) load image 4. They won't see any difference but makes it much faster and efficient.Scow
So the reason the spinner is stuck is because loading the gallery images takes most of the resources? I want to make the loader spin - the GIF is not that heavy so I don't see why it gets stuck and I can't make it spin properly, even (well, only) when the images are being downloaded to the computer. About your suggestion, it sounds like a great way to shorten the waiting time and make it work fast. I'm not sure which way is better, but if I will use no'1 I have to add thumbnails to my gallery.Apollo
But, still - it works perfect on IE - the loader spins flawlessly until the gallery is ready - but not on Chrome. There must be a reason why it behaves different on different browsers.Apollo
Yes unfortunately I cannot provide any solution to the Chrome issue, especially as it seems to work correctly (if a slightly "jerky" motion) in my version/configuration of Chrome. Possibly you could try loading with only one or two gallery images and seeing if that helps display things properly, in which case it almost certainly is the other images hogging resources. Sadly I don't know enough about browser technicalities to be able to suggest why it may load correctly in some and not in others.Scow
I would recommend implementing the Galleria slider. It handles images using progressive loading, downloading only a few images at a time. It may or may not be exactly what you want. Either way, weird issue with the GIF loading so slow… your HTML/JS looks straight-forward enough, and Google didn't turn up anything for 'chrome gif freezes during page load'.Rooker
Here is a new link. And this is the hiddenPic class: .hiddenPic { display: none; } which makes it invisible.Apollo
@ChrisNicholson Might be worth mentioning that although I didn't change the gallery functionality, I managed to fix the loading time by optimizing (compressing) the gallery JPGs using JPGmini. It's an amazing tool; it reduced the size of my 15 photos from 8MB to 2MB with no visible quality loss, which is quite impressive.Apollo
D
5

You just need to delete this declaration on line 602:

background-attachment: fixed;
Dimerous answered 21/8, 2012 at 22:55 Comment(3)
I changed it (it's live on the website right now) - but the GIF loader still gets stuck as soon as it appears, until the gallery is loaded.Apollo
Finally, a real solution! It's working flawlessly now :) I couldn't find any info though on why this declaration messes the way the GIF is showing up and spinning on Google Chrome. Also, should I keep the new hiddenPic attribute? is there any difference?Apollo
And does it matter in my case? I declared <img src="images/ajax-loader.gif" alt="" class="hiddenPic" /> in order to make the browser load it ASAP when entering the gallery page, but I'm not sure it makes a difference anyway, because the browser loads the style.css file before the html body, therefore applying the #gallery { background: url(images/ajax-loader.gif); } very quickly.Apollo
L
3

I also had the same problem. The way I fixed it was to put the loading gif in it's own element (to keep markup clean, use a pseudo element).

Now, instead of using the background-attachment rule, you can use position: fixed. Here's the code you should use (assuming you'd like that loader gif to sit right in the middle of the screen):

#gallery:after {
    content: "";
    background: url(images/ajax-loader.gif);
    position: fixed;
    top: 50%;
    left: 50%;
    width: 50px; /*change to the width of your image*/
    height: 50px; /*change to the height of your image*/
    margin-left: -25px; /*Make this 1/2 the width of your image */
    margin-top: -25px; /*Make this 1/2 the height of your image */
}

Hope this helps!

Litha answered 20/6, 2013 at 18:35 Comment(0)
K
1

I'm a strong advocate of using dataURI with base64-encoded images in this and similar situations. What it does is effectively eliminates the need for a separate http request to retrieve the spinner gif, meaning the "loading" animation is immediately available to be rendered. This makes the value of the UX improvement so more valuable than a couple extra kilobytes in overhead - especially since the stylesheet would be only downloaded once and then cached by the client.

This fiddle has the animation embedded from ajaxload.info, having added literally less than 1KB to the final CSS.

Note that this kind of resource embedding is not supported at all on IE7 (but IE7 users have much bigger concerns to address :)

Kinshasa answered 20/8, 2012 at 5:33 Comment(4)
When should I use data URI base64 encoded images in general? Where does it particularly excel?Apollo
@amiregelz: imo whenever the overhead of encoding is cheaper than separate connections and extreme responsiveness is demanded - "loading" gfx is a classic example where you don't want the user to wait for it to load :) I also consider resources for embedding based on how often it is used across the site, would spriting it be more difficult (icons applied as partial backgrounds are particularly tough) and would it be preferrable to css declarations (gradients/patterns take more space to declare, plus there is nominal computational overhead compared to when pre-rendered graphics is used)Kinshasa
My GIF loader data URI code, when encoded with base64, is painfully long. Is it still worth using it? I can see there is a delay since it takes time to decode the base64 code, but it's quite slow because of the length of the code.Apollo
@amiregelz: by that logic, we should all use raw bitmaps :) your jsfiddle renders instantly for me (not the best hardware either). There is a decent resource covering main points, if you need more info you should really ask a new question.Kinshasa
G
0

You may try this using jQuery BlockUI Plugin (v2)

Hope this helps.

Greengrocery answered 19/8, 2012 at 7:24 Comment(0)
C
0

Personally for loaders i've always done it this way , I do not remember where i read it .. But its always worked for me ..

$(function(){

$('#overlay')
    .hide()  
    .ajaxStart(function() {
        $(this).css("display","inline");
        })
    .ajaxStop(function() {
        $(this).hide();
        });
});

What it does , is it takes the div with an id of overlay and on any AJAX request that goes out , makes it visible and once the ajax request is complete , it hides it out.

Let me know if u need more code.

Cheers.

Chemnitz answered 20/8, 2012 at 14:45 Comment(0)
H
-1

In the CSS for #gallery

    background-position: center;

Should be

    background-position: center center;

You should also try to use jQuery. See http://yulounge.alienworkers.com/photogallery/ for an example.

Healall answered 19/8, 2012 at 8:29 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.