Hi Robert,
From what I can tell, I think that plugin you linked to is mainly
for storing hidden pieces of text that an application can then
programmatically display (instead of loading the text via Ajax,
etc.). I'm not sure that it would really help with image "pre-loading".
CSS background images are cached by the browser the same way that
inline images with an <img> tag are. But the browser doesn't actually
load an image specified in a CSS file unless an element on the page
requires the image. That's why :hover images aren't pre-loaded. They
aren't loaded until the element is actually a member of the ":hover"
pseudoclass. This can cause a crappy delay for "rollover" effects
where the background image changes (but there are good workarounds
for this problem...keep reading).
Also, using a browser with tabs doesn't really have any impact on
caching other than the browser's tabs may make it easier for a user
to saturate their net connection with more "simultaneous" requests
and thus cause pages to load a bit slower (because the pages in the
tabs all trying to load at once).
Below I use the term "object" to refer to any file loaded from a web
server. (.gif, .jpg, .css, .js, .html, etc.).
Browsers will generally request objects from the server (pages,
images, etc.) in the order they appear in the source code. The
browser requests the initial page, but then many sub-requests are
spawned in the browser by the code in the page. This is how the
browser loads the CSS files, JS files and image files, etc.
But, if you have a bunch of background images referenced in your CSS
file(s), those images are not simply loaded in the order they appear
in the CSS files. Instead they are (usually) loaded in the order that
the elements requiring those images appear in your page's source
code. But the background image can't actually be requested unless the
CSS file has already been loaded. So, if a page design uses lots of
background images specified via external CSS files, it is important
to make sure the CSS files are loaded as soon as possible.
I have found that a good way to help prevent background-image lag (on
page load) is to make your CSS files load as the first externally-
referenced object(s) inside your <head> tag. So, I recommend putting
any CSS <link> tags or <style type="text/css">@include(my-css-
file.css)</style> tags inside the <head> BEFORE any javascript-
loading <script> tags. This can help the browser get started on
downloading the images specified in the CSS file(s) even before any
other objects are requested. I have seen big differences in IE 6 page-
rendering performance using this simple technique, especially when
some visual-design-altering scripts are invoked on document.ready().
As a general practice, I now always load my CSS files before any JS
files just to make sure the browser has the CSS rules at the ready
when it starts encountering elements in the <body> that it needs to
render.
In many cases, another way to optimize page loading performance in
general is to REDUCE THE TOTAL NUMBER OF REQUESTS that are required
for a page to fully render. So, let's say you have an HTML page that
loads two external javascript files, and ten background images via
one external CSS file. That would (theoretically) require 14 total
requests to the server (one request for each "object"). Well, what if
you could combine all those CSS background images into a single image
file and then use the "sprite" technique (see below) for displaying
the images? You could reduce the total number of requests to render
the page to just 5.
I highly recommend this ALA article:
http://www.alistapart.com/articles/sprites/
That article changed my life. And incidentally, it is the best
workaround for the "delayed background image load on :hover" problem.
So if you have a link with a background image, instead of actually
changing the background image on :hover to a different image, you
change the *position* of the background image, because the background
image contains BOTH the regular state on the button AND the :hover
state of the button in the same image file. Basically, what was two
separate image files are now just joined into one image file. You can
extend that principle by combining all the separate button images
into one single, large image file. So all your main navigation
buttons could use the same exact background-image file but each one
only shows a portion of the image by repositioning the background
image with a negative position offset. Of course, you also need to
consider whether combining the images into one file makes the total
byte count larger of smaller, so it's helpful to have a basic
understanding of how GIFs and JPEGs are compressed.
Also, another thing to keep in mind for page rendering speed
(especially on busy websites) is that under most circumstances, even
when an object has already been cached by the browser, the browser
will (in most cases) STILL make a request to the server for that
object. It does this to check if the file has changed since the last
time it was cached/downloaded. Essentially, even if the file is
cached by the browser, the browser still asks the server for the file
but it also tells the server how old the cached version it already
has is. 99% of the time, the server will just send a tiny reply
saying, "There is no need to download the object again. You already
have the most recent copy in your cache." Each of these
"unnecessary" requests doesn't use much processing time or net
bandwidth, but they can all definitely add up to noticeable page
rendering differences in most mainstream browsers, even on high-
performance machines with fast net connections.
To help deal with this, there are ways to configure a web server so
that it will instruct the browser to not make these "unnecessary"
requests, but most web servers aren't configured to such a degree.
For example, you can configure Apache to tell the browser not to
bother checking whether files of type ".gif" and ".jpg" have changed
for 3 hours since they were last cached by the browser. On a busy,
commercial website, this can prevent literally millions of extraneous
request negotiations per day and can ultimately lead to faster server
response times because the server isn't wasting cycles (and bytes of
bandwidth) just telling browsers that its files haven't changed since
they last cached them. And it can also reduce page rendering time
because the browser will *instantly* load an object from its cache
instead of checking with the server first for a newer/changed
version. Browser behavior can vary on this front, and the browser can
always be configured by the user to check with the server every time
no matter what the server told it to do. But 99% of the time, this
technique can work well to save processing cycles and bandwidth for
both the server and the browser. Of course the downside is, if you DO
change a GIF or JPEG on the server, then there can be a delay before
users who are browsing your site will actually download the updated
file. So this approach does add a bit of logistical complication that
must be considered carefully.
I'm not sure if any of that answers your questions, but hopefully it
will be helpful to somebody in some way.
Cheers,
-THEO-
On Apr 3, 2007, at 11:57 AM, Robert O'Rourke wrote:
Hi again,
Thanks for the help and explanations with the google maps, thats
all working beautifully now.
As my first time out using jquery I've set up a blend effect
for the css background image of the website I am working on however
on occasion the images aren't ready immediately even after theyve
been loaded previously, in moz at least.
I've found this caching plugin [1] however i'm not sure how to
proceed to make it work with css images. My concern is that the
images are large and loading them all every time a page loads will
make things ridiculously slow.... I'm not too well up on how
browsers cache css background images, especially browsers that use
tabs. I've tried appending the images to the body as they are
loaded so you can switch back to them seamlessly however it doesn't
seem to work. Only the current image and previous image seem to be
stored.
I'd appreciate any hints or links to the details of how browser
caching works so I can learn something else new today =]
[1] http://www.civicactions.com/sites/home2.civicactions.net/files/
jquery.cache_.js_.txt
Thanks in advance,
Rob
ps. apologies for my rambling, I could be way off the mark here...
