Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Caching of javascript (inline)?

Status
Not open for further replies.

DannyTEM

Technical User
Jul 18, 2002
60
GB
Hello All,

I have a question regarding caching with javascript.

Traditionally, banner dispayed on webpages are done so by using a timestamp or random number either clientside using javascript or serverside. This ensures a revisit to a page forces a new banner to be called rather than using a cached version.

In a particular situation, we are using javascript to initially invoke this process using math.random() (it is also done serverside but the clientside version seems to be causing a problem).

If a page with banner code (shown below) is viewed, a link (not the banner) on the page is clicked and then the user views the new page before hitting the back button and returning to the original page, will the javascript shown be re-run or will the browser use a cached version and thus use a cached banner?

<SCRIPT language=JavaScript type=text/javascript>
<!--
var rnd = Math.round(Math.random() * 10000000);
document.writeln('<IFRAME src=" width=468 height=60 scrolling=no allowtransparency=true frameborder=0 marginheight=0 marginwidth=0>\n');
document.writeln('<A href=" target="_blank">\n');
document.writeln('<IMG src=" width=468 height=60 border=0 ismap></A></IFRAME>\n');
//-->
</SCRIPT>

I have been given the explanation below which I am not sure is correct.

" While you're navigating through the site and go back via the back-button (it
is important to go back with the back-button, as it will reload the page
from the cache), the Iframe won't be requested.
This must be a IE bug."

If is the comment about the iFrame not being requested true, and if so will any of the javascript been called /invocoated?

Thanks all,

Dan

Dan Morgan - Sitepoint Mentor (Glenplake)
(20,000+ member webmaster forums)
(Webmaster resources)
 
What you are describing is hardly a bug (although obviously the person feeding back to you seems to think so). Using the back button will not force a page to reload if it already exists in cache.

You could look into invalidating the caching by forcing the http headers to instruct the browser not to cache.

Anyone else?
Jeff
 
Thanks Jeff, I appreciate the reassurance.

Unfortunately we do not have control over individual sites like that in order to setup nocahce directives.

If the back button is used, will the javascript be rerun to take into account the random number and therefore not show a cached banner?

Basically I am keen to know what happens when back is pressed in the above situation. Is the whole page shown from cache or would be processed but a cached baner shown anway and the call to the url be anulled?

The javascript code calls an adserver which in turn calls another banner from an other adserver. The last adserver in the line is using the explanation I quoted to explain why our adserver (the first in the chain) is reporting more impressions they the last.

Many thanks again.

Dan Morgan -
 
I would not expect to see the javascript running to create a new random number when you press the back button.

It's been a long time since I was involved in the adserver business... but I remember we had all manner of issues just like the one you are experiencing.

What if the user had Javascript disabled? I think the adserver at the end of the chain should not be relying on Javascript to provide their banners... but should manage something server-side at their end.

Maybe someone else will have a better suggestion.

Jeff
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top