7

I am using a background image on my home page/landing page that's roughly 112kb and I've noticed my bounce rate being higher.

Is this image beyond the threshold of load vs. appearance?

The reason for the larger size is due to my use of the background-size: cover property. I've optimized the JPEG and this is pretty much the smallest I can get, without looking cheap and pixelated.

Any suggestions or thoughts on image size on landing pages?

See the site here...

It's pretty "across-the-board" when referring to different browsers/operating systems. I also have a separate stylesheet for IE, so that shouldn't be causing this problem.

| improve this question | |
  • Hi Kurzweilguy, welcome to UX.se! Your question, as it stands now is too wide for this forum. Read the FAQ for more details. If you can narrow it down, it will help you get better answers. – rk. May 2 '13 at 19:15
  • 3
    I'm not sure how I could make this any more specific? I simply want to know if using a background image larger than 100kb is accepted by users as common and accepted practice. – kurzweilguy May 2 '13 at 19:20
  • 1
    My bad, I thought you were asking if full screen images are good or not. Anyways, the 100kb size issue is less about UX and more about network. With high speed internet, it doesn't matter as much. With slower (dial up/edge network) connections you need a graceful manner of handling the loading time. – rk. May 2 '13 at 19:23
  • I was suggested to post this question here by a moderator on Stack Overflow, so I assumed this was more relevant to user experience. After all, the difference of milliseconds because of a larger file can ultimately turn away many users. – kurzweilguy May 2 '13 at 19:25
  • 1
    Agree with that, but unless you mention how you're dealing with slower connections there is no particular answer to this question other than "Sure, 100kb is fine" or "No! It's blasphemy!". – rk. May 2 '13 at 19:29
8

The most important thing is here whether page rendering is blocked by the image download (or if the page is incredibly ugly or unusable before images load). In your specific example the rendering isn't blocking anything (though the text shifts a bit for me in Chrome).

Remember that rendering time is more important than total download time; this is "Time to first paint", a more accurate index of what the user sees as a "loaded page". Time to download often ignores that a large amount of the last to download stuff (print style sheets, images, deferred javascript) isn't needed for the page to look ready, or at least for the user to start using it. There's even an index out there now focusing on paint speed.

It's important to note that images generally don't block the loading of the interface in HTML; the HTML document and CSS are loaded first, so images don't block much of the initial page render. IF your image dimensions are specified in the HTML there should be very little redraw upon loading of images.

Watch your loading times; loading time directly affects bounce rate. If possible A/B test and see if no/smaller images and faster loading leads to a better bounce rate. See also my answer here on loading times.

There's no set size, but smaller is better in general of course. Ditching images is a very quick way to boost the speed of websites, though in the case of a landing-page image, dropping the hero image is often unwanted; if you don't show your product/service/item of interest at all, it might not make a great first impression after all.

| improve this answer | |
  • Well to that end, there's nothing more than a nav menu and my copyright info until the image loads. Could that pose a problem? – kurzweilguy May 2 '13 at 19:42
  • Also, is it problematic that this particular image isn't loaded in the HTML, but rather in the CSS? – kurzweilguy May 2 '13 at 19:46
  • 1
    @kurzweilguy well in reality, that's all the site is; a nav menu, the name, and the copyright image. Since the name of the site makes the content obvious enough I dont' think it's a big enough problem that a couple hundred milliseconds are a major problem. – Ben Brocka May 2 '13 at 19:55
2

You can post-load the image to help with the impression of responsiveness. To control your bounce rate you primarily need to focus on getting the interactive page rendered. As long as the image doesn't take more than 2 to 3 seconds to pop in you should be safe.

As with any issue in UX, watch your stats. It's going to depend on your users' expectations more than anything. Be sure to test the speed in all of your major browsers with a good tool like Web Page Test. There can be huge variance between browsers like Chrome and IE.

| improve this answer | |
  • I'm not very familiar with "post-loading" images. Can you elaborate a little? Also, would this be possible without using a library like jQuery? I'd prefer not to load a library to speed up a page load. – kurzweilguy May 2 '13 at 19:35
  • Sorry, I can't speak to the specifics (try SO for that). Essentially, you just use js to inject the background image when the page is sufficiently loaded. – plainclothes May 2 '13 at 19:37
  • In that case, it's probably not an option for me. – kurzweilguy May 2 '13 at 19:39
  • You ought to be able to set the (background) parameters at the end of the page, instead of at the beginning. Not 100% that's possible without loading a library (can't think of an example), but I think it's possible. – David Clarke May 3 '13 at 2:25
1

Since you mentioned it is less than 1 second, it should be acceptable. The user's will notice the delay but not be distracted from the site in that much duration.

Here is the rule of thumb developed by Jackob Nielsen

  • 0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.
  • 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.
  • 10 seconds is about the limit for keeping the user's attention focused on the dialogue. For longer delays, users will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.