Javascript being requested every page load, takes a few seconds to get 304 Not Modified sometimes

[fury]

I've got Firefox 9.0.1 and I've noticed my pages are loading slowly. Exploring with Firebug reveals that the JS files are being requested every time and are waiting on a 304 Not Modified response before letting the page proceed to render. Sometimes this 304 takes a few seconds to arrive (I saw it take 20 seconds once), depending on the speed of the connection, meanwhile the user is sitting there staring at a blank page, stabbing their computer with a spoon.

This occurs very often on viewing a thread, which also loads attachment editor, tiny mce, etc., and thus has a larger number of javascript files to request, increasing the chances of this happening

I understand the merits of having a version number appended to the request, considering that if it ever does change, it would be a troubleshooting headache to leave a notice up to teach people how to hold in shift and reload their browser.

However, the drawback in page load times is frustrating to my users (those to whom it happens, including myself). Does the javascript really change so often as to require the version number query string on every page load?

Is there a way to turn this off in production to prevent browsers from requesting it every time? edit: yep, a couple of them are in page_container_js_head, but removing it from the included JS file script tags requires an edit of library/XenForo/Template/Abstract.php to comment out the foreach that puts it in.

A switch to turn this query string off and on globally would be ideal, as once the javascript does change, it would be handy to force people's browsers to start requesting it again for a brief time.

Alternatively, could it not be appended to the file name of the javascript itself, or used as part of the path name? (js/xenforo/{$xenOptions.jsVersion}/xenforo.js)

 

[Jake Bunce]

Well the version string is a cache buster for when the javascript changes (which it doesn't often). But the 304 response means the file is cached, so this isn't a problem of caching.

The question is, why is your server taking so long to respond? Some additional troubleshooting may be in order, as well as a traceroute to identify any connection problems to the server.

stabbing their computer with a spoon

This is not advisable.

 

[fury]

I will see if I can get some traceroutes from users experiencing the problem, if they still are. As far as I can tell, there isn't anything wrong with the server that makes it take long to respond. I never heard this complaint before I upgraded the board to XF. It was previously vBulletin 3.6.

I've run it through all of the online analyzers I can find and they all report back with a passing grade. Those can't account for a thread page with all the editor JS, though, and I don't think they account for the end user's connection speed, either. With a fast connection, everything is super fast and there are no problems. At home, I have a decent pipe and there's no perceivable delay in page loading. Many other users have also expressed that they have no problems either. A few people do have the problem, though. And at my office, there is a T1 shared between about 50 people. At times, it can get very dialup-like. On a slow connection, requesting any file even if it is 304 is a considerable chunk of each page load.

When I experienced this issue (most often on a thread), my page was a solid color (color of the user bar at the top that shows the links to the admin CP, etc.) for a good 3-5 seconds on average before anything else started showing up. When I looked at the Firebug report after this "delayed page load", it was showing that get request(s) for javascript in the header were blocking the rest of it, even though the browser eventually figures out it's cached from the 304 Not Modified and moves on.

When it's cached it only sends a request for the script when refreshed (F5/button). Because of the cache buster string (naturally - that's what it's supposed to do), the browser always requests it. But because it's javascript, it blocks the page load. It waits to see the 304 response from the server before it fetches what it has in cache and proceeds rendering. Then this process interacts badly with having a slow connection. Perhaps due to the number of external files associated with the page, it is running into a limit of simultaneous HTTP requests, and if a connection has a hiccup, this issue is exaggerated

I tried an addon that put javascript at the end of the body, but that didn't fix it. Once I removed that query string from all the script tags, my slow page loading problem went away, and so did one other person's - will have to check in on the others and see if it improved things for them.

Perhaps a clever RewriteRule can make the browser cache behave normally while still keeping the cache busting behavior of the version string. Maybe rewriting js/xenforo/version/xenforo.js to js/xenforo/xenforo.js and having the JS include point to that path instead of using a query string. I'll try that the next time XF updates JS.