The Problem
In Chrome some people in our company are experiencing slowness loading some pages. I've profiled this in chrome and I can see there is a task that sits there and does nothing for ~8 seconds:
The actual request is only taking about 24ms to complete the request:
.
Devtools network tab reflects the same results as fiddler.
This has only started happening in the past ~1 month, and slowly more people in the company are experiencing it.
Other Details
Incognito mode has no effect.
Closing all chrome windows fixes it temporarily.
Opening a debug instance of chrome is uneffected.
In the events on the request, there is a huge jump between load events:
Seems to be caused by chrome being open for a long time. I get it a lot less frequently since restarting most days.
Any idea's on what could be causing this?
Update
The requests taking a long time was actually just a symptom of the issue. The real issue is something causing the DOM to freeze. I've tracked it down to be the footer functionality of Kendo grids. Without the footerTemplate being set, the grids load at their normal speed.
We've contacted Telerik, but they haven't had any other reports of a similar issue. I've also tried removing all extensions, analytics, and anti-virus' on our computer's but no change.
The only thing that has seemed to work is changing chrome back to an older version. So it's seemingly connected to the chrome version, and something about DOM updating.
There could be two issues as per your explanation and the screenshot you have posted here.
First, there could be some issue with google-analytics loading.
For performance boost on modern browsers, google has suggested to use Alternative Async Tag.
<!-- Google Analytics -->
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src='https://www.google-analytics.com/analytics.js'></script>
<!-- End Google Analytics -->
https://developers.google.com/analytics/devguides/collection/analyticsjs/#alternative_async_tag
I would recommend you to put this tag at the bottom just before the </body> tag for maximum performance.
Second, there could be some issue with firewall.
Please check with your network administrator if there are any request blocking.
I can't tell what's wrong, but to be sure check if this setting is set to "Online"
Though for an entire company to experience such a thing would be weird... it sounds like something malicious is going on :D, or just some bad network settings.
You could try using another network and see if the problem still happens.
Related
We have deployed an MVC 3 website on an IIS6 box.
Everything runs fine, but the performance is abysmal.
Can anyone help me understand
why am I getting 20 second response times to get a script bundle?
why bundled scripts are not cached by IE even if the Expires header is set?
The site is several times faster in Chrome (I have noticed the cache behaviour is correct), but we cannot force customers to use it.
Any help would be great. I'm kind of wondering if it's a server-side setting that's forcing the bundle recompilation each request, or if it's just IE acting like usual.
Edit: as per comments request, I'm including also the bundle request headers:
If you have different download times for a full reload between the two browsers it could be that you are doing intense computations with a client side framework like angularjs (I have seen big performance differences from highly complex angularjs apps between the two browsers).
If both your browsers show the same download time, it is either a network issue, or a server issue.
The IE caching could be a separate issue, break your problem into two parts - look for the cause of the slow downloads first.
All I can do now is suggest an approach to finding the issue.
Summary of what you know
It looks like you have:
Server sends an Expires header one year from now
When you reload the page (i.e. you don't force a full refresh using Ctrl+F5)
IE doesn't take any notice of the cache header, and when it sends it's new request it doesn't use If-Modified-Since or If-None-Match
Chrome behaves differently and respects the Expires and/or ETag response headers (it doesn't even make the request again for the bundle).
EDIT 1: You also seem to be saying (though it would be good to see a timeline from chrome) that Chrome downloads the files faster, implying it is not a server-side problem. Your latest comment states that Chrome's downloads are also slow. (end edit)
And you also seem to be saying that this behaviour is consistent (i.e. 100 requests in IE, and 100 requests in Chrome show the above behaviour with no deviations).
Approach
You should break this problem into two parts:
Why is the download so slow?
Is there a server-side performance problem? Look for common download times in IE and Chrome, and Firefox (it could be due to bundling/minification/compression on the server).
Is there a network connectivity issue (dropped packets, for instance)? Look for inconsistent download times, Start times, Request times, between requests in a given browser and the same behaviour across all browsers.
Is a script slowing down IE, but not Chrome (this is not uncommon, I maintain legacy sites where the scripts don't run well in IE but do in Chrome) - look at different profile results between browsers.
Why is the javascript not being cached in IE? Troubleshoot (1) first, then worry about this.
It is possible that the two are related, but approaching them separately will be a start. Number 1 is far easier to diagnose that 2, the top references to caching javascript in IE on the web are to prevent it in order to help with development.
Root cause diagnosis
EDIT 1 The first thing to do is try the site from a browser on the server, or very close to the server to see if you have a network issue. (end edit)
Tools like Fiddler, the browser developer tools, timeline and script profiler, and YSlow are your friend. Compare each of the following between Chrome and IE (and see what happens in Firefox as well) and spot the difference. Note: you may need to clear the browser cache between tests.
browser developer tools -> script profile: see if you have a slow running script in IE compared to Chrome
similar analysis in a tool like YSlow (look for comparisons between the two browsers, not script improvements)
request and response headers, and timeline from a normal (i.e. not full reload) page load
request and response headers, and timeline from a full page reload (Ctrl+F5)
Start and Request durations for every js file for a given browser, and between browsers (this may point to network issues)? I note that the Start and Request alone are taking 0.6s and 1s each in IE - that is very very poor performance.
5 requests, and 5 full reloads with cache clearing between (that is, don't chase a ghost - be consistent in your test methodology)
Download times should be no different between Chrome and IE with no scripts actually running so also add a control test. Assuming that your bundle files don't "do anything" (i.e. they contain functions that the page calls rather than kicking off long processes by themselves) then create a blank page in your site which references exactly the same javascript files - not just the bundle, but every single js reference.
With the control test you can compare pure download times and caching behaviour in IE to Chrome, without any client side javascript running (use the developer tools profiler to verify no scripts are running). If your bundle files do kick off long running things, just temporarily disable those things by putting return statements at the top of the script and concentrate only on the download into the browser.
I've got a web service that, like most others, uses js and css files. I use the old trick of appending a version number to the js and css file like; ?v=123 and that gets changed every time we update the service on production.
Now, this works fine on all browsers, except for Chrome. Chrome seems to prefer it's cached version over getting the new one and therefor seems to ignore the appended variable. In some cases, forcing it to refresh cache (cmd+r / ctrl+f5) wasn't enough so I had to go into options and clear out the cache for it to load up the new content.
Has anyone experienced this issue with Chrome? And if so, what was the resolution to the problem?
Chrome should certainly treat requests with varying query strings as different requests; a cached result for style.css?v=123 should never be used for style.css?v=124. If you're seeing different behavior, please file a bug at http://new.crbug.com/ and post the bug ID here.
That said, I'd first check to see whether the page was cached longer than you expected. If a new version of the page itself wasn't downloaded, then it would still be requesting ?v=123 as the HTML wouldn't have changed. If you're sending long-lived cache headers with the page, it's certainly possible that Chrome is caching it more aggressively than you expected. If that's the behavior you're seeing, please star http://crbug.com/8742 for updates.
I had also same experience
You can user Ctrl + Shift + R for cache free browsing in both Chrome + Mozilla.
I have had this experience as well.
I run a membership site which displays content such as "You must be logged in as a Gold member in order to see this content" if they are not logged in or are trying to view content not allowed by their membership level. But even if the user is logged in, the user would still see "You need to log in", due to Google Chrome's aggressive caching. In Firefox, however, it works fine as I test logging in and out of all 5 levels of membership - each displaying the proper content.
While Chrome's caching problem can be solved by clearing the cache every time the user logs in and out, it would be really annoying to take that approach.
I'm totally stumped here, so any ideas would be appreciated.
I have a RichFaces application, which recently became non-functional when used from IE6. The problem began when I included the following line in my main template:
<a4j:loadScript src="resource://jquery.js"/>
This results in the following generated HTML:
<script src="/AgriShare/a4j/g/3_3_3.Finaljquery.js.jsf" type="text/javascript"></script>
By "non-functional" I mean that pages no longer load, b/c the first page appears to hang the browser for a long time, and then all references to jQuery say that the object was not defined. Eventually this appears to put IE6 in a state where further clicks do nothing.
After a lot of trial and error I have established the following:
The app still works in Chrome, Firefox and IE8
The app still works in IE6, if I switch to HTTP. So, the problem appears to be related to HTTPS, which I can't dispose of.
I further narrowed down the problem by trying to manually request 3_3_3.Finaljquery.js.jsf in IE6 address bar. It asks me if I want to save the file (so it can see it is there), but when I say 'Save', it hangs for about 5 seconds and then says:
Internet Explorer cannot download 3_3_3.Finaljquery.js.jsf from [host_name].
The connection with the server was reset.
Doing the same download over HTTP succeeds.
Gradually reducing the size of the file, I noticed that the download eventually succeeds over HTTPS, if I get the files size below ~ 110KB. There is no specific size it works at though. I tried the same trick with prototype.js and it worked at a different size value.
I can't trace the SSL session, b/c I cannot get access to the certificate's private key, so now I have absolutely no clue what to try next.
Any ideas would be greatly appreciated.
Try using Fiddler for debugging. It can handle SSL.
You might also want to consider hosting the server yourself and taking a look at the server log.
The problem was solved by turning off compression of javascript files in Web Cache.
Sounds like the problem might be related to this: http://support.microsoft.com/default.aspx?scid=kb;en-us;327286
An issue has started recently, within Chrome and reportedly Firefox, pages would be loading fine and browsing would be as normal and then suddenly then a page would fail to load (continuing to spin as if loading). The page that fails is often not the same.
If I refresh the page or try to goto another page on the domain within the same browser, the browser doesn't even try to resolve the name or make a connection, and is then unable to load the page.
Swapping to another browser and I am back to browsing the domain normally again, while the original browser(in most cases Chrome) will not load the pages until a restart.
This has happened with 3 different people on 3 different machines in both Chrome and Firefox.
The domain that it is running off has allot of ajax calls within certain pages, I am not sure if the server is tripping out due to the number of requests from the one client...I am not sure.
I am not sure if this is a server, client or script functionality issue, as I can not personally reproduce it. I can do little to debug or work out what is causing this or how to fix it...
As you can see I am not sure of allot with this problem :) so I am throwing it out to stack-overflow in the hope that someone may have had similar experiences or have any directions I could look towards.
Cheers,
Brendan
If the page is making many requests in a short time, your firewall (router) may block it. I've noticed this behavior on my own router, and had to set it to a less restrictive level to make things work.
IE8 has a feature called InPrivate Filtering, which will block scripts it finds on webpages from more than 'n' different sites.
I'm listening to the most recent 'Security Now' podcast which is raving about this feature as being great.
At the very same time I'm screaming NOOO! What the *#&$ -- because my site (as does many many others) includes the following (jQuery + SWFObject). i.e. I'm using Google's CDN to host my jQuery.
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/swfobject/2.1/swfobject.js"></script>
So whats the deal - should I stop usin jQuery and swfobject from a CDN ?
Whats everybody else doing?
**Edit: ** I couldn't find out if they keep a list of 'trusted sites' or not, but according to this from Microsoft the InPrivate filtering is per session. So at least someone has to actively enable it every session.
InPrivate Filtering is off by default and must be enabled on a
per-session basis. To use this
feature, select InPrivate Filtering
from the Safety menu. To access and
manage different filtering options for
Internet Explorer 8, select InPrivate
Filtering Settings from the Safety
menu. To end your InPrivate Browsing
session, simply close the browser
window.
If your site has content that people would not want cached (bank site, porn, or something else "sensitive"), then I would not use an externally hosted file. Or if your site is just totally broken if the file does not load I would consider it. But if your site is anything else, I wouldn't worry about it. I don't think this is a feature most people will use if they want to hide their tracks. And if they really want to, let them deal with the consequences.
This may seem silly but since IE8 is out, why don't you test your site with InPrivate turned on and see how it behaves? Also if you can report back your findings here that would be great :)
It looks like there's a significant chance this will be disabled with InPrivate enabled, but it ultimately depends on each user's browsing habits.
If a user visits 10 sites in regular mode that all link to files from the same third-party domain, links to files on that domain will be blocked when InPrivate is enabled.
So while you won't be able to take advantage of the CDN, you should host files like this yourself if you need them to work reliably.
InPrivate Blocking keeps a record of
third-party items like the one above
as you browse. When you choose to
browse with InPrivate, IE
automatically blocks sites that have
“seen” you across more than ten sites.
You can also manually choose items to
block or allow, or obtain information
about the third-party content directly
from the site by clicking the “More
information from this website” link.
Note that Internet Explorer will only
record data for InPrivate Blocking
when you are in “regular” browsing
mode, as no browsing history is
retained while browsing InPrivate. An
easy way to think of it is that your
normal browsing determines which items
to block when you browse InPrivate.
Disclaimer: I haven't actually tested any of this as I don't have IE8, but the document you linked to is pretty clear about this.
You should host the JS files on your own site.
Here's another reason to host the JS file on your site.
I've always wondered, would it be possible to have a safe fallback in the event the CDN is down/unavailable?
Something like:
<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
<script type="text/javascript">
if (typeof jQuery == 'undefined') {
document.write(unescape("%3Cscript src='local/jquery.min.js' type='text/javascript'%3E%3C/script%3E"));
}
</script>
I think there would be a low percent of people using IE8 (I think), then turning on the option "InPrivate Browsing". Google's CDN somehow says "it has a server near where the user accessing the website is, so that the performance is increased" (not directly quoted). IE has caused me numerous problems in the past, and I dropped support for it.
does it work from the domain name of the site e.g. ajax.googleapis.com or does it resolve the name? if it just logs the domain, couldn't you just wrap it in a CNAME e.g. js.yourdomain.com -> ajax.googleapis.com?