Adding "cache" in Clear-Site-Data slows down page loading - http-headers

I have added "Clear-Site-Data" header with the following directives: "cache", "storage". This causes the page loading time to increase significantly. After removing the "cache" directive, the loading time returns back to normal. I have read in the Mozilla documentation about what all things "cache" clears, but my site does not create any cache as verified from the console debugger. So why does "cache" slow down the page loading?

Related

IHP - Morphdom interfering with other JavaScript (e.g. DyGraph)

I am using IHP and IHP's use of Morphdom and / or Turbolinks seems to interfere with some other JavaScript things when the page isn't a fresh load. This includes things like Elm apps, and in this example, Dygraph:
Uncaught ReferenceError: Dygraph is not defined
at HTMLDivElement.<anonymous> (<anonymous>:51:33)
at Function.each (jquery-3.6.0.slim.min.js:2:3209)
at E.fn.init.each (jquery-3.6.0.slim.min.js:2:1687)
at HTMLDocument.initCharts (<anonymous>:40:25)
at HTMLDocument.dispatch (jquery-3.6.0.slim.min.js:2:42842)
at HTMLDocument.v.handle (jquery-3.6.0.slim.min.js:2:40826)
at Object.e.dispatch (turbolinks.js:5:1411)
at r.notifyApplicationAfterPageLoad (turbolinks.js:6:1175)
at r.visitCompleted (turbolinks.js:6:1800)
at r.complete (turbolinks.js:5:24022)
In this case I am setting up a graph using Dygraph and using the following to try to initiate it upon the Turbolinks loading in:
$(document).on('ready turbolinks:load', initCharts);
which I thought would fix this because it would call the function only when Turbolinks had loaded the page. But this doesn't seem to have helped.
Essentially it seems like the Dygraph js is not loaded before it is called later in the page. This only seems to happen when we come from another page using Morphdom. The temporary fix is to refresh the page when the graphs won't load, but this is definitely not a great long-term solution.
How can I properly load in new JS files in IHP without Morphdom getting in the way? How might we fix such things?

Autoptimize and google insights

I am using autoptimize plugin for wordpress speed.
When i do speed test on google insights its showing the autoptimize files in the errors.
What could be the solution for this.
I am getting autoptimize.js file as error in "Eliminate render-blocking resources"
As well in "Remove unused CSS"
PLease have a look at the snapshot and suggest some solution for this.
There should be a setting in autoptimize to inline and defer itself. That should prevent the error, because I think it will delay any non critical css and js from loading until after the initial page load. But I was just googling about a similar thing and saw a few warnings about what is and is not critical css/js being moved around, so I wouldn't trust it too much.
That css error you have showing can be addressed by either removing the import from the page totally, if that is possible, or maybe split it up and only load the smaller portion needed for that page. So if you check the inline and defer option, and remove that css file by removing the import line, you should be good to go.

Partial view never affects site after upload and IIS reset

I'm including a partial view in one of the pages of my MVC4 site which when deployed, even after a restart of the web site and recycling of the app pool, never seems to affect the site
I'm wondering if this is caching coming into play
I ended up including the content of the partial view in the page iteself and that seems to have worked but I'd rather have the partial view as I'd like to use the view in other parts of the site
The question is, does anyone have any suggestions as to why this might be happening? I've been pulling my hair out trying to get a view to post the correct data, only to realise that some of the hidden inputs are just missing because the partial view has not been refreshed
EDIT:
Ok now I have a need to use this partial view in more than once place. On my dev environment the partial is rendering correctly. Uploading to the server doesn't seem to have any effect, but what's worse, deleting the partial view from the server also has the same issue.
My site still thinks the file is there and complains about the model type passed to the view now (I changed the model type in the view - all working fine on my local dev) - why does it still think the file is there?
I deleted one of the parent views to see if the site carried on working, but as soon as I delete any other file, the site is affected. Why is this particular file giving me trouble? It's as if the server has cached it at the file system level and is supplying the wrong file content to ASP.NET
I'm going to try renaming the file next
Ok so renaming the file appears to have worked.
I didn't try Fals suggestion but I might try that next time, strange behaviour I'm not going to try and understand why at this point!

Solve IE6 static content caching issues on IIS6

I'm currently experiencing problems with static content - most noticeably jQuery datepicker images, but also other static files - which results in images/static content loaded many times - I can clearly see it in IE6 status bar (not to mention SLOW rendering).
The problem and possible solutions seems to be described here: http://www.explainth.at/en/tricks/flickfix.shtml. However, I use IIS6 not Apache, and static files that I don't want to feed through php or asp.
How do I make IE6 cache static images properly? How do I add custom response header for specific files/folders?
Hm, let met re-phrase it. I'm not sure it is caused by the bugs above. Actually, I tried appcmd to apply cacheControlMode/etc and it doesn't seem to work. As far as I remember, IE6 also does not cache for XMLHttpRequest calls? So, the biggest problem that I need to solve is:
in jQuery calendar, moving mouse over image buttons (prev/next) causes them to be reloaded-refreshed
in jQuery dialog, each dialog('open') causes images from theme (like header background) to be re-loaded/refreshed
etc
This link probably gives a better explanation: http://ajaxian.com/archives/internet-explorer-and-ajax-image-caching-woes
How do I solve this - that is, without feeding images through ASP.NET to setup headers?
Thanks everybody for listening, the trick with appcmd seems to work ;-) The problem was that I used jQuery theme from googleapis... which obviously was not affected by appcmd ;-) Moving theme to local folder did the trick. These are the commands:
\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/images" -section:system.webServer/staticContent -clientCache.cacheControlMode:UseMaxAge
\Windows\system32\inetsrv\appcmd.exe set config "Default Web Site/images" -section:system.webServer/staticContent -clientCache.cacheControlMaxAge:"01:00:00"
from http://forums.iis.net/t/1067723.aspx

Secured and unsecured items message in IE

I'm getting "This page contains bothe Secure and Non secure items"message in IE. When I commented the following piece of code from dojo.js.uncompressed.js file, the message is gone.
if(dojo.isIE){
if(!dojo.config.afterOnLoad){
document.write('<scr'+'ipt defer src="//:" '
+ 'onreadystatechange="if(this.readyState==\'complete\'){' + dojo._scopeName + '._loadInit();}">'
+ '</scr'+'ipt>'
);
}
Is that an issue with the dojo? I would like to move the commented code to another custom file so that the dojo framework is not affected. Can you suggest a better way of implementing it.
Thanks.
You would get that error if you're using frames or have external files where some of the files have https URLs while some have http URLs. Assuming, your main page loads up through https, you could try changing:
src="//:"
to:
src="https//:"
the //: is most likely the problem, as I ran into a similar issue with a chunk of javascript code... In internet explorer, the locaiton //: is not secure, so when your page (presumably on an https:// url) loads, IE notes that you've got your main code loading from a secure location, and another script being loaded in from an unsecure location.
The workaround that I came to was to create an empty file in my web root named "blank.html" (though "blank.js" would probably work better in your case) and replace the //: link with "/blank.html". This results in another hit to your webserver, but browser caching will probably make that impact minimal.