Why would an image that's much smaller than our Website header logo be taking so long to load?

[danatanseo]

When I check http://www.ccisolutions.com at Pingdom, we have a tiny graphic that is taking much longer to load than other graphics that are much bigger. Can anyone shed some light on why this might be happening and what can be done to fix it?

Thanks in advance!

Dana

[danatanseo]

Thanks so much Alan for this great response. While I am not as technically savvy as you and Jason, I knew that I shouldn't 100% rely on Pingdom either, so I am very familiar with the other tools you mentioned and use them routinely.

Since my hands are tied as I have no access to either server or source code. as I mentioned to Jason, I will be taking these suggestions to our IT Director to see how far I can get in addressing these issues.

I am on the PageSpeed warpath, and really appreciate your generous response.

I'll let you know what happens!

Dana

[danatanseo]

Thanks so much Jason,

This is great information. As I do not have access to the server or source code, I am going to take your response, in addition to Alan's to our IT Director and see what kind of actions we can take.

It's a bit of a relief to know that the images aren't our biggest problem.

Your comment about 304's is very timely because last week I was scouring through server log files and noticed quite a few 304's. You've pretty much answered my question on why I found so many of those.

These are all the pains of self-hosting with insufficient staff and know-how to set things up properly. Hoepfully, we can get by with a little help from our friends.

Thanks so much!

Dana

[AlanBleiweiss]

All great info so far. Let me add some considerations.

CSS images - 16 - total file size - 455,806

Quite often a site references images in CSS files that aren't even displayed on some, most or nearly all pages.  They're baked into the CSS style sheet used across part or all of the site.

When this happens, Google crawls all of those images regardless of whether they're displayed.  They do so because it's one of their goals to "discover all the content you have".  Because of that, their crawler has no choice but to make extra calls to the server for every image referenced.

So every call to the server adds to the page speed that matters most to Google rankings. As a result, if a review of those images shows they are not needed on key pages of the site, consider having a different style sheet created for those pages that doesn't include them in the CSS.

Also, while Pingdom helps to detect possible bottlenecks (I use it solely for this reason) it is NOT a valid representation of potential page speed problems as far as Google's system is concerned.  The reason is the Pingdom system does not process a page's content the way the Google system does.  So even if Google Analytics reports a page speed of 15 seconds, Pingdom will routinely report a speed a tiny fraction of that.

While not ideal, I always rely on URIValet.com and WebPageTest.org (the '1st run test, not the "2nd run, because that caches processing) to do my evaluation comparisons.

Where I DO use Pingdom, is when I enter in a URL (be sure to set the test server to a U.S. server, not their European server), when the test has been run, I click over to the "Page Analysis" tab.  That breaks down possible bottleneck points in file types, process types, and even domains (if you have 3rd party service widgets or code that's a big issue sometimes and this will show the possible problem sources).

For example, for your home page, that report shows 73% of even that system's own time was processing images.  And it also shows six domain sources, with 94.49% of the process time coming from your own domain.

Note an interesting thing though - that report also shows 63% of the time was due to "connect" time - meaning more than half of even Pingdom's process was sucked up just connecting wwhich helps reaffirm the notion that if Google has to make many requests of your server, each request has to connect and thus it can add to overall speed.

[retailgeek]

Hey Dana,

Smooshing images is always a best practice, but in your case, I tool a peek at your homepage and your images aren't that poorly optimized.  In your case image optimization is going to save you 30K of 176K in images on your homepage.  (I still wouldn't discourage you from setting up automated image optimization such as smoosh).

Your bigger performance problems are that you aren't using gzip on your CSS or JS files.  Turning on GZip for your .css and .js files would save you 110K out of 236K in text files.

By far the biggest thing you could do to speed up your user experience would be to set a reasonable browser cache for all your static assets.  You're website has many assets that are used on every page the visitsor sees (like all the stuff in your header, footer, and nav).  The browswer should download those files the first time the visitor hists and pages, and then when they go to every other page, the browser should know it's OK to use the local copy rather than going back to the server to see if their is a newer version.  But because their is no browser cache set, the browser is obligated to check with the server every time.  In most cases the browser will get an error 304 error when it asks for the same file again (error 304 means the asset hasn't changed since the last time you ask), so the browser uses the local copy, but all that hand-shaking takes time that you could save if you set browser cache times for all your asset.

GZip is #3 on the SEO Tips article you found, Browser Caching is #1, and those are the two things that are costing your particular homepage the most page performance issues.

-Jason

[danatanseo]

Thanks Charles,

Your comments made me curious for more information because I am sooooo not a graphics person. You sent me in the right direction and I appreciate that. I also found this post here at SeoMoz: http://www.seomoz.org/blog/15-tips-to-speed-up-your-website

Looks like we have some smooshing to do!

Dana