While checking the page speed, Google Page speed suggested me to "Leverage Browser Caching". As I enabled the caching in my MVC application using this code in .config file.
<clientCache cacheControlMode="UseMaxAge" cacheControlMaxAge="7.00:00:00"/>
After this, caching for static content which comes from my own domain is being cached, yet it is working.
However, static resources which comes from external domains are not being cached.
For example:
mydomain.com/content/scripts/somescript.js --> BEING CACHED
http://widget.uservoice.com/ha3YmZucx5RAYmq2cS9qw.js --> NOT BEING CACHED
Google is still suggesting me to "Leverage Browser Caching" for that reason.
How can I enable my application to cache static resources which comes from external domains?
You can't cache static resources from third-party domain; that's not how things work. If there's third-party resources not being cached, that means that third-party has either directly chosen not to employ caching (it may need to be always up-to-date to function properly) or has neglected to implement caching. The only thing you can do about that is submit a ticket to the third-party and ask them to fix it.
Related
I run wordpress site and am using Akamai for caching. I have a link on every page so the user can switch between desktop and mobile site at any point. This link once clicked stores cookie which is passed to server with every request and so server knows if needs to return mobile site or desktop version.
Now when I access via "origin" it all works fine as it skips Akamai caching. However when accessing site as normal, so with Akamai caching, the link doesn't do anything. I'm assuming its because as far as Akamai is concerned its exactly the same url request and as Akamai has already its cached version it returns the same page ignoring the cookie all together.
Is there any way to tell akamai directly from my php files in wordpress not to cache html and do it only for images,css etc?
Or maybe is there a setting in Akamai itself where this can be specified?
If not then what other options would I have to get this working?
Yes there are a number of ways to do this. The easiest way would be to do a no cache on specific file extensions such as .html
You can tweak the files to be or not to be cached in AKAMAI through "Configuration Attributes and Digital Properties" screen.
On "Time To Live Rules", you can define path and their caching policy.
Apart from that if you want to validate if a particular web resource id rendered from AKAMAI or not, you can use Fiddler and a particular PRAGMA header.
Refer link Validate if web resource is served from AKAMAI (CDN)?? for more details.
I found a few different question here that explain how to make sure CSS loads properly without the user being logged in: CSS not being applied on non authenticated ASP.NET page.
Why does this problem only happen in the development environment, and not in production? If the problem is that web.config says that non-authenticated users cannot access the css files, then why does it work fine in production? It seems that in web.config should prevent that access in both production and development.
The answer is simple.
In your dev environment this is the asp.net engine which serves all the content, static and dynamic. Thus, authorization rules apply to both.
In your prod, iis routes dynamic requests to asp.net page handler but requests to static content is handled by iis. Thus, authorization does not apply as the asp.net is not involved in requests to jpgs, csses and other static assets.
If you want a uniform semantics between environments, you'd have to turn on running all managed modules for all requests, this is a setting of your asp.net web application. It routes all requests via asp.net which causes the engine to apply all modules (including the url authorization module) for all requests.
On our web server we want to provide urls that can be used in HTML elements, for displaying user profile pictures.
I could do this in two ways:
put the images on the web server as static resources: mysite.com/user1.jpg
implement an IHttpHandler: mysite.com/images?userid=1
are there any benefits of one method over the other?
Not handling images via ASP.NET but letting IIS deal with them as static content and circumventing the ASP.NET pipeline altogether would be fastest.
Implementing an HttpHandler, apart from requiring code, would require the ASP.NET pipeline to be involved - this takes more resources from the server.
Basically, if the content is static, let it be static and let IIS handle it.
Whilst allowing IIS to handle the images would be easier, it depends on whether or not you want to compress the files as they are sent?
Certain versions of IIS support GZIP compression, thus meaning you can compress the files as IIS serves them, however, older versions of IIS may not, meaning if you need to compress the files, you would have to use an HTTPHandler or similar to compress and serve them.
Let IIS deal with them. Serving images from a handler can take up a lot of resources.
Don't do that unless absolutely necessary.
If your site has a lot of images, this means that many extra requests for Asp.net to handle.
Asp.net needs quite a lot more resources per request than what IIS would need to push out a static file.
I have put my web site through Google's pagespeed test and it has told me to "Leverage browser caching".
I did some research into this and found that I need to enable the content expiration in IIS 6. I did this and set the content to expire every 30 days. I then put my web site through the pagespeed test again and it still came up with the "Leverage browser caching" recommendation.
I have also put the web site through http://web-sniffer.net to see whats coming back and it comes back with Cache-Control: private.
I then tried <%# OutputCache Duration="30" VaryByParam="none" %> in the web form and now it's coming back with Cache-Control: public, max-age=30 which I guess is along the right lines but the google page speed test is still coming back with a list of resources (mostly images) on my web page that have no expiration.
I'm quite confused on this subject. I was under the impression that the web site would inherit from the IIS settings but this wasn't the case until I turned on the outputcache on the page. Is there a way I can get the web site to use the IIS settings or has it got to be done on a page-by-page basis?
Try adding the following to the code-behind in your form:
Response.Cache.SetCacheability(HttpCacheability.Server);
Response.Cache.SetExpires(DateTime.Parse("6:00:00PM"));
http://msdn.microsoft.com/en-us/library/system.web.httpcachepolicy.aspx
HttpCacheability enumeration:
NoCache
Private
Server
ServerAndNoCache
Public
ServerAndPrivate
http://msdn.microsoft.com/en-us/library/system.web.httpcacheability.aspx
Pagespeed probably refers to static resources like js, css, png, gif, etc. files.
By default IIS content expiration do not apply to those files. You need to edit IIS metabase manually.
http://www.galcho.com/Blog/post/2008/02/27/IIS7-How-to-set-cache-control-for-static-content.aspx
I work on a web application in ASP.NET and HTML5. I have a simple page Default.aspx. In its Page_Load handler I call 'Response.Redirect("xxx.aspx"). I also defined a manifest file, Default.appcache as I want my application to work offline (in such case I javascript methods are used for redirection). Browser cached the page as expected but a problem occured - even though server is online, browser uses the cached page. When user enters Default.aspx no call is sent to server. How can I prevent this behavior? I would like the browser to send a normal request to IIS if it is online and use cached page only when server doesn't respond.
I would be grateful for all suggestions.
You can't, pages in the cache are always served from the cache. The only way to update them is update the manifest and force new versions to be downloaded.
If you want one page to be served when online and a different one when offline then you should investigate the FALLBACK section of the manifest. Note that the page which references the manifest is always cached, so you need to set the fallback up on a different pair of pages.