Legacy Reduce codebase being injected into footer ?

[Adam H]

Hi Guys,

Been looking at optimising our setup over the past week after the decision to develop the setup as our own rather than moving to VB5 or xenforo and looking to reduce the content to code ratio for pages , something ive noticed is the large amount of script being outputted by vbcredits in the footer. Id really like to get rid of it or condense it some how ?

In effect hoping to reduce page size or page requests if it means moving the code into an external file ?

Any tips on what we can do to resolve this with out breaking anything, thought id ask before diving in and looking myself. We have no plans of updating or upgrading anything in the future unless there is a security issue so editing files is fine if needed

 

[Fillip H.]

The JS code currently contains references to phrases, and these references would be broken by simply cutting and pasting the JS into an external file.

I've changed this to a Feature Request so I can look into this further for a future version

 

[Adam H]

I thought that would be the case , so there would be no other way you could see to reduce it before a new version ?

Good to see its being considered for the future however , i see this as a big importance especially with alot of people choosing to stay with vb 4 and/or moving to XF and looking to deduce and refine resource usage and obviously with responsive themes a big thing reducing the amoiunt of crap in VB4 themes is important.

 

[Fillip H.]

Moving the JS code to an external file will not reduce your resource usage by any noticeable degree (if anything, it will increase your bandwidth usage and Apache resource usage as more requests have to be made to Apache for the file) - it will also have no impact on SEO as the JS is already loaded late enough that it's not interfering with any actual content.

The benefit of moving it to an external file is the ability to cache it in the browser, so for repeat visitors they may have a ~5ms reduction in load times.

 

[Adam H]

Yeah , its the caching ability that im looking to achieve to stop it from loading on every single page refresh unless its actually needed , It may seem trivial for such a small amount of load time but our server/sites are horrible for surges of traffic of over 10k UV at a time, when those surges happen every little bit helps with having less requests. Less requests should result in better server response time overall in theory.

 

[Fillip H.]

But the browser will still need to make the request to the web server - a browser's cache doesn't stop that from happening. I know this for a fact, as I've inspected the page load here on DBTech in Chrome's developer tools.

Looking in Chrome's developer tools for this server (keep in mind that we have Google's mod_pagespeed installed so that may account for any discrepancies between your own browser & setup), all JS files are still being requested, but instead of re-downloading them the server returns 304 Not Modified. I would assume that for that to happen, some form of hash of the file is sent by the browser and compared against a stored hash on the web server that is updated on file modification.

This leads me to believe that the less in-line JS you have, the more requests your web server needs to be able to handle per user per page load. If that is the case, and your server is currently struggling with visitor surges, then you may experience an overall detriment of performance as your web server will take longer to process the requests and return 304 Not Modified.

On our server (with an avg. server load of 1.20), it takes approx. 250ms to return 304 Not Modified for a linked JS file. For obvious reasons I don't have any statistics on the page load times without the in-line JS.

Further to that, this would also explain why page speed tools recommend merging JS files - after all, returning 304 for one file is vastly quicker than returning it for twenty.
That being said, I would strongly not recommend attempting to install any such tools on a vB4 forum, as it can (and most likely will) break the JS and certainly interfere with mods.

vB5 features "rollup" files for this particular reason as well.


PS: If you're looking for a new host, I can recommend www.hivelocity.net This is a specialised server set-up (& discount) they've created for us, and buying it also nets you a coupon for 25% off any DBTech products.

If you need something out of the ordinary, their tech team has proven quite capable at analysing needs based on given statistics, so I'm sure they would be able to help you out with something that can weather the digital storm a little bit better

As with the specialised set-up, if you were to contact their sales team for something more tailored, mentioning you're from DragonByte Tech should also net you a discount

 

[Adam H]

, upgrading a server is just working around the problem rather than solving the issue thats causing it. Our server is more than capable of dealing with the traffic and it is only this site that has these issues.

The combination of a couple of heavy mods and vbseo doesnt help but thats something we are over coming in the next phase, Optimising our database and removing poor/slow queries is also in the running but i want to make sure ive done everything i can in the setup/templates/mods to make a difference before going further. Just so i can see a measurable difference in each stage i go through.

I disagree that having the masses of code loaded upon every refresh is less effective than caching it in a file as static content with a header expires set. It may not make much effect for first time users but the more pages they view the less requests will be needed to download that file and content again.

I agree it isnt a good idea to go through all the Google page speed recommendations with VB4, however alot can be accomplished with little effort and is worth doing if you are looking at VB4 as as home for another couple of years at least then i dont mind totally rewriting the theme sorting what i want to use and what i don't