Curiously I recently ran a page speed test of index page at http://www.background-checks-systems.com and noticed it responded with 34 http requests due to plenty of image lookups that were not in that page, but rather in other pages of site. A bit perplexed, I further researched as to see why.
It appears that when I merged all css files into one global file, many divisions contained background css images although not rendered by index page, but listed from other pages in the site – it still created unnecessary http requests when robot crawled css file link.
I ran additional test by placing css directly into main page using after getting rid of all unused styles from global css file and amazingly my first view http request went down to 14 from 34, file size decreased by more than half and load time down to 1.061s from 4.32s
Perhaps this method may work for your high-traffic pages (if not, at least your index page) whereby you can still call your css link for formatting while creating in-page head css file for background images.
Logistically it may seem like a bit of work, but keep in mind that is only for pages that contain different image backgrounds. If the same background is used more commonly throughout the site, by all means leave it in your main css file.
Anyone else experience this? or maybe I was just ignorant to this?
Is it possible that something about how you specified the background image triggered them to be downloaded? I’ve never seen CSS elements get downloaded that weren’t actually referenced on the page.
If your CSS is small enough there is no question that inlining it will be faster (at least for first-time visitors). It does mean that you can’t serve it from a CDN and that you will also be serving the CSS to bots that may not need it.
FWIW, WebPagetest isn’t really a “bot” and it isn’t crawling. It is just loading the page in an actual browser and observing what the browser does. I’m assuming the pages that were downloading unexpected resources didn’t have the elements that the css was referring to anywhere on the page which is what has me confused.
I have not been able to duplicate this anomaly again.
To be honest with you, those high numbers of HTTP requests and file sizes where obtained using websiteoptimization.com speed test. Since then, I’ve placed all styles back into main CSS and also changed declaration of index page to HTML5 from XHTML Strict. Got some good numbers back from webpagetest.org and the other site aforementioned.
I’m starting to wonder if the cause of that anomaly would have been mod_pagespeed caching since I had been doing editing prior.
Oddly enough, when I go to /var/www/mod_pagespeed/cache/http,3A I see all domains that I host and a couple of other unknown domains that I do not host in my server (ex. 2Fdn-auctions.com, 2Fanswers.yahoo.com & 2Ftomomanddad.info) mind you, they are not in my vhosts.
Probably worth sending a question over to the mod_pagespeed discussion group. As far as the extra resources go, if the test was done with a site that emulates a browser instead of using a full browser then I wouldn’t be surprised if it downloaded everything it saw in the CSS blindly - I’m a huge proponent of only doing testing with real browsers because that’s the only way you will get the actual site behavior (including javascript execution, DOM manipulation, etc).
[quote=“pmeenan, post:6, topic:615”]
As far as the extra resources go, if the test was done with a site that emulates a browser instead of using a full browser then I wouldn’t be surprised if it downloaded everything it saw in the CSS blindly[/quote]
Further down the page, I see that WSO listed all CSS IMG objects from main stylesheet that are not in index page.
Does Google pagespeed & Yahoo’s Yslow use this same type of browser emulation when calculating page speed? if so, they would be reading non-existent objects in a page which leads me back to original thought of doing on-page CSS inlining of background images.
No, YSlow and Page Speed are browser plugins that run within a real browser (well, technically Page Speed has an SDK so you can hook it up to anything but all implementations I am aware of are with a real browser).
Not sure what Yslurp does. From what I’ve seen published on the web, the Google speed information comes from real users with real browsers that visit your site (that have the Google toolbar installed and have enabled the pagerank information sharing).