"Every time I view the page" should not mean "every time an icon is reused on the page"

RESOLVED DUPLICATE of bug 56599

Status

()

Core
Networking: Cache
P3
minor
RESOLVED DUPLICATE of bug 56599
17 years ago
17 years ago

People

(Reporter: Bob Kanefsky, Assigned: pnunn)

Tracking

Trunk
Future
PowerPC
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Here's a design bug that makes it harder to design pages that load quickly, 
although it does not affect correctness, only performance.

For purposes of deciding whether to use a cached inline image, the loading of a 
page ought to be considered to be happening all at the same time, so that pages 
that use many copies of a single image load quickly, without multiple requests to 
the server. That is, "Every time I view the page" should not mean "make sure that 
an icon used throughout the page didn't change in the two seconds since the page 
started loading.

A classic example would be a site that uses colored balls as bullets. Another 
common example is any stock tracking service that uses many green up-arrows and 
red down-arrows.

On my own site, I draw bar graphs using a 10x1 pixel bar that is stretched out to 
different heights. Works great, and it only loads the image once (all 91 bytes of 
it), but asks for the image a dozen times, getting a 304 response each time but 
the first":

me - - [23/Sep/2000:19:28:09 -0400] "GET /setiathome/c.gif HTTP/1.1" 200 91
me - - [23/Sep/2000:19:28:14 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:15 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:15 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:15 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:15 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:15 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:16 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:16 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:16 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -
me - - [23/Sep/2000:19:28:16 -0400] "GET /setiathome/c.gif HTTP/1.1" 304 -

That's with build id 200092220, MacOS 9, but I strongly suspect it's true on all 
platforms. The above example is from http://roving-mouse.com/setiathome/, but the 
easiest way to see it is to make a test file on a server for which you have 
access to the logs (either that or trace it in the browser somehow).

Updated

17 years ago
OS: All

Comment 1

17 years ago
Pam , this looks related to 56599
Assignee: neeti → pnunn
(Assignee)

Comment 2

17 years ago
How are your prefs set? Do you have them set to test the cache contents
every time  or once per session?
(This info is under Edit/Preferences/Advanced/Cache)
-p
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
(Reporter)

Comment 3

17 years ago
In case it wasn't clear from the summary:
  1. My prefs were set to "Every time I view the page"
  2. Eleven requests were sent for c.gif during one page load.

The desired behavior is never to recheck during the loading of a page.
"Every time" should be interpreted to mean "Check whether the icon
changed since I previously visited the page a minute ago",
not "Check whether the icon changed since an identical one used
on this page was loaded one second ago."

As for Bug 56599, it may or may not be related, but it's different
from this one.  It sounds like the issue there is a background image
that is reloaded on a different page, and is used only once per page.
I suspect this one is a design bug rather than an implementation bug.
(Assignee)

Comment 4

17 years ago
Wellll, actually, you only had one request for the image. The others
were verifying the image was fresh.....
I realize that's not the behaviour you saw in 4.7 and I hope to add 
another pref that allows you to choose to just verify the top document
(the page) when you update rather than verify everthing. 
Unfortunately, this change will not make it into RTM. 

I'm trying to find a way to duplicate the 4.7 behaviour for RTM.
Your point about the same image used repeatedly on a page, like the
use of bullet points is well taken.

I'm marking this as a duplicate of #56599 since its all part of the
same problem.
-p

*** This bug has been marked as a duplicate of 56599 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 5

17 years ago
I just created a page like you described. A simple page with one image
requested 9 times. Set my prefs to verify every time.
And watched my server log.

And I get one 200 for the page and one 200 for the image that was requested
on the page 9 times. I got no 304's for the images.

I suspect the 304's you saw were for images that had been resized.
Every time you resize an image, as far as the image cache is concerned, you
have requested a new image. This makes sense when you realize we save the
images decoded and don't assume all platforms have fast scaling algorithms.

When the request for the same image in different dimensions came in, the 
imglib makes a new request for the image from the network cache. The cache
sees you want an image that has been tagged that you want its freshness
verified. It verifies it and gives the imglib what it has in its network cache.
It has no other way to verify it than go out and check the server.


-pn
You need to log in before you can comment on or make changes to this bug.