Issue: Improve jump/scroll to page section speeds (on page load)

This is likely due to the following waterfall:
- Page loads (documentReady fires)
- vw/base.js sees TOC present, and subsequently requests toc.js
- vw/base.js sees sections present, and subsequently requests section.js
- once toc.js is loaded, TOC links will work.
- once section.js is loaded, it jumps to the vwsec matching the requested anchor if that is actually a wiki section.

Unfortunately, to prevent a phishing technique, the user-generated anchors must be prefixed with vwsec and jumped to using Javascript after the document is ready, rather than using built-in browser or XenForo jumps. However, we may be able to reduce the time of the waterfall after that point. In general though, the timing delay is going to occur for any Javascript functionality, due to lazy-loading. The alternative to lazy-loading is to front-load scripts, which involves loading a lot of scripts when they aren't actually needed (something other requests have asked VaultWiki not to do). So the trick is to find a balance.

Unfortunately, in the case of anchor links, it is not possible to get this from the incoming request when PHP generates the page, because requested anchors are not actually sent to the server. It's only client-side. So we must rely on client-side technology like Javascript only, or we must assume that the toc.js is going to be needed in some cases and load it even if it may not be needed.

In 4.2, we eliminate dependency on YUI and move to JQuery, which is already loaded by XenForo, so there should not be a timing delay based on that. I will see if we can do more.

Two steps you can already take are as follows:
- Make sure your timing tests are not done in debug mode. While in debug mode, you are unable to benefit from some bundled script files that we already provide which reduce latency.
- Make sure you are using a CDN for static wiki assets (Options > VaultWiki: Site Config). This will further reduce latency, and avoid the problem of browsers only being able to load 6 files from the same domain at a time.

In the browser's tools, watch the request waterfall. Any further insight you can provide into the way it is flowing on your site can be helpful in determining the best ways to improve latency that will actually benefit your specific case.

Something that I failed to mention is the tests (1x PC, 1x mobile) were conducted on the vaultwiki.org XF demo, not my own site. I thought this would be fairer as it is closer to a vanilla XF site (except for VaultWiki, of course ) plus you'd know more about its configuration. That does however mean debug mode is a factor to take into consideration.

The steps were: 1) copy a section link to clipboard, 2) open a new browser window in incognito mode, 3) paste URL from clipboard, 4) Press/tap enter/go, 5) Wait for desired wiki section to finish scrolling into view. The recorded time was the duration between 4 and 5 (at the end of the scroll animation).

The specific URL tested was https://www.vaultwiki.org/xf-wiki/in...-XF2#Heading-2.

Looking at the requests on that page, it looks like the scroll in VaultWiki 4.2 will be anywhere from 60-300ms faster, just due to removing the YUI dependency.

However, when I viewed that page using incognito mode, the scroll effect was almost instantaneous for me (less than 1 second after the page was ready). Most of the delay was due to the problem I described (browser maximum requests at 6), which delayed things by close to 0.8 seconds. The script was included in the initial request, not queued later because a section was noticed, so there was no delay from that. It looks like there is little that we can really do to improve this.

This can be reduced in the following ways:
- Not having debug mode active (it was when I viewed the page). I believe this would cut a lot, due to bundling, minified files, in both XenForo and VaultWiki. The delay might be reduced 30% or more.
- Use a CDN for wiki assets that has a different sub-domain from other static assets. (this could cut up to 800ms on the tested page)
- Support HTTPv2 in your web server, and use a browser than supports it. (this could cut up to the same 800ms on the tested page)