background-image: url(images/whatever.jpg) a separate GET?

[salmobytes]

Every img tag (<img src="xxx.jpg">) in the html source represents a
separate
GET roundtrip between client and server, no?

What about background images in css?
I'm starting to see more and more designs--coming from the
graphics design people--that call for ever increasing numbers of
repeat-x or repeat-y sliver-gradients as div backgrounds. Does each
such
background image require a separate GET to the server?
.....seems like it must.

And if so, lots of fancy css on a webpage will make for a chatty
website,
which, among other things, will degrade performance on high
latency connections, like satellite dishes, etc.

Is there a javascript way to test load times on the client, so you
could test load times for different css schemes, layered over the
same html source?

[Harlan Messinger]

salmobytes wrote:

Every img tag (<img src="xxx.jpg">) in the html source represents a
separate
GET roundtrip between client and server, no?

Yes, except for the ones that are already cached. Depending on the
configuration, the client may send a conditional GET, with the date when
the cached version was retrieved in an If-Modified-Since header, in
which case the server will send a 304 Not Modified response if there has
been no change, saving time and bandwidth.

What about background images in css?
I'm starting to see more and more designs--coming from the
graphics design people--that call for ever increasing numbers of
repeat-x or repeat-y sliver-gradients as div backgrounds. Does each
such
background image require a separate GET to the server?
....seems like it must.

Yes, subject to the comments above about caching.

And if so, lots of fancy css on a webpage will make for a chatty
website,
which, among other things, will degrade performance on high
latency connections, like satellite dishes, etc.

Yes, unless the images on each page are more or less the same ones being
reused, in which case caching will take care of much of it.

>
Is there a javascript way to test load times on the client, so you
could test load times for different css schemes, layered over the
same html source?

I don't think so, but there are tools you can use for this, such as WAPT
from http://www.loadtestingtool.com/. I used the previous version for a
couple of projects and found configuration a little more complicated
than I would have liked (it would have been nice, for example, if steps
could be copied; maybe they *can* be in version 5 and I don't know about
it) but the results were satisfactory, and it does let you time things
like image loading times and tallies bytes downloaded.

>

[Rik Wasmus]

On Mon, 10 Dec 2007 21:02:39 +0100, salmobytes
<Sa***************@gmail.comwrote:

Every img tag (<img src="xxx.jpg">) in the html source represents a
separate
GET roundtrip between client and server, no?

If the UA chooses to fetch that image, and it isn't cached somewhere, yes
indeed.

What about background images in css?

Same thing.

I'm starting to see more and more designs--coming from the
graphics design people--that call for ever increasing numbers of
repeat-x or repeat-y sliver-gradients as div backgrounds. Does each
such
background image require a separate GET to the server?
....seems like it must.

If they are different images, then yes offcourse, everything has to be
retrieved, that's why we don't usually make print quality images for the
web.

Is there a javascript way to test load times on the client, so you
could test load times for different css schemes, layered over the
same html source?

Javacript would not be the most perfect tool to test this, as it is
dependable on the same UA, and can actually slow things down. There is
also a difference between load (getting the content) and render (try to
figure out how to display it) time. I don't know a tool that does what you
want specifically, however, the 'speedreport' at
<http://www.websiteoptimization.com/services/analyze/index.htmlmight
give you some indication of bottlenecks.

And offcourse, while laying out pages, you make sure they:
- display properly without any images whatsoever.
- display properly without any css whatsoever.

... nothing more irritating then waiting for an image to load before you
can read any text..
--
Rik Wasmus

[Jeff North]

On Mon, 10 Dec 2007 12:02:39 -0800 (PST), in
comp.infosystems.www.authoring.stylesheets salmobytes
<Sa***************@gmail.com>
<76**********************************@i29g2000prf. googlegroups.com>
wrote:

>| Every img tag (<img src="xxx.jpg">) in the html source represents a
| separate
| GET roundtrip between client and server, no?
|
| What about background images in css?
| I'm starting to see more and more designs--coming from the
| graphics design people--that call for ever increasing numbers of
| repeat-x or repeat-y sliver-gradients as div backgrounds. Does each
| such
| background image require a separate GET to the server?
| ....seems like it must.
|
| And if so, lots of fancy css on a webpage will make for a chatty
| website,
| which, among other things, will degrade performance on high
| latency connections, like satellite dishes, etc.
|
| Is there a javascript way to test load times on the client, so you
| could test load times for different css schemes, layered over the
| same html source?

If you are using Firefox then download the Firebug plugin.
Once installed and activated you will find a tab labeled Net.
This displays a graph of load times for each item on your page.
It's a quick and dirty way of finding what is loaded, when and how
long it takes.
-- -------------------------------------------------------------
jn******@yourpantsyahoo.com.au : Remove your pants to reply
-- -------------------------------------------------------------