From: FAQ server on 10 Apr 2010 19:00 ----------------------------------------------------------------------- FAQ Topic - Why are my rollovers so slow? ----------------------------------------------------------------------- Images are cached by the browser depending on the headers sent by the server. If the server does not send sufficient information for the browser to decide the image is cacheable, the browser will check if the image has been updated every time you change the src of an image (in some user settings). To overcome this you must send suitable headers. http://www.mnot.net/cache_docs/ The complete comp.lang.javascript FAQ is at http://jibbering.com/faq/ -- The sendings of these daily posts are proficiently hosted by http://www.pair.com.
From: VK on 11 Apr 2010 10:03 On Apr 11, 3:00 am, "FAQ server" <javascr...(a)dotinternet.be> wrote: > ----------------------------------------------------------------------- > FAQ Topic - Why are my rollovers so slow? > ----------------------------------------------------------------------- > > Images are cached by the browser depending on the headers sent by > the server. If the server does not send sufficient information > for the browser to decide the image is cacheable, the browser > will check if the image has been updated every time you change the > src of an image (in some user settings). To overcome this you > must send suitable headers. > > http://www.mnot.net/cache_docs/ Someone should finally remove this IE/NN 4 times silliness from the FAQ. Indeed one can craft server-side img headers in most sick way and with enough of application screw the caching mechanics. Has nothing to do with the rollovers. When NN3 first introduced Image and onmouseover/onmouseout for it, it became hugely cool and popular to make graphics menu with rollover effect. But as at that POD time even 14.4 Kbps was a rare really cool spead, it would lead to inevitable delays for the first pass over the menu items while getting mouse over picture state. To avoid that a precaching mechanics was provided as well: var imgOver = new Image(); imgOver.src = 'some/url'; The latter statement triggered 'some/url' loading and caching right away, so by the time user started roll over the menu at least some if not all mouseover images would be cached and shown immediately. Of course - as usual in the Web - some people found a malicious usage for that for so-called "Cach overflow attacking" by making a bunch of new Image with src pointing to really big files. So the initial functionality "imgOver.src = 'some/url';" equals image precaching had to be blocked. As it was still POD era, rollovers became slow again on the first pass and caused a lot of complains about "my old menu doesn't behave as before" By the connection speed increase this issue became eliminated by itself, as delays became hardly noticeable. Also a workaround became used by caching images over hidden (i)frame instead of imgOver.src = 'some/url'; I vote to remove this urban legend out or at least mark it as a urban legend but leave for a "historical flavor".
From: Garrett Smith on 11 Apr 2010 18:51 VK wrote: > On Apr 11, 3:00 am, "FAQ server" <javascr...(a)dotinternet.be> wrote: >> ----------------------------------------------------------------------- >> FAQ Topic - Why are my rollovers so slow? >> ----------------------------------------------------------------------- >> [...] > I vote to remove this urban legend out or at least mark it as a urban > legend but leave for a "historical flavor". Yeah that question is outdated. The information in the answer still has practical relevance. An Image request can be used for reasons other than rollover. For example, a program that wants to know if the user has disconnected from the Internet can ping a server to check for connection and issue a warning after a period of time that the image has not loaded. In that case, having the image cached would be problem because `onload` would fire for the loading of the cached image in some browsers (though I cannot recall which browsers or versions). So remove or replace with something else relevant? -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Stefan Weiss on 11 Apr 2010 19:52 On 11/04/10 16:03, VK wrote: > On Apr 11, 3:00 am, "FAQ server" <javascr...(a)dotinternet.be> wrote: >> ----------------------------------------------------------------------- >> FAQ Topic - Why are my rollovers so slow? >> ----------------------------------------------------------------------- >> >> Images are cached by the browser depending on the headers sent by >> the server. If the server does not send sufficient information >> for the browser to decide the image is cacheable, the browser >> will check if the image has been updated every time you change the >> src of an image (in some user settings). To overcome this you >> must send suitable headers. >> >> http://www.mnot.net/cache_docs/ > > Someone should finally remove this IE/NN 4 times silliness from the > FAQ. Indeed one can craft server-side img headers in most sick way and > with enough of application screw the caching mechanics. Has nothing to > do with the rollovers. It's not really a frequently asked question, AFAICT, but the pointer to the caching tutorial is useful, and could help to solve similar problems. On the other hand, the FAQ text isn't entirely accurate: | To overcome this you must send suitable headers .... and hope that the UA's cache is enabled and properly configured. Client side caching can only be encouraged, but not forced from the server side. For example, there's an issue with IE6 and IE7 (and possibly IE8, didn't test) where checking the "don't store encrypted pages" (or similar) will completely disable the cache for SSL sites - not only the disk cache, but any kind of caching at all. In this mode, IE will always fetch the rollover images, even if it had just fetched them a few seconds ago. Very annoying. > When NN3 first introduced Image and onmouseover/onmouseout for it, it > became hugely cool and popular to make graphics menu with rollover > effect. But as at that POD time even 14.4 Kbps was a rare really cool > spead, it would lead to inevitable delays for the first pass over the > menu items while getting mouse over picture state. And now, with our mobile devices, we're often back to this "rare really cool spead"... (granted, rollovers usually aren't an issue on mobile devices ;-) > To avoid that a precaching mechanics was provided as well: > var imgOver = new Image(); > imgOver.src = 'some/url'; Somebody is probably going to tell you that Image isn't a standard constructor, and that this is a portability hazard, but to be honest, I can't think of any reasonably modern browser which doesn't support it. If there are any, please feel free to correct me. > Of course - as usual in the Web - some people found a malicious usage > for that for so-called "Cach overflow attacking" by making a bunch of > new Image with src pointing to really big files. > > So the initial functionality > "imgOver.src = 'some/url';" equals image precaching > had to be blocked. As it was still POD era, rollovers became slow > again on the first pass and caused a lot of complains about "my old > menu doesn't behave as before" By the connection speed increase this > issue became eliminated by itself, as delays became hardly noticeable. > Also a workaround became used by caching images over hidden (i)frame > instead of imgOver.src = 'some/url'; What? I never heard about any "cache overflow attack" or any of the other stuff you mentioned, and I certainly wouldn't recommend using a hidden Iframe to preload images (and why should Iframes be immune to this "attack"?). Could you provide a source or citation? -- stefan
From: Richard Cornford on 12 Apr 2010 07:55 On Apr 12, 12:52 am, Stefan Weiss wrote: > On 11/04/10 16:03, VK wrote: >> On Apr 11, 3:00 am, "FAQ server" wrote: >>> ----------------------------------------------------------------- >>> FAQ Topic - Why are my rollovers so slow? >>> ----------------------------------------------------------------- > >>> Images are cached by the browser depending on the headers sent by >>> the server. If the server does not send sufficient information >>> for the browser to decide the image is cacheable, the browser >>> will check if the image has been updated every time you change the >>> src of an image (in some user settings). To overcome this you >>> must send suitable headers. > >>>http://www.mnot.net/cache_docs/ > >> Someone should finally remove this IE/NN 4 times silliness from >> the FAQ. Indeed one can craft server-side img headers in most >> sick way and with enough of application screw the caching >> mechanics. Has nothing to do with the rollovers. > > It's not really a frequently asked question, ... <snip> Since the point of a FAQ is to provide the answers to questions that get frequently asked in order that it is possible for people to quickly find those answers, and so don't need to ask (and so don't need to be given repetitive answers), observing that a question answered in a FAQ is not frequently asked might be no more than testimony that the FAQ is doing its job. >> Of course - as usual in the Web - some people found a malicious >> usage for that for so-called "Cach overflow attacking" by making >> a bunch of new Image with src pointing to really big files. > >> So the initial functionality >> "imgOver.src = 'some/url';" equals image precaching >> had to be blocked. As it was still POD era, rollovers became slow >> again on the first pass and caused a lot of complains about "my old >> menu doesn't behave as before" By the connection speed increase this >> issue became eliminated by itself, as delays became hardly >> noticeable. Also a workaround became used by caching images over >> hidden (i)frame instead of imgOver.src = 'some/url'; > > What? I never heard about any "cache overflow attack" or any of the > other stuff you mentioned, and I certainly wouldn't recommend using > a hidden Iframe to preload images (and why should Iframes be > immune to this "attack"?). Could you provide a source or citation? What is the correct form of citation for; made up off the top of his head? Richard.
|
Next
|
Last
Pages: 1 2 3 Prev: sorry for the link in the footer Next: Javascript Concatenator - has bugs |