views:

277

answers:

2

I threw together a quick little microsite that you can see at http://monterraauction.com. If you don't have a super-fast connection (and nothing's cached), the very last items to load are the background-images that are used for CSS image-text replacement (primarily, that h1#head at the top, with a 7kb background image). Nothing debilitating, but it looks slightly awkward. And I'm asking this question as a matter of curiosity more than anything else ;) Also, please note that this occurs in Firefox, but not Chrome.

Now, underneath the h1#head I have a jquery.cycle.lite-powered slideshow in div#photo. In the HTML markup there are a total of 13, heavy image files that make up each of the slides. If I remove all but the first slide, then the problem goes away! So the CSS background-images are loading after...those HTML images are done? But here's what's confusing:

I check it out in YSlow...the CSS background-images have a much lower response time than all of the slides in #photo. Right after all the JS files finish loading, in fact. So why aren't they showing up first?

I tried $('#photo img:last-child').load(function() { alert('Locked and Loaded!')});, but the background-images pop up a while before the alert does, so I'm assuming it's not waiting until the last slide has loaded (admittedly I'm a bit of JS noob so maybe I'm just making a wrong assumption).

I also tried commenting out all the jquery.cycle.lite stuff, so that I knew I didn't have any JS manipulating the DOM elements in #photo, but that wasn't the problem. I tried putting all the JS at the bottom of the document, right before </body>, but that didn't work. Lastly, I tried turning off javascript, and of course the css background-image loads way before the images in #photo, so it's definitely a JS thing (amirite?)

I guess the obvious solution here is to mark the slides up as LINKS rather than IMGs, and have Javascript insert those 12 extra slideshow images after the DOM is ready--users without javascript shouldn't need to download the extra images anyways. But again, I'm curious:

Why does removing the extra HTML images from within #photo solve the problem? And why are the CSS background-images showing up after the HTML images have loaded, even though YSlow says the css background-images loaded first? Seeing as how it happens in FF but not Chrome, is it simply a browser issue?

I appreciate any insight you guys could give me!

A: 

What happens if you insert a little script block up at the top of the <head> to pre-load your background images? (Just create new "Image" objects and set the source properties.) I'm not saying that's necessarily a good idea, but it might be an interesting experiment.

(Note that I mean a script block that you intend to be executed at parse time, and not something that sets up a "page ready" handler a la jQuery(function() { ... }).)

Pointy
A: 

Well, I didn't see this issue, even though when I looked at the HTML, all of the <img>s were there. Here's the Net panel for my attempt to reproduce:

SamB
Ah, now that I look at my Net panel (instead of YSlow), it shows that the css background-image is indeed loading after the HTML images (which contradicts what YSlow was telling me--or is Response Time technically different than download time?)Are you using FF 3.6? I guess I should have noted I'm still using 3.5.8 for some plugin compatability, wonder if that affects it.
Kevin C.
AH, yeah, my `User-Agent` is `Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 GTB6 GTBA`. Also, I believe "response time" is from object request to object response, not from page request to object response.
SamB