Issue: 593 GB bandwidth use in less than a month from inactive Vaultwiki install.

This combination is usually invoked on pages that contain BB-Codes and/or allow AJAX posting. If someone uses some VaultWiki-provided BB-Codes (including autolinks) in a post submitted by AJAX, the Javascript here is the "base" needed in order to dynamically load whatever other content is missing for the BB-Codes to render properly as they appear. Even though the wiki is not visible for non-admins, this does not mean that any of the BB-Codes it provided are not visible.

There are some ways we can tweak this, as I believe I have noticed some cases where AJAX edits/replies are not available yet this code is triggered as though they are. In the cases where there are no AJAX posting functions but that have triggers for this code, it may be possible to tweak those as well, as not all result in a scenario where this code is required. For cases where AJAX is available but the likelihood is low that it will result in a VW-BB-Code anyway, perhaps a smaller, custom version of the script that avoids yui_loader.php initially can be formulated.

Regarding yui_loader.php, as this loads various combinations of Javascript (sort of like how XenForo's proxy.php loads various images), I would expect a high number for this in general. We have a few optimizations in mind for reducing its PHP overhead, such as by moving the most common of its combinations to static files, but this would not have a net effect on bandwidth usage.

The optimizations I've spoken of in this post are a large undertaking, and while it's something we're looking at now coincidentally, it will not be ready for the next release, as it requires going through all of VaultWiki with a fine-tooth comb to find, move, adjust various triggers, and possibly refactoring the base script.

As for the FontAwesome, I am surprised that you have an issue with this if you already have FontAwesome defined by something else. My experience has been that a font will not load from the source file if the system already knows what the font is, such by a previous definition earlier in your style. Actually, when I look at the site waterfall, I see that FontAwesome's source file is only loaded once (at the /vault location, rather than the previously defined location). My expectation would be that if VaultWiki were completely disabled, that it would still load once, but from a different location. Since you already use FontAwesome on your site, you can easily remove the VaultWiki definition by modifying the vw_base.css template, thereby loading from your preferred location. For others who prefer to use the external bootstrap CDN, we can add an admin setting for that.

Also, if your CDN offers lower bandwidth rates, you should consider using the CDN for your wiki assets. Settings > VaultWiki: Site Config > Wiki CDN URL. The CDN should be capable of pulling missing content from your main site automatically; the location it pulls from should be capable of processing PHP (the output of the PHP file to be cached by the CDN).

Fontawesome is loaded from CDN by XFMG already, so there should not be a need for any additional calls:
https://maxcdn.bootstrapcdn.com/font...wesome.min.css
Please add support for using that instead. This will save over 240GB bandwidth per month.

If all resources are served from CDN, then that will reduce costs. But currently they are not. Even though a CDN is set in VW settings.

A general optimization and bandwidth reduction review would be very welcome.
Can yui_loader bandwidth be reduced?

VaultWiki will not load resources from a CDN if you are an admin and debug mode is turned on. This is by design.

Please load my homepage without logging in. You will see /vault/resources/ loaded from my server instead of CDN.

Improved the behavior of Font-Awesome for the next release:

Added a setting to use the third-party maxcdn.bootstrapcdn location.

1. If yes, use the MaxCDN location. Bandwidth saved.
2. If no, is there a CDN URL set?
   
   1. If yes, the font is now loaded via the CDN+yui_loader. yui_loader automatically sets the CORS policy for the cross-domain font include to work in Firefox. The CDN caches the result.
   2. If no, do any of the forum component URLs differ (such as wiki on a different sub-domain)?
      
      1. If yes, load the font via yui_loader. yui_loader automatically sets the CORS policy for the cross-domain font include to work in Firefox. Relies on browser caching.
      2. If no, load the font via its local static file.

Previous versions only loaded the font via the local static file.

Moved the initial yui_loader.php combination (invoked by base.js) to a static file. This has no effect on bandwidth (possibly requires more), but reduces PHP overhead when no CDN is set. This required a small refactor to nearly all existing Javascript files, as YUI's built-in loader does not support using a static file here. This process revealed that a previous major refactor, which would have reduced bandwidth requirements for other Javascript files (not yui_loader), was not applied to all; this has been flagged for a future release.

The only other optimization that might make it into the next release is a suturing of base.js and xf/base.js, which would reduce latency more than bandwidth.

Thanks!

Marking this as Fixed in 4.1.x:

- When the new minify static files option is enabled (default: enabled -- as previous versions shipped with minified files by default), and the user is not an admin with debug mode turned on:
--- files such as base.js and xf/base.js are loaded as a single minified file xf/compiled/base.js

- All remaining JS files that were not already refactored have been refactored. I said this was likely to reduce bandwidth, but this is probably only possible when using minified files.