PageSpeed Insights

Hello,

Thanks for notifying us about this, but we’re well aware of that. We haven’t fully optimized the assets at this point which causes larger JavaScript bundles than usual. These kind of optimizations need to take place at the end of the development cycle when all module dependencies have been finalized.

This will be addressed before the release and is a shortcoming of the pre-release version that is currently in use on woltlab.com.

Tests currently yield results in the range of 85-90 depending on the login status and the page being tested. There will be some additional optimizations for the gold release, but most improvements have already been implemented.

We’re looking to achieve results hitting 90 and above. There is a limit to how well you can perform in such synthetic tests but from our experience these last few points do not really make a difference at all. For example our JavaScript bundle contains more modules than being required on a single page request, but might be necessary for other pages. This creates a higher bandwidth usage for a single page visit, but offers great savings when navigating on the site which is something that such a simple test does not cover at all.

Quote from Black Rider

Which still is no best practice and creates an unnecessary overhead.

In theory you are right, but in practice it is not that simple. This is a highly customizable software so there are severe limits of the runtime predictions we can make. We must therefore take the average (or at least, what we predict to be the average) and go with it. Of course, this is solvable on a case-by-case basis, for example, when building a website where you have full control over everything.

For example, we cannot take HTTP/2 and newer for granted, especially with HTTP/1.x there is a fixed limit of 6 concurrent requests to the same origin. If we would load all modules on demand, we could easily hit this limit and cause some serious latency to the responsiveness of the site. Now add in some extra latency on a 3G connection and you’re seriously screwed. Even with HTTP/2 there is a significant cost to this approach and the latency remains an issue for cascading dependencies.

We’re already offering the accelerated guest view which offers even greater savings by allowing for some serious predictions about the components being required at runtime. This can slim down the static bundle significantly, further improving the bandwidth usage.

Last but not least, there are still components that are currently statically bundled but might only be required in some cases. The current module loader does not permit us to easily offload those into standalone bundles that can be loaded on demand which avoids the request cascade of fetching all modules on their own. This is something we’re looking forward to improve but the impact on the inner workings of the module loading is much greater. We’ve already migrated a lot of our vanilla JavaScript bundles to TypeScript and at some point we should be able to get rid of require.js. But this will take a lot of time and effort.

Quote from Grafidea

What do you think about the built-in js.gz and css.gz compression in woltlab? It is possible?

Your web server already takes care of that and does a far better job at it.