using WebResource.axd to reference .js files

[George Ter-Saakov]

I always been using .js files directly thus allowing myself to control
caching of them...

If I add .js files to assembly then reference is looking like this
/DragDropTest/WebResource.axd?d=Zi4hg60qpn9AQZGLKlz2Eg2&t=633331472507562215

It's more convenient to have related .js file as a resource in DLL but
question is:
How big is a runtime penalty for this?


George.

 

[Anthony Jones]

I always been using .js files directly thus allowing myself to control
caching of them...

If I add .js files to assembly then reference is looking like this
/DragDropTest/WebResource.axd?d=Zi4hg60qpn9AQZGLKlz2Eg2&t=63333147250756
2215

It's more convenient to have related .js file as a resource in DLL but
question is:
How big is a runtime penalty for this?

A couple of questions you could answer using www.fiddlertool.com would be:-

a) does that URL remain the same until the the .axd until the axd is
recompiled or does it change more frequently

b) what are headers that affect local caching are sent (ETag, Last-Modified,
Expires, Cache-Control) with the response.

If the URL doesn't keep changing and resonable values are being sent in the
headers then you can be comfortable that most of the time such a resource
request would be handled by a cache rather than invoke the runtime at all.

 

[George Ter-Saakov]

I have done that....

Cons:
1. URLs do get cached by browser.
2. Parameters do not change as long as application is not restarted....
(which is acceptable)

Negs:
1. Browser still sends separate request to check if file was updated. It
does get 304 evrytime though.
2. You can not specify your own header information. IE supports following
header "Cache-Control: max-age=2592000;post-check=36000,pre-check=432000"
this eliminates #1. It's like browser is guaranteed that file will not be
changed for that much of time. Google post-check/pre-check..

Unclear:
Still not clear what would be better (in terms of performance). Hit file
system for static .js file or hit .NET runtime to get resource with
WebResource.axd.

Thanks
George.

 

[Anthony Jones]

I have done that....

Cons:

I think you mean 'Pros', right?

1. URLs do get cached by browser.
2. Parameters do not change as long as application is not restarted....
(which is acceptable)

Negs:

This would be the 'Cons'

1. Browser still sends separate request to check if file was updated. It
does get 304 evrytime though.

Does the request include the pragma: no-cache header. If so you're using
refresh. When using refresh IE will push requests for other static
resources through the cache with the aforementioned header. Also by default
it typically will make use the same approach when first fetching the page in
a session. Therefore you will see this if you close and re-open IE.

Try just navigating to it from another page and see what happens.

2. You can not specify your own header information. IE supports following
header "Cache-Control: max-age=2592000;post-check=36000,pre-check=432000"
this eliminates #1. It's like browser is guaranteed that file will not be
changed for that much of time. Google post-check/pre-check..

Yes any change to the source would result in an new URL (it what I call an
immutable URL) so any single URL will only ever be associated with specific
content.

Unclear:
Still not clear what would be better (in terms of performance). Hit file
system for static .js file or hit .NET runtime to get resource with
WebResource.axd.

Well the static is always going to be quicker but by the looks of it not by
any amount that matters even in extreme circumstances.

 

[George Ter-Saakov]

1. You got it right about Pros and Cons..... I messed up there

2. About 304... You right, I did the test and it turned out browser does not
hit server each time. Only if it was closed and reopened (or F5 was hit).

---------------------------------------------------

With Cache-Control: max-age=2592000;post-check=36000,pre-check=432000 it
does not even send request when it was closed and opened again.
And if you hit F5 then IE rechecks (and caches) files in background thread.

That makes page to appear instantly....

To see it in a work hit this url (open it, IE will cache images, close IE
and open this URL again).
http://www.mspiercing.com/Group/belly-button-rings-38.aspx?SortType=0

I am using the Cache-Control for pictures of items. You will notice that
page just instantly appears (when you hit it second time) with images (it
has a lot of images) as opposed to "conventional" page where IE will show
empty spot until it sends request to the server (even though images were
cached) and gets 304.

I wish I could add those headers to WebResource.axd.

Too bad only IE supports it good this is that IE is about 80% of all
browsers

Thanks
George.